В чем разница между менеджером продукта и лидером доставки в командах непрерывного обнаружения и доставки?

Перед каждой продуктовой командой стоят две фундаментальные задачи высокого уровня: определение продукта, который необходимо создать, и доставка этого продукта на рынок. Таким образом, если говорить о роли руководителя доставки и менеджера продукта в Agile-командах, то основная задача менеджера продукта (PM) - формирование продукта, а основная задача руководителя доставки (также известного как менеджер доставки) - доставка продукта (хотя каждый из них участвует в обоих процессах). <\/p>\r\n\r\n

И открытие, и доставка идут параллельно, поэтому мы должны определить эти две роли как часть непрерывного открытия и доставки.<\/p>\r\n\r\n

Казалось бы, все более чем понятно, но после многолетнего опыта оказания услуг по UI\/UX-дизайну в составе многочисленных продуктовых команд мы можем констатировать, что в большинстве компаний до сих пор используется процесс, который по своей сути является водопадным (даже если они называют его Agile), где открытие - это только первый шаг разработки продукта. Такой подход приводит к тому, что многие продукты оказываются неудачными, и вот почему.<\/p>\r\n\r\n

<\/p>\r\n\r\n

Что не так с тем, как большинство компаний организуют процесс разработки продуктов?<\/h2>\r\n\r\n

В большинстве организаций, независимо от их размера, процесс разработки продукта выглядит примерно так:<\/p>\r\n\r\n

\r\n\t
• Компания получает идеи от заинтересованных сторон, владельцев бизнеса или клиентов. <\/li>\r\n\t
• Затем идеи расставляются по приоритетам и формируется дорожная карта. Но для того чтобы расставить приоритеты, сначала необходимо составить некое бизнес-обоснование для каждого продукта, чтобы узнать, какую ценность он принесет и сколько денег или времени на него потребуется. На основе этой информации строится дорожная карта. <\/li>\r\n\t
• Затем менеджер по продукту выбирает наиболее приоритетный вопрос и обсуждает его с заинтересованными сторонами для разработки концепции и создания списка "требований" (пользовательских историй). Пользовательские истории нужны для того, чтобы донести до дизайнеров и инженеров то, что должно быть создано.<\/li>\r\n\t
• После того как компания определила требования, она просит команду дизайнеров визуализировать идею с помощью UI\/UX-дизайна (если компания вообще решает взять в штат команду дизайнеров).<\/li>\r\n\t
• Далее инженеры получают требования и проектные спецификации для реализации идеи (вот тут-то Agile и вступает в игру, поскольку инженеры обычно делят работу на спринты, чтобы параллельно разрабатывать и тестировать идею).<\/li>\r\n\t
• Если тестирование QA не включено в эти спринты, то команда QA проводит дополнительное тестирование, чтобы убедиться, что новая концепция функционирует так, как задумано.<\/li>\r\n\t
• Наконец, после того как специалисты по контролю качества одобрят реализованную идею, она развертывается и представляется реальным клиентам.<\/li>\r\n<\/ul>\r\n\r\n

  Такой процесс мало похож на Agile и является причиной многих проблем:<\/p>\r\n\r\n

  \r\n\t
  • Идея очень долго не доходит до реальных заказчиков. <\/li>\r\n\t
  • Дорожные карты рискуют превратиться в список функций, которые хотят реализовать различные подразделения (и, скорее всего, как минимум половина из этих идей не будет работать так, как вы ожидаете).<\/li>\r\n\t
  • Менеджер по продукту превращается в менеджера проекта, который только собирает требования и передает их разработчикам.<\/li>\r\n\t
  • Компания не может получить полную отдачу от UX-дизайна, поскольку дизайнеры включаются в процесс слишком поздно (если вообще включаются).<\/li>\r\n\t
  • Аналогичная проблема существует и с разработчиками. Хотя они могут внести большой вклад в инновации продукта, во многих компаниях от инженеров требуется только написание кода, и они включаются в процесс разработки продукта очень поздно. <\/li>\r\n<\/ul>\r\n\r\n

    Утверждение продукта заказчиком происходит слишком поздно. В результате предприятия вкладывают время и деньги в деятельность, которая на самом деле не приносит им пользы.
    \r\nКаков же выход из этой ситуации? Процесс создания продукта и его доставки должен идти параллельно и непрерывно. В сильных продуктовых командах менеджеры по продуктам, дизайнеры, руководители отдела доставки (если таковые имеются) и разработчики работают в тесном сотрудничестве, чтобы создать высококачественный продукт, который понравится пользователям.<\/p>\r\n\r\n

    Теперь давайте определим роли менеджера по продукту и руководителя доставки с точки зрения непрерывного создания и доставки продукта.<\/p>\r\n\r\n

    <\/p>\r\n\r\n

    Как менеджер продукта и руководитель доставки вписываются в непрерывное обнаружение и доставку<\/h2>\r\n\r\n

    Для начала давайте посмотрим, как должны выглядеть эти два процесса.<\/p>\r\n\r\n

    Процесс обнаружения продукта <\/strong>направлен на то, чтобы отличить хорошие идеи от плохих и, как следствие, позволить команде получить утвержденный бэклог продукта. Ключевым компонентом процесса обнаружения продукта является тесное сотрудничество между командами управления продуктами, проектирования пользовательского опыта и инженеров. Прежде чем приступить к созданию решения, эти специалисты совместно работают и проводят эксперименты, чтобы исключить риски, находя ответы на следующие вопросы:<\/p>\r\n\r\n

    \r\n\t
    • Будут ли люди готовы использовать это решение и платить за него?<\/li>\r\n\t
    • Возможно ли создать данное решение\/функцию с технической точки зрения?<\/li>\r\n\t
    • Будет ли программное обеспечение\/функционал достаточно простым для использования людьми?<\/li>\r\n\t
    • Поддержат ли заинтересованные стороны эту концепцию?<\/li>\r\n<\/ul>\r\n\r\n

      Когда у команды есть доказательства того, что идея, которую они собираются реализовать, достаточно ценна с точки зрения заказчика и технически осуществима, приходит время ее реализовывать.<\/p>\r\n\r\n

      Цель доставки продуктов<\/strong> - создание и выпуск высококачественных технологических решений, которые будут покупать люди, а бизнес - получать выгоду. Непрерывная доставка позволяет командам производить продукты\/функции в коротких циклах, обеспечивая их надежный выпуск с большей скоростью и частотой. <\/p>\r\n\r\n

      Непрерывное обнаружение и доставка означают, что команда выполняет все вышеперечисленные действия еженедельно, как часть своих регулярных обязанностей. Такие процессы охватывают все - от определения того, достаточно ли потребителей хотят получить данное решение, до разработки эффективных продуктов, приносящих пользу как клиентам, так и бизнесу. Таким образом, время, потраченное на серьезные исследования, положительно сказывается на разработке, а именно так и должны работать компании. <\/p>\r\n\r\n

      Непрерывное обнаружение и доставка особенно хорошо работают для компаний, ориентированных на продукт, поскольку они склонны фокусироваться только на тех продуктах\/функциях, которые приносят больше пользы конечному пользователю.<\/p>\r\n\r\n

      Мы лучше всего ощутили эту связь между открытием и доставкой, когда работали в качестве удаленных дизайнеров над Haven Diagnostics, программным обеспечением, позволяющим оценивать риски распространения заболеваний в офисах. Прежде чем разрабатывать продукт, они хотели узнать, кто их пользователи. Наш дизайнер постоянно общался с генеральным директором (который также выполнял роль PM) и инженером, обсуждая их видение, ожидания и проводя мозговой штурм идей дизайна для формирования конечного продукта. Лучшие концепции затем тестировались пользователями.<\/p>\r\n\r\n

      В ходе "мозгового штурма" мы вместе выдвигали идеи о том, как повысить точность расчетов и лучше адаптировать результаты к потребностям конкретных клиентов. Хотя эта процедура не затрагивала непосредственно дизайн, она повлияла на бэкэнд и повысила качество продукта.<\/p>\r\n\r\n

      В рамках двух непрерывных процессов существует множество задач, которые команда должна выполнять ежедневно. Менеджер продукта и руководитель поставки должны помогать команде и следить за тем, чтобы она создавала то, что нужно клиентам и бизнесу.<\/p>\r\n\r\n

      Роль и обязанности менеджера по продукту<\/h2>\r\n\r\n

      Начнем с роли менеджера по продукту как наиболее вовлеченного в процесс обнаружения.<\/p>\r\n\r\n

      Хороший менеджер продукта - это тот, кто в наибольшей степени соответствует определению масштаба, видения продукта, целевой аудитории и проблем, которые должен решать продукт. Эти люди служат голосом клиентов для всей организации. Таким образом, в традиционном управлении проектами задача PM заключается в том, чтобы обеспечить команде разработчиков продукт, который стоит создавать. <\/p>\r\n\r\n

      Вот список их основных обязанностей:<\/p>\r\n\r\n

      \r\n\t
      • Сбор обратной связи от пользователей (желательно из прямых источников, таких как комментарии в службах самообслуживания, Customer Success Team и т.п.). <\/li>\r\n\t
      • Распределять запросы по конкретным идеям и темам, чтобы компания могла отслеживать количество запросов по каждой из них.<\/li>\r\n\t
      • Сообщайте клиентам о том, что вопрос решен, чтобы они чувствовали, что их слышат.<\/li>\r\n\t
      • Глубоко изучайте данные о продукте, чтобы понять истинную картину и распознать закономерности.<\/li>\r\n\t
      • Определите пользователей, которые взаимодействуют с соответствующими элементами продукта, и изучите их глубже.<\/li>\r\n\t
      • Проводите генеративные интервью, чтобы помочь команде понять то, что не могут объяснить данные.<\/li>\r\n\t
      • Поощряйте клиентов делиться своим опытом, чтобы создать полный контекст.<\/li>\r\n\t
      • Придумайте несколько решений и протестируйте их, чтобы понять, какое из них лучше всего приводит к желаемому результату.<\/li>\r\n\t
      • Попробуйте различные решения на разных сегментах, чтобы понять, решают ли они проблему желаемым и удобным способом.<\/li>\r\n\t
      • Выберите лучший вариант путем сравнения и сопоставления и убедитесь, что решение решает реальную проблему.<\/li>\r\n\t
      • Поделитесь с командой разработчиков не только "что", но и "почему", чтобы они могли принимать решения, которые лучше соответствуют потребностям клиентов.<\/li>\r\n\t
      • Вместе с разработчиками представьте продукт небольшим тестовым группам для сбора отзывов и данных об использовании.<\/li>\r\n\t
      • По мере совершенствования релиза проводите тестирование на дополнительных сегментах потребителей.<\/li>\r\n<\/ul>\r\n\r\n

        Кстати, большинство описанных выше действий выполняются в сотрудничестве менеджера по продукту с UX-дизайнером.<\/p>\r\n\r\n

        <\/p>\r\n\r\n

        Роль и обязанности руководителя доставки<\/h2>\r\n\r\n

        Многие менеджеры по продукту в растущих компаниях перегружены задачами по управлению проектами, что отвлекает их от основных обязанностей. Вот тут-то и приходят на помощь менеджеры по доставке.<\/p>\r\n\r\n

        Менеджер по доставке<\/strong> - это такой руководитель проекта, который несет наибольшую ответственность за своевременную поставку продукта с соблюдением стандартов и качества. Их основная задача - ускорить работу команды разработчиков за счет устранения препятствий (помех), которые могут возникнуть в процессе разработки. Для этого руководители доставки могут общаться с отделом маркетинга, руководителями доставки из других команд, дизайнерами и т.д.<\/p>\r\n\r\n

        Руководитель доставки<\/strong> - это роль, а не обязательно отдельная должность в организации. Очень часто руководители поставок имеют должность Scrum-мастера, менеджера проекта или менеджера программы. Неважно, как вы называете этого человека, если есть кому выполнять эту работу.<\/p>\r\n\r\n

        Вот что делают руководители поставок на регулярной основе:<\/p>\r\n\r\n

        \r\n\t
        • Отслеживают и устраняют препятствия, управляют рисками и зависимостями.<\/li>\r\n\t
        • Определять оптимальную структуру команды и распределять людей по командам доставки продуктов.<\/li>\r\n\t
        • Обеспечение регулярной доставки проектов и продуктов в соответствии с методологией Agile.<\/li>\r\n\t
        • Содействие проведению непрерывных итераций.<\/li>\r\n\t
        • Поддерживать контакты между основателем и командой.<\/li>\r\n\t
        • Наставничество над QA и Tech-руководителями.<\/li>\r\n\t
        • Фасилитация и руководство основными Agile-церемониями, такими как стенд-апы, планирование спринта, подготовка бэклога и ретроспективные встречи.<\/li>\r\n\t
        • Поддерживать сроки и бюджеты проектов.<\/li>\r\n\t
        • Поддерживать атмосферу сотрудничества, творчества и эффективности в коллективе.<\/li>\r\n<\/ul>\r\n\r\n

          Подводя итог, можно сказать, что должность руководителя службы доставки направлена на то, чтобы помочь команде быстрее продвигать проекты - не крича на них, а избавляясь от препятствий.<\/p>\r\n\r\n

          Как узнать, нужно ли мне нанимать менеджера по продукту, менеджера по доставке или обоих?<\/h2>\r\n\r\n

          Если говорить о необходимости найма менеджера по продукту, то короткий ответ будет таким: "Да, этот специалист нужен в вашей команде". Менеджеры по продукту в первую очередь отвечают за успех продукта, донося до пользователей четкое видение и стратегию, поэтому они играют важнейшую роль в процессе разработки продукта. В небольших компаниях роль менеджера по продукту часто выполняют генеральные директора, основатели и т.д.<\/p>\r\n\r\n

          Что касается менеджера по поставке, то, как мы уже говорили, он может иметь должность Scrum-мастера, менеджера проекта или менеджера программы. Если в вашей организации нет менеджера по доставке (независимо от его должности), то эту функцию часто выполняют менеджер по продукту или инженерные менеджеры. И для небольших стартапов это вполне приемлемо. Однако если в вашей компании более пяти продуктовых команд, мы бы настоятельно рекомендовали нанять и менеджера по продукту, и руководителя доставки.<\/p>\r\n\r\n

          В конечном счете, все зависит от структуры команды разработчиков продукта и от того, что лучше подходит для каждого конкретного проекта.<\/p>\r\n