Вадим Митякин - Метод параноика. Как взять под контроль неопределённость в проектах при создании цифровых продуктов для бизнеса

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

Не обманывайтесь. Этой истории уже несколько десятков лет. Борьба идёт с переменным успехом, и периодически верх берет то одна, то другая сторона. Благодаря ей на свет регулярно появляются новые методологии и подходы. Дизайн-мышление, проектирование на основе персонажей, Jobs-to-be-done, Agile, Scrum, RUP, экстремальное программирование и т.д. Каждая новая модель предполагает радикальное улучшение процесса и возможность наконец-таки получать по итогу проекта именно то, что требуется. Но, как говорил Брукс в своей знаменитой книге «Мифический человеко-месяц», серебряной пули как не было, так и нет. И вряд ли она когда-нибудь появится. Методологии в основном служат не снижению неопределённости, а только лишь обосновывают перенос рисков со специалистов на бизнес.

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

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

Вы уже догадываетесь, к чему я веду? Если неопределённость является корневой причиной невозможности точного планирования, вероятно, есть смысл сконцентрироваться на поиске способов её уменьшения. Конечно, в силу описанных выше особенностей проектной работы устранить её полностью невозможно. Но это и не нужно. Большое значение имеет само знание о наличии неопределённости и её локализация в отдельных частях проектах. Как писал Нассим Талеб уже после выхода «Чёрного лебедя», объясняя ключевую идею книги, причиной неожиданности события может быть как сама природа такого события (например, метеорит), так и слепота наблюдателя (как экономический кризис 2008 года). И если с первой категорией мы ничего поделать не можем, то со второй такая возможность есть.

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