Проектный и продуктовый подход к созданию ценности

Тут в сфере разработки программного обеспечения, кажется, назрел очередной холивар. На тему того, должен ли жить ещё проектный подход в ИТ или все уже должны дружно отмаршировать в сторону подхода продуктового. Кратко и с чувством проблематика донесена в статье «Желаю смерти большинству IT-проектов«. Где прогрессивная сторона представлена Agile-пропагандистами, а консерваторами и ретроградами — последователи PMBOK. Казалось бы, очередная буря в стакане, вызванная недостатком понимания матчасти и смешиванием в одну кучу самых разных факторов и понятий.

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

Definition of Scrum
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

— Scrum Guide 2017

То есть скрам, как самый яркий представитель Agile-подходов, не является методом управления проектами, а является «фреймворком для решения комплексных проблем в процессе создания и доставки продуктов». Он может использоваться внутри проекта, либо в него может быть завёрнута серия проектов, но это разные явления принципиально разного порядка. С другими Agile-подходами всё также. Однако повсеместно в соцсетях, ориентированных на трудоустройство, фигурирует навык Agile Project Management (каюсь, у меня тоже прописан). С другой стороны, разработка любого софтверного продукта суть проект. По определению проекта.

Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов

— PMBOK

Ведь любой софтверный продукт, который создаётся, уникален. Иначе бы он просто копировался.

Откуда же берётся противопоставление Agile / не-Agile проектов или проектный /  продуктовый подходов? Дело в том, что, PMBOK — пожалуй, слишком мудрёный свод знаний, в своей попытке универсальности и научности изложения, вводящий в ряд заблуждений любого, кто осваивает тему проектного менеджмента. Не в том смысле, что он содержит ошибки, а в том, что есть, всё-таки, разница между интеллектуальной деятельностью разработки, уникальной в каждом создаваемом элементе, и, скажем, конвейерной сборкой одинаковых велосипедов из одинаковых деталей.

Кажется, я заразился и сам стал изъясняться слишком мудрёно.

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

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

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

Во-вторых, фокус на ограничениях вынуждает уделять им очень много внимания ещё на старте. Ведь чтобы нам определить бюджет и срок, надо тщательно определить (и зафиксировать) скоуп работ. И вот он задел для каскадно-водопадного подхода.

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

И первая иллюзия второго витка навевается в неокрепшие менеджерские умы экономической теорией в виде преимущества разделения труда Адама Смита и Фордовского конвейера. Массовое поэтапное производство — это же очень эффективно. Сначала специально обученная группа делает один этап работ. Потом другая группа, заточенная под другую деятельность, делает другой и так далее. Освобождающиеся переключаются на другой проект. Показало свою эффективность в деле булавок и приготовления гамбургеров, должно и в разработке программного обеспечения сработать.

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

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

Весьма неплохо рассмотрен миф «масс-продакшена» в видео об упаковке конвертов.

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

Однако, ввиду того, что ни один проект никогда не шёл по плану, картина в среднем выглядит, скорее, как-то так:

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

Итак. Почитав PMBOK и попытавшись реализовать проектный подход «наиболее очевидным эффективным образом», получаем:

Фокус на ограничениях:

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

Ещё раз, PMBOK не заставляет так делать. Он просто не делает разницы между проектом по возведению памятника в центральном сквере и проектом по созданию новой операционной системы.

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

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

Итог — серия узкоприменимых заготовок. Возможно, даже выполнявшихся разными командами с разными руководителями проектов.

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

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

Так что продуктовый подход всё-таки требует определённых ментальных преобразований. И организационных, поскольку развивать продукт лучше стабильной в своём составе командой. Продуктовой командой. Поскольку проектные команды наследуют от проекта и свой временный характер.

И вот тут уже приходят Agile в целом и скрам в частности.

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

И в поиске иллюстрации к деятельности владельца продукта я нашёл изумительное 15-минутное видео, которое, возможно, и статью эту делает несколько избыточной. В общем, настоятельно рекомендую посмотреть.

В сухом остатке — да, продуктовый и проектный подходы различаются. Но не являются чем-то взаимоисключающим. Или даже взаимозаменяющим.

Но надо менять мышление.

Потому что когда я слышу «надо оформить проект по внедрению скрама» или «проект по устранению техдолга», мне приходит в голову анекдот о полёте на солнце ночью.