Одна из основных задач для любой команды — выстраивание прозрачных процессов на каждом этапе работы. Если этого нет — специалисты путаются в задачах, бизнес потеряет контроль над процессами, а беспорядок неизбежно влияет на time to market и сложность онбординга новых сотрудников.
Всем привет! Меня зовут Ася Задесенец. Я менеджер проектов в СберЗдоровье. За последний год моей команде удалось создать абсолютно прозрачную и удобную модель управления проектами — как для бизнеса, так и для сотрудников. В этом материале я поделюсь нашим опытом. Статья будет полезна начинающим руководителям проектов.
Начало пути и проблемы
К моменту создания моей команды уже был сформирован огромный бэклог не отсортированных и не классифицированных задач — они просто скапливались в огромной очереди без какой-либо структуры. Разобраться с проектами в таком виде было сложно, еще сложнее — управлять ими. Ситуацию усложняли и другие факторы:
- роадмап велся в нескольких инструментах;
- в бэклог могли попадать задачи, не соответствующие критериям готовности (Definition of Ready, DoR);
- были узкие места в проработке функционала и/или аналитике;
- команда не могла принимать участие в формировании идеи заказчика — да, мы за открытость и приветствуем идеи от отдела разработки.
Фактически продуктивная работа команды в таких условиях была невозможна — это понимали как мы, так и бизнес. Чтобы наладить процессы и избавиться от издержек — от путаницы в задачах до снижения time to market — нам надо было сделать «мини-революцию» и мы не стали с этим затягивать.
Распил «дерева» на «три доски»
Для нас стало серьёзным испытанием настроить работу в системе так, чтобы следить за процессами в команде: от рождения идеи заказчика до релиза фичи на продакшн.
Оценив имеющиеся проблемы, мы поняли, что решить их нам поможет разделение всех процессов на разные группы, а групп — на этапы (от идеи до реализации).
Таких групп мы выделили три — так в нашей команде появилась концепция «трех досок» (дашбордов).
- Первая доска «Продуктовое дискавери». Включает проработку требований с командой продуктовой разработки, работу дизайнеров над прототипом, разработку и аналитику для возможного разделения задачи на этапы.
- Вторая доска «Аналитика». Включает этапы проработки архитектуры и системного анализа. Здесь так же выполняется проверка кибербезопасности, проводится архитектурный совет и другие согласования.
- Третья доска «Истории». Разработка, куда же без нее?
Первая доска «Продуктовое дискавери»
На первую доску мы вынесли все процессы, связанные с первичной проработкой идей. Каждая поступающая на доску инициатива получает тип «Исследование» и делится на несколько этапов, в соответствии с которыми выполняется вся работа:
- Бэклог. Это склад для исследований — начальный этап проекта.
- Исследование. Анализируем данные о нашей идее и формулируем проблему.
- Дизайн. Проводим верхнеуровневый анализ и делаем заметки по макетам с дизайнером.
- Тестирование идеи. Заносим на продуктовый кутеж (прожарку) нашу задачу и проводим UX-исследование. В итоге получаем описание сценариев, на основе которых дорабатываем финальные макеты по дизайну.
- Анализ и архитектура. Команда разработки на основе требований и прототипа дизайна делает прототип архитектуры и предварительный системный анализ.
- Оценка. Исходя из предыдущих этапов, показываем наброски администратору проекта и/или техлиду команды, чтобы получить верхнеуровневую оценку. В случае согласования вносим задачу в планы разработки команды.
- Ожидает аналитику. Отправляем задачу на полноценный системный анализ и прохождение этапов согласования и текущий статус является конечным путем на этой доске.
Со временем мы решили расширить первую доску, добавив в нее end-to-end путь. В результате мы изменили блок «Ожидает аналитику» на «Проектирование» и добавили ещё несколько этапов.
- Проектирование. Отправляем задачу на полноценный системный анализ и прохождение этапов согласования.
- Реализация. Вся команда активно работает над задачей: системный аналитик проводит анализ, разработчик проводит технический анализ (см. 2 и 3 доска).
- Готово. Идея от заказчика считается успешно выполненной.
Вторая доска «Аналитика и согласования»
На вторую доску мы вынесли все процессы, связанные с задачей типа «Аналитика». На текущей доске, помимо самой системной аналитики, задача проходит все этапы согласований — от архитектурных и до кибербезопасности.
Процессы, так же как и на первой доске, разделены на этапы:
- Бэклог. Текущий статус — склад задачи для анализа. Задачи в бэклоге должны быть приоритезированы согласно скорингу.
- Анализ. Анализируем входящую задачу, уточняем точные функциональные требования, рисуем технические схемы совместно с тимлидом команды.
- Согласование. Проводим согласование будущей задачи с архитектором, сотрудниками кибербезопасности, с заказчиком задачи и командой, которая будет заниматься текущим проектом.
- Декомпозиция и оценка. Разбиваем проект на этапы, принимая, что каждый этап будет равен пользовательской истории со сроком жизни две недели.
- Готова к разработке. Отправляем задачу на полноценный технический анализ с дальнейшим планированием новой созданной пользовательской истории.
Третья доска «Истории разработки»
Выше уже был спойлер, что проект декомпозируется на истории со сроком жизни две недели. На этой доске предусмотрены следующие этапы:
- Готово к разработке. Текущий статус — склад задачи для технического анализа и дальнейшей работы над историей.
- Планинг. Пользовательская история ожидает взятия в работу.
- ТехДизайн. Проводим детальный технический анализ и описываем способ реализации в документации. Декомпозируем историю на задачи, оценивая каждую задачу (стараемся, чтобы длительность была не более 8 часов).
- В работе. Берем историю в работу и, соответственно, начинаем работать над задачами.
- Тестирование. Проводим тестирование всех задач в истории, показывая демо-версию для заказчика.
- Закрыт. Проводим релиз истории на продакшн.
Результат внедрения концепции «Трех досок»
Разделение огромного бэклога на отдельные дашборды позволило нам получить ряд выгод, причем как организационных, так и бизнесовых.
- Удобство планирования. Мы можем отслеживать движение задачи от этапа к этапу и прогнозировать загрузку команды минимум на квартал.
- Прозрачность. В каждой задаче есть чеклисты, которые включают основные пункты DOR. Мы понимаем, что нужно сделать, чтобы передать задачу дальше.
- Простота оценки нагрузки. Мы видим, на каком из этапов скапливаются задачи и на основе этой информации можем планировать способы оптимизации — например, привлечь дополнительного дизайнера.
- Отсутствие «лишних» задач. В разработку попадают только те задачи, которые прошли детальную проработку на предыдущих этапах.
- Сокращение Time-to-Market. Мы увеличили производительность команд за счет снижения количества переключений между задачами и более детальной проработки всех реализуемых задач (работа с выявлением блокеров и зависимостей на более ранних этапах).
Что думаете о концепции трех досок? Попробовали у себя на практике бы? Пишите в комментарии своё мнение.
Не читал, просто увидел что-то умное, и что-то со словом Сбер, и зашёл сказать, что здорово, если это поможет снова не идти туда, где открывал счёт😜
Здорово, крутой кейс.
Благодарю! Если будут вопросы - задавайте :)
А каким сервисом пользуетесь?
Для флору 3х досок используем Яндекс Трекер.
Задача начиная процесс на первой доске меняет свои доски пр достижении конечного статуса, это как-то автоматизированно?
Полноценных беклогов у досок нет, все храниться в очередях?
Да, в трекере пространство = очередь.
Есть автоматизация :) Например, задача с типом "Аналитика" создается автоматически, если "Исследование" попадает в статус ""Проектирование""
Получается вы разработали с нуля систему? Или использовали готовое решение уже?
Для нашей команды сделали текущий путь - с нуля. Потом уже выяснили, что есть похожая история flight levels
Почему не использовали сразу готовое решение, если не секрет? Сейчас есть достойные решения на отечественном рынке
Например? Какие готовые решения вы имеете ввиду?
Зависит от ваших требований к системе. Нужно ли анализировать отношения с клиентами или достаточно будет проектного управления, эдо, таск-трекера с графиком ганта, календарным графиком и проч.
А сколько человек в комнате? Есть ли корреляция между количеством людей и необходимостью делить на группы?
Команда у нас достаточно большая. 15 человек в разработке.
Крутая статья, но так показалось что у вас как то много аналитики согласований. Такое ощущение, что Проектирование и Реализация дублируют друг друга. Например:
1) Проектирование и Реализация - на Проектировании у вас есть"полноценный системный анализ и прохождение этапов согласования" в то же время после проектирования идет этапа Аналитика и у вас опять есть пункты "Анализ" и "Согласование". Это немного странно.
+
Не очень понятно что подпадает под "Проводим детальный технический анализ"? Аналитик же уже должен был эту задачу сделать и отдать данные в разработку.
И еще пара вопросов:
1) У вас всего есть UX исследования или в каких то случаях вы это этап пропускаете? Например, когда изменения в продукте идут "под капотом", без изменений в UI\UX
2) Как вы согласуете ранжирование бэклогов разных досок? Во тесть у вас фича которую вы прогнали по доске Продуктовое дискавери, после которой вы поняли что это прям MustHave. После этого фича падает в бэклог доски Аналитика и аналитик берет задачи из этого бэклога по своему желанию или в порядке очереди? Или есть какой-то скор\приоритет? И аналогичный вопрос по бэклогу Истории
Привет! У нас всё таки отличается системный анализ от технического.
В системном анализе больше формирования функциональных требований, рисование схем диаграммы потоков и данных.
А вот уже подробный технический анализ включает в себя выбранные подходы к разработке и детализация на апишки.
Тем самым, функционал до команды доходит более декомпозированным и простым.
Отвечаю на вопросики:
1. UX исследования заказчик проводит почти у всех своих новых проектов. Если идея занимает небольшое изменение в существующем функционале - то текущий этап пропускается.
2. Хороший вопрос. К сожалению, полноценно от скоринка (беклога) отказать не удалось :( Поэтому, продакт оунер ставит приоритеты у проектов, и далее распределяю в очередь аналитику и историю для разработчика, исходя из пожеланий продакт оунера.
Первая доска это сырная доска
Вторая доска - копченая
Третья - рыбная
[TL;DR]
Идея нарезать value stream («от рождения идеи… до релиза фичи») лежит на поверхности.
И способов «нарезать» м. б. много: 1) выделение стадий value stream (от идеи до анализа, от анализа до разработки, от разработки до релиза); 2) группировка фич по сложности (трудозатратам) реализации (имхо, «простые» — «Покупка из каталога» и сложные — «Карта и анализы»); 3) а можно нарезать по компонентам/сервисам системы (сервис «Авторизация» {клиента, врача, администратора клиники}, «Поиск» {по клиникам, по врачам, по городам, «рядом»}).
Однако, в описанном варианте «три доски» соответствуют стадиям, что вряд ли соответствует главной цели — «снижения time to market», т. к. у всех задач остается один и тот же путь.
Еще очень пугает, что стадии институализируются (извини за слово:). «Прогресс» по доскам станет предметом отдельного рассмотрения и velocity на каждой доске будет жить своей жизнью, вместо одного «огромного бэклога», ты получишь три меньшим числом, но таких же «огромных».
Судя по всему, как были проблемы, так и остаются с этапами «Анализ и архитектура», «Оценка», «Анализ», «Декомпозиция» (это тоже анализ) и «Планинг». Предполагаю, что после 6 мес. использования «трех досок» на этих этапах будет «висеть» 50% всех задач-проектов с наибольшим overdue (если вы чуть-чуть ставите директивные сроки).
Очень расстраивает, что «В работе» (~30% задач спустя полгода) на доске «Истории разработки» остается черным ящиком и, по сути, противопоставляется всем другим этапам (и ролям). Хотя именно здесь (на этом этапе) можно достичь наибольших эффектов agile (если ты в него веришь:).
Я почти совсем уверен, что внедрение «трех досок» дало эффект в разгребании бэклога и понимании его «огромности», предполагаю, что «выскочили» задачи, которые надо «просто сделать» и те, к которым еще «нормально не подступились». Вот их бы пустить по разным стримам.:)
Хорошие вопросы :)
1. У нас в целом Value stream под каждый отдельный продукт в стриме создан. И эти самые три доски - как раз визуализация Value stream.
2. Все верно, мы визуализировали процесс, чтобы далее его измерить, найти задержки в процессе и постараться их устранить :)
В Сбер теперь школьников набирают?