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