Выбор методологии разработки новых программных продуктов зависит от ряда следующих факторов: новизна и новаторство концепции; понимание клиента, что он хочет; понимание поставщика программных продуктов, что хочет клиент. Парадокс заключается в том, что и тот и другой ошибаются с самого начала на этапе формирования идеи. Для того чтобы идея была подтверждена в виде MVP и в дальнейшем развивалась в виде продукта, необходимо выбрать подход и механизмы, направленные на быстрое получение обратной связи от клиента.   В этой статье мы поделимся опытом запуска стартапа в компании — системном интеграторе ОТР2000 с точки зрения выбора и внедрения гибкого подхода к разработке протестированных и
работоспособных программных продуктов. Для перехода к деталям и особенностям внедрения методологии, необходимо понять результаты данной трансформации в контексте жизненного цикла стартапа. Существуют два основных этапа [1]:  Два наших продукта — «ЧАТ СТП» и «ЕЦУ» — прошли первый этап и в настоящий момент имеют дорожную карту развития вплоть до 2022 года. Поставка MVP третьего продукта «Сервисы ИИ» для подтверждения жизнеспособности концепции ожидается к концу 2020-го, после чего будет принято решение о выделении инвестиций для развития и масштабирования.  Теперь по порядку немного о наших продуктах молодого департамента ЦИИ «Центр искусственного интеллекта» в ОТР2000. Продукт «Чат СТП» (неформальное название «Мессенджер»). Данный продукт предназначен для предоставления технической поддержки клиенту в части сопровождения информационных систем в B2B- и B2G-секторе. Мессенджер является дополнительной альтернативой телефонным обращениям и включает в себя кастомизируемый под свои потребности жизненный цикл обработки обращений. Продукт «ЕЦУ» — единый центр управления (неформальное название «Супервизор»). Идея ЕЦУ — обеспечить омниканальность различных ИС заказчика в одной системе для эффективного управления и получения всей доступной информации в одном инструменте. ЕЦУ является мощным аналитическим инструментом в части сопровождения проектов и информационных систем. Продукт «Сервисы Искусственного Интеллекта» готовится к выпуску MVP и представляет собой компоненты по категоризации текста по определенным правилам и поиск решений из базы знаний для ускорения предоставления технической поддержки пользователям и снижения трудозатрат. Нахождение продукта на втором этапе жизненного цикла является интегральной характеристикой с точки зрения общего результата: клиент выделил инвестиции, и стала понятна бизнес-экономическая модель продукта. Чтобы поддерживать интерес клиента к развитию продуктов и тем самым обеспечивать приток инвестиций, мы для себя выявили две основные метрики:  Короткие релизные циклы позволяют быстрее предоставлять клиенту реализованную гипотезу для получения обратной связи в части доставки ценностей и необходимых изменений. Если через пару выпущенных версий клиент понимает, что нужно убрать или изменить определенный функционал, мы, несомненно, делаем это, так как мы не боимся изменений, даже если они поступают в последний момент [2]. Для эффективного управления данными изменениями для наших продуктов налажен релизный цикл, равный в среднем 2 неделям, по результату которого мы выпускаем протестированную и работоспособную версию программного продукта, готовую для установки в продуктивную среду клиента.
Соотношение выпущенных фич с новыми в бэклоге характеризует: Культурная среда компании является началом проведения трансформации в части новых практик и подходов. В нашем случае компания ОТР2000 является системообразующей IT-компанией, надежно закрепившейся на B2G-рынке с 2000 г., и насчитывает около 2500 сотрудников, географически распределенных по всей России и за рубежом. На протяжении 20 лет компания экспоненциально росла в части поддержки и развития своих продуктов, что отразилось в выстраивании жесткой матричной структуры департаментов управления. Данный выстроенный механизм имеет водопадную структуру, и перед тем как выпустить очередную версию продукта, необходимо пройти фиксированные этапы через департаменты. Выпуск работоспособной версии может занимать до полугода, и триггером перехода от одного департамента к другому в основном служит установленная форма отчета с большим количеством подписей. В большинстве случаев сотрудники департамента фокусируют деятельность на подготовке отчетов для приемки результатов своей работы смежным отделом дальше по цепочке. С такой культурной спецификой сложно фокусироваться на потребностях клиента и способах их удовлетворения. Более того, существующие механизмы из-за своей инертности не позволяют быстро апробировать идеи и выпускать MVP для новых продуктов на рынок. В рамках создания молодого подразделения «Центр Искусственного Интеллекта» в ОТР2000 в начале марта, было принято решение апробировать гибкие методики разработки программных продуктов, которые позволяли бы в кратчайшие сроки выпускать работоспособные версии для инкрементного увеличения ценности продукта. Внедрение гибкой методологии началось с идеологической трансформации восприятия сотрудниками своей роли и ее влияния на общий результат в рамках организационной сущности продуктовой команды. Идея продуктовой команды заключается в способности выводить новые продукты на рынок от стадии задумки до выпуска протестированной и работоспособной версии продукта при наличии всех необходимых функциональных ролей и ресурсов.  В продуктовую команду должны входить «для фуллхауза» следующие роли (сразу стоит отметить, что данные роли может выполнять один человек): Становление и развитие продуктовой команды проходило через много этапов, из которых можно выделить следующие основные: Под ритуалом понимается периодическое организационное событие, включающее в себя фиксированный состав участников, направленное на синхронизацию участников в части актуальных и приоритетных задач. Более того, ритуалы играют ключевую системообразующую роль развития продуктовой команды, так как задают правила и форматы взаимодействия членов команды.   Мы успешно апробировали и используем следующие ритуалы в рамках 2-недельного релизного цикла: Ответственным за фасилитацию обозначенных выше ритуалов является скрам-мастер, и в его обязанности входит не только организовать их ритмичность, но и сформировать цели и решаемые задачи в рамках данных ритуалов. Если ритуалы организованы правильно, то задачи решаются последовательно и всегда есть фокус на приоритетных в данный момент вопросах. В целях организации короткого инкрементного релизного цикла мы внедрили CI/CD-подход. Данный подход заключаются в следующих технических и организационных возможностях:  Имея данные возможности, продуктовая команда быстрее определяет проблемы и дефекты при очередном CD, а также устанавливает причинно-следственные связи для их устранения. Для продуктов команд ЦИИ мы в среднем имеем 15 МР и 4 деплоя сборки в день. На картинке проиллюстрирован общий организационной подход в рамках внедрения CI/CD в разрезе управления средой разработки для одной из команд. Отображение данного подходя является базовым, что обеспечивает легкость масштабирования на дополнительные команды и смежные продукты. Единственным критерием внедрения эффективного CI/CD-подхода является полное прохождение жизненного цикла сборки от локального MR отдельного разработчика до установки версии в продуктивную среду силами одной команды. Ответственным за процесс и работы CI/CD составе команды отвечает DevOps-инженер. Существует много моментов, которые мы хотели бы показать в рамках использования и внедрения инструментов разработки продуктов. Однако в этой статье мы лишь подсветим основные инструменты, которые прижились и доказали эффективность:
Управление содержанием — продукты Atlassian (JIRA, Service Desk, Confluence).
Управление CI/CD — Gitlab.
Управление коммуникациями — Discord, Telegram.
Управление развитием команд — Mural. Интересные лайфхаки при использовании инструментов: В заключении хотели бы отметить, что целью статьи является возможность поделиться результатами запуска и развития стартапа с точки зрения внедрения фундаментальных процессов и подходов для непрерывной поставки ценности в виде инкрементов продукта. Приведенные результаты, достигнутые за 6 месяцев, могут служить определённой метрикой для сравнения. Мы как стартап не останавливаемся на месте и решаем следующие стратегические вопросы в рамках развития: Ссылки на источники литературы
[1] — Стив Бланк, Боб Дорф — Стартап. Настольная книга основателя.
[2] — https://agilemanifesto.org/iso/ru/manifesto.html Scrum master