Фреймворк управления и анализа проектов DaShe

Основной причиной неудачи проекта в DaShe считаются неучтенные риски. Не форс-мажоры какие-нибудь, не «за такие деньги ничего приличного не сделаешь», а самые обычные проблемы, присутствующие в любом проекте: конфликт между стейкхолдерами, то есть теми, кто так или иначе задействован в проекте или оказывает на него влияние со стороны (от англ. stakeholder – «владелец доли»), неудачная концепция продукта, низкая производительность разработчиков, необязательность субподрядчиков и т. д. Все это – неизбежные риски, приводящие к неудаче проекта только в том случае, если они не были своевременно предусмотрены и компенсированы.

Но если риски можно предусмотреть и устранить, почему проджект-менеджеры этого не делают? Причиной тому второе слово – сложность. Рисков в проекте много; даже не так – очень много. Любое действие или решение, не проверенное многолетней практикой, является риском: если вы что-то делаете в первый раз, это «что-то» обязательно пойдет не так. А в проектной деятельности (в отличие от всем знакомой процессной, повторяющей одни и те же бизнес-процессы) большинство действий и решений новые. Поэтому ключевая особенность проекта, его суть – это сложность: слишком много новых, непредсказуемых задач, чтобы можно было легко их разрешить.

Казалось бы, справиться с большим количеством всего можно, используя мощную методологию, или фреймворк (тот же PMBoK). Однако сложность так просто не сдается: «тяжелая» методология добавляет в проект массу дополнительных действий (написание детальных планов, ведение разнообразной документации, совещания по любому поводу) и чрезвычайно перегружает проджект-менеджера. В результате будут предусмотрены лишь те риски, которые учитывает используемая методология, а вот на все остальные просто не хватит времени.

Обратная ситуация возникает при работе по «легким» методологиям (таким как скрам или канбан; первая – более директивная, при второй рабочий процесс оптимизируется личными усилиями каждого члена команды). В случае «легких» методологий у проджект-менеджера вообще нет никакого чек-листа для рисков, и он пользуется исключительно личным опытом (своим и команды проекта). В случае квалифицированных разработчиков такой подход срабатывает: «коллективный разум» хорошей команды превосходит по охвату самую тяжелую методологию. Но если команда чуть менее квалифицирована, в проекте снова появляются неучтенные риски.

Технологии управления проектами развиваются более 50 лет, но, несмотря на это, шансы на успех среднего проекта все еще меньше 50 %. Причина – нелинейный (квадратичный и более) рост сложности по мере увеличения объема проекта (количества функций, реализуемых создаваемым продуктом). Сложность влечет за собой появление неконтролируемых рисков, которые реализуются в возникающих непредвиденных ситуациях, влекущих за собой перерасход бюджета, увеличение сроков и в худшем варианте – принципиальную невозможность выпуска продукта. DaShe нацелен на систематическое ограничение сложности всех составляющих проектной деятельности, что позволяет сохранить контроль над рисками и обеспечить тем самым благополучное завершение проекта.

Для успешного управления проектами (то есть их завершения в срок, в пределах бюджета и без скрытых дефектов в продукте) нужно уметь справляться со сложностью. Поскольку «усложнять просто, упрощать сложно» (закон Мейера), для этого требуются специальные усилия; сама по себе сложность может только расти (вместе с числом компонентов, функциональностью, документацией, техническим долгом, историей личных отношений и т. д. и т. п.). Фреймворк DaShe и есть набор принципов и методов, обеспечивающих преодоление сложности.

0.2. DaShe: методология – «швейцарский нож»

DaShe – фреймворк управления проектами, нацеленный на максимизацию вероятности успеха, под которым понимается получение ожидаемого результата (продукта) с соблюдением заданных сроков, бюджета и отсутствием скрытых рисков.

Прагматический подход, реализуемый в DaShe на основе парадигмы «сложность – риски», заключается в том, чтобы:

1) предоставить проджект-менеджеру достаточно обширный чек-лист потенциальных рисков и методов их минимизации;

2) не перегружать его при этом обязательным выполнением многочисленных процедур, соответствующих некоторой «методологии».

Если PMBoK можно сравнить с целым заводом по производству проектной документации, а скрам (от англ. scrum – «схватка») – с курилкой при этом заводе, то DaShe окажется «швейцарским ножом» или чемоданчиком с инструментами, которые всегда полезно иметь под рукой.