Выбор методологии разработки новых программных продуктов зависит от ряда следующих факторов: новизна и новаторство концепции; понимание клиента, что он хочет; понимание поставщика программных продуктов, что хочет клиент. Парадокс заключается в том, что и тот и другой ошибаются с самого начала на этапе формирования идеи. Для того чтобы идея была подтверждена в виде MVP и в дальнейшем развивалась в виде продукта, необходимо выбрать подход и механизмы, направленные на быстрое получение обратной связи от клиента.
В этой статье мы поделимся опытом запуска стартапа в компании
системном интеграторе ОТР2000 с точки зрения выбора и внедрения
гибкого подхода к разработке протестированных и
работоспособных программных продуктов.
Продукты стартапа
Для перехода к деталям и особенностям внедрения методологии, необходимо понять результаты данной трансформации в контексте жизненного цикла стартапа. Существуют два основных этапа [1]:
- Поиск жизнеспособной экономической модели продукта;
- Развитие и масштабирование продукта.
Два наших продукта ЧАТ СТП и ЕЦУ прошли первый этап и в настоящий момент имеют дорожную карту развития вплоть до 2022 года. Поставка MVP третьего продукта Сервисы ИИ для подтверждения жизнеспособности концепции ожидается к концу 2020-го, после чего будет принято решение о выделении инвестиций для развития и масштабирования.
Теперь по порядку немного о наших продуктах молодого департамента ЦИИ Центр искусственного интеллекта в ОТР2000. Продукт Чат СТП (неформальное название Мессенджер). Данный продукт предназначен для предоставления технической поддержки клиенту в части сопровождения информационных систем в B2B- и B2G-секторе. Мессенджер является дополнительной альтернативой телефонным обращениям и включает в себя кастомизируемый под свои потребности жизненный цикл обработки обращений.
Продукт ЕЦУ единый центр управления (неформальное название Супервизор). Идея ЕЦУ обеспечить омниканальность различных ИС заказчика в одной системе для эффективного управления и получения всей доступной информации в одном инструменте. ЕЦУ является мощным аналитическим инструментом в части сопровождения проектов и информационных систем.
Продукт Сервисы Искусственного Интеллекта готовится к выпуску MVP и представляет собой компоненты по категоризации текста по определенным правилам и поиск решений из базы знаний для ускорения предоставления технической поддержки пользователям и снижения трудозатрат.
Результаты продуктовых команд
Нахождение продукта на втором этапе жизненного цикла является интегральной характеристикой с точки зрения общего результата: клиент выделил инвестиции, и стала понятна бизнес-экономическая модель продукта. Чтобы поддерживать интерес клиента к развитию продуктов и тем самым обеспечивать приток инвестиций, мы для себя выявили две основные метрики:
- Короткие релизные циклы;
- Отношение выпущенных фич к новым в бэклоге;
Короткие релизные циклы позволяют быстрее предоставлять клиенту
реализованную гипотезу для получения обратной связи в части
доставки ценностей и необходимых изменений. Если через пару
выпущенных версий клиент понимает, что нужно убрать или изменить
определенный функционал, мы, несомненно, делаем это, так как мы не
боимся изменений, даже если они поступают в последний момент [2].
Для эффективного управления данными изменениями для наших продуктов
налажен релизный цикл, равный в среднем 2 неделям, по результату
которого мы выпускаем протестированную и работоспособную версию
программного продукта, готовую для установки в продуктивную среду
клиента.
Соотношение выпущенных фич с новыми в бэклоге характеризует:
- Интерес клиента к продукту красная линия на графике. Данная линия характеризует идеи и гипотезы клиента, которые придают уверенность каждой выпускаемой версии в том, что она будет являться более ценной, чем предыдущая. В случае если линия имеет пологий темп роста, необходимо прилагать больше усилий для вовлечения клиента в процесс разработки продукта.
- Уровень мотивации команд зеленая линия на графике. Если зеленая линия имеет такой же темп роста, что и красная, это говорит о том, что команда понимает цель и ценность каждой версии и стремится успевать за идеями клиента. Если линия пологая, то необходимо приложить усилия в части формирования и развития команды.
- Уровень декомпозиции в каждой новой версии мы стремимся выпускать от 5 до 8 новых фич, что позволяет нам иметь релизный цикл, равный двум неделям. Если за релизный цикл выпускается одна большая фича, необходимо задуматься о более детальной декомпозиции.
Становление и развитие продуктовых команд
Культурная среда компании является началом проведения трансформации в части новых практик и подходов. В нашем случае компания ОТР2000 является системообразующей IT-компанией, надежно закрепившейся на B2G-рынке с 2000 г., и насчитывает около 4000 сотрудников, географически распределенных по всей России и за рубежом. На протяжении 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-часовая встреча, которая проводится после выпуска 34 версий с целью анализа организационных подходов и поиска их улучшений. Результатами данной встречи являются конкретные шаги, направленные на улучшение качества и скорости выпускаемой версии.
Ответственным за фасилитацию обозначенных выше ритуалов является скрам-мастер, и в его обязанности входит не только организовать их ритмичность, но и сформировать цели и решаемые задачи в рамках данных ритуалов. Если ритуалы организованы правильно, то задачи решаются последовательно и всегда есть фокус на приоритетных в данный момент вопросах.
Организация 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