Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

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

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

Как лучше вести себя в ситуации, когда к разным сотрудникам или разным командам в составе организации необходимо применять различные подходы с точки зрения наделения их полномочиями?

Это тонкий вопрос. Моя первая реакция на него – не надо никогда и никому лгать. Вторая реакция – ко всем надо относиться справедливо. Это значит, что если при предоставлении определенных полномочий Сэму от него не требуется, чтобы он сначала доказал, что достоин их, то такие же полномочия нужно предоставить и Максу.

Тем не менее если вы считаете, что компетентность Сэма позволяет выполнить работу хорошо, а компетентность Макса пока нет, то будет только справедливо, если вы объясните почему. Возможно, Макс еще не принимал участия в таком большом количестве проектов или у Макса во время работы на предыдущем проекте было много проблем. Вы должны быть справедливы, но честны. Вы должны четко объяснить Максу, что он должен cделать, чтобы заслужить такие же права, как у Сэма.

Насколько возможно, вы должны предоставлять всем сотрудникам одинаковые права. Но я предпочитаю не давать сотрудникам (или командам) одинаковые полномочия, если их уровни компетентности существенно отличаются. В противном случае это будет моментально интерпретировано более компетентными сотрудниками как несправедливость. Политкорректность оказывает плохую услугу как новичкам, так и экспертам [Hunt 2008: 26]. Если мне приходится выбирать из двух зол, я выбираю лояльность по отношению к наиболее компетентным сотрудникам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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