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

2. Придайте социальному давлению направление, сделав группу в целом ответственной за достижение разделенной цели. Спортивные команды выигрывают или проигрывают – и тут важен каждый человек. То же самое относится к командам разработчиков. Ответственность команды – ответственность, разделяемая всеми ее членами .

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

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

Не забывайте, что если человек не ощущает себя частью группы, то он будет невосприимчив к давлению со стороны коллег. Когда я был подростком, мне удалось избежать группового влияния, и это сказалось вполне определенным образом. Я не пью, не курю, не употребляю наркотики и не играю в азартные игры. Подозреваю также, что мне не удалось принять участие в некотором количество оргий.

Если сотрудник не развивают свои компетенции путем самообразования, а коучинг, сертификация и давление со стороны коллег не помогают, у вас в запасе остаются следующие три действия:

Поговорите с ним.

Поговорите с ним в последний раз.

Избавьтесь от него.

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

Я имею в виду инструменты.

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

Инструменты могут играть важную роль в повышении дисциплины в компании. Приверженцы Lean-методологий настаивают, что инструменты должны быть сконфигурированы таким образом, чтобы это позволяло максимально защитить процессы от ошибок(метод также известен как «защита от дурака») и тем самым затруднить выпуск программного обеспечения, содержащего дефекты [Poppendieck 2007: 196]. Меры по превентивному исключению ошибок можно считать техническим эквивалентом коучинга, который также помогает повысить дисциплину разработки.

На моей последней работе я, помимо прочего, отвечал за создание приложения, которое должно было выполнять ряд важных контрольных функций: присылать менеджерам уведомления о перерасходе бюджета; требовать, чтобы все данные, вводимые в журнал учета времени, предварительно проверялись двумя заинтересованными лицами; рассылать уведомления, если введенные в журнал учета времени часы неверно суммировались в рамках недели, и проактивно проверять, что списки команд и активных проектов находятся в актуальном состоянии. Да, некоторых это раздражало. Но еще больше жалоб поступало, когда приложение сбоило.

Люди и процессы – сердце вашей компании, к этой же категории относятся и инструменты. Это значит, что, подобно людям и процессам, инструменты должны быть тщательно подобраны и адаптированы под потребности вашего бизнеса. Никогда не меняйте свой бизнес под свои инструменты. Как однажды написал Джоэл Спольски:

Если речь идет о критически важной для вашего бизнеса функции – выполните ее сами, чего бы это ни стоило [65].

Я думаю, этот тезис с небольшими оговорками может быть распространен и на используемые инструменты:

Если инструмент очень важен для вашего бизнеса – разработайте его сами, чего бы это ни стоило.

Не поймите меня превратно. Я никого не призываю создавать свой личный Visual Studio или Eclipse. Но вы должны выбирать для себя столь же адаптируемые программные продукты, какими являются Visual Studio и Eclipse. Не выбирайте настраиваемые инструменты. Чаще всего под настраиваемостью понимается возможность изменить набор пунктов меню, поменять их местами и выбрать ваш любимый цвет. Это не то , что я имею в виду под адаптируемостью. Точно так же не думайте, что вы в порядке, если пользуетесь инструментами, в названии которых есть слово Agile. Его обычно применяют с маркетинговыми целями, и его присутствие в названии продукта совсем не означает, что он имеет соответствующую архитектуру. Мне приходилось видеть так называемые гибкие инструменты, в которых было столько же гибкости, сколько в Ким Чен Ире, помещенном в ледник.

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

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

Эта фраза никак не выходила у меня из головы, когда я недавно столкнулся с рядом проблем… назовем их проблемами с дисциплиной…

• Сотрудник отсутствует на совещании без предупреждения, при этом ранее он прислал подтверждение своего участия.

• Доска задач не поддерживается в актуальном состоянии и не отражает последнее состояние задач и пользовательских историй.

• Никто по собственной инициативе не проверяет, не перерасходован ли бюджет.

• Проблема, вызвавшая временную приостановку проекта, не решается в оговоренные сроки.