19 апреля 2019

От Скрама к Канбану и новому продуктовому подходу

Ольга Шаврина
За 5+ лет работы в продуктовых командах я настолько привыкла, что «у нас Скрам», что даже не подвергала сомнению его волшебную силу, несмотря на то, что все время что-то смущало и раздражало.

Примерно 3 месяца назад мы неожиданно перешли на Канбан и отказались от спринтов. Ощущения непривычные :) делюсь.
Было
Чистого Скрама у нас, конечно, никогда не было. Было что-то вроде Скрамбана: ограниченные по времени спринты, спринт-планинги и оценка задач. Но задачи (а особенно баги) могли втиснуться в спринт после его начала (мы же стартап, ну). Некоторые задачи на стадии реализации могли оказаться сложнее, чем казалось раньше, что добавляло им часов и ставило под угрозу завершение спринта. Для наглядности использовали Канбан-доску.

Приоритизация задач


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

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

Беклог вели в Spreadsheets-документе, выглядело это так:
Спринт-планинги

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

Да, это занимало много времени – до 4-х часов раз в две недели. Если умножить это на количество участников (с зарплатами разработчиков!) – получается куча денег.

Тикеты

Для наглядности мы использовали Канбан-доску. Даже не так – две Канбан-доски :) одну - цифровую в Jira и одну физическую в переговорке для дейли-митингов. Проблем с синхронизацией досок не возникало – в Жире доска обновляется автоматически, а физическую доску обновляем на митинге, проговаривая, что изменилось.
Тикеты организованно печатали после спринт-планинга и наклеивали в колонку ToDo. В среднем в спринт входило 25-30 тикетов. Целью было переместить их все в колонку Done за время спринта (1,5 - 2 недели). Чем больше тикетов оставалось в колонке ToDo – тем больше было давление на программистов. Под конец спринта всегда ощущалось, что парни стрессуют.
Проблемы тех-команды
1
Неверные оценки. 100% точно оценить задачу ты можешь только постфактум. Более-менее точно можешь оценить, если делал что-то схожее в прошлом. Но если задача новая (а в 90% случаев это так), ты можешь дать только приблизительную оценку и, конечно, ошибешься в меньшую сторону потому, что на тебя смотрит босс (ಠ_ಠ)
2
Непредсказуемое увеличение часов – болезни, баги, непродуманные мелочи… в итоге времени на задачи тратится больше, чем планировали, а конец спринта неумолимо приближается.
3
Переходящие из спринта в спринт задачи. Все время оставались какие-то хвосты, о которых надо было думать и они отъедали время от текущего спринта.
4
Регулярно стрессующие программисты :( Нежные они ребята. Чтобы функционировать им нужны комфортные условия, покой, тишина, кофе и печеньки, определенность, ясность и чувство контроля. Стресс раз в две недели по независящим от них причинам снижает эффективность в разы.
5
Подмена приоритетов – целью было уложиться в спринт вместо того, чтобы сделать качественно. Часто пренебрегали глубоким тестированием и проработкой edge-case'ов.
6
Долгие спринт-планинги, в которых участвовала вся команда. Не спорю, что ценно обсуждать задачи всей командой. Но когда на это уходит пол-дня и все равно ни одна задача не проговаривается глубоко и потом никто ничего толком не помнит – неэффективно.
Переход
Началось с того, что к нам пришел новый Head of product с опытом работы по Канбану и сказал «Хей, давайте попробуем по-моему». Мы выразили скептицизм, но решили а чёб нет.

Первое, что мы сделали – отказались от беклога, разделенного на секции по отделам. Вместо этого стали фокусироваться на глобальных индикаторах компании и определять цели тех-команды на квартал и уже исходя из них ставить задачи. Для этого на самом верхнем уровне внедрили Hoshin и стали еженедельно с ним согласовывать работу всех отделов.
Вообще Hoshin оказался очень крутой и удобной штукой, но подробно о нем рассказывать пока не буду. Это не имеет прямого отношения к Канбану и вообще тема для отдельного разговора :)
Картинка с сайта https://en.hoshinplan.com/ - это сервис, который мы используем
В результате, задач стало меньше, тех-команда стала чувствовать больше контроля над ситуацией и ощущать, что мы двигаем компанию вперед к квартальным целям, а не просто делаем то, что просят эти странные люди без технического образования :)

Второе, что мы сделали – прибрались в Жире. Но это, наверное, тоже тянет на отдельный пост.

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

Оставили обе Канбан-доски. Перестали организованно печатать тикеты, завели стикеры и маркеры в переговорке, чтобы быстро можно было создать тикет и повесить на доску. Заказали для всех членов команды цветные магнитики с героями Star Wars, чтобы лепить их на стикеры и видеть, кто над какой задачей работает. Догадайтесь, кто я ;)

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

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

В колонке ToDo теперь не 30 задач, а 8-10 – это меньше давит на психику и позволяет команде контролировать ситуацию.

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

В целом, задач стало меньше и мы смогли фокусироваться на важных для бизнеса. Даже стали получать «Хей, спасибо за долгожданную фичу!» вместо «Ну когда вы уже это сделаете?» от других отделов.

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

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