Меняем способ организации команды.

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

Однако, принципиальным вопросом для успеха таких преобразования является наличие хороших руководителей. Если у вас в компании их достаточно, или вы умеете их привлекать, то в сохранении традиционного стиля управления нет проблем. Однако, обычно именно руководители группы являются дефицитной позицией. Особенно когда работа группы предполагает вовлечение всех ее участников и достижение синергии коллективного взаимодействия – а именно это нужно при работе с новыми продуктами в режиме неопределенности VUCA-мира или при недостатке компетенций. Для этого руководитель должен работать через делегирование, в коучинговом или менторском режиме, а в стиле раздачи поручений. Конечно, книги по менеджменту и лидерству полны призывов именно к такому способу управления, но какой процент таких руководителей вы видели на практике? Очень мало.

Agile-методы, особенно Scrum, решают эту проблему не за счет личных качеств руководителя, а за счет организации процесса. Кроме того, Scrum делит обязанности традиционного руководителя на три части: ответственный Product Owner за продукт, ответственность Scrum Master за самоорганизацию команды, и ответственность команды в целом. Разделение ответственности, передача ее части команде используется и в других Agile-методах. И потому требования к каждой позиции снижаются, подобрать подходящих людей становится легче. А прозрачность работы команды в Agile-методах позволяет наблюдать за происходящим и корректировать при необходимости, помогая команде преодолевать проблемы.

Отметим, что развитие IT показало, что при сохранении принципиального разделения ответственности за продукт и за организацию, детальное разделение ответственности в разных компаниях отличается очень сильно. Недавно Егор Толстой и Стас Цыганов организовали в IT-сообществе сбор полного MindMap управленческой ответственности команды, результаты опубликованы на GitHub и доступны. В статье – картинка, а по ссылке можно скачать себе полный mindmap и внести свой вклад в обсуждение. И хотя эта работа сделана на материале IT-отрасли, в ней много общезначимых пунктов и вы можете подумать о применении его в рамках своей отрасли, выполнив адаптацию сами или организовав аналогичное обсуждение в профессиональном сообществе. А потом – подумать о том, как ответственность разделяется в вашей компании: что находится внутри команды и как именно распределено, что передано руководителю следующего уровня, за что отвечает инфраструктура и техноструктура, увидеть упущенные или провисающие фокусы ответственности.

Так же я хочу поговорить о вариантах перехода от традиционной иерархии к организации с разделением ответственности. Пусть у нас есть отдел продаж, и мы хотим в нем перейти на Scrum с тем, чтобы получить эффекты от командной работы и убрать потери от индивидуализма продавцов. Может показаться, что это совершенно бесперспективная задача, чистое теоретический кейс, потому что «всем известно», что продавцы – яркие индивидуалисты, у них к тому же обычно стоит индивидуальный KPI по продажам – какая тут командная работа и сотрудничество? Между тем, эти кейсы – вполне реальны, более двух лет назад я слышал на IT-Spring от Марины Симоновой (