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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чек-лист для делегирования

В своей книге «За закрытыми дверями» (Behind Closed Doors) Джоанна Ротман и Эстер Дерби приводят удобный чек-лист, который можно использовать при делегировании задач[36]. Я добавил к этому перечню несколько дополнительных вопросов, чтобы учесть разные уровни зрелости и уровни полномочий, а также индивидуальные особенности команд и сотрудников.

1. Уделяется ли достаточно внимания рискам, которые может повлечь за собой делегирование работы в данном конкретном случае?

2. Умеют ли сотрудники должным образом распоряжаться предоставляемыми им полномочиями и обладают ли они необходимой для этого дисциплиной?

3. Провели ли вы соответствующий анализ при выборе уровня полномочий, подходящего для данной ситуации?

4. Решили ли вы для себя вопрос, кому в данном случае следует предоставить полномочия – отдельным сотрудникам или команде в целом?

5. Вы делегируете большую часть работы?

6. Достаточно ли у сотрудников умений и навыков, чтобы справиться с этой работой?

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

8. Располагают ли ваши сотрудники необходимыми инструментами, чтобы добиться успеха?

9. Понимают ли они, как должен выглядеть конечный результат?

10. Вы установили необходимые ограничения, касающиеся выполнения работы (включая бюджет, сроки, доступные ресурсы и требуемое качество)?

11. Известен ли сотрудникам крайний срок, когда работа должна быть завершена?

12. Понимают ли они, как должны выглядеть результаты выполнения отдельных этапов?

13. Знают ли они, как часто необходимо информировать вас о ходе работы (выполнении промежуточных этапов)?

14. Если им понадобится помощь, смогут ли они обратиться к вам (или другому сотруднику) за получением необходимого коучинга или менторства?