Проектный менеджмент до появления SCRUM
Пока не появилась гибкая методология управления проектами, компании традиционно использовали каскадный («водопадный») подход. Этапы работы над проектом следовали друг за другом:
Заказчик приходил и рассказывал о задаче. Требования к проекту превращались в подробное техническое задание, сразу разрабатывались дизайн-макеты проекта. Разработчики получали отдельные ТЗ и приступали к работе после утверждения дизайна. Команда тестировала проект, исправляла ошибки и доводила продукт до готовности. Звучит хорошо и в теории каскадный подход работает. Но на практике все не так гладко.
Каскадный подход замедляет работу над проектом — команда разработчиков переходит к следующему этапу, только когда полностью выполняет задачи прошлой фазы. Вернуться назад нельзя, “перепрыгнуть” через стадию — невозможно. Плюс, продукт тестируется когда команда уже разработала приложение.
Как работает тестирование в гибком подходе для сравнения: за спринт команда разрабатывает готовый «кусок» приложения и начинает работу над следующей итерацией. Тестировщик работает параллельно с разработчиками — баги всплывают и фиксятся в моменте, а не перед релизом проекта.
Простой пример: на одном проекте у нас проблема с внедрением платежной системы Stripe в приложение. Мы нашли альтернативное решение: внедрили Braintree вместо того, чтобы пытаться установить Stripe любыми способами. Если бы мы работали по каскадному подходу — вышли бы за рамки сроков. Пришлось бы пытаться внедрить Stripe, либо менять документацию и согласовывать это с заказчиком, если бы решили использовать другую платежную систему. На все это уйдет немало времени.
В digital-сфере невозможно предсказать все проблемы, а в большом проекте тем более. Каскадный подход игнорирует динамические изменения. Есть ТЗ, которому команда следует на всем процессе разработки. Проект делается за один раз — его никак не переделаешь. После определения требований к проекту сложно заложить функции, не учтенные на первых стадиях разработки. Любое изменение в документации нужно согласовывать с заказчиком.
Переосмысление проектного менеджмента: как эффективно запускать стартап
Каскадный подход — это лишняя бюрократизация, сложность коммуникации с заказчиком и срыв сроков. У компаний были проблемы, но никто не жаловался, потому что альтернативных вариантов не видели, пока в 1995 году не появился Agile.
Гибкий подход начал вытеснять традиционные методы работы. Подробные ТЗ исчезли, коммуникаций с клиентом стало больше, а дедлайны соблюдались. Через несколько лет Agile превратился в Манифест гибкой методологии разработки, содержащий все принципы подхода.
Компании уже применяли на практике эту методологию, но только после обнародования о ней узнали массы. Со временем подход Agile обзавелся новыми методологиями: Lean, XP, Scrum, Kanban. Остановимся на двух последних — расскажем про свой опыт работы с ними.
Визуализация, ограничение времени и задач, непрерывная работа — лицо подхода Kanban. Обязательный элемент — доска. На нее переносятся планируемые задачи. У доски есть списки, которые отражают этапы проекта. Каждая карточка в списке — задача. Она, получив новый статус, последовательно перемещается из одного столбца в другой (в Kanban это называется потоком). Если этот пункт не соблюдать — подход не работает.
Мы работаем по Скраму в любом случае и на дизайн-проектах используем Канбан-доску как таск менеджер. На разработке мы используем Jira, а на дизайне — Trello. Канбан-доска как способ организации таск менеджера — да. Trello, как инструмент — да, но скоро будет нет.
В Scrum работа над проектом разделяется на короткие этапы (спринты) с четкими рамками: обычно один спринт длится от 2 до 4 недель. В течение цикла команда ежедневно встречается, чтобы оценить ход работы и обменяться информацией по проекту. В конце спринта команда тестирует готовый «кусок» продукта и демонстрирует его заказчику.
Основные принципы фреймворка, которые помогают командам в работе:
- Гибкий список задач.
- Ежедневные встречи.
- Готовность к изменениям.
- Разделение проекта на этапы.
- Коммуникации внутри команды.
Принципы методологии помогают нам не вылезти за рамки бюджета и времени. Команде легче разработать продукт и вывести его на рынок.
Команда, работающая над проектом
Обычно в команде не больше 9 разработчиков, плюс владелец продукта и Scrum-мастер. Участников может быть больше — никто вас за это не съест. Но координировать работу будет сложнее, к этому нужно быть готовым. Scrum-команда самоорганизовывается: сама решает, как выполнить работу. Так работает в теории. О практике мы поговорим чуть позже.
Владелец продукта отвечает за начальную идею и готовый проект. Чаще всего эту роль играет заказчик: дает идею, деньги и составляет требования. Владелец продукта не всегда лучше всех в команде понимает, как должен выглядеть продукт. Совместно с другими членами команды он направляет продукт в нужное направление.
Scrum-мастер налаживает коммуникации внутри команды и помогает ей справляться с трудностями. Его главная задача — объяснить принципы методологии. Scrum не работает, если не все в команде их понимают.
Команда разработчиков — обычно это 5-7 человек, которые разрабатывают продукт. У каждого своя зона ответственности и задачи, но вместе они отвечают за достижение цели спринта. «Разработчик» — не обязательно программист. Это может быть любой специалист, например QA инженер или дизайнер.
Состав команды в «боевых» условиях
Scrum-мастер и Владелец продукта у нас — это проектный менеджер. Так почти в каждом проекте. Почему? Вот, например, у меня есть проект. Одна задача может быть расписана в пару словах, а может — в нескольких абзацах. Всего на проекте 1211 задач. Владелец продукта должен вести бэклог, расписывать и приоритизировать задачи. В большинстве проектов заказчик этим не занимается, но все зависит от договоренностей. На одном проекте мы негласно делим с заказчиком обязанности: он периодически кидает задачи в бэклог, описывает их и обозначает приоритет.
На практике у нас сложилась такая ситуация, что команда формируется исходя из интересов. Заказчик хочет получить работающий продукт в срок и бюджет. Мы хотим того же, но еще кросс-функциональную команду, чтобы каждый разработчик мог без сложностей продолжить работу другого. Если последний отвалится по болезни, например.
Бывало, что заказчику нужно выйти в релиз через месяц. Оцениваем объем работ — понимаем, что обычной командой (проектный менеджер, дизайнер, 2 программиста и тестировщик) не уложимся в сроки. Тогда подключаем к проекту столько людей, сколько потребуется.
Практика показала, что на каждом проекте состав команды всегда разный: даже если сначала была стандартная команда, то в зависимости от загруженности она уменьшается, либо увеличивается.
Мы готовы к тому, что кто-то из команды отвалится по болезни или по другой причине. В таких случаях берем свободного разработчика, либо перетягиваем с другого проекта, если ситуация позволяет. Так же делаем, когда кто-то в команде не успевает: фронтенд-, бэкенд-разработчик или дизайнер. Такой подход исключает риск растянуть сроки.
Как выстраивать работу в Scrum
Scrum — это не универсальное решение в работе, с которым каждый проект будет взлетать. Слепо внедрять все артефакты — не всегда хорошо на практике. Мы до сих пор изучаем Scrum и подстраиваем его под себя. Управлять проектом стало проще, команда работает продуктивнее и это только начало.
Каждый день мы активно изучаем Scrum, стараемся эффективнее вести проект до релиза и общаться с заказчиком. Рассказываем, как мы внедряем в компанию Scrum и почему следовать правилам — не всегда хорошо на практике.
Вести бэклог проекта
Заказчик приходит к нам с какой-нибудь идеей. Он рассказывает: в чем суть стартапа и какие функции он хочет видеть. Обычно хватает общего описания проекта, а все остальное обсуждается с заказчиком во время разработки, если конкретных желаний нет.
Команда обсуждает идею, составляет майндмэп, подбирает тех стек. Рабочие задачи формируются в список — формируется общий бэклог. Вверху те задачи, над которыми команда работает в первую очередь. Постепенно список будет меняться: появятся новые требования к продукту или старые потеряют ценность.
В Purrweb бэклог проекта ведет проектный менеджер на основе желаний заказчика. Если разработчик понимает, что какую-то фичу нужно реализовывать по-другому, иначе она будет плохо работать или не будет вообще — бэклог проекта меняется. Это и есть та необходимая гибкость в управлении проектами.
Задачи в бэклоге располагаются в приоритетном порядке: команда обсуждает проект и договаривается: что нужно сделать в первую очередь, чтобы выполнить цель спринта. Крупные компании как Google и Amazon используют такие критерии приоритизации бэклога, как Impact/Effort, Feature buckets, User Story Mapping и MoSCoW.
На приоритизацию задачи влияет здравый смысл, заказчик, разработчики и тестировщик. Мы с тимлидом раскидали задачи по спринтам на планировании. Разработчики обсуждают, что нужно сделать за спринт и распределяют работу между собой. Бывает, что заказчику нужно показать часть готового функционала инвесторам. Проект — 3 месяца, а он обещал инвесторам через 3 недели показать готовый «кусок». Естественно, мы эту часть разработаем на первом спринте. Так заказчик влияет на приоритизацию задач.
Мы практикуем User Story Mapping. Этот инструмент использует бизнес-аналитик, чтобы спроектировать шаги пользователя в приложении: как он будет использовать продукт, что будет делать для этого и что хочет получить в конце. User Story Mapping помогает нам расставить приоритеты в бэклоге продукта.
User Story Mapping у нас уже применялся на разработке, а недавно появился и на дизайне. Как это работает: бизнес-аналитик составляет документ с пользовательскими сценариями. Мы оцениваем его и отдаем в дизайн. Дизайнер составляет майндмэпу, которую мы презентуем заказчику. Он говорит: «это именно то, чего я и хотел». Обычно, когда заказчик приходит с проектом, у него уже что-то есть. Ко мне, например, однажды пришел клиент с уже готовой майндмэпой.
Делить проект на спринты
Спринт — это когда собираешь большой проект по маленьким кусочкам. Команда берет из бэклога проекта задачи на спринт и оценивает объем работ. Разработчики распределяют задачи между собой, решают, сколько продлится спринт и начинают разработку проекта. За спринт команда планирует закрыть поставленные задачи. Команда знает, какой будет результат.
Оптимальная длина спринта для нас на разработке — 2 недели. За одну неделю команда не так много сделает, чтобы показать результат заказчику. Больше 2-х недель — заказчик долго не видит готовую часть продукта, ему сложнее отслеживать движение проекта к цели.
Ежедневно встречаться
В начале каждого дня команда собирается на дейли. Участники встречаются примерно на 15 минут и обсуждают:
- что было сделано вчера;
- какие возникли трудности;
- какие задачи будут решаться сегодня.
Команда ежедневно синхронизируется и обменивается информацией. Каждый понимает, кто чем занимался вчера, у кого появились проблемы и какие задачи команда планирует сделать сегодня. Ежедневные встречи — крутой инструмент, чтобы отслеживать движение продукта как к цели спринта, так и самого проекта.
Показывать заказчику результаты
Когда один или несколько циклов разработки заканчиваются, команда вместе с заказчиком собираются на встречу. Команда показывает клиенту готовую часть продукта и вместе с ним обсуждает, как можно улучшить проект.
В Purrweb демо-презентация готового «куска» приложения проводится каждые 2 недели. На тестовом сервере запускается готовый фрагмент, над которым команда работала в течение спринта. Заказчик «трогает» продукт. Заказчик видит прогресс. Заказчик доволен.
Учиться на ошибках
После демо-презентации, команда собирается на ретроспективу — еще одну встречу, но уже без заказчика. Scrum-мастер и разработчики анализируют прошедший спринт и учатся на ошибках: обсуждают проблемы и полученный опыт.
Однажды на созвоне с заказчиком я полчаса рассказывал про все, что мы сделали за спринт. Получилось так, что мы не успели собрать демо-версию и мне пришлось тянуть время, пока разрабы все подготовят. На ретроспективе мы это обсудили и составили action step (AS) разработчику: собирать демо-версию за день до созвона с заказчиком. Больше таких казусов не случалось. Для этого и нужны ретро.
Когда мы начинали внедрять Scrum, у нас не было ретроспективы. Только сформированная команда не понимает своей скорости работы, в чем она хороша, а в чем проседает. Участники только-только «принюхиваются» друг к другу. Как следствие — команде тяжело. Ретро нужно, чтобы людям стало проще работать вместе.
Ретроспектива помогает понять, что у команды круто получается, что — так себе. Следующий шаг — определить AS, чтобы превратить минусы в плюсы и не допускать ошибок в будущем. Следующую ретроспективу мы начинаем с проверки выполнения AS: все ли сделали работу над ошибками.
Почему SCRUM особенно хорош для управления стартапа и MVP
Мы разрабатываем стартапы и MVP с 2014 года, за это время у нас были разные подходы к проектному менеджменту. Мы рассказали, как работает Scrum в теории и как на практике, и уверенно можем сказать, что он хорош для разработки и управления стартапа и MVP. Потому что:
- каждый в команде знает текущие задачи и проблемы;
- в конце каждого спринта команда учится на ошибках;
- бэклог проекта может меняться;
- приоритеты могут меняться;
- заказчик видит прогресс и контролирует движение проекта к цели;
- команда всегда готова расширить свой состав, если кто-то отвалится по болезни или будет не успевать.
Строгая последовательность разработки заменяется спринтами. Так команда может оперативно менять список задач: одни добавить, вторые детализировать, а третьи выкинуть. Бэклог проекта постоянно меняется — на релизе продукт приобретает новые функции и избавляется от ненужных. Заказчик с первого спринта наблюдает за состоянием продукта и принимает решение: добавить или удалить функцию, продолжить или остановить разработку.
Скрам — это не набор инструкций, а идеология, у которой есть 3 столпа: прозрачность, проверка и адаптация. Прозрачность помогают внести daily, Jira на разработке и Trello на дизайне. Проверка — ретроспектива, а адаптация — развитие точек роста, которые мы выявили на ретро. Вот это и есть сердце Скрама, которое «бьется» в наших рабочих процессах.
Мы придерживаемся этой идеологии, но нужно понимать, что универсального решения нет. Когда у нас только появились крупные проекты — появились проблемы: выходили за рамки сроков и бюджета. Мы начали выяснять, откуда они появились и как исправить ситуацию в лучшую сторону.
В итоге пришли к тому, что у нас есть сейчас. Благодаря тому, что рабочие процессы абсолютно прозрачны, мы 24 на 7 их инспектируем, чтобы решать проблемы в зачаточном состоянии. Наши рабочие процессы не стоят на месте: постоянно меняются и адаптируются под меняющиеся требования.
Не нужно хвататься за все новое и принимать это как истину. Нужно попробовать, разобраться в этом, а дальше уже делать выводы. Закончить хотелось бы уместной цитатой Альберта Эйнштейна: «Самая большая глупость — это делать то же самое и надеяться на другой результат».
