Колонки

«Копипаст не работает»: как попытаться внедрить scrum — и пойти своим путем

Колонки
Елена Шутова
Елена Шутова

менеджер проектов Puzzle English

Ольга Лисина

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

Но делать все по учебнику не всегда получается, да и в реальности все может работать не так, как в книжке. Менеджер проектов Puzzle English Елена Шутова рассказывает, как в компании с переменным успехом пытались внедрить scrum, а в итоге адаптировали этот фреймворк под себя.

«Копипаст не работает»: как попытаться внедрить scrum — и пойти своим путем

В 2014 году мы получили инвестиции в размере $500 тыс. и продолжили воплощать в жизнь задуманное — развивать новые сервисы, создавать мобильные приложения и искать точки роста. Наши ряды пополнили новые сотрудники, и уже в 2016 году было ясно, что нужна другая система мотивации и управления персоналом.

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

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

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

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


Первый скепсис

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

Когда мы впервые серьезно заговорили в компании про скрам, многие коллеги отреагировали скептически. Оказалось, некоторые из них были травмированы неудачным опытом работы по скраму и были уверены в том, что все «эти ваши странные ритуалы» бесполезны.

Скептики опасались двух проблем: 

  1. Хаоса — непонимания, как все должно работать и кто теперь ответственный.
  2. Траты времени на «бесконечные» встречи (скрам предполагает четыре формальных события для инспекции и адаптации: планирование спринта, daily, обзор спринта и ретроспектива спринта).

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


Скрам с конца

Бросить все и начать с начала — сложно. Чтобы минимизировать всеобщий стресс от перекройки процессов, попробовали начать с конца. Да, это был совсем не scrum, но идея похожа:

  • только один человек (product owner) отвечает за бэклог и транслирует пожелания и идеи бизнеса;
  • в понедельник определяем цель недели и составляем под нее отдельный список задач (бэклог спринта);
  • в конце недели отмечаем, что сделано, а что нет, почему не успели и с какими сложностями столкнулись.

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

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

  1. Разрыв коммуникации. 

    Кто-то изначально считал daily пустой тратой времени и утверждал, что у нас есть технологии (а еще можно посмотреть коммиты, позвонить в скайпе или написать в чатике, чтобы задать вопрос).

    Но в итоге они согласились, что ежедневные «пятиминутки» (почти как Daily Scrum) могут избавить от ситуаций, когда два человека обсудили между собой какие-то изменения и проделанную работу, а до остальных эта информация не дошла — или кто-то забыл написать коммент к задаче. В общем, решили запустить ежедневные встречи для синхронизации.
  2. Сложности с рациональным распределением задач между членами команды разработки, определением четкой цели и плана ее реализации. 

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

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

    На этом этапе решили устраивать еще и ретроспективные встречи и обзоры. 

Так мы плавно подошли к пониманию необходимости соблюдения всей последовательности событий скрама.

Какое-то время мы честно выполняли все как в инструкции, написанной Джефом Сазерлендом и Кеном Швабером, и, сами того не желая, пришли к «копипасту скрама» (это когда действуешь четко по инструкции, но что-то не работает).


Что было дальше

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

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

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

Мы вместе проводим «обзор» прошедшей недели и планируем новую, параллельно разбирая ошибки. Получается своеобразный «обзор» и «ретроспектива» в одном. 

Это очень полезная для нас встреча — она помогает нащупать и обсудить слабые стороны, совместно спланировать и синхронизировать работу всех отделов, обсудить новые гипотезы и точки роста.

Дополнительно есть встречи у каждого отдела, по мере необходимости.


На данный момент мы:

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

Как достичь максимума

  • Копипаст не работает. Нельзя просто брать зарубежные подходы и напрямую внедрять в бизнес. Любые инструменты управления должны  переосмыслены в соответствии с менталитетом и корпоративной культурой, переработаны, иначе вы рискуете разрушить то, что хоть как-то работало и приносило свои плоды.
  • Мнение людей важно. Часто руководство спускает сверху указание работать по скраму, а сотрудники не очень понимают: зачем это надо, как это работает и что за детский сад с 15-минутными встречами. Сопротивление изменениям может убить их, поэтому важно найти путь внедрения технологии, который поможет сотрудникам принять ее.
  • Достигнутое — не предел. Внедрив скрам и решив насущные проблемы, стоит проанализировать, как он работает. А затем скорректировать процесс. И неоднократно.
  • Догмы непродуктивны. Любое авторитетное мнение стоит критически перепроверить. То, что хорошо для одной компании, может не подойти другой. Скрам — только один из возможных инструментов, и, вероятно, решая проблемы в своей компании и экспериментируя со скрамом, аджайлом, лином, вы разработаете некий новый более эффективный инструмент управления сложными процессами.

Фото на обложке: Shutterstock / Pixel-Shot

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Kanban или scrum: что лучше использовать?
  2. 2 Agile, scrum, kanban: в чем разница и для чего использовать?
  3. 3 Три распространенных ошибки тех, кто захотел перейти на Scrum

Актуальные материалы —
в Telegram-канале @Rusbase