Кому передавать полномочия – командам или отдельным сотрудникам

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

В одном из моих недавних проектов участвовал сотрудник с определенным опытом в дизайне и верстке. Я мог бы поручить ему выбор логотипа для нашей компании. Но я предпочел, чтобы в данном случае решение принималось всей командой (четвертый уровень), поскольку посчитал целесообразным, чтобы все члены команды ощущали свою связь с общей целью, которую поставила перед собой компания.

В то же время, хотя я и был уверен, что все члены команды были достаточно компетентны, чтобы самостоятельно добавлять новые функциональные возможности в продукт, над созданием которого мы работали, кроме меня, право добавлять новые возможности в backlog проекта было только еще у одного сотрудника. Естественно, я приветствовал любые идеи, поступавшие от членов команды (третий уровень полномочий). Но в качестве владельцев продукта окончательные решения принимались совместно мной и моим коллегой (четвертый уровень).

В вышеописанном проекте были реализованы несколько вариантов распределения полномочий:

• Можно предоставить одному из членов команды полномочия иного (более высокого) уровня, чем имеются у остальных членов команды.

• От людей, располагающих одинаковыми полномочиями, можно потребовать достигать согласия при принятии решений.

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

• И наконец, можно сказать команде, что решение определенной задачи следует поручить одному сотруднику, но у команды есть право выбрать этого человека.

Иллюстрацией первого варианта может служить описанная мной ситуация, когда полномочия владельца продукта осуществлялись мной и еще одним сотрудником.

В качестве примера второго варианта могло бы быть требование, что решения относительно архитектуры продукта принимаются всей командой через достижение согласия. Никому не разрешается привлекать новые технологии или принимать важные решения относительно дизайна продукта самостоятельно, не вовлекая остальных в принятие решения.

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

И наконец, примером реализации четвертого варианта было назначение одного сотрудника ответственным за развертывание релизов продукта у клиента. При этом мне было безразлично, кто конкретно будет этим заниматься.

Возможность для всех членов команды работать над одной и той же задачей может быть хорошей стратегией для снижения рисков. Отдельному сотруднику легче допустить ошибку, чем ту же ошибку совершить всей командой. В то же время в некоторых ситуациях может оказаться легче или безопаснее поручить ответственность за решение задачи одному сотруднику. Например, задачу переписать заново весь неудачный код, написанный менеджером.

Но, как и всегда, все зависит от конкретных обстоятельств.