Развитие продукта в общем цифровом пространстве

Стартапы часто сталкиваются с проблемами и вызовами, которые требуют гибкого управления. Задача руководителя – приведение организации на путь устойчивого развития.
В статье Артём Варкулевич, CEO и основатель стартапа Онтонет, руководитель отдела бизнес-архитектуры с 20-летним стажем в ИТ, расскажет, как подходы системной инженерии и онтологическая платформа поддерживают гибкие подходы к разработке в стартапе. Похожие проблемы роста существуют и в историях корпоративных команд.
Статья подводит технологический задел под существующие процессы и показывает, как обеспечить команды инструментарием управления разработкой.

Стартапы часто сталкиваются с проблемами и вызовами, которые требуют гибкого управления. Задача руководителя – приведение организации на путь устойчивого развития.
Для этого необходимо пройти через пять уровней организационной зрелости:

Мы – разработчики специализированного продукта, платформы построения онтологических моделей “Онто”, предназначенной для свободного моделирования систем в визуальной среде. При разработке Онто мы активно используем возможности самой платформы, гибкие технологии и MBSE.

MBSE (Model-Based Systems Engineering) — это подход к системной инженерии, который фокусируется на создании и использовании моделей системы как основного средства разработки, анализа, верификации и валидации в процессе разработки системы. В отличие от традиционных методов, которые часто опираются на обширные текстовые документы, этот подход предлагает более эффективный и структурированный способ обработки сложных систем. Модели являются единственным источником информации о продукте, что упрощает коммуникацию и позволяет быстрее выявлять и исправлять ошибки. Они позволяют проводить детальный анализ системы и симуляции для определения ее эффективности и соответствия требованиям, повышая качество и прогностические способности процесса разработки.

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

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

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

Информационные связи в это время отличаются спонтанностью и непоследовательностью. Процессы впервые возникают как реакция на новую задачу. Команда создает MVP, а в качестве управления задачами используются любые трекеры, например, Jira, Trello или Kanban-доска на Miro.

Компании активно используют информационные системы для сбора, хранения и обработки данных. Это может быть контактная информация о клиентах, данные о контрактах, предоставляемых услугах и так далее.

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

То, что разработчики, аналитики, руководитель проекта и другие участники процесса разработки не видят тех реальных ценностей, которые приносит результат их труда, очень сильно снижает уровень команды в целом, снижая осознанность процесса и вклада каждого участника.
А осознанность всех участников команды позволяет запускать внутренние процессы вовлеченности и повышения эффективности разработки.

Мы пришли к пониманию, что главная ценность любой информационной платформы – не просто накопление знаний, а накопление знаний в виде модели связанных элементов. Отдельные инструменты не дают возможности интегрировать все имеющиеся данные. Исходя из этой потребности, мы поставили перед собой задачу разработки среды свободного моделирования для построения сложных систем.

Так появилась платформа Онто, которая позволила за полгода с нуля построить в команде управляемые процессы и перейти на второй уровень зрелости — повторяемость процессов, практически не останавливаясь на первом.

Чтобы было легче разобраться в нашем частном использовании некоторых терминов привожу их список в небольшом словарике:

Наш процесс отличается от тех команд, которые вынуждены заниматься поддержкой продукта с использованием разных инструментов.

Так как наша цель — это не только клевая онтологическая платформа, но и тот профессиональный рост, который мы можем обеспечить друг другу.
И это значит, что одна из целей это — “ненапряжная” разработка, а не добиться того, что происходит во многих коммерческих командах, когда в команде растут напряжение и усталость. Как друг от друга, и от того результата, который они добиваются. За 20 лет я видел десятки таких выгоревших команд. А это значит, что основной упор мы делаем на формирование адекватно наполненных задачами спринтов. А сама платформа Онто стала для нас центральным инструментом для управления задачами, спринтами и интеграцией команды.

Эволюция команды

Чуть больше чем полгода назад мы стали вести в Онто задачи. Но мы быстро поняли, что просто списка задач недостаточно – и у каждой задачи появился жизненный цикл. Задачи стали меняться, у них появились состояния. Задача могла быть назначена исполнителю, выполнена и так далее. Для выполнения цикла работ мы описали исполнителей и спринты в нашей сети.

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

Раньше мы регистрировали баги средствами GitHub. Но мы увидели, что задачи были привязаны к одному спринту. Среди них мы не видели те задачи, которые решают разработчики, закрывая баги. Это плохо сказывалось на общей оценке и управляемости процесса планирования и разработки.

Тогда мы стали вести в Онто баги и задачи на закрытые баги. Теперь все задачи складывались в спринт. У нас появились исполнители, спринты, жизненный цикл задач и баги, и у багов тоже появился свой жизненный цикл.

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

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

Я считаю, что визуализация данных – важная составляющая, потому что практически 90% информации мы воспринимаем при помощи зрения.

Реестр возможностей позволяет нам наполнять бэклог задач для реализации. Порой даже слишком агрессивно.

Получив реестр возможностей и предложений, я уже как владелец продукта занимаюсь их приоритезацией. В этот процесс я всегда вовлекаю команду. Возможности при этом делим на 4 части:

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

2. Быстро реализуемая и полезная пользователям «Возможность»

3. Сложно реализуемая, но полезная для пользователей «Возможность».

4. Рутина

В спринте мы обязательно берем в разработку одну большую «Возможность», которая для нас станет инновационным базисом. А так же хотя бы одну историю, развивающую одно из заложенных ранее инновационных направлений. Обязательно берем несколько возможностей, которые реализуются быстро. Не меньше чем 20% загрузки команды оставляем на исправление багов.

В блок “Рутина” мы заглядываем достаточно редко. Там нет багов, так как с ними мы работаем отдельно, но иногда есть истории, которые требуют завершения, но особую пользу это не принесет.

После ранжирования возможностей мы делаем архитектурный скетч для каждой возможности, признанной достойной внимания. На скетче мы фактически проектируем то, какие компоненты нашей платформы должны быть изменены. На этом шаге мы сразу определяем, какие навыки нам понадобятся для того, чтобы закрыть ту или иную фичу. Достаточно ли нам будет только фронтенд-разработчиков или разработчиков бэкенда, потребуется ли привлекать специалистов из бизнес-анализа, системного анализа или нашего UX/UI. Таким образом, мы понимаем, какие ресурсы нам нужно подключить для решения этой задачи.

Мы берем “Возможность” в работу и передаем ее в команду развития только при условии детальной проработки: есть дизайн, отсутствуют блокеры из других веток реализации. Только в этом случае команда уже не останавливаясь, может довести эту историю до конца.

Получается, что наши задачи максимально декомпозированы, и мы можем проследить весь путь от задачи до предложения. Любой из участников нашей команды может пройти этот путь вверх и посмотреть, какое предложение было изначально, откуда появилась такая задача. Это способствует развитию, во-первых, внутренней осознанности команды, а во-вторых, пониманию своего места в ней. Это сильно помогает в командно-образовательном процессе, потому что мы все понимаем ценность тех задач, которые мы делаем.

Итак, в нашем процессе разработки появились такие связанные сущности как «Возможность”, “Эпик”, “Пользовательская история”, “Задача”, “Спринт”, “Модуль”, “Визуальный элемент”, »Исполнитель”. Связанность между сущностями мы достигаем общим правилом: не создавать объекты без связей. Это значит что мы не можем создать задачу просто так, без оснований, мы обязательно должны ее включить в какую-то большую историю. А большую историю не можем начать без предложения. Это помогает нам построить большую связанную модель где все компоненты поддерживают друг друга.

Сейчас при планировании спринта мы заранее определяем его цели. Это значит, что на ретроспективу мы приходим и обсуждаем не просто незакрытые задачи. Мы обсуждаем, почему мы не добились тех или иных целей спринта, что нам помешало. И это нам дает возможность еще более качественно планировать наши спринты.

Откуда берутся задачи

Как я рассказал выше, задачи разработчикам возникают не на ровном месте (в процессе хаосного программирования в 4 руки с аналитиком, на основании 10 страничного текста в каком-то аналоге вики) , а в процессе шага нашего процесса: “проработка решения” в результате чего мы получаем вот такой архитектурных скетч.

До разработки скетча мы доупаковываем “Возможность”, изменяя карту пользовательских историй, проверяем истории на дубли, добавляем те, которых не хватает, изменяем существующие.

Начало спринта

Перед началом спринта у нас есть список Возможностей, которые я, как владелец продукта, готов предложить команде. Также у нас есть детализированное знание о том, КАК эту Возможность реализовать, и то, что у нас нет блокирующих историй, которые должны закончиться ДО начала разработки Возможности.

Внутри спринта

Каждые два дня мы проводим регулярные стендапы на 10 минут для синхронизации внутри команды. За таймингом мы следим очень жестко чтобы этот ритуал не стал обузой. Наш спринт достаточно гибкий и чаще всего мы стараемся спланировать его таким образом чтобы в нем осталось много свободного времени. При этом у нас всегда есть бэклог с проработанными возможностями которые команда может взять в работу дополнительно.

Завершение спринта

Перед завершением спринта мы проводим регулярное ретро, где обсуждаем, что нам мешало весь спринт, что можно улучшить, и как нам не брать в работу задачи, которые и брать бы не стоило.

Все необходимые инструменты в одном месте

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

Про инструменты поговорим отдельно. Допустим, что карта пользовательских историй ведется на любой доске, например, Miro. Мы сформировали пользовательские истории, из них собрали MVP, а задачи дальше стали двигать в Trello или в Jira. К примеру, мы договорились, что у нас готовые пользовательские истории будут зелеными.

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

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

У нас руководитель проекта смотрит на маленький, очень компактный скетч, в котором видно, что сейчас участники команды закрыли все свои задачи. Теперь руководитель проекта видит на маленькой доске, которая содержит максимум 10-15 элементов, что все задачи закрыты, и меняет состояние возможности и пользовательским историям.

Соответственно, изменения транслируются и в другие инструменты:

В инструментах с одной доской все это пришлось бы делать руками, связывая слова из разных конструкций. И пытаясь одновременно удержать модель в голове. Это требует от всех участников огромных усилий для того чтобы оставаться в контексте.

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

Здесь у нас отлично сложилось, потому что есть отработанный навык гибкого подхода к разработке, проектированию в составе команд и соответствующий инструментарий. Можно сказать, что мы покрыли визуальным инструментарием собственные навыки.

Сейчас мы плавно переходим к регламентному уровню зрелости, потому что появились четко разделенные роли и зоны ответственности. Например, у нас на продакшн никогда не попадет код, который не одобрен нашим менеджером по качеству; “Возможность” не попадет в работу до тех пор, пока там не будет описанных пользовательских историй, хотя бы связанных.

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

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

Все наши инструменты мы реализуем в рамках общего цифрового пространства на платформе Онто.

Основными функциями платформы Онто являются:

Реестр предложений

В реестре мы регистрируем все предложения, которые попадают нам от пользователей.

Для удобства обработки предложений мы ведем отдельную доску, где накапливаем знания по предложению, достаточные для начала разработки возможности.

Реестр возможностей

Когда мы создаем новую «Возможность» из предложения, она появляется в реестре возможностей. Это -основа для будущих задач, которые наполнят бэклог.

Карта пользовательских историй

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

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

У пользовательских историй тоже появился жизненный цикл. Пользовательская история может быть взята в работу, реализована или отклонена.

В течении очень короткого времени мы поняли, что для управляемого развития проекта только пользовательских историй недостаточно, поэтому у нас появились одновременно процессы управления эпиками и возможностями.

Карта эпиков и возможностей

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

Планирование возможностей

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

Архитектурный скетч

Архитектурный скетч ( или дизайн решения) позволяет нам протянуть связи между историями проектирования и разработки. На разработку скетча попадают Возможности, уже прошедшие первичную оценку реализуемости. В этот момент мы уже на 70% представляем, как Возможность будет реализована. После скетча уровень понимания достигает 90%. Небольшие правки по решению допускаем на этап реализации.

Спринт

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

Вишенка

А еще у нас на карточке любого из наших объектов можно увидеть его связи и дополнительные свойства, которые нам помогают быстрее переходить на внешние источники или смотреть контексты (диаграммы) , где еще используется этот объект.

Итак, мы гибко управляем разработкой нашей платформы Онто при помощи моделей, созданных на самой платформе. Эти модели являются единственным источником информации о продукте, что упрощает коммуникацию, управление требованиями и приоритетами разработки.
У нас появились четко разделенные роли и зоны ответственности, повысилась осознанность как команды, так и каждого специалиста. Каждый из нас знает что и зачем он делает, как его работа связана с достижением целей команды в целом. Как итог, мы прошли путь от нулевого до регламентированного уровня зрелости команды за полгода. Думаю, без использования Онто этот результат был бы недостижим.

Описанный выше подход применим как для команд стартапов, так и для команд из регулярного бизнеса.

Буду рад ответить на вопросы и поделиться своим опытом. Напишите мне в чат канала нашего приложения, я всем отвечу.