Назад

Проектный менеджмент и SCRUM: как, зачем и почему?

Мы в Purrweb занимаемся разработкой проектов с 2014 года. За это время выстроили собственные процессы в дизайне, разработке и управлении проектами. Не боялись экспериментировать: перепробовали много подходов, где-то спотыкались, где-то падали, но всегда учились на ошибках. Я Анастасия Енина, руководитель проектного менеджмента в Purrweb, и я хочу рассказать о том, как мы применяем методологию управления проектами Scrum на практике.

Время чтения: 9 минут

Scrum: управление проектами на практике
Содержание

    Проектный менеджмент до появления SCRUM

    Пока не появилась гибкая методология управления проектами, компании традиционно использовали каскадный («водопадный») подход. Этапы работы над проектом следовали друг за другом: 

    Scrum: управление проектами на практике

    Заказчик приходил и рассказывал о задаче. Требования к проекту превращались в подробное техническое задание, сразу разрабатывались дизайн-макеты проекта. Разработчики получали отдельные ТЗ и приступали к работе после утверждения дизайна. Команда тестировала проект, исправляла ошибки и доводила продукт до готовности. Звучит хорошо и в теории каскадный подход работает. Но на практике все не так гладко.

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

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

    Простой пример: на одном проекте у нас проблема с внедрением платежной системы Stripe в приложение. Мы нашли альтернативное решение: внедрили Braintree вместо того, чтобы пытаться установить Stripe любыми способами. Если бы мы работали по каскадному подходу — вышли бы за рамки сроков. Пришлось бы пытаться внедрить Stripe, либо менять документацию и согласовывать это с заказчиком, если бы решили использовать другую платежную систему. На все это уйдет немало времени.

    В digital-сфере невозможно предсказать все проблемы, а в большом проекте тем более. Каскадный подход игнорирует динамические изменения. Есть ТЗ, которому команда следует на всем процессе разработки. Проект делается за один раз — его никак не переделаешь. После определения требований к проекту сложно заложить функции, не учтенные на первых стадиях разработки. Любое изменение в документации нужно согласовывать с заказчиком.

    Переосмысление проектного менеджмента: как эффективно запускать стартап

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

    Гибкий подход начал вытеснять традиционные методы работы. Подробные ТЗ исчезли, коммуникаций с клиентом стало больше, а дедлайны соблюдались. Через несколько лет Agile превратился в Манифест гибкой методологии разработки, содержащий все принципы подхода.

    Компании уже применяли на практике эту методологию, но только после обнародования о ней узнали массы. Со временем подход Agile обзавелся новыми методологиями: Lean, XP, Scrum, Kanban. Остановимся на двух последних — расскажем про свой опыт работы с ними.

    Визуализация, ограничение времени и задач, непрерывная работа — лицо подхода Kanban. Обязательный элемент — доска. На нее переносятся планируемые задачи. У доски есть списки, которые отражают этапы проекта. Каждая карточка в списке — задача. Она, получив новый статус, последовательно перемещается из одного столбца в другой (в Kanban это называется потоком). Если этот пункт не соблюдать — подход не работает.

    Scrum: управление проектами на практике

    Дмитрий Ларин

    Мы работаем по Скраму в любом случае и на дизайн-проектах используем Канбан-доску как таск менеджер. На разработке мы используем Jira, а на дизайне — Trello. Канбан-доска как способ организации таск менеджера — да. Trello, как инструмент — да, но скоро будет нет.

    Дмитрий Ларин 
    , проектный менеджер в Purrweb

    В Scrum работа над проектом разделяется на короткие этапы (спринты) с четкими рамками: обычно один спринт длится от 2 до 4 недель. В течение цикла команда ежедневно встречается, чтобы оценить ход работы и обменяться информацией по проекту. В конце спринта команда тестирует готовый «кусок» продукта и демонстрирует его заказчику.

    Основные принципы фреймворка, которые помогают командам в работе:

    1. Гибкий список задач.
    2. Ежедневные встречи.
    3. Готовность к изменениям.
    4. Разделение проекта на этапы.
    5. Коммуникации внутри команды.

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

    Команда, работающая над проектом

    Обычно в команде не больше 9 разработчиков, плюс владелец продукта и Scrum-мастер. Участников может быть больше — никто вас за это не съест. Но координировать работу будет сложнее, к этому нужно быть готовым. Scrum-команда самоорганизовывается: сама решает, как выполнить работу. Так работает в теории. О практике мы поговорим чуть позже.

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

    Scrum-мастер налаживает коммуникации внутри команды и помогает ей справляться с трудностями. Его главная задача — объяснить принципы методологии. Scrum не работает, если не все в команде их понимают.

    Команда разработчиков — обычно это 5-7 человек, которые разрабатывают продукт. У каждого своя зона ответственности и задачи, но вместе они отвечают за достижение цели спринта. «Разработчик» — не обязательно программист. Это может быть любой специалист, например QA инженер или дизайнер.

    Состав команды в «боевых» условиях

    Светлана Колпакова

    Scrum-мастер и Владелец продукта у нас — это проектный менеджер. Так почти в каждом проекте. Почему? Вот, например, у меня есть проект. Одна задача может быть расписана в пару словах, а может — в нескольких абзацах. Всего на проекте 1211 задач. Владелец продукта должен вести бэклог, расписывать и приоритизировать задачи. В большинстве проектов заказчик этим не занимается, но все зависит от договоренностей. На одном проекте мы негласно делим с заказчиком обязанности: он периодически кидает задачи в бэклог, описывает их и обозначает приоритет.

    Светлана Колпакова 
    , проектный менеджер в Purrweb

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

    Бывало, что заказчику нужно выйти в релиз через месяц. Оцениваем объем работ — понимаем, что обычной командой (проектный менеджер, дизайнер, 2 программиста и тестировщик) не уложимся в сроки. Тогда подключаем к проекту столько людей, сколько потребуется.

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

    Антон Кирюхин

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

    Антон Кирюхин 
    , проектный менеджер в Purrweb

    Как выстраивать работу в Scrum

    Scrum — это не универсальное решение в работе, с которым каждый проект будет взлетать. Слепо внедрять все артефакты — не всегда хорошо на практике. Мы до сих пор изучаем Scrum и подстраиваем его под себя. Управлять проектом стало проще, команда работает продуктивнее и это только начало.

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

    Вести бэклог проекта

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

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

    Антон Кирюхин

    В Purrweb бэклог проекта ведет проектный менеджер на основе желаний заказчика. Если разработчик понимает, что какую-то фичу нужно реализовывать по-другому, иначе она будет плохо работать или не будет вообще — бэклог проекта меняется. Это и есть та необходимая гибкость в управлении проектами.

    Антон Кирюхин 
    , проектный менеджер в Purrweb

    Задачи в бэклоге располагаются в приоритетном порядке: команда обсуждает проект и договаривается: что нужно сделать в первую очередь, чтобы выполнить цель спринта. Крупные компании как Google и Amazon используют такие критерии приоритизации бэклога, как Impact/Effort, Feature buckets, User Story Mapping и MoSCoW.

    Светлана Колпакова

    На приоритизацию задачи влияет здравый смысл, заказчик, разработчики и тестировщик. Мы с тимлидом раскидали задачи по спринтам на планировании. Разработчики обсуждают, что нужно сделать за спринт и распределяют работу между собой. Бывает, что заказчику нужно показать часть готового функционала инвесторам. Проект — 3 месяца, а он обещал инвесторам через 3 недели показать готовый «кусок». Естественно, мы эту часть разработаем на первом спринте. Так заказчик влияет на приоритизацию задач.

    Светлана Колпакова 
    , проектный менеджер в Purrweb

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

    Светлана Колпакова

    User Story Mapping у нас уже применялся на разработке, а недавно появился и на дизайне. Как это работает: бизнес-аналитик составляет документ с пользовательскими сценариями. Мы оцениваем его и отдаем в дизайн. Дизайнер составляет майндмэпу, которую мы презентуем заказчику. Он говорит: «это именно то, чего я и хотел». Обычно, когда заказчик приходит с проектом, у него уже что-то есть. Ко мне, например, однажды пришел клиент с уже готовой майндмэпой.

    Светлана Колпакова 
    , проектный менеджер в Purrweb

    Делить проект на спринты

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

    Антон Кирюхин

    Оптимальная длина спринта для нас на разработке — 2 недели. За одну неделю команда не так много сделает, чтобы показать результат заказчику. Больше 2-х недель — заказчик долго не видит готовую часть продукта, ему сложнее отслеживать движение проекта к цели.

    Антон Кирюхин 
    , проектный менеджер в Purrweb

    Ежедневно встречаться

    В начале каждого дня команда собирается на дейли. Участники встречаются примерно на 15 минут и обсуждают:

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

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

    Показывать заказчику результаты

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

    В Purrweb демо-презентация готового «куска» приложения проводится каждые 2 недели. На тестовом сервере запускается готовый фрагмент, над которым команда работала в течение спринта. Заказчик «трогает» продукт. Заказчик видит прогресс. Заказчик доволен.

    Учиться на ошибках

    После демо-презентации, команда собирается на ретроспективу — еще одну встречу, но уже без заказчика. Scrum-мастер и разработчики анализируют прошедший спринт и учатся на ошибках: обсуждают проблемы и полученный опыт.

    Антон Кирюхин

    Однажды на созвоне с заказчиком я полчаса рассказывал про все, что мы сделали за спринт. Получилось так, что мы не успели собрать демо-версию и мне пришлось тянуть время, пока разрабы все подготовят. На ретроспективе мы это обсудили и составили action step (AS) разработчику: собирать демо-версию за день до созвона с заказчиком. Больше таких казусов не случалось. Для этого и нужны ретро.

    Антон Кирюхин 
    , проектный менеджер в Purrweb

    Когда мы начинали внедрять Scrum, у нас не было ретроспективы. Только сформированная команда не понимает своей скорости работы, в чем она хороша, а в чем проседает. Участники только-только «принюхиваются» друг к другу. Как следствие — команде тяжело. Ретро нужно, чтобы людям стало проще работать вместе.

    Ретроспектива помогает понять, что у команды круто получается, что — так себе. Следующий шаг — определить AS, чтобы превратить минусы в плюсы и не допускать ошибок в будущем. Следующую ретроспективу мы начинаем с проверки выполнения AS: все ли сделали работу над ошибками.

    Почему SCRUM особенно хорош для управления стартапа и MVP

    Мы разрабатываем стартапы и MVP с 2014 года, за это время у нас были разные подходы к проектному менеджменту. Мы рассказали, как работает Scrum в теории и как на практике, и уверенно можем сказать, что он хорош для разработки и управления стартапа и MVP. Потому что:

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

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

    Дмитрий Ларин

    Скрам — это не набор инструкций, а идеология, у которой есть 3 столпа: прозрачность, проверка и адаптация. Прозрачность помогают внести daily, Jira на разработке и Trello на дизайне. Проверка — ретроспектива, а адаптация — развитие точек роста, которые мы выявили на ретро. Вот это и есть сердце Скрама, которое «бьется» в наших рабочих процессах.

    Дмитрий Ларин 
    , проектный менеджер в Purrweb

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

    В итоге пришли к тому, что у нас есть сейчас. Благодаря тому, что рабочие процессы абсолютно прозрачны, мы 24 на 7 их инспектируем, чтобы решать проблемы в зачаточном состоянии. Наши рабочие процессы не стоят на месте: постоянно меняются и адаптируются под меняющиеся требования.

    Не нужно хвататься за все новое и принимать это как истину. Нужно попробовать, разобраться в этом, а дальше уже делать выводы. Закончить хотелось бы уместной цитатой Альберта Эйнштейна: «Самая большая глупость — это делать то же самое и надеяться на другой результат».

    Насколько публикация полезна?

    Оцени эту статью!

    19 оценок, среднее 4.4 из 5.

    Оценок пока нет. Поставьте оценку первым.

    Так как вы нашли эту публикацию полезной...

    Подписывайтесь на нас в соцсетях!

    Поделиться