Здесь важно вспомнить закон Галла, утверждающий, что
Компании, занимающиеся разработкой цифровых продуктов на заказ, стараются избегать ответственности. То же относится к IT-специалистам, работающим внутри бизнеса. Наиболее популярный прием для переноса рисков на бизнес – продавать не результат, а процесс. Модель такова: специалисты с известными компетенциями в дизайне, проектировании и разработке продают свое рабочее время, а бизнес несет ответственность за то, как использует их время и профессиональные навыки. Если результат не соответствует ожиданиям, значит, бизнес неправильно управлял процессом или хотел чего-то заведомо ошибочного. Но счета за потраченное время должны быть оплачены в любом случае.
Когда на стороне заказчика есть специалисты по проектному управлению, подобная модель действительно позволяет бизнесу быстро сформировать команду из профессионалов, фактически арендовав их на время проекта. В остальных случаях подрядчики прибегают к различным ухищрениям, например, предлагают работать над проектом по гибкой методологии. При этом команда специалистов рассматривается как единый механизм с нужным набором компетенций (обычно неизменным от проекта к проекту), работающий в соответствии с текущими запросами бизнеса. Это подается как преимущество: клиент сам определяет направление развития продукта, уточняет требования и устанавливает приоритеты. Проект движется своим чередом, и «все будет готово, когда будет готово». Вам что-то не нравится, и вы хотите ясности? Похоже, вы ретроград и не следите за трендами, сейчас все agile!
Не обманывайтесь. Эта история длится десятки лет. Борьба идет с переменным успехом, и периодически верх берет то одна, то другая сторона. Благодаря этому регулярно появляются новые методологии и подходы: дизайн-мышление, проектирование на основе персонажей, Jobs-to-be-done, Agile, Scrum, RUP, экстремальное программирование и прочее. Каждая новая модель предполагает радикальное улучшение процесса и возможность получить нужный результат. Но, как говорил Брукс в своей знаменитой книге «Мифический человеко-месяц», серебряной пули не существует, и вряд ли она когда-нибудь появится. Методологии в основном служат не для снижения неопределенности, а для обоснования переноса рисков со специалистов на бизнес.
Независимо от используемого в проекте подхода, источник риска – неопределенность – не исчезает. Компромисс между сторонами тоже не решает проблему, в конечном счете кто-то все равно должен заплатить за возникающие издержки: либо одна сторона, либо другая, либо обе.
Но можно посмотреть на вопрос по-другому, сказав, что идея определить в самом начале проекта стоимость и сроки ошибочна. В этом случае факт, что проекты постоянно выходят за запланированные границы, объясняется не низкой компетенцией специалистов, а принципиальной невозможностью спрогнозировать эти границы. Не понимая этого, компании, занимающиеся разработкой продуктов, склонны оценивать проекты по формуле x2 или x3, закладывая в бюджет двойную или даже тройную наценку за риски. Но кто может сказать, что такое x1?
Догадываетесь, к чему я веду? Если неопределенность мешает точному планированию, стоит сконцентрироваться на поиске способов ее уменьшения. Конечно, полностью устранить ее невозможно, но это и не требуется. Значение имеет само знание о наличии неопределенности и ее локализация в отдельных частях проектах. Нассим Талеб после выхода книги «Черный лебедь» объяснял ее ключевую идею: причиной неожиданности события может быть как сама природа такого события (например, метеорит), так и слепота наблюдателя (как экономический кризис 2008 года). И если с первой категорией мы ничего поделать не можем, то со второй такая возможность есть.