Блог Product lab

Продуктовое мышление против проектного мышления

Управление проектами Agile Product Management
Продуктовое мышление против проектного мышления
Перевод оригинальной статьи

Многие ли из вас задумывались: в чем разница между продуктовым и проектным мышлением? Какого будет правильнее придерживаться в той или иной ситуации? Возможно ли их вообще совместить?

Читайте об этом в нашей новой статье!

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

Проектное Мышление

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

Так что же такое проектное мышление?

В центре внимания проектного мышления находится поставка (delivery). Это может быть поставка определенных функций или программного обеспечения, или действительно поставка чего-либо физического, от самолетов до домов. И поскольку основное внимание уделяется поставке, основное измерение проводится на временном графике. Управление проектами в особенности фокусируется на результаты (output): важно измерять, насколько точно мы смогли заранее оценить график, а затем достичь запланированных результатов в соответствии с этим графиком. Успех в значительной степени определяется тремя этапами: вы заблаговременно берете все спецификации, устанавливаете график с вехами на протяжении всего пути, а затем поочередно достигаете все вехи.

Продуктовое Мышление

Продуктовое мышление использует принципиально иной подход. Вместо того, чтобы сосредотачиваться на результатах, продуктовое мышление фокусируется на показателях или конечных результатах (outcome). (На русском языке output и outcome переводятся одинаково, как результат, но в английской практике outcome – это последствия output, например, output – созданный цементный завод, а outcome – сколько тонн цемента этот завод создает – примечание редактора).

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

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

Преимущества

Итак, каковы преимущества отказа от временных рамок проекта в пользу сосредоточения внимания на показатели (outcome)?
Прежде всего, нет ничего важнее показателей, к которым мы движемся. Главное преимущество продуктового мышления (product mindset) заключается в том, что мы гарантированно получаем более эффективное достижение показателей.

Имея проектное мышление, мы с самого начала предполагаем, что уже знаем, как достичь желаемых показателей (outcome). Исходя из этого предположения, мы создаем план и график проекта, полный требований и основных этапов, а затем приступаем к выполнению этого плана. Если мы правы, и то, что мы изначально предполагали, оказывается правильным решением, тогда все замечательно. Мы просто выполняем план и достигаем показателей (outcome).
Но что, если мы изначально ошибались? Что, если решение, которое мы определили, не приведет к тем показателям, на который мы надеялись?

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

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

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

На примере проекта

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

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

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

На примере продукта

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

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

Как только я понял проблему, я погрузился в исследование решений, от создания функций до интеграции программного обеспечения сторонних производителей. Когда я это сделал, мне стало ясно, что решение состоит в том, чтобы ничего не создавать. Вместо того чтобы создавать новые функции или интегрировать чужое программное обеспечение (в данном случае это было портфолио для студентов), решение состояло в том, чтобы изменить то, что мы просили студентов делать. Вместо того чтобы сосредоточиться на инструменте «портфолио для студентов», мы могли бы просто попросить их создать части портфолио, а затем использовать любое программное решение, которое они захотят, чтобы продемонстрировать свою работу. Выгоды для всех будут значительными. Студенты будут контролировать свое портфолио, и мы не будем привязаны к созданию программного обеспечения или использованию какого-либо конкретного поставщика.

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

Правильный выбор

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

Главное — принимать обязательства и проектные планы только в тот момент, когда мы уверены, что можем сделать это. Поэтому вместо того, чтобы заранее выбрать определенный путь, мы берем на себя обязательства, как только проверим, что надо сделать, и действительно поймем, что для этого потребуется. Часто на практике это один или два рабочих спринта. Это может показаться действительно запоздалым процессом, но именно в этот момент оценки и планы действительно могут что-то значить. Марти Каган в своей книге “Inspired: How to Create Tech Products People Love”, называет этот тип обязательств “обязательством высокой целостности”. Мы даем командам время, чтобы сделать правильные открытия и исследования, прежде чем просить обязательств.

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

В конце концов

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

Для тех, кто хочет разобраться с продуктовом мышлении у нас есть курсы по Agile и дизайн-мышлению.
• На курсе по Agile вы узнаете, что такое гибкое мышление, Agile-трансформация, Scrum и Kanban. Каждый месяц проходит тренинг в открытом формате для всех желающих в онлайн или офлайн.
• На корпоративном курсе по дизайн-мышлению вы узнаете, как проектировать востребованные продукты и услуги.

А для заинтересованных в проектным мышлением, мы предлагаем корпоративный «Базовый курс по управлению проектами». На курсе слушатели знакомятся с областями знаний и процессами проектного управления, разбирают с тренером вопросы применения PMBOK и ISO21500 в реальной жизни организаций. Инструменты управления изучаются на практических занятиях. На упражнения и разбор реальных кейсов отводится 70% всего времени курса.

Если вы интересуетесь управлением проектами, то по ссылке ниже вы можете подробнее узнать про наш корпоративный тренинг “Управление проектами на основе стандартов PMBOK и ISO 21500”.

Базовый курс управления проектами


Статьи про управление продуктами и проектами:


Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи: