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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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