Путь трёх досок в планировании

Одна из основных задач для любой команды — выстраивание прозрачных процессов на каждом этапе работы. Если этого нет — специалисты путаются в задачах, бизнес потеряет контроль над процессами, а беспорядок неизбежно влияет на time to market и сложность онбординга новых сотрудников.

Всем привет! Меня зовут Ася Задесенец. Я менеджер проектов в СберЗдоровье. За последний год моей команде удалось создать абсолютно прозрачную и удобную модель управления проектами — как для бизнеса, так и для сотрудников. В этом материале я поделюсь нашим опытом. Статья будет полезна начинающим руководителям проектов.

Начало пути и проблемы

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

  • роадмап велся в нескольких инструментах;
  • в бэклог могли попадать задачи, не соответствующие критериям готовности (Definition of Ready, DoR);
  • были узкие места в проработке функционала и/или аналитике;
  • команда не могла принимать участие в формировании идеи заказчика — да, мы за открытость и приветствуем идеи от отдела разработки.

Фактически продуктивная работа команды в таких условиях была невозможна — это понимали как мы, так и бизнес. Чтобы наладить процессы и избавиться от издержек — от путаницы в задачах до снижения time to market — нам надо было сделать «мини-революцию» и мы не стали с этим затягивать.

Распил «дерева» на «три доски»

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

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

Таких групп мы выделили три — так в нашей команде появилась концепция «трех досок» (дашбордов).

  • Первая доска «Продуктовое дискавери». Включает проработку требований с командой продуктовой разработки, работу дизайнеров над прототипом, разработку и аналитику для возможного разделения задачи на этапы.
  • Вторая доска «Аналитика». Включает этапы проработки архитектуры и системного анализа. Здесь так же выполняется проверка кибербезопасности, проводится архитектурный совет и другие согласования.
  • Третья доска «Истории». Разработка, куда же без нее?
Путь трёх досок в планировании

Первая доска «Продуктовое дискавери»

На первую доску мы вынесли все процессы, связанные с первичной проработкой идей. Каждая поступающая на доску инициатива получает тип «Исследование» и делится на несколько этапов, в соответствии с которыми выполняется вся работа:

  • Бэклог. Это склад для исследований — начальный этап проекта.
  • Исследование. Анализируем данные о нашей идее и формулируем проблему.
  • Дизайн. Проводим верхнеуровневый анализ и делаем заметки по макетам с дизайнером.
  • Тестирование идеи. Заносим на продуктовый кутеж (прожарку) нашу задачу и проводим UX-исследование. В итоге получаем описание сценариев, на основе которых дорабатываем финальные макеты по дизайну.
  • Анализ и архитектура. Команда разработки на основе требований и прототипа дизайна делает прототип архитектуры и предварительный системный анализ.
  • Оценка. Исходя из предыдущих этапов, показываем наброски администратору проекта и/или техлиду команды, чтобы получить верхнеуровневую оценку. В случае согласования вносим задачу в планы разработки команды.
  • Ожидает аналитику. Отправляем задачу на полноценный системный анализ и прохождение этапов согласования и текущий статус является конечным путем на этой доске.
Доска Продуктовое Дискавери v1
Доска Продуктовое Дискавери v1

Со временем мы решили расширить первую доску, добавив в нее end-to-end путь. В результате мы изменили блок «Ожидает аналитику» на «Проектирование» и добавили ещё несколько этапов.

  • Проектирование. Отправляем задачу на полноценный системный анализ и прохождение этапов согласования.
  • Реализация. Вся команда активно работает над задачей: системный аналитик проводит анализ, разработчик проводит технический анализ (см. 2 и 3 доска).
  • Готово. Идея от заказчика считается успешно выполненной.
Доска Продуктовое Дискавери v2
Доска Продуктовое Дискавери v2

Вторая доска «Аналитика и согласования»

На вторую доску мы вынесли все процессы, связанные с задачей типа «Аналитика». На текущей доске, помимо самой системной аналитики, задача проходит все этапы согласований — от архитектурных и до кибербезопасности.

Процессы, так же как и на первой доске, разделены на этапы:

  • Бэклог. Текущий статус — склад задачи для анализа. Задачи в бэклоге должны быть приоритезированы согласно скорингу.
  • Анализ. Анализируем входящую задачу, уточняем точные функциональные требования, рисуем технические схемы совместно с тимлидом команды.
  • Согласование. Проводим согласование будущей задачи с архитектором, сотрудниками кибербезопасности, с заказчиком задачи и командой, которая будет заниматься текущим проектом.
  • Декомпозиция и оценка. Разбиваем проект на этапы, принимая, что каждый этап будет равен пользовательской истории со сроком жизни две недели.
  • Готова к разработке. Отправляем задачу на полноценный технический анализ с дальнейшим планированием новой созданной пользовательской истории.
Доска Аналитика и согласования
Доска Аналитика и согласования

Третья доска «Истории разработки»

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

  • Готово к разработке. Текущий статус — склад задачи для технического анализа и дальнейшей работы над историей.
  • Планинг. Пользовательская история ожидает взятия в работу.
  • ТехДизайн. Проводим детальный технический анализ и описываем способ реализации в документации. Декомпозируем историю на задачи, оценивая каждую задачу (стараемся, чтобы длительность была не более 8 часов).
  • В работе. Берем историю в работу и, соответственно, начинаем работать над задачами.
  • Тестирование. Проводим тестирование всех задач в истории, показывая демо-версию для заказчика.
  • Закрыт. Проводим релиз истории на продакшн.
Доска Истории разработки
Доска Истории разработки

Результат внедрения концепции «Трех досок»

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

  • Удобство планирования. Мы можем отслеживать движение задачи от этапа к этапу и прогнозировать загрузку команды минимум на квартал.
  • Прозрачность. В каждой задаче есть чеклисты, которые включают основные пункты DOR. Мы понимаем, что нужно сделать, чтобы передать задачу дальше.
  • Простота оценки нагрузки. Мы видим, на каком из этапов скапливаются задачи и на основе этой информации можем планировать способы оптимизации — например, привлечь дополнительного дизайнера.
  • Отсутствие «лишних» задач. В разработку попадают только те задачи, которые прошли детальную проработку на предыдущих этапах.
  • Сокращение Time-to-Market. Мы увеличили производительность команд за счет снижения количества переключений между задачами и более детальной проработки всех реализуемых задач (работа с выявлением блокеров и зависимостей на более ранних этапах).

Что думаете о концепции трех досок? Попробовали у себя на практике бы? Пишите в комментарии своё мнение.

2828
20 комментариев

Не читал, просто увидел что-то умное, и что-то со словом Сбер, и зашёл сказать, что здорово, если это поможет снова не идти туда, где открывал счёт😜

2
Ответить

Здорово, крутой кейс.

1
Ответить

Благодарю! Если будут вопросы - задавайте :)

1
Ответить

Получается вы разработали с нуля систему? Или использовали готовое решение уже?

Ответить

Для нашей команды сделали текущий путь - с нуля. Потом уже выяснили, что есть похожая история flight levels

1
Ответить

А сколько человек в комнате? Есть ли корреляция между количеством людей и необходимостью делить на группы?

Ответить

Команда у нас достаточно большая. 15 человек в разработке.

1
Ответить