Масштабирование самоуправления

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

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

Надо сказать, большинство ситуаций, о которых мне рассказывают, относятся к одной из двух:

1. Менеджмент еще не доверяет команде и не хочет, образно говоря, ослабить натяжение поводка.

2. Команда хочет изменить то, что, по мнению руководства, является частью фундамента компании.

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

Приведу пример второго случая: было бы странно, если бы каждая команда сама выбирала для себя инструмент конфигурационного управления программным обеспечением. Если разработчики используют GitHub, так должны работать все команды. И даже если бы одна из команд испытывала страсть к какому-либо другому инструменту, совокупные затраты компании, связанные с разрешением на его использование, перевесили бы любые выгоды, полученные в результате. Это простой и понятный пример, но есть и другие, не столь «прозрачные». Например, должна ли каждая команда по-своему подходить к автоматизации тестирования? Могут ли команды сами выбирать языки программирования, которые хотят использовать? Что вы скажете о фреймворках пользовательского интерфейса, или совместимости браузера, или дорогостоящих функций, таких как поддержка в режиме офлайн, или agile-методик, который хотят применять команды? В самом ли деле всем командам нужно поддерживать несколько инициатив, касающихся продуктов, реализуемых в рамках компании?

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

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

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

Перечислю ключевые факторы, которые необходимо учесть, отвечая на этот вопрос.

Уровень командного мастерства

Специалисты различают три уровня навыков командной работы. Команда А — опытная: ей можно доверить выбор, потому что он стопроцентно будет верным. Команда Б: у ее членов правильные намерения, но во многих ситуациях нет опыта, необходимого для принятия взвешенных решений, поэтому они могут нуждаться в некоторой помощи. Команда В — совсем молодая, и, возможно, сама не знает, чего она еще не знает. Такие команды без эффективного коучинга могут ненароком создать серьезные проблемы.

Значение скорости

Один из главных аргументов в пользу общего центра решения задач — это скорость. Логично предположить, что для того, чтобы работать быстро, команды должны иметь возможность опираться на работу коллег и не тратить время на изобретение велосипеда. Однако иногда компании сознательно идут на жертвы ради самоорганизации, позволяя командам в потенциале дублировать некоторые задачи и идти вперед медленнее. А иногда от этого зависит жизнеспособность бизнеса.

Значение интеграции

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

Источник инноваций

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

Размер и расположение компании

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

Культура компании

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

Зрелость технологии

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

Значение для бизнеса

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

Уровень ответственности