Сам я бывший 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.
