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