Вдохновленные - читать онлайн книгу. Автор: Марти Каган cтр.№ 23

ИССЛЕДОВАНИЕ ПРОДУКТА

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

ЕВАНГЕЛИЗМ

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

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

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

Операционный менеджер с техническими навыками ^[9] — это особый тип менеджера проекта, миссия которого заключается в устранении препятствий — всего, что может мешать команде в работе над продуктом. Иногда эти препятствия связаны с другой продуктовой командой, а иногда с организационными функциями, не касающимися разработки продукта. Всего за один день менеджер проекта может отыскать нужного человека из маркетингового подразделения и убедить его принять предлагаемое решение или одобрить идею; согласовать с менеджером из другой команды приоритетные направления взаимодействия; убедить дизайнера продукта разработать графику для разработчика пользовательского интерфейса и устранить еще с десяток подобных препятствий.

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

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

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

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

Если ваша компания доросла до значительного масштаба, я уверен, что вы отлично знаете, о чем идет речь.

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

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

1. Согласованность с инвестиционной стратегией.

Меня не перестает удивлять, как часто команды — это просто отражение текущих инвестиций компании. В таких компаниях команды существуют просто потому, что так принято. Но мы, конечно же, обязаны инвестировать не только в настоящее, но и в будущее. Мы должны отказываться от продуктов, переставших быть прибыльными, и время от времени сокращать вложения в продукты-«дойные коровы», чтобы иметь возможность больше вкладывать в будущие источники дохода и роста. К распределению инвестиций по времени с учетом фактора риска можно подходить по-разному. Одни люди предпочитают использовать модель «трех горизонтов роста» ^[10], другие — подход портфельного менеджмента. Главное — чтобы у вас непременно была четкая инвестиционная стратегия, а структура продуктовых команд в вашей компании должна быть ее отражением.