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