Как мотивировать команду на достижение общей цели? Как правильно сформулировать эту цель? Спускать ли ее сверху или делегировать ответственность в команду? С какими проблемами можно столкнуться в процессе целеполагания?
Недавно я перешла работать в новый проект проектным и линейным менеджером. Сразу ввела практику в Maintenance команде проводить DEMO-Ретроспективу раз в месяц. Чтобы проводить анализ результатов, которых команда добилась за месяц, обсуждать, что можно улучшить в следующем месяце, чтобы добиться лучших результатов.
Итак, с какими проблемами я столкнулась при постановке командных целей:
1. Целей нет
На первом же DEMO-Ретро митинге столкнулась с тем, что команда не представляет, какие перед ней стоят цели. Да, краем уха слышали, что есть какие-то проектные метрики. Но какое отношение они имеют к ним? Соответственно, когда я решила подстветить отрицательные результаты и области для улучшения, столкнулась с волной сопротивления: «С чего это ты решила, что мы плохо работаем? Почему мы должны выполнять эти метрики?»
2. Нет понимания ожиданий заказчика от команды и ценности для заказчика
Совершенно не было понимания у команды, кто для них является заказчиком и какую ценность они делают для заказчика, что в их работе не несет никакой ценности для заказчика и является потерями (времени, ресурсов).
3. Сопротивление изменениям
Как правило, люди не любят перемен, потому что перемены — это выход из зоны комфорта, и сопротивляются им изо всех сил.
В теории ограничений хорошо описаны слои сопротивления, и как с ними работать. В первую очередь необходимо показать команде, что есть проблема (иначе нет смысла меняться).
На дополнительном митинге мы обсудили, кто является заказчиком для команды, какую ценность команда делает для заказчика (находит и устраняет баги в коде, делает импрувменты, проводит тесты…). Я донесла команде ожидания заказчика: для заказчика важно не просто делать свою работу качественно и в срок, но и уметь анализировать результаты, делать выводы, постоянно улучшаться, предлагать, как можем сократить стоимость разработки, как сделать меньшими усилиями больше, что можем оптимизировать, автоматизировать, как можем уменьшить стоимость maintenance, чтобы больше ресурсов было на новые фичи. После этого мы вместе проанализировали текущее положение дел. Как выяснилось, по многим показателям команда отстает от ожиданий, определили области с отставанием. Перевели ожидания заказчика в понятные и измеримые метрики проекта и команды, например:
- проактивность — в количество предложенных и сделанных импрувментов
- уменьшение стоимости мейнтенанса — в количество приходящих багов
- оптимизацию процесса — в lead time и cost per bug
4. Спускание целей сверху
На первом митинге я спустила команде информацию (об ожиданиях, метриках и плане действий) «сверху». Нарисовала красивую презентацию, рассказала, команда с умным видом слушала и кивала. Но этого недостаточно для того, чтобы команда эти цели разделяла. Как вы думаете, на следующем ДЕМО-Ретро митинге хоть кто-то ответил мне, какие ожидания от нас заказчика и какие цели в команде?
Поэтому на втором митинге мы собрались с командой, и я им дала несколько заданий, на время:
- Написать, какие сейчас цели у команды? (рассуждали о том, что запомнили с предыдущего митинга, вспомнили процентов 30)
- Описать, какие ожидания у заказчика от команды? Какие есть критерии оценки нашей работы относительно этих ожиданий? И как команда оценивает себя сейчас по этим параметрам.
- Обсудив ответы на предыдущие 2 пункта, вспомнив, что такое SMART, сформулировать цели на ближайший месяц.
После этой встречи начало формироваться понимание целей у команды. Но этого явно недостаточно. Здесь тоже действует Agile: итеративно и последовательно приводим команду к правильному майндсету, чтобы команда понимала, что они не просто так ходят на работу, чтобы высиживать по 8 часов, а чтобы стремиться к выполнению определенных целей.
5. Визуализация целей
Мало обозначить цели, обязательно нужно сделать эти цели видимыми и понятными.Например, что значит для команды cost per bug (затраты времени на решение баги) 40 часов? Это пустой звук. Поэтому нужно перевести это в понятную для команды цель: закрыть за месяц 10 багов.
Прогресс движения к целям должен быть понятен для команды. В примере с cost per bug, каждый день надо отмечать, сколько уже закрыто багов и сколько осталось закрыть до конца месяца.
Скрам мастер/Тим лидер должен делать упор на цели во время ежедневных митингов:
- идем ли мы по плану?
- есть ли риск не выполнить цели?
- что мы можем сделать, чтобы выполнить все цели до конца месяца?
- что нам нужно (какие ресурсы), чтобы выполнить эту цель?
6. Почему я, программист, должен вообще об этом задумываться?
Я встретила большое сопротивление, как со стороны дизайнеров, так и со стороны тим лидеров: зачем это вообще нужно? Ведь программисты нанимались программировать, а не цели себе ставить, ставить цели и назначать работу — задачи тим лидера. Но, я считаю, что это все равно нужно делать, регулярно и последовательно. Задумываться о таких вещах, как цели проекта и команды, полезно, это развивает осознанность, придает значимость работе команды и, в конце концов, общие цели становятся объединяющим фактором для команды.
