Большинство компаний знают, что по мере роста им необходимо удвоить усилия по подбору квалифицированного и мотивированного персонала, но не всегда осознают, какие еще изменения в этом плане важны, когда бизнес растет и становится сложнее.
Что меняется в ролях руководителей? Как сохранять комплексный, всеобъемлющий подход к продукту, когда в компании работает много команд? Как добиваться того, чтобы команды чувствовали свою самостоятельность и ответственность в условиях, когда они владеют лишь небольшой частью целого? Как мы поощряем ответственность, когда единственный, кто владеет в компании всеми продуктами, — это СЕО? Как мы справляемся с резким расширением структуры взаимозависимости?
Все эти темы мы обсудим в следующих главах, посвященных вопросам масштабирования сильной продуктовой компании.
Глава 16. Роль руководства
Основная задача лидеров любой компании из сферы высоких технологий заключается в найме, развитии и удержании классных профессионалов. В продуктовой компании роль руководства выходит за эти рамки, также предполагая то, что мы называем комплексным видением продукта.
В стартапе, как правило, работает одна или две продуктовые команды, поэтому всегда удерживать в голове обобщенное представление о продукте не составляет труда. Но эта задача усложняется по мере роста компании, когда она сначала переходит на более крупный и сложный продукт, а затем еще и существенно увеличивает число работающих в ней команд.
Одна из сложнейших проблем роста состоит в знании того, как составляющие продукта объединяются в целое. Некоторые предпочитают воплощать в жизнь его комплексное видение путем связывания команд.
Далее описаны три элемента руководства, которые крайне важны для всеобъемлющего видения продукта.
Роль лидера, обеспечивающего целостность продукта и его актуальность для бизнеса (видение продукта, стратегия, функциональность, правила и логика ведения бизнеса), обычно выполняет либо руководитель продуктового направления (глава продукта, директор по продукту), либо главный продакт-менеджер. Этот человек должен регулярно контролировать работу продакт-менеджеров и отдельных продуктовых групп, выявляя конфликты между ними и помогая разрешать противоречия.
Это очень высокая и сложная роль директорского уровня, но нередко в крупных корпорациях на нее назначают главного продакт-менеджера. Поскольку директор по продукту в первую очередь несет ответственность за развитие навыков менеджеров продукта, именно главный продакт-менеджер может сосредоточиться на самом продукте и быть всегда на связи с продакт-менеджерами, дизайнерами, инженерами и тестировщиками компании. Если на эту роль назначается главный продакт-менеджер, он должен непосредственно подчиняться директору по продукту, чтобы все в компании понимали значение его должности и круг обязанностей.
Но, кто бы ни выполнял эту роль — директор по продукту или главный продакт-менеджер, — следует помнить, что она чрезвычайно важна для любой компании с большими и сложными бизнес-системами, особенно если многие из них остались с давних времен.
Одну из важнейших ролей в крупной компании играет человек или люди, ответственные за комплексный пользовательский опыт. Эти руководители обязаны обеспечить последовательный и эффективный пользовательский опыт в масштабе всей системы. Иногда это задача лидера дизайнерской группы, иногда — одного из менеджеров или директоров дизайнерского подразделения, а иногда — главного дизайнера. В любом случае это должен быть человек с мощным комплексным подходом к дизайну продукта.
В крупном продукте так много взаимодействий и взаимозависимостей — и так много необходимых институциональных знаний о бизнесе, пользователях и пути клиента, — что непременно хотя бы один человек должен следить за всем, с чем взаимодействует пользователь в продукте. И не стоит ожидать, что кто-либо из продакт-менеджеров или дизайнеров сможет постоянно держать все это в голове.
И наконец, чтобы обеспечить комплексное, всеобъемлющее понимание того, как в целом устроена система с точки зрения технологий, нам нужен лидер технологического подразделения (его часто называют техническим директором или вице-президентом по технологиям). На практике этому человеку нередко помогает группа инженеров-менеджеров и директоров и (или) архитекторов программного обеспечения.
Технический директор, менеджеры и архитекторы софта несут ответственность за целостный взгляд на функционирование технологической системы. Они должны анализировать и пересматривать архитектуру и системный дизайн всего программного обеспечения — как систем, разработанных вашими сотрудниками, так и любых систем, разработанных субпоставщиками. И у них должна быть четкая стратегия управления техническим долгом.
Повторюсь, в компаниях с большими и сложными бизнес-системами, особенно если многие из них сформировались много лет назад, это крайне важная должность, и человек, ее занимающий, обязан находиться в организации там, где он будет всегда на виду и доступен для всех.
Чем крупнее становится компания, тем важнее эти три роли и тем заметнее их отсутствие. Если продукт или сайт выглядит так, будто над его созданием трудилось с полдесятка разных агентств; пользовательские модели конфликтуют друг с другом, а юзабилити оставляет желать лучшего, — у вас, скорее всего, нет директора по дизайну или главного дизайнера. Если проекты не развиваются, потому что менеджеры продукта не понимают последствий своих решений либо часто просят разработчиков, взглянув на код, сказать им, как на самом деле работает система, то вы, вероятно, еще не осознали значения главного продакт-менеджера. А если ваш софт представляет собой полный хаос и мешанину и даже на внесение простейших изменений уходит вечность, значит, вы, по всей вероятности, страдаете от огромного технического долга.
Тут вы можете спросить: а что же будет, если одного из этих важных людей, не дай бог, собьет машина или он просто уволится? Во-первых, изо всех сил старайтесь не допустить подобного! Заботьтесь об этих людях; не давайте им ни малейшего повода захотеть уйти и не позволяйте почувствовать, что эта должность им нужна исключительно ради денег. Во-вторых, всегда стремитесь развивать и готовить «скамью запасных» из таких людей; у каждого из тех, кто играет эти роли, должен быть хотя бы один заместитель, на которого можно переложить свои обязанности. Но помните: это очень редкий и невероятно ценный «товар», так как на обучение и подготовку таких специалистов уходит много сил и времени.
Некоторые компании считают, что проблему можно решить, если четко задокументировать систему, — до такой степени, чтобы описано было буквально все. И тогда все, кому это необходимо, смогут получать из этих бумаг ответы на вопросы, на которые в противном случае обязаны отвечать главный дизайнер, главный продакт-менеджер и архитектор софта. Я знаю несколько организаций, которые изо всех сил пытались этого добиться, но ни разу не видел, чтобы кто-нибудь в этом действительно преуспел. По-видимому, сложность и размеры систем растут гораздо быстрее, чем это возможно задокументировать, а в случае с программным обеспечением окончательный ответ вообще всегда содержится в самом исходном коде (по крайней мере, окончательный ответ в настоящий момент, который далеко не всегда совпадает с логикой в долгосрочном периоде).
И финальное замечание: несмотря на то что описанные выше три лидера, обеспечивающие комплексное видение системы — с точки зрения продукта, дизайна и технологий, — чрезвычайно ценны каждый по отдельности, их истинная мощь реализуется только в комбинации. Поэтому предпочтительно, чтобы они максимально тесно сотрудничали друг с другом и размещались в компании рядом, возможно, даже в одном кабинете.
Глава 17. Директор по продукту
Эта глава предназначена для представителей трех аудиторий. Непременно прочитайте ее, если вы:
• СЕО или глава отдела персонала и сейчас заняты поиском директора по продукту; вы лучше разберетесь в том, какого именно человека нужно искать;
• в настоящее время возглавляете продуктовое подразделение — это ваш ключ к успеху;
• мечтаете в один прекрасный день возглавить продуктовую компанию; в этой главе четко и откровенно обсуждаются навыки, которые вам понадобится для этого развить.
Для обозначения этой должности я использую название директор по продукту (или вице-президент по продукту), но она может называться и по-другому. В любом случае речь идет о главной роли, связанной с продуктом, в вашей компании или структурном подразделении. С организационной точки зрения человек, ее занимающий, обычно управляет продакт-менеджерами и дизайнерами, а иногда также аналитиками, и подотчетен СЕО. Поэтому за редкими исключениями ему важно иметь равные права с техническим директором и вице-президентом по маркетингу.
Сразу скажу, что к этой роли предъявляется много требований и исполнять ее на должном уровне очень сложно, но те, кто в этом преуспевает, оказывают на результаты деятельности своих компаний огромное влияние. Этих сотрудников очень высоко ценят, и со временем они нередко становятся основателями собственных компаний. В сущности, некоторые из лучших венчурных предпринимателей в мире инвестируют средства только в фирмы, которые основывают люди, ранее отлично зарекомендовавшие себя на этом поприще.
Если говорить предметно, то вы ищете человека с доказанной компетентностью в четырех ключевых аспектах: 1) развитие команды; 2) видение продукта; 3) исполнительность; 4) продуктовая культура.
РАЗВИТИЕ КОМАНДЫ
Важнейшая сфера ответственности любого директора по продукту — это создание и развитие сильной команды продакт-менеджеров и дизайнеров. В приоритеты их деятельности входят рекрутинг, тренинги, обучение и постоянный коучинг этих сотрудников. Поскольку обучение и развитие отличного персонала требуют иных навыков, чем создание отличных продуктов, многие во всем остальном превосходные продакт-менеджеры и дизайнеры продукта так и не становятся лидерами.
Наихудшая ошибка, которую можно совершить в этом плане, — поставить на эту лидерскую позицию человека, который не слишком хорошо проявил себя на предыдущем рабочем месте. Я понимаю: такое заявление звучит странно, потому что кажется очевидным, но вы удивились бы, узнав, как много людей, принимая такое решение, рассуждают примерно так: «Ну да, он, конечно, не слишком сильный профессионал, зато неплохо работает с людьми и заинтересованными лицами. Так почему бы не сделать его директором по продукту и не нанять ему в помощь сильного исполнителя?» Разве сможет не слишком успешный в работе человек сколотить команду эффективных работников и обеспечить их постоянный рост и развитие? И какой посыл такое назначение даст остальной компании?
Вам необходимо убедиться, что на это место назначается человек, доказавший свою способность развивать других. У него должен быть впечатляющий послужной список в деле выявления и привлечения потенциальных талантов и активной и постоянной работы с этими людьми, нацеленной на исправление их слабостей и использование сильных сторон.
ВИДЕНИЕ ПРОДУКТА И СТРАТЕГИЯ ЕГО РАЗВИТИЯ
Видение продукта движет компанией и вдохновляет ее, поддерживая во всех взлетах и падениях. Казалось бы, тут все просто, на самом же деле нет. Сложность состоит в том, что компании могут понадобиться два разных директора по продукту, например, в следующих ситуациях:
1. В компании есть СЕО или основатель, имеющий максимально четкое видение продукта.
2. Четкого видения продукта в организации нет — обычно так бывает, когда основатель ушел или скончался.
Нужно также описать две очень скверные ситуации, связанные с видением и стратегией развития продукта, с которыми вы можете столкнуться.
Первая: ваш СЕО очень силен в продукте и имеет его четкое видение, но хочет нанять вице-президента по продукту (чаще на этом настаивает совет директоров). Он убежден, что нанимать нужно кого-то по его образу и подобию или хотя бы человека с таким же видением продукта. В результате, как правило, немедленно возникает межличностный конфликт и вице-президент по продукту занимает новое место недолго. Так что, если в вашей компании эта позиция напоминает непрерывно вращающуюся дверь, возможно, это как раз такой случай.
Вторая: СЕО не силен в видении продукта, но нанимает кого-то похожего на себя. Это не приводит к столкновению и разногласиям (обычно СЕО и вице-президент отлично ладят), но при этом видение продукта отсутствует, что, в свою очередь, вызывает разброд и шатание в продуктовых командах, ослабляет моральный дух в компании и, как следствие, ведет к отсутствию инноваций.
Как вы уже, наверное, поняли, вице-президент по продукту должен дополнять СЕО — это главное. Если ваш СЕО имеет четкое видение продукта, некоторые кандидаты в вице-президенты по продукту с такими же сильными качествами не захотят занимать эту должность, зная, что их задача будет заключаться в основном в том, чтобы претворять в жизнь видение руководства.
Часто складывается еще одна неблагоприятная ситуация. Ваш СЕО и основатель компании имеет четкое видение продукта, и у него есть надежный партнер, очень сильный исполнитель, который эффективно управляет продуктом, но потом основатель уходит, и компания сталкивается с серьезной проблемой, так как в ней не остается никого, у кого было бы видение будущего. Обычно вице-президент по продукту не может измениться в одночасье, и, даже если он на это способен, остальная компания не всегда готова видеть этого человека в новом для него свете. Вот почему, на мой взгляд, предпочтительнее, чтобы основатели оставались в компании, даже если решают привлечь в качестве СЕО другого человека.
Если вам интересно, что делать, когда ваш СЕО считает себя сильным лидером и провидцем, а компания придерживается иного мнения, знайте: вам нужен весьма определенный тип директора по продукту — человек с четким видением, но способный и готовый убедить СЕО в том, что это его и только его идея.
ИСПОЛНИТЕЛЬНОСТЬ
Каков бы ни был источник видения и каким бы великим оно ни было, оно не имеет большого значения, если вы не можете реализовать идею и вложить ее в руки пользователей в виде реального продукта. Вам нужен такой директор по продукту, который знает, как это сделать, и уже доказал свою компетентность в этом плане.
Многие аспекты усиливают способность команды реализовывать свои замыслы последовательно, быстро и эффективно. Директор по продукту должен быть экспертом в выявлении новых потребителей, исследовании и разработке продукта, но исполнительность также означает, что он знает, как эффективно работать, будучи частью организации определенного масштаба. Чем больше ваша компания, тем важнее, чтобы этот человек обладал проверенными сильными навыками, особенно в управлении взаимоотношениями с заинтересованными сторонами, а также в информационно-разъяснительной работе (так называемом евангелизме) в рамках организации. Директор по продукту обязан уметь вдохновлять и мотивировать людей и убеждать их двигаться в одном направлении.
ПРОДУКТОВАЯ КУЛЬТУРА
У хороших продуктовых компаний сильная команда, четкое видение и последовательное исполнение. В отличной продуктовой компании ко всему этому добавляется такой важнейший аспект, как сильная продуктовая культура.
Сильная продуктовая культура означает, что команда в полной мере осознает важность непрерывного и быстрого тестирования и обучения. Ее члены понимают, что для того чтобы учиться и приобретать необходимые знания, им нужно совершать ошибки, но это должно происходить быстро и им надо уметь снижать связанные с этим риски. Люди понимают необходимость постоянных инноваций. Они знают, что отличные продукты появляются в результате равноправного сотрудничества. Они уважают и высоко ценят своих дизайнеров и инженеров. Они понимают мощь мотивированной продуктовой команды.
Сильный директор по продукту хорошо осознает важность сильной продуктовой культуры, способен привести примеры такой культуры из собственного опыта и имеет планы по ее внедрению в вашей компании.
Какой опыт необходим эффективному директору по продукту, в частности в той или иной предметной области, зависит от компании и отрасли. Но вам нужен человек, как минимум обладающий широкими познаниями и образованием в области технологий, понимающий экономику и динамику вашего бизнеса и рынка.
И наконец, последнее, но важное замечание: всего, что обсуждалось ранее, недостаточно. Есть еще одно условие: директор по продукту должен уметь ладить и успешно сотрудничать с другими ключевыми руководителями, особенно с СЕО и техническим директором компании. Отсутствие таких навыков личных взаимоотношений не принесет пользы никому. Попробуйте устроить так, чтобы в программу отбора кандидатов на эту должность входил совместный обед, по крайней мере с СЕО и техническим директором, а еще лучше — и с главами маркетингового подразделения и дизайнерской группы. Будьте максимально открыты и постарайтесь придать этому мероприятию искреннюю, дружескую атмосферу.
В крупных продуктовых компаниях встречается также особая роль, которую я считаю весьма эффективной. Речь идет о менеджере продуктовой группы (group product manager, GPM), которого чаще называют сокращенно — GPM.
У GPM разнородные функции. Отчасти это исполнитель, а отчасти менеджер по персоналу высокого уровня. На мой взгляд, GPM — это менеджер продукта, уже доказавший свою эффективность (как правило, занимавший до этого должность старшего менеджера продукта), который теперь готов к большей ответственности.
Традиционно менеджеры продукта проходят один из двух путей карьерного роста.
Первый — оставаться исполнителем; если вы достаточно в этом сильны, то нередко постепенно проходите весь путь до главного продакт-менеджера. Да, это тоже исполнитель, но не простой, а «звезда» в своем деле, готовая и способная справиться с самой сложной задачей, касающейся продукта. Это очень уважаемая и ценная роль, и оплачивается она не хуже директорской и даже вице-президентской.
Другой карьерный путь — переключиться на функциональное управление продакт-менеджерами (самое распространенное название этой должности — директор по управлению продуктами). В этом случае в компании работают несколько продакт-менеджеров (обычно от трех до десяти), которые отчитываются перед этим человеком. Он отвечает, по сути, за два направления. Во-первых, он должен гарантировать высокую квалификацию, отличную подготовку и максимальную эффективность своих подчиненных. Во-вторых, ему нужно обеспечить видение и стратегию работы с продуктом и согласованную деятельность разных продуктовых команд, или так называемое общее видение продукта.
Многие эффективные главные менеджеры продукта на этом этапе еще точно не определились, какой из этих карьерных путей для них предпочтительнее, поэтому должность GPM дает им отличный шанс почувствовать вкус обоих миров.
GPM — это менеджер продукта в конкретной продуктовой команде, но, помимо этого, он отвечает за развитие и коучинг небольшого числа других продактов (обычно из одной — трех команд).
Если директор по продукту обычно работает с продактами из самых разных областей, то в обязанности GPM входит содействие деятельности продуктовых команд, работающих в тесном сотрудничестве друг с другом. Думаю, это будет проще объяснить на примере. Допустим, вы коммерческая компания на стадии роста, в которой трудится десять продуктовых команд. Предположим также, это команды трех типов: группа платформы/общих услуг и по группе для двух сторон рынка (скажем, покупатели и продавцы; водители и пассажиры такси; хозяева и гости сдающихся в аренду квартир и так далее). У вас также есть вице-президент по продукту и три GPM — по одному для каждой из трех названных групп: для стороны покупателя, для стороны продавца и для группы платформы/общих услуг.
Теперь детально рассмотрим роль GPM для стороны покупателя, представив, что в компании работают три продуктовые команды, прямо связанные с покупательским опытом. GPM со стороны покупателя будет членом одной из этих команд, а менеджеры продукта двух остальных ему подотчетны. Мне нравится такая система, потому что сторона покупателя должна представлять собой единую «бесшовную» структуру, даже если в компании несколько продуктовых команд, работающих над разными аспектами этого направления. Ради достижения этой цели GPM тесно сотрудничает и с продакт-менеджерами из других компаний.
Из-за того, что GPM объединяет управление своей командой с ответственностью за коучинг и развитие от одного до трех менеджеров продукта, их часто называют играющими тренерами.
Со временем одни GPM становятся директорами или вице-президентами по управлению продуктом, другие занимают должность главного продакт-менеджера, третьи решают остаться GPM, потому что им нравится практическая работа в своей продуктовой команде наряду с возможностью посредством коучинга влиять на другие команды и менеджеров продукта.
Глава 18. Директор по технологиям
Даже самая великолепная идея продукта остается всего лишь замыслом, если вы не можете воплотить ее в жизнь. А это значит, что вам жизненно необходимо иметь хорошие отношения с теми, кто реализует идеи — с разработчиками. В этой главе описана роль лидера инженерного подразделения, и я очень рад, что в работе над ней мне помогал сам Чак Гейгер, один из самых успешных технических директоров Кремниевой долины.
Я уже не раз говорил, что, если вы, будучи менеджером по продукту, сумели наладить профессиональные отношения с коллегой-технарем, работа станет приносить вам удовлетворение, а иначе вам не позавидуешь. Чтобы помочь вам лучше понять, что требуется для максимально эффективной работы технического подразделения, мы и предлагаем вашему вниманию этот короткий рассказ.
Во-первых, уточним, о каком подразделении идет речь. Это часть компании, которая отвечает за архитектуру, инжиниринг, качество, функционирование и безопасность сайта, управление релизами и поставкой продукта или отдельных функциональных дополнений на рынок. Кроме того, подразделение создает продукты и услуги компании и поддерживает их использование.
Называется должность этого лидера по-разному, но чаще всего вице-президент по технологиям, технический директор или главный инженер. В этой главе мы будем использовать термин «технический директор», а вы можете говорить так, как принято в вашей компании.
Важно заметить, что технический директор — это не директор по информационным технологиям. Это две принципиально разные роли, и, если ваше техническое подразделение подотчетно ИТ-директору, это сигнал о том, что ваша компания страдает рядом «патологий», которые мы обсуждали в главе 6.
Отличительная особенность высококлассного технического директора — умение использовать технологии как стратегический инструмент для развития бизнеса и продуктов. Такой директор многократно расширяет возможности компании и убирает все технологические барьеры. Для этого технический директор выполняет шесть основных обязанностей. Они представлены в порядке приоритета. Для каждой дано описание того, как оценить качество ее исполнения.
Создание отличной структуры с сильной управленческой командой, нацеленной на развитие навыков сотрудников. В данном случае эффективность измеряется на основе планов развития всего персонала, коэффициента удержания сотрудников и оценки менеджеров продуктового и технического подразделений остальной частью компании.
Сотрудничество с менеджерами высшего звена с целью повышения уровня их информированности об этой сфере, улучшения деятельности по слияниям и поглощениям и принятия более обоснованных решений относительно создания новых продуктов, закупок и установления партнерских отношений.
Обеспечение способности технического подразделения быстро, надежно и последовательно поставлять на рынок качественный продукт. Тут для оценки эффективности используются такие критерии, как последовательность и частота релизов, так и качество и надежность поставляемого и запускаемого софта. Как известно, основным препятствием для быстрой поставки продуктов на рынок часто бывает технический долг, и именно технический директор несет ответственность за то, чтобы он не превышал управляемого уровня и чтобы компания всегда была способна поставлять на рынок качественные продукты и успешно конкурировать.
Гарантия наличия у компании архитектуры, способной обеспечивать функциональность, масштабируемость, надежность, безопасность и эффективность, необходимые для успешной конкуренции и процветания. В компаниях с несколькими продуктовыми линейками или вертикальной бизнес-структурой технический директор должен стать лидером по реализации объединяющей стратегии в сфере технологий; ему необходимо видеть картину в целом, а не отдельные ее части. Образно говоря, технический директор — это дирижер стратегии в области технологий в рамках всей компании. Критерии оценки архитектуры варьируются в зависимости от характера бизнеса, но главное, чтобы инфраструктура постоянно контролировалась и развивалась соразмерно темпам роста бизнеса, и мы оцениваем сбои и простои, возникшие из-за проблем с инфраструктурой или архитектурой, которые сказываются на наших потребителях.
Обеспечение активного участия старшего инженерно-технического персонала в течение всего этапа исследования продукта и его значительного вклада в результат этой деятельности. Если ваши инженеры и архитекторы вступают в работу только на этапе написания кода, вы извлекаете из их труда лишь малую толику той огромной пользы, которую могли бы получить. Мы настоятельно призываем вас как можно внимательнее относиться к их участию в исследовании продукта (как в плане продолжительности, так и охвата) и следить за тем, как часто инновации становятся результатом этого участия.
Технический директор представляет техническое подразделение; он демонстрирует лидерство в общении с разработчиками, партнерами и потребителями. Эффективность лидерства данного типа можно оценить по успехам в налаживании взаимоотношений с высшими учебными заведениями (с целью найма лучших выпускников инженерных специальностей); стоит также обратить внимание на участие в мероприятиях сообщества разработчиков и их спонсирование.
Чтобы улучшить отношения с коллегой из технической службы, вы можете пригласить его на обед и обсудить рабочие вопросы, выяснив, какие задачи он считает самыми сложными и как вы можете помочь их решить с продуктовой точки зрения. Все, чем вы окажетесь полезны друг другу, будет иметь огромное значение для создания эффективного продуктового подразделения, способного разрабатывать и поставлять на рынок продукты-хиты.
Глава 19. Операционный менеджер с техническими навыками
Менеджеры продукта, работающие в активно развивающихся компаниях и корпорациях, часто жалуются, что им приходится тратить слишком много времени на деятельность, связанную с управлением проектами. В результате его почти не остается для выполнения своих основных обязанностей — обеспечения того, чтобы у инженерно-технического персонала компании был продукт, который действительно стоит создать.
Операционный менеджер с техническими навыками[9] — это особый тип менеджера проекта, миссия которого заключается в устранении препятствий — всего, что может мешать команде в работе над продуктом. Иногда эти препятствия связаны с другой продуктовой командой, а иногда с организационными функциями, не касающимися разработки продукта. Всего за один день менеджер проекта может отыскать нужного человека из маркетингового подразделения и убедить его принять предлагаемое решение или одобрить идею; согласовать с менеджером из другой команды приоритетные направления взаимодействия; убедить дизайнера продукта разработать графику для разработчика пользовательского интерфейса и устранить еще с десяток подобных препятствий.
Этот менеджер обычно еще и выполняет функцию Scrum-мастера для своей команды (если в ней предусмотрена такая роль). Его задача — помогать команде быть проворнее, но делает он это не кнутом и розгами, а устраняя преграды, мешающие людям трудиться эффективно.
Этих сотрудников могут называть менеджерами проекта или иногда сопровождающими программного продукта, но если такие люди есть в вашей компании, непременно убедитесь, что они определяют свои функциональные обязанности так, как только что описал я, а не в духе устаревшего управления разработкой программ.
Если в вашей компании нет менеджера проекта — как бы ни называлась эта должность, — его обязанности обычно ложатся на плечи менеджера продукта и руководителей инженерных групп. Для маленькой компании такая ситуация вполне допустима, и в ней даже есть некоторые преимущества. Но если в компании работает 5–10 продуктовых команд, важность этой роли существенно возрастает.
Глава 20. Структурирование продуктовых команд
Перед каждой компанией, которая на определенном этапе развития достигает большого масштаба, встает сложная задача — разделить свой продукт между многими продуктовыми командами. Такая потребность возникает уже при наличии одной-двух команд, но по мере того как их число растет — до двадцати пяти, пятидесяти, ста и более, — она становится острой необходимостью, иначе компания не сможет достаточно быстро работать и реагировать на изменения. А еще это очень важно для того, чтобы поддерживать в командах чувство личной ответственности за нечто значимое и одновременно вызывать у людей желание вносить вклад в более масштабное видение, в котором сумма больше отдельных частей.
Если ваша компания доросла до значительного масштаба, я уверен, что вы отлично знаете, о чем идет речь.
Особенно усложняет эту задачу то, что для нее не существует единственно правильного решения. В хороших продуктовых компаниях выслушиваются разные мнения, учитывается множество факторов, обсуждаются все возможные альтернативы и только потом принимается решение.
Я работал со многими продуктовыми и технологическими компаниями в момент обсуждения ими разных вариантов и нередко имел возможность собственными глазами наблюдать, как в итоге решался этот вопрос. Знаю: людям очень хотелось бы заполучить точный «рецепт» структурирования продуктовых команд, но увы, его не существует. Зато есть ряд важных принципов, и чтобы преуспеть в этом деле, их необходимо понять и взвесить все возможные варианты с учетом своих условий. Предлагаю обсудить эти принципы подробно.
1. Согласованность с инвестиционной стратегией.
Меня не перестает удивлять, как часто команды — это просто отражение текущих инвестиций компании. В таких компаниях команды существуют просто потому, что так принято. Но мы, конечно же, обязаны инвестировать не только в настоящее, но и в будущее. Мы должны отказываться от продуктов, переставших быть прибыльными, и время от времени сокращать вложения в продукты-«дойные коровы», чтобы иметь возможность больше вкладывать в будущие источники дохода и роста. К распределению инвестиций по времени с учетом фактора риска можно подходить по-разному. Одни люди предпочитают использовать модель «трех горизонтов роста»[10], другие — подход портфельного менеджмента. Главное — чтобы у вас непременно была четкая инвестиционная стратегия, а структура продуктовых команд в вашей компании должна быть ее отражением.
2. Минимизация взаимозависимости.
Важнейшая задача — свести к минимуму зависимость команд друг от друга, чтобы они быстрее функционировали и чувствовали себя более самостоятельными. Конечно, полностью устранить взаимозависимость невозможно, но мы можем и должны целенаправленно работать над ее постепенным уменьшением почти до нуля. Обратите внимание: характер зависимости со временем меняется, поэтому следите за ней постоянно и всегда спрашивайте себя, как можно ее уменьшить.
3. Чувство владельца и самоуправление.
Всегда помните об одной из самых важных отличительных характеристик эффективных продуктовых команд — это команды «миссионеров», а не «наемников», что подводит нас прямо к ключевым концепциям чувства владения и самоуправляемости. Команда должна чувствовать, что она наделена широкими полномочиями, при этом быть ответственной за важную часть общего продуктового предложения компании. Достичь этого труднее, чем может показаться на первый взгляд, потому что большие системы не всегда «нарезаются» на части абсолютно точно. Некоторая взаимозависимость всегда будет постепенно ослаблять силу чувства собственности, но мы должны прилагать все усилия, чтобы оно оставалось сильным.
4. Максимальная оптимизация.
По мере роста организационных подразделений у них часто появляются общие потребности, поэтому возрастает значение общих сервисов. Это чрезвычайно важно для скорости и стабильной работы подразделений и команд. Никому не нужно, чтобы каждая команда заново изобретала колесо. Однако следует помнить, что создание общих сервисов ведет к усилению взаимозависимости и может посягать на автономию команд.
5. Видение продукта и стратегия его развития.
Видение продукта описывает, к чему стремится компания, а продуктовая стратегия отмечает основные вехи, которые нужно преодолеть, чтобы дойти до цели. Надо признать, многие крупные и старые организации не имеют ничего подобного, хоть это и чрезвычайно важно. Как только вы определите свои видение и стратегию, убедитесь, что ваши команды структурированы так, чтобы обеспечивалась их реализация.
6. Размер команды.
Этот принцип в высшей мере практичный. Продуктовая команда минимального размера обычно состоит из двух инженеров-программистов и менеджера продукта, а если она отвечает за интерфейсную технологию, то еще и из дизайнера продукта. Считается, что меньшее количество членов продуктовой команды не дотягивает до необходимой критической массы. Однако замечено, что один продакт и один дизайнер способны загрузить достойными внимания задачами не более 10–12 инженеров-программистов. Кроме того (если это до сих пор неясно), очень важно, чтобы в каждой продуктовой команде был один, и только один, менеджер продукта.
7. Согласованность с архитектурой.
На практике при структурировании продуктовых команд многие компании руководствуются принципом архитектуры. Часто начинают с видения продукта, затем выстраивают архитектуру, которая поможет реализовать это видение, после чего выстраивают команды вокруг сложившейся архитектуры.
Вам может показаться, что при таком подходе все делается «задом наперед», на самом деле на то есть веские причины. Архитектуры определяют технологии, а технологии определяют наборы необходимых навыков членов команд. Конечно, нам хотелось бы, чтобы каждая команда была полностью укомплектована для работы на любом уровне архитектуры, но на практике это чаще всего невозможно. Инженеры обучены и подготовлены к работе с разными технологиями. Одни специализируются в той или иной предметной области (и во многих случаях занимаются этим не один год), у других совершенно отсутствуют некоторые необходимые навыки. Архитектура ведь меняется не в одночасье.
Обычно, если компания, комплектуя команды, не обращает на архитектуру должного внимания, это заметно сразу и проявляется несколькими способами. Во-первых, такие команды ощущают себя так, будто им приходится постоянно бороться с архитектурой. Во-вторых, взаимозависимости между командами кажутся несоразмерными. В-третьих, работа в таких командах движется медленно, и люди не чувствуют, что наделены широкими полномочиями — в сущности, это следствие двух первых пунктов.
В крупных компаниях одна или несколько команд предоставляют услуги общего характера всем продуктовым командам. Мы можем называть их общим центром обслуживания или платформенными командами, но в основном они отражают ту или иную архитектуру. Это позволяет обеспечить оптимизацию высочайшего уровня, и многие компании, достигая определенного масштаба, формируют подобные команды. Однако их чрезвычайно сложно укомплектовать персоналом, так как они, по замыслу, находятся в зависимости и подчинении у всех остальных команд компании, поскольку создаются ради обеспечения их деятельности. Непременно убедитесь, что включили в состав команд общего сервиса сильных и отлично разбирающихся в технологиях продакт-менеджеров.
8. Разделение по пользователю или клиенту.
В разделении кроются огромные преимущества и для продукта, и для команды. Если, например, ваша компания снабжает двусторонний рынок с покупателями на одной стороне и продавцами на другой, весьма полезно ориентировать одни команды на покупателей, а другие на продавцов. Тогда каждая продуктовая команда сможет углубиться в изучение своих потребителей, вместо того чтобы пытаться узнать все обо всех. Однако даже в коммерческих организациях всегда будет некоторое количество команд, которые обеспечивают общую основу и предоставляют услуги всем командам. Это действительно отражает архитектуру; словом, я стараюсь донести до вас мысль, что иметь команды обоих типов — обычное дело и, по сути, общепринятое.
9. Разделение по бизнес-подразделениям.
Крупные компании часто занимаются разными направлениями бизнеса — с общей основой для своих продуктов. Если бы технологии в разных бизнес-подразделениях существовали независимо друг от друга, мы просто структурировали бы продуктовые команды как разные компании. Но обычно так не бывает. У крупной компании, как правило, несколько направлений бизнеса, но все они базируются на общем и нередко взаимосвязанном фундаменте. Это немного напоминает разделение по типу потребителя, с некоторыми важными отличиями. Структура бизнес-единицы — конструкция искусственная. Разные бизнес-единицы часто продают продукты фактически одним и тем же покупателям. Таким образом, хотя разделение по подразделениям и обеспечивает определенные преимущества, в списке приоритетных факторов оно стоит не на первом месте
.
10. Структура — цель движущаяся.
Оптимальная структура продуктового подразделения представляет собой постоянно движущуюся цель. Подразделения должны и будут меняться с течением времени. Это не значит, что вам надо реорганизовывать их раз в несколько месяцев, но пересматривать структуру команд примерно каждый год действительно имеет смысл.
Мне часто приходится объяснять, что идеального способа структурировать команды не существует; каждая попытка сделать это в продуктовом подразделении будет означать оптимизацию чего-то одного за счет другого. Так что, как, впрочем, в случае с большинством решений по поводу продуктов и технологий, это всегда компромиссы и выбор. И я очень надеюсь, что описанные выше принципы помогут вам в дальнейшем структурировать свои подразделения.
Большинство ведущих современных технологических компаний добились успеха с помощью модели наделенных широкими полномочиями целеустремленных, стабильных, кросс-функциональных эффективно сотрудничающих продуктовых команд, которую я описываю в этой книге. Безусловно, результаты говорят сами за себя, но я объясняю львиную долю их преимуществ повышением мотивации и подлинным чувством владельца, которые возникают, когда члены команды понимают, что во многом сами управляют своей судьбой.
Хотя большинство руководителей компаний утверждают, что их команды пользуются огромной свободой действий и самостоятельностью, члены этих команд нередко жалуются, что далеко не всегда чувствуют себя так, как описывает руководство. И всякий раз, сталкиваясь с такой ситуацией, я стараюсь в деталях разобраться, почему команда не может самостоятельно принимать решения и в чем именно она чувствует себя ограничиваемой и ущемленной.
Надо сказать, большинство ситуаций, о которых мне рассказывают, относятся к одной из двух:
1. Менеджмент еще не доверяет команде и не хочет, образно говоря, ослабить натяжение поводка.
2. Команда хочет изменить то, что, по мнению руководства, является частью фундамента компании.
В целом большинство команд, скорее всего, согласятся, что есть то, в чем им позволено действовать по собственному усмотрению, и то, что незыблемо, так как считается общим для всех команд компании.
Приведу пример второго случая: было бы странно, если бы каждая команда сама выбирала для себя инструмент конфигурационного управления программным обеспечением. Если разработчики используют GitHub, так должны работать все команды. И даже если бы одна из команд испытывала страсть к какому-либо другому инструменту, совокупные затраты компании, связанные с разрешением на его использование, перевесили бы любые выгоды, полученные в результате. Это простой и понятный пример, но есть и другие, не столь «прозрачные». Например, должна ли каждая команда по-своему подходить к автоматизации тестирования? Могут ли команды сами выбирать языки программирования, которые хотят использовать? Что вы скажете о фреймворках пользовательского интерфейса, или совместимости браузера, или дорогостоящих функций, таких как поддержка в режиме офлайн, или agile-методик, который хотят применять команды? В самом ли деле всем командам нужно поддерживать несколько инициатив, касающихся продуктов, реализуемых в рамках компании?
Как часто бывает с продуктом, все сводится к компромиссу. В данном случае к компромиссу между самоуправлением команды и использованием преимуществ централизованного управления.
Должен признаться, мне по душе идея самостоятельной продуктовой команды, наделенной широкими полномочиями, но я также большой сторонник инвестиций в общий центр решения задач, поскольку это прочная база, которую все команды могут использовать для создания потрясающих продуктов и опыта, делая это гораздо быстрее, чем при ее отсутствии.
Для протокола скажу, что, по моему убеждению, четкого ответа на этот вопрос быть не может. Наилучшим для каждой команды будет свой ответ, а он, безусловно, в значительной мере зависит от ее культуры.
Перечислю ключевые факторы, которые необходимо учесть, отвечая на этот вопрос.
Уровень командного мастерства
Специалисты различают три уровня навыков командной работы. Команда А — опытная: ей можно доверить выбор, потому что он стопроцентно будет верным. Команда Б: у ее членов правильные намерения, но во многих ситуациях нет опыта, необходимого для принятия взвешенных решений, поэтому они могут нуждаться в некоторой помощи. Команда В — совсем молодая, и, возможно, сама не знает, чего она еще не знает. Такие команды без эффективного коучинга могут ненароком создать серьезные проблемы.
Значение скорости
Один из главных аргументов в пользу общего центра решения задач — это скорость. Логично предположить, что для того, чтобы работать быстро, команды должны иметь возможность опираться на работу коллег и не тратить время на изобретение велосипеда. Однако иногда компании сознательно идут на жертвы ради самоорганизации, позволяя командам в потенциале дублировать некоторые задачи и идти вперед медленнее. А иногда от этого зависит жизнеспособность бизнеса.
Значение интеграции
Когда портфель компании состоит из набора связанных, но в основном независимых продуктов, интеграция и взаимозависимость не так важны. Но когда портфель включает тесно связанные продукты, интеграция приобретает огромное значение. Тут все сводится к вопросу об оптимизации работы команд: должны ли они делать это ради достижения своих целей или ради компании в целом?
Источник инноваций
Если основные источники будущих инноваций необходимы на уровне общего центра задач, командам нужно дать больше свободы в деле изменения базовых компонентов. Если же такие источники ожидаются на уровне решений, следует поощрять менее активное изменение фундаментальных инструментов и вместо этого направить креативность команд на инновации решений их уровня.
Размер и расположение компании
Многие острые вопросы в самоуправлении возникают из-за проблем, связанных с масштабированием. По мере роста и усложнения компаний — особенно если их команды локализованы в разных местах — фундаментальные решения и принципы становятся все более важными, притом что их труднее поддерживать. Одни компании пытаются справиться с этой задачей с помощью концепции центров передового опыта, которые поддерживают и развивают фундаментальные решения всей компании на месте. Другие пробуют более сильные комплексные роли. Третьи включают процесс.
Культура компании
Важно также признать роль, которую в культуре компании играет акцент на самоуправлении в сравнении с акцентом на фундаментальных решениях. Чем ближе компания в этом спектре перемещается к последним, тем больше это воспринимается командами как постепенное ограничение их самостоятельности. Такая ситуация может казаться вполне приемлемой для упомянутых выше команд типа Б и В, но весьма проблематична для команд уровня A.
Зрелость технологии
Нередко компании пытаются преждевременно стандартизироваться на общем фундаменте, когда он еще не готов эффективно обеспечивать ожидаемые от него выгоды и преимущества. Если слишком сильно давить в этом плане до полной готовности фундамента, можно серьезно навредить командам, которые излишне полагаются на него в работе. В этом случае вы построите карточный домик, который может рассыпаться в любой момент.
Значение для бизнеса
Если общий фундамент очень большой, повышается риск того, что какая-либо из команд компании не станет его использовать. Для некоторых областей деятельности такое положение вещей нормально, но, если речь идет о продуктах или инициативах, крайне важных для бизнеса, это вопрос жизни и смерти.
Уровень ответственности
Другой важный фактор — это уровень ответственности, который неотделим от расширения полномочий и самоуправления. При ее отсутствии — особенно если у вас нет сильных команд типа А — у команд мало причин переживать из-за баланса между ответственностью и самостоятельностью. Но вам надо устроить все так, чтобы для людей это было важно. Например, если я уверен в профессионализме команды и в том, что ее члены в полной мере понимают последствия и риски и все же настаивают, что тот или иной компонент общего фундамента нуждается в замене, я, скорее всего, стану на их сторону.
Как видите, для достижения баланса между самоуправлением и использованием общего фундамента необходимо учесть массу важных факторов и соображений. Но, я уверен, если вы обсуждаете эти темы честно и открыто, большинство ваших команд готовы идти на разумные уступки. Иногда достаточно задать несколько вопросов о возможных последствиях, чтобы помочь командам принять более обоснованное решение. Если же команды постоянно принимают в связи с этим неверные решения, возможно, стоит задуматься об опытности их членов, но, вероятно, им просто не хватает знаний об общем бизнес-контексте.
Бизнес-контекст включает в себя два основных элемента:
1. Общее видение продукта.
2. Конкретные бизнес-цели, стоящие перед каждой командой.
Эти ключевые темы обсуждаются в следующих главах. Если руководство компании не уделяет этим двум важнейшим частям бизнес-контекста достаточно внимания, у нее непременно начинаются проблемы, в частности возникает своего рода вакуум, порождающий неопределенность в отношении того, какие решения команда имеет право принимать самостоятельно, а какие нет.
Обратите внимание: хотя для обеспечения бизнес-контекста руководство предлагает людям видение продукта и ставит перед командами конкретные бизнес-цели, о том, как они должны решать свои задачи, не говорится ни слова. Именно в этом и заключается свобода действий и гибкость продуктовых команд.
Глава 21. Знакомьтесь: Лиа Хикман из Adobe
Cтартапам или небольшим компаниям для успешной работы часто достаточно одной сильной продуктовой команды с ярким, ориентированным на продукт СЕО или менеджером продукта. Но крупным компаниям обычно нужно больше. Им требуется сильное лидерство продукта в самом лучшем смысле этого слова, что, конечно же, предполагает обеспечение убедительного видения продукта и четкой стратегии работы с ним.
Одна из самых сложных задач в нашей индустрии — инициировать серьезные изменения в крупной и финансово успешной компании. Во многих отношениях сделать это значительно проще, когда у организации серьезные проблемы и она испытывает сильный дискомфорт, который можно использовать как очень мощный мотивирующий фактор. Однако поистине великие компании всегда готовы нарушить свой статус-кво сами, прежде чем это сделает кто-то другой. Разница между преуспевающими Amazon, Netflix, Google, Facebook и легионами других крупных, но медленно умирающих компаний, заключается именно в сильном продуктовом лидерстве.
В 2011 году Леа Хикман возглавила подразделение Adobe Creative Suite. К этому времени она проработала в Adobe уже несколько лет, помогая строить очень большое и успешное направление бизнеса, которое ежегодно приносило компании примерно 2 миллиарда долларов на продаже лицензий. Речь идет о программном пакете Creative Suite для настольных компьютеров.
Леа понимала, что рынок меняется и ее компании необходимо перейти со старой модели, ориентированной на настольный компьютер и требующей ежегодного обновления лицензии, к модели, основанной на подписке и поддерживающей планшеты и смартфоны со всеми их бесконечными моделями, которые дизайнеры все активнее использовали. Если смотреть шире, Леа знала, что устаревшая модель стимулировала компанию на изменения Creative Suite в направлениях, которые не были полезны ни для потребителей Adobe, ни для долгосрочного успеха самой компании. Но внедрить изменения такого огромного масштаба — а на доходы от Creative Suite приходилась примерно половина совокупного годового дохода Adobe, составлявшего 4 миллиарда долларов, — было чрезвычайно трудной задачей.
Нужно понимать, что каждая косточка и мышца в крупном корпоративном организме работает на защиту имеющегося стабильного дохода, и столь грандиозные изменения обязательно означали бы выталкивание компании за пределы ее зоны комфорта. И такие перемены затронули бы практически все направления деятельности компании: финансовое, юридическое, маркетинговое, технологическое, продажи.
Назовем типичные поводы для беспокойства.
Финансовый персонал был крайне обеспокоен тем, как переход с лицензионной модели на модель подписки скажется на доходах.
Инженерно-технические команды волновал переход от последовательной модели релизов каждые два года к модели непрерывного исследования и поставки продукта на рынок, особенно учитывая гарантии его качества. Разработчиков также беспокоило, что это приведет к усилению их ответственности.
Отдел продаж ожидал, что предлагаемый Леа переход повлечет за собой серьезные изменения способов продажи продуктов Creative Suite. Вместо крупной сети посредников Adobe перейдет к прямым отношениям с потребителями. Хотя многие в компании, в сущности, с нетерпением ждали таких перемен, в продажах понимали, что это весьма рискованно, ведь если что-нибудь пойдет не так, посредники, скорее всего, не простят компании измены.
И конечно же, не стоит недооценивать эмоциональной стороны перехода с модели владения софтом на модель арендного доступа к нему как для потребителей, так и для торгового персонала компании.
Учитывая то, что у используемого тогда пакета Creative Suite уже было более миллиона пользователей, Леа отлично понимала, какой будет кривая принятия технологии и что определенный сегмент клиентской базы станет сильно сопротивляться изменению этого параметра. Она также знала, что дело не только в том, будет ли новый набор приложений Creative Cloud лучше прежнего, но и в том, что он будет отличаться от прежнего, и во многих смыслах весьма существенно. И одним людям, чтобы «переварить» эти изменения, понадобится больше времени, чем другим.
Стоит также учитывать, что Creative Suite представляет собой пакет интегрированных приложений, включающий пятнадцать основных программ и множество небольших утилит. Следовательно, трансформировать пришлось бы не один продукт, а полный пакет, что резко повышало риск и сложность задачи. Стоит ли удивляться, что на трансформацию продукта такого масштаба шло так мало компаний?
По мнению Леа, ее и ее команды ждали очень тяжелые времена. Она понимала, что для того, чтобы все эти взаимосвязанные компоненты имели возможность идти вперед параллельно, ей нужно максимально четко сформулировать убедительное видение нового будущего, в котором целое будет лучше и больше суммы отдельных частей.
Сначала Леа в сотрудничестве с техническим директором Adobe Кевином Линчем объединила несколько многообещающих прототипов, чтобы наглядно продемонстрировать мощь нового фундамента, и использовала результат для того, чтобы ободрить и сплотить руководство и продуктовые команды вокруг новой идеи. Затем она инициировала длительную и даже изнурительную кампанию, в рамках которой постоянно общалась с лидерами и заинтересованными сторонами из разных подразделений компании. Для Леа не существовало такого понятия, как слишком много общения. А непрерывный поток прототипов отлично помогал подогревать искренний интерес людей к тому, что именно принесет им предлагаемое ею новое будущее.
Набор межплатформенных приложений Creative Cloud стал настолько успешным (на момент написания этой главы Adobe заработала более миллиарда долларов в форме повторного дохода быстрее, чем любая другая компания в мире), что компания перестала выпускать релизы Creative Suite для ПК и сосредоточила инновации на этом новом фундаменте. Сегодня более 9 миллионов профессионалов-креативщиков подписаны на этот замечательный продукт Adobe и активно используют его в своей работе. А сама Adobe во многом благодаря этому переходу более чем утроила рыночную капитализацию по сравнению с показателем до соответствующих изменений. Сегодня она стоит около 60 миллиардов долларов.
Крупные компании со значительными доходами очень часто отказываются рисковать тем, что имеют, и не внедряют необходимых для выживания и, уж конечно, для дальнейшего процветания изменений. Леа решила эту и многие другие проблемы, пойдя ва-банк, — благодаря убедительному видению, четкой стратегии и постоянным коммуникациям со множеством заинтересованных сторон.
Этот пример — один из самых впечатляющих, почти фантастических из всех, что я мог бы вам привести. Речь идет о поистине великом лидере продукта, который сумел инициировать и внедрить массовые и значимые изменения в прочно устоявшейся крупной корпорации. И я убежден, что Adobe не достигла бы тех вершин, на которых прочно закрепилась сегодня, без Леа — великого лидера, который готов не покладая рук трудиться над тем, чтобы довести до победного конца необходимые изменения.
Я очень рад тому, что сегодня Леа — партнер в Silicon Valley Product Group; она помогает другим компаниям успешно проходить через серьезную трансформацию и внедрять современные передовые методики работы с продуктами.