Как не факапить больше чем запланировали: Scrum в разработке веб-сервисов

Дмитрий Сергеев, генеральный директор сервиса по автоматизации маркетинга и коммуникации с пользователями Carrot quest, поделился особенностями управления разработкой продукта.

У нас сложный продукт, состоящий из большого количества функциональных частей. Для его развития не обойтись без отличной команды разработки продукта, которая должна расти и развиваться. Чуть больше чем за год наша команда разработки продукта выросла с 4-х человек до 9. За этот же год у нас полностью изменились процессы.

Эта статья как раз о том, как мы управляем разработкой продукта.

Итак. Сейчас команда разработки — это 9 человек: СТО и scrum master, бэкэнд разработчики, фронэнд разработчики, тестер, дизайнеры и product owner.

Мы используем методологию scrum. Точнее, ее модификацию. Мы не следуем всем канонам. Тестируем и оставляем только то, что работает у нас. Например, мы так и не научились применять Story point-ы. Несколько раз пробовали их использовать, но как-то не заходят. Но, пожалуй, все по порядку.

Наша рабочая неделя заканчивается и начинается в субботу. Нет, разработчики не работают 6 дней в неделю.

В субботу собирается узкий круг из Scrum master-а, Product owner-а, дизайнера, ответственного за продукт, и самых заряженных членов команды. Чтобы поиграть в PS4 (в первую очередь) и спланировать задачи в спринт. Обычно планирование занимает 2-3 часа. Это возвращение старых или незаконченных задач в спринт, добавление новых и расстановка приоритетов.

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

Мы пробовали делать планирование в “рабочий” день. Это не работает. Все слишком спешат: отвлекаемся на клиентов, команда дергает по вопросам, у каждого куча своих задач и так далее. А у нас часто происходят зарубы (читать “проектирование”) как реализовывать тот или иной функционал. Чем больше времени мы можем уделить этому, тем точнее продумаем как будет работать продукт. Это чертовски важно!

В итоге, в субботу у нас готов план на неделю с хвостиком.

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

Понедельник один из самых офигенных дней. Почти как четверг (об этом позже). В понедельник происходит 2 важных события: Demo и Планерка.

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

Каждый из команды самостоятельно рассказывает о своих результатах. Это делает всех сопричастными. Это важно:)

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

Когда мы запускали Demo, была задача демонстрировать результаты команды разработки. Чтобы на деле показать важность работы каждого разработчика, ответственность и все такое. Но в процессе команды сами попросили расширить Demo, дав слово всем. Мы думали, что от этого Demo разбухнет, станет скучным и длинным. Но по факту оно занимает 15 минут и дает огромную пользу.

Это процесс расстановки приоритетов и фиксирования человекочасов у тех задач, которые были запланированы в субботу.

Раньше мы собирались в кругу с разработчиками и у каждого спрашивали, сколько нужно времени на задачу. Если задачи не помещались в спринт, мы убирали лишние с низким приоритетом. Так все были в курсе, кто что делает и как оценил задачу.

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

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

Мы итерационно пришли к тому, что ставить задачи на 100% времени неправильно. Под 100% времени я понимаю не 40 часов, а 36 часов в неделю. Часа 4 уходит на всякую человеческую “фигню” и естественные потребности.

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

У каждого разработчика свое время на внезапные задачи. У scrum master-а оно 12 часов, у фронтэнд разработчика 4 или более часов. Объемы внезапных задач мы выявили итерационно, фиксируя левые задачи и затраты на них несколько недель подряд.

Мы уверены, что в команде важны синхронизация, коммуникации и вот это все. Чем лучше все члены команды понимают, что делается в спринте и продукте, тем продуктивнее совместная работа.

Поэтому каждое утро у нас проходят стендапы. Мы определили железное время, к которому никто не должен опаздывать (10:15). Во время стендапа каждый коротко рассказывает 3 пункта:

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

На стендап уходит 10 минут в день, но это уменьшает риски незавершения спринта, так как сосед может помочь решить какую-то проблему.

Иногда во время стендапа меняются приоритеты задач. Например, если от дизайнера зависит задача фронтэнд разработчика, то это повод переставить местами задачи дизайнера (если это возможно). Таких примеров, когда происходит синхронизация задач и мелкие изменения приоритетов, масса. Самое важное, что это происходит по инициативе самой команды.

Была задача еще глубже (чем на Demo) погрузить компанию в особенности задач каждой команды. Цель: синхронизировать всех со всеми, чтобы было понимание, что происходит в соседней команде, и работала взаимопомощь.

Для этого мы стырили формат “Рыбного четверга” у Людвига Быстроновского, немного (полностью) его модифицировав.

Каждый! четверг после работы (в 18.00) мы организуем какую-то презентацию (за полгода существования этого формата ни одного рыбного четверга не пропущено).

Презентации бывают на самые разные темы:

• ​изменения процессов во внедрении автоматизации маркетинга;
• гипотезы, сработавшие в платных каналах (маркетинг);

• регламент отношений поддержки пользователей и разработки;

• когортная аналитика в продажах;

• построение воронок на clickhouse, результаты исследования;

• и мнооого чего еще.

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

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

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

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

Вообще, думаю, проектирование и дизайн — это история для отдельной статьи. Например, как проходит дальнейшая валидация дизайна с пользователями сервиса или аналитика результата. Напишите в комментариях, если это интересно.

В пятницу мы подводим итоги. Каждую пятницу в конце рабочего дня (18:00) мы проводим небольшую ретроспективу, в которой коротко разбираем спринт, что удалось и что пошло не так.

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

На основе ретроспектив мы дорабатываем процессы или меняем какие-то детальки.

Нет.

Потратив суммарно 3-4 часа в неделю на все процессы: планирование, синхронизацию, митинги, мы не завершаем 100% спринтов вовремя. Такова жизнь.

Есть еще много работы, чтобы приблизиться к идеальной Burndown диаграмме.

• ​надо улучшить определение времени на задачи, для этого давать больше информации о задаче разработчикам;

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

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

• попробовать на ретроспективе фиксировать причины, по которым не завершаем спринты. Посмотреть, какие из них самые больные и частые;

• и так далее.

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