Управление бизнесом как ИТ-проектом

Сам я бывший 1С-программист, еще на «семерке» программировал. Написал два продукта: «Новейший отчет 7.7» и «Rocket Launcher 7.7. Перенос справочников и документов».

Потом я был руководителем проекта, внедрял производственный учет: молочный комбинат, кожгалантерейная фабрика – был наемным РП-шником для бизнеса.

Инфостарт начался с того, что я решил продавать свои разработки через интернет, разместил их и позвал остальных, у кого есть авторские продукты, на общий портал.

Прошло 14 лет, и мы продолжаем развиваться в этом направлении и обрастать дополнительными сервисами.

Что на сегодня Инфостарт, какие сервисы и продукты мы предлагаем? Я собрал небольшой список того, что у нас есть на портале, и что мы разрабатываем.

Сейчас портал представляет из себя «все в одном», но мы планируем разделить все на отдельные сервисы, которые не будут визуально пересекаться между собой. Возможно, у каждого раздела появится отдельный значок, сайт с окружением или домен.

Инфостарт и все наши сервисы растут по выручке: в 2021 году мы достигли 400 млн рублей. У нас 108 штатных специалистов. Это я к к тому, чем приходится мне управлять.

Что же такое управление проектом?

Проект в основном состоит из:

• сбора требований,

• проектирования,

• разработки,

• тестирования,

• документирования,

• обучения,

• ввода в эксплуатацию

• и обратной связи, которая опять превращается в некий сбор требований.

Последовательность может меняться, но так или иначе каждый этап в жизни проекта существует.

Мы можем соотнести этапы управления проектом и управления бизнесом.

Например:

• сбор требований = разработка стратегии;

• проектирование = бизнес-планирование;

• разработка = организация процесса;

• тестирование = оптимизация;

• документирование = разработка регламентов.

• обучение пользователей = обучение сотрудников;

• ввод в эксплуатацию = операционная деятельность;

• обратная связь = анализ показателей (KPI) .

Инструменты и технологии для улучшения процессов

Есть замкнутый цикл Деминга, который иллюстрирует цикличность действий, направленных на улучшение процессов. В соответствии с этим циклом, мы проектируем, исполняем, контролируем и улучшаем процесс

Деминг озвучил этот цикл в пятидесятых годах прошлого века.

Есть картинка из системы качества по ISO. Мы видим тот же цикл Деминга, более детализированный по этапам.

Популярная в ИТ-мире методология DevOps – это реинкарнация цикла Деминга, завернутый в петлю цикл. В виде восьмерки или знака бесконечности, что только подчеркивает непрерывность и бесконечное улучшение процесса или продукта.

Здесь тоже есть планирование, разработка, интеграция, доставка, ввод в эксплуатацию и получение обратной связи.

В современном мире, чтобы выполнять этот замкнутый процесс, есть множество инструментов и технологий. Для каждого из этих этапов существуют свои инструменты. На слайде показаны не все, одних таск-менеджеров может быть сотня.

Но я бы хотел рассказать о том, какими инструментами пользуемся мы в компании Инфостарт. На слайде перечислены инструменты, которыми мы пользуемся в процессе управления и web-разработки (так как наш портал – это web-проект).

Но на инструментах web-разработки я заострять внимание не буду. К тому же у нас есть еще 1С-разработчики, у них свой стек инструментов.

Меня больше интересует этап планирования и получения обратной связи. Поэтому я подробнее расскажу о стеке, который относится к работе управления: как мы управляем проектом или бизнесом Инфостарта с помощью данных инструментов.

Планирование – Google Docs

Во главе угла у нас стоит G Suite: мы используем документы, почту, календарь.

Почему мы пользуемся Google Docs? Я думаю, им все так или иначе пользуются, но не всеми возможностями.

Мы используем Google Docs с 2012 года. Я всех заставил перейти на Google Docs и отказаться от других редакторов.

Вся документация, любой документ внутри компании создается в Google Docs. Это дает множество преимуществ, перечисленных на слайде:

• одна копия документа – мы никогда не пересылаем никаких файлов по почте, всегда имеем одну ссылку на один документ с историей его изменений;

• мультиплатформенность;

• автосохранение;

• права;

• удобный поиск и т.д.

Вся документация по продукту у нас хранится в Google Docs. Жизнь любого проекта начинается и заканчивается в Google Docs.

В Jira для этих целей используется Confluence – там описываются все регламенты и для документация к процессам и продуктам компании, чтобы вся документация была в одном месте.

Google Docs – некий Confluence для проекта в нашем мире. Самое важное, что в Google Docs можно комментировать любой кусок текста, подписаться на изменения, отслеживать, что меняется в документе. Но это ни для кого не новость.

На слайде в качестве примера показана работа с одним из документов, с одним из регламентов нашей компании.

У нас, как и в любой другой компании, есть ряд регламентов, должен знать каждый сотрудник, есть тестирование по этим регламентам и т.д.

Исполнение и контроль – Infostart BPM

После того как зарождается некое требование или стратегия в Google Docs, перед нами стоит задача реализации. Для этой цели мы используем внутреннюю систему управления задачами, которая называется Infostart BPM. Это некий симбиоз CRM, Service Desk, Help Desk, Task и Project Management.

Пока что мы развиваем BPM для своих нужд, но у нас в планах открыть его для всех участников портала, чтобы они тоже могли вести в нем задачи.

Проект развития Infostart BPM мы назвали HyperTask.

Пока что мы планируем предложить эту систему для подключения внутрь нашей системы удаленных исполнителей, партнеров и авторов – чтобы они могли его использовать для управления задачами по техподдержке и разработке.

Почему HyperTask? Основная идея нашего сервиса в том, чтобы мы список задач видели в разных плоскостях. По аналогии с HyperCube, HyperTask – многомерные задачи.

Нам важно видеть список задач в различных представлениях:

• в виде списка;

• дерева;

• Канбан-доски;

• диаграммы Ганта;

• календаря;

• ментальной карты, чтобы узлы ментальной карты могли быть задачами – для выгрузки идей в некую форму.

Возможно, появятся еще какие-то варианты представления списка задач, поэтому HyperTask.

Вот так у нас примерно выглядит обычный список задач.

А так выглядит таблица со списком – здесь есть отборы, возможности для сортировок. Это похоже на список задач в RedMine.

Список задач можно представить в виде древа или ментальной карты. Ментальная карта, конечно, немного по-другому выглядит, но у нас пока что древо и ментальная карта – это одно и то же.

Есть еще диаграмма Ганта, в которой мы можем планировать задачи.

И основной вид списка задач у нас – Канбан-доска, где мы ведем задачи.

Здесь заложены примерно все методологические основы Канбана. Это реальная доска двухмесячной давности с задачами по веб-разработке.

Естественно, задачи мы должны видеть в календаре. У каждого сотрудника есть раскладка напоминаний по задачам.

Но с другой стороны сейчас во всех популярных сервисах CRM и сервисах по управлению задачами – Битрикс 24, Trello, AmoCRM – представление в виде доски Канбан уже стало стандартом де факто.

Причем это практически то же самое, что и воронка продаж. С точки зрения CRM процесс продажи – это воронка, а с точки зрения управления задачами – это Канбан.

Поэтому у нас в этой единой системе HyperTask все процессы, включая процессы CRM представлены в виде канбан-досок.

Сейчас у нас около 20 досок, часть из них мы унифицировали.

Сама задача выглядит так, как показано на слайде:

• служебная информация по задаче;

• участники;

• напоминания;

• дерево проекта – если задача включена в проект или у нее есть подчиненные или родительские задачи;

• если задача – это лид или потенциальная сделка, в ней подключается дополнительная функциональность с точки зрения CRM. Отсюда можно звонить, отправлять и получать email, создавать пользователей, контрагентов и т.д.

Слева в разделе «Мои задачи» видно, из каких пунктов состоит наш BPM, как гибрид CRM и Task-менеджера. Это задачи, напоминания, заказы, звонки, почта, отчеты и т.д.

Постепенно мы откроем эту систему и для сообщества.

Система мониторинга на основе Slack

Также мы активно используем в управлении Slack. Это не только корпоративный мессенджер – благодаря открытому API его очень легко интегрировать с другими сервисами.

Нечто подобное есть в Telegram, но Slack еще более заточен для внутрикорпоративного общения. В нем можно общаться внутри компании, а с внешним миром – нельзя. На первый взгляд это кажется недостатком, но на самом деле это основное преимущество, потому что в Slack можно организовать внутреннее виртуальное пространство для общения.

Благодаря возможностям интеграции с остальными сервисами Slack может выступать как система мониторинга.

• В частности, мы можем получать в Slack все уведомления из BPM-системы. Эта возможность стандартно доступна любым пользователям Инфостарта – в профиле можно подключить отправку уведомлений в Slack, Telegram или Viber, там для этого есть инструкции по подключению. А поскольку все задачи в BPM управляются внутри Инфостарта, все уведомления от BPM попадают в Slack.

• Также в Slack есть некие служебные фиды – например, есть служебный фид «Заказы»: где отображаются заказы с сайта. Есть фид «Поддержка», «Чат» и т.д. Все разбито на разные потоки.

• Плюс у каждого отдела есть группа для общения – виртуальный опен-спейс, внутри которого идет общение, помимо внутренних сообщений друг другу.

• Но Slack – прежде всего средство мониторинга бизнес-процессов. Все задачи проходят по этапам с триггерами – алгоритмами, срабатывающими в момент перемещения с этапа на этап. В эти триггеры заложены дополнительные автоматические задания и уведомления, которые идут в Slack. В будущем мы планируем этот поток дополнительно рассортировать. На среднем скриншоте примерно видно, как SlackBot нас уведомляет об изменениях в тех или иных задачах.

• Плюс у нас есть возможность отслеживать изменение документов Google Docs, на которые подписан.

Я уже говорил, что на этапе сбора требований жизнь задачи начинается в Google Docs. Возможности BPM позволяют нам создать задачу из Google Docs сразу в системе. Например, я комментирую кусок текста, а этот текст превращается в задачу, поставленную на сотрудника.

Далее – если это задача по разработке, то при ее движении по Канбану все изменения в системе (все помещения разработчиков в репозиторий) тоже так или иначе привязываются к этому таску.

Соответственно, после выполнения этой задачи и передачи ее на этап технического документирования, можно дойти до основного документа сбора требований и понять, что было сделано. Логирование идет внутри таска, но исходники задачи, которые превращаются в документацию, находятся в Google Docs

То есть мы должны «протащить» задачу по всему циклу:

• с момента планирования в Google Docs;

• после этапа планирования мы отдаем таск в разработку;

• он должен пройти через всю петлю и вернуться на этап документирования обратно в Google Docs;

• когда задача будет выполнена, можно настроить триггер об этом – тогда в исходный документ добавится комментарий, что данное требование реализовано. Тогда те, кто подписан на изменения в документе, получат уведомление – опять же, если использовать Slack, уведомления о закрытии задачи придут и в Slack.

Надеюсь, мой доклад был полезен, и вы почерпнете из него некоторые идеи. А еще его можно воспринимать как анонс будущих возможностей на сайте.

Всем спасибо за внимание!

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе INFOSTART MEETUP Kazan.