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