2. Минимизация взаимозависимости.
Важнейшая задача — свести к минимуму зависимость команд друг от друга, чтобы они быстрее функционировали и чувствовали себя более самостоятельными. Конечно, полностью устранить взаимозависимость невозможно, но мы можем и должны целенаправленно работать над ее постепенным уменьшением почти до нуля. Обратите внимание: характер зависимости со временем меняется, поэтому следите за ней постоянно и всегда спрашивайте себя, как можно ее уменьшить.
3. Чувство владельца и самоуправление.
Всегда помните об одной из самых важных отличительных характеристик эффективных продуктовых команд — это команды «миссионеров», а не «наемников», что подводит нас прямо к ключевым концепциям чувства владения и самоуправляемости. Команда должна чувствовать, что она наделена широкими полномочиями, при этом быть ответственной за важную часть общего продуктового предложения компании. Достичь этого труднее, чем может показаться на первый взгляд, потому что большие системы не всегда «нарезаются» на части абсолютно точно. Некоторая взаимозависимость всегда будет постепенно ослаблять силу чувства собственности, но мы должны прилагать все усилия, чтобы оно оставалось сильным.
4. Максимальная оптимизация.
По мере роста организационных подразделений у них часто появляются общие потребности, поэтому возрастает значение общих сервисов. Это чрезвычайно важно для скорости и стабильной работы подразделений и команд. Никому не нужно, чтобы каждая команда заново изобретала колесо. Однако следует помнить, что создание общих сервисов ведет к усилению взаимозависимости и может посягать на автономию команд.
5. Видение продукта и стратегия его развития.
Видение продукта описывает, к чему стремится компания, а продуктовая стратегия отмечает основные вехи, которые нужно преодолеть, чтобы дойти до цели. Надо признать, многие крупные и старые организации не имеют ничего подобного, хоть это и чрезвычайно важно. Как только вы определите свои видение и стратегию, убедитесь, что ваши команды структурированы так, чтобы обеспечивалась их реализация.
6. Размер команды.
Этот принцип в высшей мере практичный. Продуктовая команда минимального размера обычно состоит из двух инженеров-программистов и менеджера продукта, а если она отвечает за интерфейсную технологию, то еще и из дизайнера продукта. Считается, что меньшее количество членов продуктовой команды не дотягивает до необходимой критической массы. Однако замечено, что один продакт и один дизайнер способны загрузить достойными внимания задачами не более 10–12 инженеров-программистов. Кроме того (если это до сих пор неясно), очень важно, чтобы в каждой продуктовой команде был один, и только один, менеджер продукта.
7. Согласованность с архитектурой.
На практике при структурировании продуктовых команд многие компании руководствуются принципом архитектуры. Часто начинают с видения продукта, затем выстраивают архитектуру, которая поможет реализовать это видение, после чего выстраивают команды вокруг сложившейся архитектуры.
Вам может показаться, что при таком подходе все делается «задом наперед», на самом деле на то есть веские причины. Архитектуры определяют технологии, а технологии определяют наборы необходимых навыков членов команд. Конечно, нам хотелось бы, чтобы каждая команда была полностью укомплектована для работы на любом уровне архитектуры, но на практике это чаще всего невозможно. Инженеры обучены и подготовлены к работе с разными технологиями. Одни специализируются в той или иной предметной области (и во многих случаях занимаются этим не один год), у других совершенно отсутствуют некоторые необходимые навыки. Архитектура ведь меняется не в одночасье.
Обычно, если компания, комплектуя команды, не обращает на архитектуру должного внимания, это заметно сразу и проявляется несколькими способами. Во-первых, такие команды ощущают себя так, будто им приходится постоянно бороться с архитектурой. Во-вторых, взаимозависимости между командами кажутся несоразмерными. В-третьих, работа в таких командах движется медленно, и люди не чувствуют, что наделены широкими полномочиями — в сущности, это следствие двух первых пунктов.
В крупных компаниях одна или несколько команд предоставляют услуги общего характера всем продуктовым командам. Мы можем называть их общим центром обслуживания или платформенными командами, но в основном они отражают ту или иную архитектуру. Это позволяет обеспечить оптимизацию высочайшего уровня, и многие компании, достигая определенного масштаба, формируют подобные команды. Однако их чрезвычайно сложно укомплектовать персоналом, так как они, по замыслу, находятся в зависимости и подчинении у всех остальных команд компании, поскольку создаются ради обеспечения их деятельности. Непременно убедитесь, что включили в состав команд общего сервиса сильных и отлично разбирающихся в технологиях продакт-менеджеров.
8. Разделение по пользователю или клиенту.
В разделении кроются огромные преимущества и для продукта, и для команды. Если, например, ваша компания снабжает двусторонний рынок с покупателями на одной стороне и продавцами на другой, весьма полезно ориентировать одни команды на покупателей, а другие на продавцов. Тогда каждая продуктовая команда сможет углубиться в изучение своих потребителей, вместо того чтобы пытаться узнать все обо всех. Однако даже в коммерческих организациях всегда будет некоторое количество команд, которые обеспечивают общую основу и предоставляют услуги всем командам. Это действительно отражает архитектуру; словом, я стараюсь донести до вас мысль, что иметь команды обоих типов — обычное дело и, по сути, общепринятое.
9. Разделение по бизнес-подразделениям.
Крупные компании часто занимаются разными направлениями бизнеса — с общей основой для своих продуктов. Если бы технологии в разных бизнес-подразделениях существовали независимо друг от друга, мы просто структурировали бы продуктовые команды как разные компании. Но обычно так не бывает. У крупной компании, как правило, несколько направлений бизнеса, но все они базируются на общем и нередко взаимосвязанном фундаменте. Это немного напоминает разделение по типу потребителя, с некоторыми важными отличиями. Структура бизнес-единицы — конструкция искусственная. Разные бизнес-единицы часто продают продукты фактически одним и тем же покупателям. Таким образом, хотя разделение по подразделениям и обеспечивает определенные преимущества, в списке приоритетных факторов оно стоит не на первом месте
.
10. Структура — цель движущаяся.
Оптимальная структура продуктового подразделения представляет собой постоянно движущуюся цель. Подразделения должны и будут меняться с течением времени. Это не значит, что вам надо реорганизовывать их раз в несколько месяцев, но пересматривать структуру команд примерно каждый год действительно имеет смысл.
Мне часто приходится объяснять, что идеального способа структурировать команды не существует; каждая попытка сделать это в продуктовом подразделении будет означать оптимизацию чего-то одного за счет другого. Так что, как, впрочем, в случае с большинством решений по поводу продуктов и технологий, это всегда компромиссы и выбор. И я очень надеюсь, что описанные выше принципы помогут вам в дальнейшем структурировать свои подразделения.
