Такман – перезагрузка

Когда я впервые столкнулся с моделью групповой динамики Такмана (forming-storming-norming-performing), то меня заинтересовало, как оно работает на реальных IT-проектах. Ведь процесс все время должен перезапускаться – кто-то приходит, кто-то уходит (в отпуск, на другой проект, на другую работу) – так до стадии полноценного функционирования можно вообще не дойти… Кроме того, есть случаи когда хочется самому перезапустить процесс. Например – при “нерабочей атмосфере на проекте”.

Сейчас я читаю книгу Тимура Гагина “Модели НЛП в работе психолога”, и там приведены интересные рекомендации и численные оценки. Давайте посмотрим, при каких условиях перезапуститься IT-команда:

Введение-выведение значимых людей

Значимые – это те, которые участвуют в большом количестве обсуждений и их голос учитывается. Пятый девелопер врядли сильно повлияет на картину, а вот PM – может повлиять сильно. В зависимости от квалификации, конечно. В первую очередь – от готовности и умения отстаивать свою точку зрения.

Резкое изменение состава

Треть и более. Если у вас на проекте нерабочая атмосфера – смените состав резко. По одному – будут ассимилироваться.

Открытый конфликт

Если все было долго тихо, а тут возник большой конфликт – групповая динамика может перезапуститься. Как пример:

• Пришел новый менеджер в проект-‘сонное болото’ и начал всех строить. Кто-то уйдет, возможно – выдавят менеджера, и динамика перезапуститься;
• Кто-то принесет конфликт из дому;
• Переезд в новый офис с дележом хороших и плохих мест.

Регулярные провалы команды

Тут важно, чтобы фейлы воспринимались именно как фейлы. Для кого-то это будет “пятый спринт не можем сделать нормального тестирования”, а для кого-то не будет и “за полгода пятый проект проваливаем и заказчика разоряем”. Так что в зависимости от потребностей – усиливаем или ослабляем “ощущение провала” у сотрудников.

Завершение проекта и переход в другую фазу

Тут понятно и почти неизбежно. Изменение состава и перспектив.

Резкое ухудшение окружающего мира

• Экономический кризис;
• Появление серьезного конкурента. Актуально для продуктовой разработки;

Резкая смена ниши проекта

IMHO, маловероятно в реальных условиях.

• Раньше писали приложение для суперсервера, а теперь портируем его на мобильные устройства. Другая архитектура, другие специалисты становятся ведущими и т.д.
• Было аутсорсинговое приложение с одним заказчиком, а теперь будем работать по продуктовой модели с 10000+ пользователей. Повлияет только если каждый сотрудник будет контактировать с пользователями.

PS: Картинка взята у Славы Панкратова.