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

В этой статье мы поделимся опытом запуска стартапа в компании — системном интеграторе ОТР2000 с точки зрения выбора и внедрения гибкого подхода к разработке протестированных и
работоспособных программных продуктов.

Продукты стартапа

Для перехода к деталям и особенностям внедрения методологии, необходимо понять результаты данной трансформации в контексте жизненного цикла стартапа. Существуют два основных этапа [1]:

1. Поиск жизнеспособной экономической модели продукта;
2. Развитие и масштабирование продукта.

Два наших продукта — «ЧАТ СТП» и «ЕЦУ» — прошли первый этап и в настоящий момент имеют дорожную карту развития вплоть до 2022 года. Поставка MVP третьего продукта «Сервисы ИИ» для подтверждения жизнеспособности концепции ожидается к концу 2020-го, после чего будет принято решение о выделении инвестиций для развития и масштабирования.

Теперь по порядку немного о наших продуктах молодого департамента ЦИИ «Центр искусственного интеллекта» в ОТР2000. Продукт «Чат СТП» (неформальное название «Мессенджер»). Данный продукт предназначен для предоставления технической поддержки клиенту в части сопровождения информационных систем в B2B- и B2G-секторе. Мессенджер является дополнительной альтернативой телефонным обращениям и включает в себя кастомизируемый под свои потребности жизненный цикл обработки обращений.

Продукт «ЕЦУ» — единый центр управления (неформальное название «Супервизор»). Идея ЕЦУ — обеспечить омниканальность различных ИС заказчика в одной системе для эффективного управления и получения всей доступной информации в одном инструменте. ЕЦУ является мощным аналитическим инструментом в части сопровождения проектов и информационных систем.

Продукт «Сервисы Искусственного Интеллекта» готовится к выпуску MVP и представляет собой компоненты по категоризации текста по определенным правилам и поиск решений из базы знаний для ускорения предоставления технической поддержки пользователям и снижения трудозатрат.

Результаты продуктовых команд

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

1. Короткие релизные циклы;
2. Отношение выпущенных фич к новым в бэклоге;

Короткие релизные циклы позволяют быстрее предоставлять клиенту реализованную гипотезу для получения обратной связи в части доставки ценностей и необходимых изменений. Если через пару выпущенных версий клиент понимает, что нужно убрать или изменить определенный функционал, мы, несомненно, делаем это, так как мы не боимся изменений, даже если они поступают в последний момент [2]. Для эффективного управления данными изменениями для наших продуктов налажен релизный цикл, равный в среднем 2 неделям, по результату которого мы выпускаем протестированную и работоспособную версию программного продукта, готовую для установки в продуктивную среду клиента.
Соотношение выпущенных фич с новыми в бэклоге характеризует:

1. Интерес клиента к продукту — красная линия на графике. Данная линия характеризует идеи и гипотезы клиента, которые придают уверенность каждой выпускаемой версии в том, что она будет являться более ценной, чем предыдущая. В случае если линия имеет пологий темп роста, необходимо прилагать больше усилий для вовлечения клиента в процесс разработки продукта.
2. Уровень мотивации команд — зеленая линия на графике. Если зеленая линия имеет такой же темп роста, что и красная, это говорит о том, что команда понимает цель и ценность каждой версии и стремится успевать за идеями клиента. Если линия пологая, то необходимо приложить усилия в части формирования и развития команды.
3. Уровень декомпозиции — в каждой новой версии мы стремимся выпускать от 5 до 8 новых фич, что позволяет нам иметь релизный цикл, равный двум неделям. Если за релизный цикл выпускается одна большая фича, необходимо задуматься о более детальной декомпозиции.

Становление и развитие продуктовых команд

Культурная среда компании является началом проведения трансформации в части новых практик и подходов. В нашем случае компания ОТР2000 является системообразующей IT-компанией, надежно закрепившейся на B2G-рынке с 2000 г., и насчитывает около 2500 сотрудников, географически распределенных по всей России и за рубежом. На протяжении 20 лет компания экспоненциально росла в части поддержки и развития своих продуктов, что отразилось в выстраивании жесткой матричной структуры департаментов управления. Данный выстроенный механизм имеет водопадную структуру, и перед тем как выпустить очередную версию продукта, необходимо пройти фиксированные этапы через департаменты.

1. Департамент бизнес-анализа.
2. Департамент проектирования.
3. Департамент разработки.
4. Департамент тестирования.
5. Департамент выпуска версий.

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

В рамках создания молодого подразделения «Центр Искусственного Интеллекта» в ОТР2000 в начале марта, было принято решение апробировать гибкие методики разработки программных продуктов, которые позволяли бы в кратчайшие сроки выпускать работоспособные версии для инкрементного увеличения ценности продукта.

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

В продуктовую команду должны входить «для фуллхауза» следующие роли (сразу стоит отметить, что данные роли может выполнять один человек):

• Владелец продукта — отвечает за содержание бэклога и видение продукта
• UX/UI — отвечает за дизайн продукта и пользовательский опыт
• Архитектор — отвечает за архитектуру продукта и интеграционные вопросы
• Backend-инженер — отвечает за back продукта
• Frontend-инженер — отвечает за front продукта
• QA-инженер — отвечает за работоспособность продукта
• DevOps — отвечает за выпуск продукта
• Скрам мастер — отвечает за коммуникации и развитие продуктовой команды

Становление и развитие продуктовой команды проходило через много этапов, из которых можно выделить следующие основные:

1. Первый этап — «Обнуление». На данном этапе все члены команды должны были забыть старые подходы из того времени, когда они работали в больших департаментах, так как от них теперь не требовались бумаги для перехода из одного этапа на другой. Теперь в команде были все необходимые роли для решения открытых вопросов и развития собственных процессов и подходов.
2. Второй этап — «Коммуникации». В одной команде сфокусированы все необходимые роли, скрам-мастер внедрил необходимые ритуалы для поддержки процесса разработки выпуска работоспособных версий продуктов, что упростило коммуникации для решения многих проблем.
3. Третий этап — «Роль владельца продукта». Данный этап является самым важным, без него команда не сможет сформироваться и дальше начать развиваться. Понимание и принятие роли владельца продукта должна пройти не только на уровне команды, но также на уровне заказчика и компании в целом.
4. Четвертый этап — «Роль скрам-мастера». Скрам-мастер не является руководителем сверху, наоборот, принимая все преимущества модели manager as servant, создает и развивает организационные механизмы разработки продуктов таким образом, чтобы команды ни в чем не нуждались и находились в непрерывном росте и развитии.

Ритуалы в продуктовых командах

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

Мы успешно апробировали и используем следующие ритуалы в рамках 2-недельного релизного цикла:

1. Stand Up — ежедневная 15-минутная встреча, на которой каждый участник команды рассказывает об успехе проделанной работы, блокерах и планах на текущий день. В качестве инструмента используется Kanban-доска.
2. Release Planning — двухнедельная 2-часовая встреча, на которой проходит планирование очередной версии продукта, где команда декомпозирует пользовательские истории (user stories) на подзадачи и оценивает сроки реализации в «попугаях». В качестве инструмента используется бэклог продукта.
3. Demo — двухнедельная 2-часовая встреча которая проводится после выпуска версии продукта с целью демонстрации нового функционала и получения обратной связи от клиента. В качестве инструмента используется протестированная и работоспособная версия продукта.
4. Retrospective — 2-часовая встреча, которая проводится после выпуска 3–4 версий с целью анализа организационных подходов и поиска их улучшений. Результатами данной встречи являются конкретные шаги, направленные на улучшение качества и скорости выпускаемой версии.

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

Организация CI/CD релизов

В целях организации короткого инкрементного релизного цикла мы внедрили CI/CD-подход. Данный подход заключаются в следующих технических и организационных возможностях:

1. CI (continuous integration) — непрерывная поставка инкремента продукта в виде MR (merge requests) в общий репозиторий программного кода командой продукта.
2. CD (continuous deployment) — непрерывная компиляция и сборка продукта из общего репозитория программного кода продукта.

Имея данные возможности, продуктовая команда быстрее определяет проблемы и дефекты при очередном CD, а также устанавливает причинно-следственные связи для их устранения. Для продуктов команд ЦИИ мы в среднем имеем 15 МР и 4 деплоя сборки в день. На картинке проиллюстрирован общий организационной подход в рамках внедрения CI/CD в разрезе управления средой разработки для одной из команд. Отображение данного подходя является базовым, что обеспечивает легкость масштабирования на дополнительные команды и смежные продукты.

Единственным критерием внедрения эффективного CI/CD-подхода является полное прохождение жизненного цикла сборки от локального MR отдельного разработчика до установки версии в продуктивную среду силами одной команды. Ответственным за процесс и работы CI/CD составе команды отвечает DevOps-инженер.

Инструменты продуктовых команд

Существует много моментов, которые мы хотели бы показать в рамках использования и внедрения инструментов разработки продуктов. Однако в этой статье мы лишь подсветим основные инструменты, которые прижились и доказали эффективность:
Управление содержанием — продукты Atlassian (JIRA, Service Desk, Confluence).
Управление CI/CD — Gitlab.
Управление коммуникациями — Discord, Telegram.
Управление развитием команд — Mural.

Интересные лайфхаки при использовании инструментов:

1. Управление каждым продуктом осуществляется с помощью двух проектов JIRA:
   a. JIRA управления бизнес-требованиями, к которой имеет доступ клиент, генерируя поток новых идей. С использованием данной JIRA заказчик понимает, что TTM (time to market) равно 1 месяц.
   b. Производственная JIRA разработки функционала, к которой клиент не имеет доступа, и он понимает, что уровень декомпозиции новых фич позволяет выпускать версии каждые две недели для приемки в разрезе бизнес-требований.
2. Для каждого из продуктов настроен свой репозиторий, который исключает зависимость продуктов друг от друга для релиза.
3. Мы замкнули все внутренние и часть внешних коммуникационных каналов в одном инструменте. Таким образом обеспечивается легкость управления данными коммуникациями через каналы, и все команды находятся в одном информационном поле.
4. С помощью webhooks можно с легкостью настроить нотификацию в дискорде в части бизнес-логики использования JIRA. Например, появилось новое требование для продукта в JIRA, нотификация автоматически появляется в нужном канале для привлечения внимания.
5. Инструмент Mural является универсальным, и там много встроенных шаблонов для фасилитации встреч; он является палочкой-выручалочкой для каждого скрам-мастера.

Заключение

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

1. Внедрение модели продуктовой разработки в рамках заказной.
2. Внедрение организационного и технического подхода в части разработки ядра продукта и слоя кастомизации.
3. Внедрение масштабируемого фреймворка SAFe на смежные продуктовые команды, которые являются поставщиками продуктов в других компаниях.

Ссылки на источники литературы
[1] — Стив Бланк, Боб Дорф — Стартап. Настольная книга основателя.
[2] — https://agilemanifesto.org/iso/ru/manifesto.html