Проблема «проект vs продукт»

Это перевод статьи эксперта по управлению проектами Надера К Рада.

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

У этого утверждения есть две фундаментальные проблемы, которые я объясню в этой статье:

1. Само название предпочитаемого подхода вводит в заблуждение.
   
2. Подход, ориентированный на продукт, зачастую уступает подходу, ориентированному на проект.

Проблема №1: Терминология

Проекты не заменяют ориентацию на продукт, проекты — это структурированный способ быть ориентированным на продукт. Это заложено во всех системах управления проектами и отражено разными способами. Например, в PRINCE2 этот принцип называется «фокусироваться на продукте».

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

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

Когда мы начинаем использовать продукт, возникают мелкие проблемы или идеи для его улучшения. Эти мелкие изменения могут вноситься в рамках ad-hoc подхода (сразу по мере необходимости). И это нормально: запускать целый проект ради одного мелкого исправления было бы слишком громоздко. А если копить небольшие доработки для создания одного большого проекта, то можно затянуть решение срочных проблем.

Противники проектного подхода предпочитают вносить все изменения ad-hoc, отказываясь от пакетного внесения изменений через проекты в пользу непрерывного внесения изменений. Таким образом, речь идёт не о предпочтении продуктов проектам, а о предпочтении одного способа внесения изменений другому. Противники проектного подхода предпочитают непрерывные ad-hoc-изменения пакетным структурированным изменениям (проектам).

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

Вы можете быть против «ориентации на проект», но называть это «ориентацией на продукт» — ошибка. Можно сказать, что вам не близко «проектная мышление», но называть альтернативу «продуктовым мышлением» — значит вводить в заблуждение.

Проблема №2: Уместность

Итак, какой способ изменений более уместен и создаёт больше ценности: непрерывный подход к внесению изменений (ad-hoc) или структурированный, пакетный? Противники проектов утверждают, что первый всегда лучше для программного обеспечения, что неверно.

Стратегия
Обычно проекты задают взгляд сверху-вниз, тогда как спонтанные изменения обычно идут снизу-вверх. Это делает проекты более проактивными и стратегическими. Если изменения незначительны, их мало или они действительно срочные, разумно вносить их ad-hoc способом. В противном случае проектная структура может помочь создать больше ценности.

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

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

Скука
Одна из распространённых проблем организаций, которые не упаковывают и не структурируют свои изменения, заключается в том, что они становятся слишком реактивными и теряются в бесконечном потоке небольших изменений, прилетающих со всех сторон и кажущихся срочными. Так проходит много человеко-лет, и, когда вы задаетесь вопросом: «А чего я вообще достиг?», — у вас не оказывается внятного ответа. Возможно, единственное, что вы можете сказать: «Я выжил». Ну, вы также сделали свой продукт куда более сложным — а значит, добавлять в него новый функционал теперь будет труднее. Наверное, именно поэтому мы и видим известные компании с армиями разработчиков и отсутствием реальных улучшений в их продуктах. Они слишком реактивны.

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

Адаптация
В ad-hoc подходе мы работаем с деталями и нам всегда проще менять последовательность задач, что может казаться более адаптивным (Agile) по мнению некоторых. Однако настоящая адаптивность появляется не за счёт отдельных фич, а тогда, когда фичи работают вместе и усиливают друг друга на пути к цели. Именно эту целенаправленность и целостный взгляд помогает сформировать проектный подход. Он же даёт нам системный способ оценивать результаты — понимать, какие проекты сработали, а какие нет. Этот большой цикл обратной связи позволяет нам лучше выбирать проекты в будущем.

Баланс
Оптимальная система сочетает оба подхода к изменениям:

В организациях, которые активно растут и готовы рисковать, небольшая часть мощностей (например, 30 %) может быть направлена на ad-hoc изменения, и оставшаяся на структурированные проекты.

В более консервативных, зрелых и медленных компаниях ситуация может быть обратной: 30 % мощностей направлены на проекты и 70 % — на оперативные ad-hoc изменения.

Диагноз №1

Противостояние проектам имеет корни в истории Agile. Давайте рассмотрим их подробнее.

Полное управление проектами
В первом поколении Agile-систем было несколько подходов. Большинство из них, например, DSDM и Crystal Алистера Кокберна, представляли собой полноценные системы управления проектами, разработанные для Agile-сред. Они предоставляли всё необходимое для структурированного внесения изменений.

Отсутствие внутреннего управления проектами
Другой системой первого поколения Agile была eXtreme Programming (XP) Кента Бека. В XP изначально не было системы управления проектами как таковой — весь акцент делался на гибкую разработку продукта. Подразумевалось, что XP будет работать в рамках уже существующей проектной экосистемы, и необходимая структура появлялась бы оттуда. Это видно по тому, какие взаимодействия XP описывает между проектным менеджером и командой.

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

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

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

От частичного к полному отказу
Со временем Scrum стал доминирующей системой в мире Agile, и все начали использовать Scrum или что-то, что сильно вдохновлено им. В результате подход Scrum’a с наличием частичной системой управления проектами распространился в Agile-сообществе. Конечно, если вы уберете половину чего-то и вам понравится результат, у вас возникнет вопрос: что будет, если убрать и другую половину? Это именно то, что произошло с частью Agile-сообщества: они считают, что отказ от некоторых аспектов управления проектами им помог, и поэтому нужно избавиться от оставшихся.

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

Неявные предпочтения Scrum
В оригинальном Scrum Guide, написанном Джеффом Сазерлендом и Кеном Швабером, изначально упоминались проекты, и такие книги, как Agile Project Management with Scrum Кена Швабера (2004), ясно описывали концепцию, ориентированную на проекты. Однако в обновлении Scrum Guide 2013 года были удалены ссылки на проекты, что способствовало распространению антипроектного настроя, о примере которого говорится в этой статье. Вопреки этому, в обновлении 2020 года в Scrum Guide были добавлены интересные концепции сверху-вниз, которые напоминают общую динамику проектов.

Диагноз №2

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

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

Диагноз №3

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

Заключение

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

Они считают, что их подход правильный и что в их отрасли (Разработке ПО) не должно быть проектов, что неверно. Нам требуется найти правильный баланс между непрерывными ad-hoc изменениями и структурированными, пакетными изменениями.