Срок реализации проекта апрель 2022 — август 2022

Как было до внедрения проекта?

Команда из 10 разработчиков + Тимлид. Сроки релиза назывались “через 2 месяца” с ноября 2021г. На момент старта проекта (апрель 2022) релиз переносился два раза, но и в момент старта продукт был сырой.

Отношения в команде были, на первый взгляд, хорошими. Точнее, они хорошими и были — но понятие «хорошие” к бизнесу неприменимо. В бизнес-контексте они заменяются на “продуктивные” или »эффективные” — а вот с этим было несколько проблем.

Какую задачу мы решали?

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

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

Итого, основными целями на ближайшие 3 месяца стала цель «релиз переписанного основного продукта командой, работающей по SCRUM-у” и »сформированный бэклог задач на следующие 6 месяцев с согласованными дорожными картами 3 core-фичей для реализации в ближайшие 3 месяца”. Для этого, к слову, нам понадобилось всего 3 коуч-сессии с учредителем и 2 групповые с якорным кругом компании.

Что мы сделали?

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

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

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

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

Параллельно мы ввели регулярные (сначала 1 раз в неделю, позже — 1 раз в 2 недели) встречи бизнеса и продакт-менеджера (в SCRUM он выступал, конечно, в роли PO). Здесь важно было не потерять ничего важного, и в то же время сделать единый бэклог и научить всех продуктивному взаимодействию. Никакого “коридорного” менеджмента, когда идеи сыпались когда и кому придется — теперь все идеи мы обсуждали строго на регулярных встречах. Уже на третью встречу взаимодействие стало конструктивным, идеи фиксировались, сортировались и приоритезировались.

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