Зрелость

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

Но внедрять такие изменения не просто: команда должна созреть до нужных принципов.

🤔 Пример

Допустим, мы хотим внедрить принцип из эджайл-манифеста «Изменение требований приветствуется, даже на поздних стадиях разработки, чтобы использовать изменения для обеспечения заказчику конкурентного преимущества».

Вот мы пришли в команду и сказали: «Ребята, теперь если заказчик приносит правки за 2 дня до релиза, то это ок». Менеджер толкнул классную речь и в итоге продал принцип команде. Казалось бы, теперь мы — эджайл-менеджмент-3.0.

😾Но вот часть проблем, с которыми столкнется команда, как только заказчик придет с правками за 2 дня до релиза:

• Сопротивление со стороны разработчиков, которые привыкли работать по плану и четкому ТЗ
• Заточенность технического решения под другие требования
• Возможные баги при внедрения нового решения и невозможность в срок их протестировать
• Объем изменений в принципе слишком большой для внедрения за 2 дня

🏋️ Получается, что за красивым принципом стоит огромный пласт работы со зрелостью команды:

• Изменить майндсет разработчиков и научить их работать не только по ТЗ, но и по изменяющимся требованиям
• Вырастить в команде архитекторов, которые применяют принципы эволюционной архитектуры
• Научить QA-инженеров предвидеть возможные изменения
• Внедрять культуру встреч с заказчиком, чтобы в принципе не было ситуации, что за 2 дня принесли много изменений

😎 Итого Простое провозглашение «Теперь делаем так!» не даст нужного эффекта просто так. От менеджера требуется вскрыть, что сделать еще: какие процессы поменять, какие добавить. Какие компетенции в команде прокачать. Где изменить мышление и отношение к делу. Менеджеру нужно упорно и возможно долго работать для внедрения изменений. И только тогда команда дозревает до нужного красивого принципа.