Меня зовут Евгений Бережной. 4 года назад я начал изучать Agile и влюбился в эту методологию. С тех пор я занимаюсь ее внедрением в ИТ (и не только) компании.
В этом году мы с партнером основали компанию AskTeam по внедрению Agile и принципов регулярного менеджмента. Здесь я буду приводить наши кейсы, которые мы решали, и методы, благодаря которым добивались результатов.
Кейс WhiteList
Срок реализации проекта апрель 2022 — август 2022
Как было до внедрения проекта?
Команда из 10 разработчиков + Тимлид. Сроки релиза назывались “через 2 месяца” с ноября 2021г. На момент старта проекта (апрель 2022) релиз переносился два раза, но и в момент старта продукт был сырой.
Отношения в команде были, на первый взгляд, хорошими. Точнее, они хорошими и были — но понятие «хорошие” к бизнесу неприменимо. В бизнес-контексте они заменяются на “продуктивные” или »эффективные” — а вот с этим было несколько проблем.
- Первая — в команде было несколько локальных групп по 2-3 человека, которые довольно неплохо понимали, что делают коллеги внутри этой “мини-группы”, но имели очень смутное представление о том, что делается во всей остальной разработке.
- Вторая — рост менее экспертных членов команды, или, условно, джунов, был затруднен. Очень запомнилась фраза одного синьора фронт-эндера по отношению к джуниору-фронтендеру: “Я могу судить по его знаниям только по резюме, потому что с мы с ним особо не взаимодействуем”. Для полноты картины стоит сказать, что джуниор устроился на работу в январе того года, то есть прошло более трех месяцев.
- Третья — периодические личные конфликты. Не открытые, скорее, “закулисные”. Вообще конфликты — это хорошо, они позволяют увидеть и скорректировать слабые места в системе, генерировать новые идеи, смотреть на некоторые аспекты с разных углов. Но это мы говорим про конструктивные конфликты — здесь же они были деструктивными и заканчивались негативными эмоциями и отсутствием договоренностей.
- Четвертая — бэклог. Формально он был. Точнее, были отдельные таблицы у учредителя, директора, эксперта-трейдера, продакт-менеджера и тимлида. У каждого было свое понимание того, что делать дальше, и, как часто бывает в таких случаях, у разработчика было несколько разнонаправленных задач от разных ролей, причем срок был “желательно вчера, в крайнем случае сейчас”.
Какую задачу мы решали?
Вообще мы всегда начинаем с вопроса целеполагания. По опыту, в 100% случаев изначальные цели не были четко обозначены, мы в процессе нескольких коучинговых сессий выявляли глубинные цели и составляли план по их достижению. Да, все мы знаем, что зафиксированная цель во-первых, позволяет нам меньше
А во-вторых такая записанная цель сильно повышает вероятность ее достижения. Но, парадокс, крайне мало компаний этими знаниями пользуются. Все это очень напоминает ставший уже классикой анекдот с окончанием “Некогда пилу точить, нам пилить нужно”:)
Итого, основными целями на ближайшие 3 месяца стала цель «релиз переписанного основного продукта командой, работающей по SCRUM-у” и »сформированный бэклог задач на следующие 6 месяцев с согласованными дорожными картами 3 core-фичей для реализации в ближайшие 3 месяца”. Для этого, к слову, нам понадобилось всего 3 коуч-сессии с учредителем и 2 групповые с якорным кругом компании.
Что мы сделали?
После двух недель присутствия в команде все проблемы были зафиксированы и вынесены на общую встречу с собственниками бизнеса. Далее эти проблемы мы превратили в задачи и начали их решать. За что мы любим Agile — за то, что при внедрении большинство проблем во взаимоотношениях решаются ребятами самостоятельно, со стороны команды это выглядит как решение проблем “само собой”.
Во-первых, мы провели обучение команды и собрали у них те «зоны роста”, которые они сами видят. Всегда, кстати, интересно наблюдать, как в первый раз люди обозначают только часть проблем, но со временем раскрываются и уже более доверительно проговаривают те сложности, о которых »я не знал что можно говорить”.
Во-вторых, мы поделили команду на 2 примерно равные группы и поставили их на рельсы SCRUM. Для ребят это изначально выглядело как «внедрение какого-то расписания”, фиксация своих планов на общих собраниях и »отчетность”. Первые собрания были, скорее, настороженные — но уже к концу первого спринта сознание Команды начало меняться. В конце первого же двухнедельного спринта от одного из разработчиков было приятно услышать “офигеть, как это работает — я теперь, наконец, могу подстраивать свою работу под результаты других, не тратить время на ожидание”.
Так как команду мы поделили по направлениям (бэк+девопс и фронт+дизайн), разработчики одного профиля теперь синхронизировались друг с другом, и часто консультировались или запрашивали помощь сразу на дейликах. Здесь в первый месяц мы осознанно проводили мягкую фасилитацию, позволяя выступающему на дэйлике говорить чуть дольше и несколько отходить от четкого формата дэйлика — важнее было наладить взаимодействие. Следствием этого стало сближение, и даже появились первые проблески наставничества.
Параллельно мы ввели регулярные (сначала 1 раз в неделю, позже — 1 раз в 2 недели) встречи бизнеса и продакт-менеджера (в SCRUM он выступал, конечно, в роли PO). Здесь важно было не потерять ничего важного, и в то же время сделать единый бэклог и научить всех продуктивному взаимодействию. Никакого “коридорного” менеджмента, когда идеи сыпались когда и кому придется — теперь все идеи мы обсуждали строго на регулярных встречах. Уже на третью встречу взаимодействие стало конструктивным, идеи фиксировались, сортировались и приоритезировались.
Когда команда сработалась, конфликтов на прежнем уровне уже не было, но все же мы провели отдельные встречи по решению конфликтов. Научили принципам экологичности, разобрали старые, немного поиграли в создание и конструктивное разрешение будущих конфликтов.
Какой результат?
Уже через 8 недель после старта проекта вышел релиз на альфа-группу, и еще через спринт продукт был готов. Команда работала по SCRUM, все более в него углубляясь. Первая цель была достигнута.
Срез по второй цели мы провели через 2,5 месяца — бэклог был наполнен задачами более чем на полгода, было выделено 9 core-фичей, из которых на четыре были расписаны дорожные карты. Вторая цель так же done.
Что дальше?
Мы придерживаемся следующего подхода: после построения команды и внедрения методологий, мы “отпускаем” команды минимум на 3 месяца. Это сильно повышает их автономность и дает возможность создать свою неповторимую атмосферу Команды.