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

• Вы можете проводить совещания для обсуждения оценок 360° несколько раз в год, чтобы людям не приходилось мучительно вспоминать, что именно происходило во время предыдущего обсуждения. А раз в год вы можете попросить сотрудников заполнить официальные формы и отдать их вам, чтобы вы могли их подписать и передать в отдел HR. Это будут действительно оценки 360°, а не ваши личные оценки каждого сотрудника.

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

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

Каждый раз, когда я приезжаю в Соединенные Штаты, мне приходится тратить время, а также физические и интеллектуальные усилия на перевод одних стандартов в другие. Я конвертирую доллары в евро и наоборот, мили в километры, галлоны в литры, а часы до и после полудня в 24-часовой формат. У меня скопилось уже по меньшей мере четыре электрических адаптера, потому что иногда я забываю взять их с собой в поездки. И это несмотря на то, что они указаны в чек-листе вещей, которые нужно взять с собой. (Возможно, вы задаете себе вопрос, зачем вам советы такого человека, когда речь идет о компетентности…)

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

Обычно стандартизацию не стоит навязывать. Не понадобилось никакое мировое правительство, чтобы миллиарды людей по всему миру приняли 24-часовой формат при измерении времени, григорианский календарь, английский язык или правостороннее движение. Конечно, при этом остаются и многочисленные отклонения от международных стандартов. Положительная обратная связь приводит к принятию стандартов только тогда, когда это сулит определенные выгоды.

Когда мы оцениваем свою эффективность, мы также сравниваем ее с определенными стандартами. В прошлом такие стандарты устанавливались менеджерами, которые фиксировали их на определенном уровне. Но самоорганизующиеся команды могут самостоятельно этим управлять. Их стандарты более динамичны, поскольку по мере развития компетенций люди могут сами пересматривать эти стандарты в сторону повышения [Thomas 2000: 31].

При разработке ПО предметом обсуждения между лидерами компетенций и сотрудниками в этом случае становятся их собственные стандарты, а не те, что навязаны менеджерами. К числу стандартов, устанавливаемых командами самостоятельно, могут относиться протоколы взаимодействия с пользователями, система именования файлов, требования, предъявляемые к коду, структура файлов, используемые инструменты, протоколы регистрации ошибок, правила безопасности [Poppendieck 2007: 193]. Исчезает необходимость в стандартизации сверху вниз, проводимой менеджментом. Но стандартизация снизу вверх произойдет только в том случае, если цели и контрольные показатели не оставляют у сотрудников никаких сомнений, что оптимальнее будет внести изменения в процесс своей работы.

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

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

• Чтобы ускорить принятие лучших практик, вводите их в виде целостных мемплексов, а не по отдельности. Например, большинство идей, использованных Дэвидом Алленом в книге «Как привести дела в порядок» (Getting things done), существовало задолго до появления этого труда. Но в книге все идеи собраны в единый «пакет» под легко запоминающимся брендом, что облегчает задачу применения рекомендуемых автором практик.

• Разрешите людям фокусироваться на том, в чем они сильны, и не требуйте от них большего, чем «минимально необходимый уровень компетентности», в других областях. C точки зрения организации гораздо полезнее разрешить людям заниматься тем, что им нравится, и не заставлять их развивать свои компетенции в областях, к которым они безразличны. Не имеет никакого смысла превращать своих сотрудников в однородную массу. Гораздо лучше дать людям возможность проявлять свои индивидуальные таланты, тем самым компенсируя недостатки друг друга в прочих областях. Например, сотрудник со слабыми навыками вербальной коммуникации и межличностных взаимодействий может быть супергероем во всем, что касается системной архитектуры. Время, которое он проведет на тренингах по развитию «навыков коммуникации», можно использовать гораздо продуктивнее, отправив его на семинар, где будут обсуждаться «вопросы улучшения масштабируемости программных продуктов».

• Большие проблемы начинаются с маленьких. Нельзя фокусироваться только на крупных проблемах, поскольку за это время небольшие превращаются в огромные. Например, с самого начала установите требования, предъявляемые к качеству кода, чтобы под воздействием эффекта разбитых окон ваш проект не стал похож на местность, где похозяйничали сомалийские пираты [Hunt, Thomas 2000: 5].