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

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

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

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

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

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

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

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

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

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

Скрам с конца

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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