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