Масштабирование самоуправления
Большинство ведущих современных технологических компаний добились успеха с помощью модели наделенных широкими полномочиями целеустремленных, стабильных, кросс-функциональных эффективно сотрудничающих продуктовых команд, которую я описываю в этой книге. Безусловно, результаты говорят сами за себя, но я объясняю львиную долю их преимуществ повышением мотивации и подлинным чувством владельца, которые возникают, когда члены команды понимают, что во многом сами управляют своей судьбой.
Хотя большинство руководителей компаний утверждают, что их команды пользуются огромной свободой действий и самостоятельностью, члены этих команд нередко жалуются, что далеко не всегда чувствуют себя так, как описывает руководство. И всякий раз, сталкиваясь с такой ситуацией, я стараюсь в деталях разобраться, почему команда не может самостоятельно принимать решения и в чем именно она чувствует себя ограничиваемой и ущемленной.
Надо сказать, большинство ситуаций, о которых мне рассказывают, относятся к одной из двух:
1. Менеджмент еще не доверяет команде и не хочет, образно говоря, ослабить натяжение поводка.
2. Команда хочет изменить то, что, по мнению руководства, является частью фундамента компании.
В целом большинство команд, скорее всего, согласятся, что есть то, в чем им позволено действовать по собственному усмотрению, и то, что незыблемо, так как считается общим для всех команд компании.
Приведу пример второго случая: было бы странно, если бы каждая команда сама выбирала для себя инструмент конфигурационного управления программным обеспечением. Если разработчики используют GitHub, так должны работать все команды. И даже если бы одна из команд испытывала страсть к какому-либо другому инструменту, совокупные затраты компании, связанные с разрешением на его использование, перевесили бы любые выгоды, полученные в результате. Это простой и понятный пример, но есть и другие, не столь «прозрачные». Например, должна ли каждая команда по-своему подходить к автоматизации тестирования? Могут ли команды сами выбирать языки программирования, которые хотят использовать? Что вы скажете о фреймворках пользовательского интерфейса, или совместимости браузера, или дорогостоящих функций, таких как поддержка в режиме офлайн, или agile-методик, который хотят применять команды? В самом ли деле всем командам нужно поддерживать несколько инициатив, касающихся продуктов, реализуемых в рамках компании?
Как часто бывает с продуктом, все сводится к компромиссу. В данном случае к компромиссу между самоуправлением команды и использованием преимуществ централизованного управления.
Должен признаться, мне по душе идея самостоятельной продуктовой команды, наделенной широкими полномочиями, но я также большой сторонник инвестиций в общий центр решения задач, поскольку это прочная база, которую все команды могут использовать для создания потрясающих продуктов и опыта, делая это гораздо быстрее, чем при ее отсутствии.
Для протокола скажу, что, по моему убеждению, четкого ответа на этот вопрос быть не может. Наилучшим для каждой команды будет свой ответ, а он, безусловно, в значительной мере зависит от ее культуры.
Перечислю ключевые факторы, которые необходимо учесть, отвечая на этот вопрос.
Уровень командного мастерства
Специалисты различают три уровня навыков командной работы. Команда А — опытная: ей можно доверить выбор, потому что он стопроцентно будет верным. Команда Б: у ее членов правильные намерения, но во многих ситуациях нет опыта, необходимого для принятия взвешенных решений, поэтому они могут нуждаться в некоторой помощи. Команда В — совсем молодая, и, возможно, сама не знает, чего она еще не знает. Такие команды без эффективного коучинга могут ненароком создать серьезные проблемы.
Значение скорости
Один из главных аргументов в пользу общего центра решения задач — это скорость. Логично предположить, что для того, чтобы работать быстро, команды должны иметь возможность опираться на работу коллег и не тратить время на изобретение велосипеда. Однако иногда компании сознательно идут на жертвы ради самоорганизации, позволяя командам в потенциале дублировать некоторые задачи и идти вперед медленнее. А иногда от этого зависит жизнеспособность бизнеса.
Значение интеграции
Когда портфель компании состоит из набора связанных, но в основном независимых продуктов, интеграция и взаимозависимость не так важны. Но когда портфель включает тесно связанные продукты, интеграция приобретает огромное значение. Тут все сводится к вопросу об оптимизации работы команд: должны ли они делать это ради достижения своих целей или ради компании в целом?
Источник инноваций
Если основные источники будущих инноваций необходимы на уровне общего центра задач, командам нужно дать больше свободы в деле изменения базовых компонентов. Если же такие источники ожидаются на уровне решений, следует поощрять менее активное изменение фундаментальных инструментов и вместо этого направить креативность команд на инновации решений их уровня.
Размер и расположение компании
Многие острые вопросы в самоуправлении возникают из-за проблем, связанных с масштабированием. По мере роста и усложнения компаний — особенно если их команды локализованы в разных местах — фундаментальные решения и принципы становятся все более важными, притом что их труднее поддерживать. Одни компании пытаются справиться с этой задачей с помощью концепции центров передового опыта, которые поддерживают и развивают фундаментальные решения всей компании на месте. Другие пробуют более сильные комплексные роли. Третьи включают процесс.
Культура компании
Важно также признать роль, которую в культуре компании играет акцент на самоуправлении в сравнении с акцентом на фундаментальных решениях. Чем ближе компания в этом спектре перемещается к последним, тем больше это воспринимается командами как постепенное ограничение их самостоятельности. Такая ситуация может казаться вполне приемлемой для упомянутых выше команд типа Б и В, но весьма проблематична для команд уровня A.
Зрелость технологии
Нередко компании пытаются преждевременно стандартизироваться на общем фундаменте, когда он еще не готов эффективно обеспечивать ожидаемые от него выгоды и преимущества. Если слишком сильно давить в этом плане до полной готовности фундамента, можно серьезно навредить командам, которые излишне полагаются на него в работе. В этом случае вы построите карточный домик, который может рассыпаться в любой момент.
Значение для бизнеса
Если общий фундамент очень большой, повышается риск того, что какая-либо из команд компании не станет его использовать. Для некоторых областей деятельности такое положение вещей нормально, но, если речь идет о продуктах или инициативах, крайне важных для бизнеса, это вопрос жизни и смерти.
Уровень ответственности
