Статья
Когда мотивация команды утекает сквозь пальцы: как пересмотреть практики управления
Во время работы с руководителем подразделения над мотивацией команд разработчиков мы столкнулись с парадоксом. Лидеры команды – вовлечены в релиз, чувствуют драйв, ответственность, азарт, а рядовые участники – нет. Вопрос очевидный: «Мы что, другие? Или это они – другие?»
Разбираемся, почему так происходит. Меня учили, что бытие определяет сознание. Поэтому – анализируем «бытие» команд разработчиков, точнее практику управления, в которой эти команды работают, дизайн существующей системы с точки зрения:
коммуникаций
принятия решений
вовлечения команды в принятие решений
Обнаруживаем проблему:
Лидеры – чувствуют «нерв бизнеса», напрямую взаимодействуют с пользователями, заказчиками и руководством, буквально «смотрят этим людям в глаза». И я не скажу, что это всегда легкое зрелище.
Команда – получает поток декомпозированных задач в GitLab. Каждый знает свою «часть слона» и не видит целостной картины продукта, не понимает его ценность.
Разработчики не знают своих пользователей, не слышат слова представителей бизнеса – не отдают себе отчёт в том, какой офигенный продукт ваяют. У них просто нет «организационного пространства», где все вместе могут пережить.
Как это исправить?
1. Включить команду во встречи с конечными пользователями и руководством (найти им роль и функционал для встреч, структурировать встречи так, чтобы у команды появилось пространство для участия)
2. Включить команду в обсуждение архитектурных решений, планирование релиза, формирование бэклогов проекта и спринта (чётко сформулировать их роль и долю ответственности
3. Обращаться на митапах к той реальности, которую команда «прочувствует на своей шкуре» во время вовлекающих мероприятий (добавить в структуру совещаний обращение к вопросам из «той реальности»)
4. Ставить перед командой вопросы оперативного управления: смотрите, мы решили идти с такой скоростью, а идём значительно медленнее – что будем делать? Мы вместе выбрали это решение и теперь видим, что получается криво – что будем делать? И реально совместно искать выход.
Эксперимент запущен. Уже через несколько недель мы увидим, как изменится отношение команды к своему продукту.
Разбираемся, почему так происходит. Меня учили, что бытие определяет сознание. Поэтому – анализируем «бытие» команд разработчиков, точнее практику управления, в которой эти команды работают, дизайн существующей системы с точки зрения:
коммуникаций
принятия решений
вовлечения команды в принятие решений
Обнаруживаем проблему:
Лидеры – чувствуют «нерв бизнеса», напрямую взаимодействуют с пользователями, заказчиками и руководством, буквально «смотрят этим людям в глаза». И я не скажу, что это всегда легкое зрелище.
Команда – получает поток декомпозированных задач в GitLab. Каждый знает свою «часть слона» и не видит целостной картины продукта, не понимает его ценность.
Разработчики не знают своих пользователей, не слышат слова представителей бизнеса – не отдают себе отчёт в том, какой офигенный продукт ваяют. У них просто нет «организационного пространства», где все вместе могут пережить.
Как это исправить?
1. Включить команду во встречи с конечными пользователями и руководством (найти им роль и функционал для встреч, структурировать встречи так, чтобы у команды появилось пространство для участия)
2. Включить команду в обсуждение архитектурных решений, планирование релиза, формирование бэклогов проекта и спринта (чётко сформулировать их роль и долю ответственности
3. Обращаться на митапах к той реальности, которую команда «прочувствует на своей шкуре» во время вовлекающих мероприятий (добавить в структуру совещаний обращение к вопросам из «той реальности»)
4. Ставить перед командой вопросы оперативного управления: смотрите, мы решили идти с такой скоростью, а идём значительно медленнее – что будем делать? Мы вместе выбрали это решение и теперь видим, что получается криво – что будем делать? И реально совместно искать выход.
Эксперимент запущен. Уже через несколько недель мы увидим, как изменится отношение команды к своему продукту.