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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здесь можно оставить свои комментарии. Выпуск подготовленплагином wordpress для subscribe.ru