Выбор методологии разработки новых программных продуктов зависит от ряда следующих факторов: новизна и новаторство концепции; понимание клиента, что он хочет; понимание поставщика программных продуктов, что хочет клиент. Парадокс заключается в том, что и тот и другой ошибаются с самого начала на этапе формирования идеи. Для того чтобы идея была подтверждена в виде MVP и в дальнейшем развивалась в виде продукта, необходимо выбрать подход и механизмы, направленные на быстрое получение обратной связи от клиента.
В этой статье мы поделимся опытом запуска стартапа в компании — системном интеграторе ОТР2000 с точки зрения выбора и внедрения гибкого подхода к разработке протестированных и
работоспособных программных продуктов.
Продукты стартапа
Для перехода к деталям и особенностям внедрения методологии, необходимо понять результаты данной трансформации в контексте жизненного цикла стартапа. Существуют два основных этапа [1]:
- Поиск жизнеспособной экономической модели продукта;
- Развитие и масштабирование продукта.
Два наших продукта — «ЧАТ СТП» и «ЕЦУ» — прошли первый этап и в настоящий момент имеют дорожную карту развития вплоть до 2022 года. Поставка MVP третьего продукта «Сервисы ИИ» для подтверждения жизнеспособности концепции ожидается к концу 2020-го, после чего будет принято решение о выделении инвестиций для развития и масштабирования.
Теперь по порядку немного о наших продуктах молодого департамента ЦИИ «Центр искусственного интеллекта» в ОТР2000. Продукт «Чат СТП» (неформальное название «Мессенджер»). Данный продукт предназначен для предоставления технической поддержки клиенту в части сопровождения информационных систем в B2B- и B2G-секторе. Мессенджер является дополнительной альтернативой телефонным обращениям и включает в себя кастомизируемый под свои потребности жизненный цикл обработки обращений.
Продукт «ЕЦУ» — единый центр управления (неформальное название «Супервизор»). Идея ЕЦУ — обеспечить омниканальность различных ИС заказчика в одной системе для эффективного управления и получения всей доступной информации в одном инструменте. ЕЦУ является мощным аналитическим инструментом в части сопровождения проектов и информационных систем.
Продукт «Сервисы Искусственного Интеллекта» готовится к выпуску MVP и представляет собой компоненты по категоризации текста по определенным правилам и поиск решений из базы знаний для ускорения предоставления технической поддержки пользователям и снижения трудозатрат.
Результаты продуктовых команд
Нахождение продукта на втором этапе жизненного цикла является интегральной характеристикой с точки зрения общего результата: клиент выделил инвестиции, и стала понятна бизнес-экономическая модель продукта. Чтобы поддерживать интерес клиента к развитию продуктов и тем самым обеспечивать приток инвестиций, мы для себя выявили две основные метрики:
- Короткие релизные циклы;
- Отношение выпущенных фич к новым в бэклоге;
Короткие релизные циклы позволяют быстрее предоставлять клиенту реализованную гипотезу для получения обратной связи в части доставки ценностей и необходимых изменений. Если через пару выпущенных версий клиент понимает, что нужно убрать или изменить определенный функционал, мы, несомненно, делаем это, так как мы не боимся изменений, даже если они поступают в последний момент [2]. Для эффективного управления данными изменениями для наших продуктов налажен релизный цикл, равный в среднем 2 неделям, по результату которого мы выпускаем протестированную и работоспособную версию программного продукта, готовую для установки в продуктивную среду клиента.
Соотношение выпущенных фич с новыми в бэклоге характеризует:
- Интерес клиента к продукту — красная линия на графике. Данная линия характеризует идеи и гипотезы клиента, которые придают уверенность каждой выпускаемой версии в том, что она будет являться более ценной, чем предыдущая. В случае если линия имеет пологий темп роста, необходимо прилагать больше усилий для вовлечения клиента в процесс разработки продукта.
- Уровень мотивации команд — зеленая линия на графике. Если зеленая линия имеет такой же темп роста, что и красная, это говорит о том, что команда понимает цель и ценность каждой версии и стремится успевать за идеями клиента. Если линия пологая, то необходимо приложить усилия в части формирования и развития команды.
- Уровень декомпозиции — в каждой новой версии мы стремимся выпускать от 5 до 8 новых фич, что позволяет нам иметь релизный цикл, равный двум неделям. Если за релизный цикл выпускается одна большая фича, необходимо задуматься о более детальной декомпозиции.
Становление и развитие продуктовых команд
Культурная среда компании является началом проведения трансформации в части новых практик и подходов. В нашем случае компания ОТР2000 является системообразующей IT-компанией, надежно закрепившейся на B2G-рынке с 2000 г., и насчитывает около 2500 сотрудников, географически распределенных по всей России и за рубежом. На протяжении 20 лет компания экспоненциально росла в части поддержки и развития своих продуктов, что отразилось в выстраивании жесткой матричной структуры департаментов управления. Данный выстроенный механизм имеет водопадную структуру, и перед тем как выпустить очередную версию продукта, необходимо пройти фиксированные этапы через департаменты.
- Департамент бизнес-анализа.
- Департамент проектирования.
- Департамент разработки.
- Департамент тестирования.
- Департамент выпуска версий.
Выпуск работоспособной версии может занимать до полугода, и триггером перехода от одного департамента к другому в основном служит установленная форма отчета с большим количеством подписей. В большинстве случаев сотрудники департамента фокусируют деятельность на подготовке отчетов для приемки результатов своей работы смежным отделом дальше по цепочке. С такой культурной спецификой сложно фокусироваться на потребностях клиента и способах их удовлетворения. Более того, существующие механизмы из-за своей инертности не позволяют быстро апробировать идеи и выпускать MVP для новых продуктов на рынок.
В рамках создания молодого подразделения «Центр Искусственного Интеллекта» в ОТР2000 в начале марта, было принято решение апробировать гибкие методики разработки программных продуктов, которые позволяли бы в кратчайшие сроки выпускать работоспособные версии для инкрементного увеличения ценности продукта.
Внедрение гибкой методологии началось с идеологической трансформации восприятия сотрудниками своей роли и ее влияния на общий результат в рамках организационной сущности продуктовой команды. Идея продуктовой команды заключается в способности выводить новые продукты на рынок от стадии задумки до выпуска протестированной и работоспособной версии продукта при наличии всех необходимых функциональных ролей и ресурсов.
В продуктовую команду должны входить «для фуллхауза» следующие роли (сразу стоит отметить, что данные роли может выполнять один человек):
- Владелец продукта — отвечает за содержание бэклога и видение продукта
- UX/UI — отвечает за дизайн продукта и пользовательский опыт
- Архитектор — отвечает за архитектуру продукта и интеграционные вопросы
- Backend-инженер — отвечает за back продукта
- Frontend-инженер — отвечает за front продукта
- QA-инженер — отвечает за работоспособность продукта
- DevOps — отвечает за выпуск продукта
- Скрам мастер — отвечает за коммуникации и развитие продуктовой команды
Становление и развитие продуктовой команды проходило через много этапов, из которых можно выделить следующие основные:
- Первый этап — «Обнуление». На данном этапе все члены команды должны были забыть старые подходы из того времени, когда они работали в больших департаментах, так как от них теперь не требовались бумаги для перехода из одного этапа на другой. Теперь в команде были все необходимые роли для решения открытых вопросов и развития собственных процессов и подходов.
- Второй этап — «Коммуникации». В одной команде сфокусированы все необходимые роли, скрам-мастер внедрил необходимые ритуалы для поддержки процесса разработки выпуска работоспособных версий продуктов, что упростило коммуникации для решения многих проблем.
- Третий этап — «Роль владельца продукта». Данный этап является самым важным, без него команда не сможет сформироваться и дальше начать развиваться. Понимание и принятие роли владельца продукта должна пройти не только на уровне команды, но также на уровне заказчика и компании в целом.
- Четвертый этап — «Роль скрам-мастера». Скрам-мастер не является руководителем сверху, наоборот, принимая все преимущества модели manager as servant, создает и развивает организационные механизмы разработки продуктов таким образом, чтобы команды ни в чем не нуждались и находились в непрерывном росте и развитии.
Ритуалы в продуктовых командах
Под ритуалом понимается периодическое организационное событие, включающее в себя фиксированный состав участников, направленное на синхронизацию участников в части актуальных и приоритетных задач. Более того, ритуалы играют ключевую системообразующую роль развития продуктовой команды, так как задают правила и форматы взаимодействия членов команды.
Мы успешно апробировали и используем следующие ритуалы в рамках 2-недельного релизного цикла:
- Stand Up — ежедневная 15-минутная встреча, на которой каждый участник команды рассказывает об успехе проделанной работы, блокерах и планах на текущий день. В качестве инструмента используется Kanban-доска.
- Release Planning — двухнедельная 2-часовая встреча, на которой проходит планирование очередной версии продукта, где команда декомпозирует пользовательские истории (user stories) на подзадачи и оценивает сроки реализации в «попугаях». В качестве инструмента используется бэклог продукта.
- Demo — двухнедельная 2-часовая встреча которая проводится после выпуска версии продукта с целью демонстрации нового функционала и получения обратной связи от клиента. В качестве инструмента используется протестированная и работоспособная версия продукта.
- Retrospective — 2-часовая встреча, которая проводится после выпуска 3–4 версий с целью анализа организационных подходов и поиска их улучшений. Результатами данной встречи являются конкретные шаги, направленные на улучшение качества и скорости выпускаемой версии.
Ответственным за фасилитацию обозначенных выше ритуалов является скрам-мастер, и в его обязанности входит не только организовать их ритмичность, но и сформировать цели и решаемые задачи в рамках данных ритуалов. Если ритуалы организованы правильно, то задачи решаются последовательно и всегда есть фокус на приоритетных в данный момент вопросах.
Организация CI/CD релизов
В целях организации короткого инкрементного релизного цикла мы внедрили CI/CD-подход. Данный подход заключаются в следующих технических и организационных возможностях:
- CI (continuous integration) — непрерывная поставка инкремента продукта в виде MR (merge requests) в общий репозиторий программного кода командой продукта.
- CD (continuous deployment) — непрерывная компиляция и сборка продукта из общего репозитория программного кода продукта.
Имея данные возможности, продуктовая команда быстрее определяет проблемы и дефекты при очередном CD, а также устанавливает причинно-следственные связи для их устранения. Для продуктов команд ЦИИ мы в среднем имеем 15 МР и 4 деплоя сборки в день. На картинке проиллюстрирован общий организационной подход в рамках внедрения CI/CD в разрезе управления средой разработки для одной из команд. Отображение данного подходя является базовым, что обеспечивает легкость масштабирования на дополнительные команды и смежные продукты.
| Название окружения |
Назначение |
| local |
Локальная среда разработки отдельно взятого разработчика. В данном окружении разработчик разрабатывает программный код продукта в части только своих, обозначенных задач. По окончании вливает данные изменения ветки /master или /dev в зависимости от выпускаемой версии продукта. |
| /dev |
На среде развития продукта разрабатываются новые фичи (функционал) и происходит непрерывная интеграция изменений в общий репозиторий с дальнейшим разворачиванием очередной версии билда. На данном стенде проводится интеграция компонентов продуктов, а также функциональные, нагрузочные и регрессионные тесты для согласования выпуска версии в PreProd заказчика. |
| /master |
На среде поддержки продукта осуществляется исправление только критических проблем, возникших при эксплуатации ранее выпущенной версии. Перед выпуском на PreProd проводятся только регрессионное тестирование версии. Стоит также отметить, что разница версии в ветках /dev и /master отличаются на инкремент ровно одной версии. Данный подход позволяет выносить версию в Prod по окончании релизного цикла и не зарываться в деталях и проблемах, выпущенных, например, 2 месяца назад. |
| PreProd |
На данной среде проводятся интеграция и отладка выпущенных продуктов со смежными информационными системами, а также интеграционное и регрессионное тестирование для согласования выпуска версии в Prod-среду. В дополнение на данном стенде проводят демонстрацию нового функционала заказчику и фокус-пользователям. |
| Prod |
На данной среде происходит эксплуатация пользователями выпущенных в релиз продуктов. На данном стенде не проводится тестирование. |
Единственным критерием внедрения эффективного CI/CD-подхода является полное прохождение жизненного цикла сборки от локального MR отдельного разработчика до установки версии в продуктивную среду силами одной команды. Ответственным за процесс и работы CI/CD составе команды отвечает DevOps-инженер.
Инструменты продуктовых команд
Существует много моментов, которые мы хотели бы показать в рамках использования и внедрения инструментов разработки продуктов. Однако в этой статье мы лишь подсветим основные инструменты, которые прижились и доказали эффективность:
Управление содержанием — продукты Atlassian (JIRA, Service Desk, Confluence).
Управление CI/CD — Gitlab.
Управление коммуникациями — Discord, Telegram.
Управление развитием команд — Mural.
Интересные лайфхаки при использовании инструментов:
- Управление каждым продуктом осуществляется с помощью двух проектов JIRA:
a. JIRA управления бизнес-требованиями, к которой имеет доступ клиент, генерируя поток новых идей. С использованием данной JIRA заказчик понимает, что TTM (time to market) равно 1 месяц.
b. Производственная JIRA разработки функционала, к которой клиент не имеет доступа, и он понимает, что уровень декомпозиции новых фич позволяет выпускать версии каждые две недели для приемки в разрезе бизнес-требований. - Для каждого из продуктов настроен свой репозиторий, который исключает зависимость продуктов друг от друга для релиза.
- Мы замкнули все внутренние и часть внешних коммуникационных каналов в одном инструменте. Таким образом обеспечивается легкость управления данными коммуникациями через каналы, и все команды находятся в одном информационном поле.
- С помощью webhooks можно с легкостью настроить нотификацию в дискорде в части бизнес-логики использования JIRA. Например, появилось новое требование для продукта в JIRA, нотификация автоматически появляется в нужном канале для привлечения внимания.
- Инструмент Mural является универсальным, и там много встроенных шаблонов для фасилитации встреч; он является палочкой-выручалочкой для каждого скрам-мастера.
Заключение
В заключении хотели бы отметить, что целью статьи является возможность поделиться результатами запуска и развития стартапа с точки зрения внедрения фундаментальных процессов и подходов для непрерывной поставки ценности в виде инкрементов продукта. Приведенные результаты, достигнутые за 6 месяцев, могут служить определённой метрикой для сравнения. Мы как стартап не останавливаемся на месте и решаем следующие стратегические вопросы в рамках развития:
- Внедрение модели продуктовой разработки в рамках заказной.
- Внедрение организационного и технического подхода в части разработки ядра продукта и слоя кастомизации.
- Внедрение масштабируемого фреймворка SAFe на смежные продуктовые команды, которые являются поставщиками продуктов в других компаниях.
Ссылки на источники литературы
[1] — Стив Бланк, Боб Дорф — Стартап. Настольная книга основателя.
[2] — https://agilemanifesto.org/iso/ru/manifesto.html