Как выглядит переход от проекта к продукту?


Время сделать «переход» от проекта к продукту.

После выхода в прошлом году бестселлера доктора Мик Керстен «Проект к продукту» движение продолжает набирать обороты. 55% организаций, опрошенных Gartner, стремятся перейти на менталитет, ориентированный на продукт, Как на самом деле выглядит переход от проекта к продукту?

Вам также может понравиться:
От проекта к продукту: что протекает через программный поток создания ценности?

Хотя моя компания Tasktop не является предприятием на 30 000 человек, большая часть того, что мы испытали, по-прежнему применима к крупным организациям. Мы также многому научились благодаря нашей работе с корпоративными клиентами, более 40 процентов из которых входят в список Fortune 100.

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

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

  1. бюджетирование: Финансирование распределяется на основе результатов деятельности, а новые средства распределяются по мере необходимости и на основе предоставления дополнительных результатов.
  2. Временные рамки: Не определена конечная дата – сфокусирован на многолетнем жизненном цикле продукта, включая текущее обслуживание и деятельность в области здравоохранения.
  3. Успех: Оценивается в зависимости от способности команды обеспечивать дополнительную ценность и удовлетворять бизнес-целям.
  4. Команда: Кросс-функциональные команды, посвященные определенному потоку создания ценности продукта для стабильности и трудовых ресурсов.
  5. Приоритезация: Продукты, основанные на дорожных картах и ​​проверке гипотез, выложенные владельцами продуктов и их деловыми партнерами, с акцентом на функциональность и ценность для бизнеса.
  6. Видимость: Легко привязывает развитие непосредственно к бизнес-результатам для лучшей прозрачности.
  7. Риск: Распространение на длительный период времени и несколько итераций, создавая возможности для корректировки характеристик продукта, если первоначальное предположение было неверным или возникли стратегические возможности.

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

  • Мы против них менталитет между продуктом и разработкой.
  • Проблемы должны были подняться (генеральный директор), чтобы решить.
  • Неполные знания и сочувствие к нашим клиентам.
  • Чувствовал себя более сосредоточенным на себе; рискует потерять из виду клиента.
  • Не полностью ориентирован на продукт во всей организации (через финансы, персонал, бизнес-разработчик и т. Д.).
  • Инвестиционные решения были «дважды выпечены»; они должны были перепродать инженерии.

Углубившись вглубь, мы поняли, что мышление – это все, и что контекст работы имеет решающее значение для того, чтобы мы были сосредоточены на том, что имеет значение в конце дня: на клиенте. Мы стремились смягчить эти симптомы, посмотрев в объектив клиента, чтобы убедиться, что мы действительно одержимы клиентом.

Структурирование вокруг клиента

Одним из ключевых изменений, которые мы внесли, чтобы стать более ориентированным на клиента, было положить конец менталитету «мы против них» между проектированием и продукцией.

Схема разбивки генерального директора.

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

Диаграмма с подробным описанием "клиент первым" образ мышления

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

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

Ведущий график PVS

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

Представление продукта Поток создания ценности

Генеральный директор вице-президента в PVS чарте

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

Мы посвятили много времени тому, чтобы обозначить разницу между руководителем PVS и менеджером по продукту. Вам нужны обе роли, и ни один из них не является руководителем проекта; это различие должно быть ясным для тех, кто находится в ролях и в наших коммуникациях по всему бизнесу.

Лидер PVS отвечает за все аспекты потоков ценности своих продуктов с точки зрения:

  • Бизнес: Видение, дизайн, удовлетворенность клиентов, затраты, ценообразование, рыночные изменения.
  • Оперативная: Процессы (как инженерные, так и продуктовые), лицензирование и т. Д.
  • Технические: Agile команды, оценка, архитектура.

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

Диаграмма структуры верхнего уровня по умолчанию

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

описание руководителя PVS и менеджера по продукту

Бизнес-ориентированные: Отличный лидер PVS ориентирован на бизнес. Роль сочетает управление продуктом, дизайн и техническое исполнение с бизнес-объективом на всех этапах жизненного цикла.

чуткий: Все потоки создания ценности продукта включают эклектичное сочетание ролей и личностей, у которых разные обязанности, идеи и способы работы. Для PVS крайне важно, чтобы они были чувствительны и знали об этих особенностях и управляли ими, чтобы способствовать гармонии и единству.

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

Заботится о том, как производится колбаса: Бизнес-руководство и клиенты не заботятся о том, как производится колбаса. Свинец PVS гарантирует, что он всегда имеет как можно более приятный вкус, и что существует процесс постоянного улучшения, чтобы качество колбасы всегда соответствовало высоким стандартам (и доставлялось быстрее).

Видение: Лидер PVS развивает и развивает видение продукта. Таким образом, в то время как эта роль требует исполнительных способностей, она также требует кого-то со способностью «мыслить масштабно» и устанавливать стратегическое видение.

Смягчение перехода

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

Карта потерь

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

Ключевые проблемы и преимущества путешествия, ориентированного на продукт

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

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

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

Дальнейшее чтение

Работа над проектом и работа над продуктом

Проекты и продукты в Scrum

Проект против мышления продукта: заботливая команда разработчиков