Как выбрать методологию для проекта
«Классика или гибкие методологии?» — тема для бесконечных споров на любой конференции или тренинге по управлению проектами. Дискуссия очень заразная, и любой руководитель проектов хотя бы раз участвовал в таком споре. Каждый участник обычно приводит достойные примеры того, как работает его любимый подход и не работает подход его визави.
Именно такой спор однажды произошел с одним из коллег, занимающимся внедрением Agile в крупных российских госструктурах. В результате мы договорились и сформулировали утверждение следующим образом: «Раз есть ситуации, при которых одна методология работает лучше другой, то должен быть и способ, позволяющий понять, что лучше использовать для решения поставленной задачи».
Коллега сослался на очень любопытный фреймворк Киневина, который мог бы помочь с поиском решения данного вопроса. Мы начали набрасывать на него наши аргументы и буквально влюбились в этот подход.
Модель Киневина (Cynefin Framework) была разработана в начале 2000-х гг. в IBM Дейвом Сноуденом. C 1984 г. Дейв работал в компании Data Sciences Ltd, после поглощения которой в 1996 г. оказался в IBM, где впоследствии возглавил IBM Cynefin Centre for Organizational Complexity. Модель Киневина еще называют моделью создания смысла (sensemaking), которая позиционировалась как процесс, посредством которого люди придают смысл своему коллективному опыту. Cynefin в переводе с валлийского означает «прибежище, среда обитания, привычный, знакомый».
Давайте рассмотрим эту модель подробнее и разберемся, при чем здесь вообще проекты.
Модель состоит из пяти основных доменов принятия решений, в которых может находиться система. Домены также могут называться контекстами или средами. В нашем случае в роли контекста выступает проект, поэтому мы будем рассматривать модель в адаптации к проектам (рис. 67).
Домен I. Простой (Simple), или предсказуемый (Obvious). В этом домене речь идет о простой упорядоченной среде, где не возникает проблем с пониманием причинно-следственных связей. Решения принимаются по следующей схеме:
Осознание ситуации → Категоризация ситуации → Ответ на ситуацию с использованием хорошо известного решения.
Важно отметить вот что: предполагается, что у ситуации всего одно решение, которое всем кажется очевидным. Ситуации, в которых существует только одно решение, называют лучшими практиками (best practices). Использование лучших практик встречается в управлении качеством, когда организации разрабатывают внутренние стандарты для ужесточения требований, которые могут являться обязательными и на уровне законодательства. Лучшие практики могут быть основаны как на текущих результатах компании и желании их улучшить, так и на анализе рынка (benchmarking).
Популярными лучшими практиками являются ГОСТ и ISO. До сих пор, например, колбаса или тушенка с обозначением ГОСТа на этикетке ассоциируется у потребителей с высоким уровнем качества продукта. Пример лучших практик на уровне организаций — это рабочие процессы в компаниях типа McDonald’s, которая смогла сделать так, что бургер компании в любой стране мира будет иметь одинаковый внешний вид и вкусовые качества. Хорошим примером из IT-отрасли может служить тестирование, где есть чек-лист, следуя которому сотрудник имеет возможность удостовериться, что приложение (или его часть) работает корректно.
Домен II. Сложный (Complicated). В этом домене среда является упорядоченной, но уже не так просто найти связь между причиной и следствием. Для нахождения таких связей требуется определенный уровень компетенции и опыта. Решения принимаются по схеме:
Осознание ситуации → Анализ ситуации экспертом → Ответ на ситуацию с помощью одного из нескольких вариантов решений.
Важно отметить, что, в отличие от предыдущего домена, здесь уже нет единственно верного решения. Любые попытки действовать по принципу домена I вызывают недоумение у экспертов и потерю всяческой мотивации. Это связано с тем, что они могут быть не согласны с навязываемым «единственным правильным решением».
Практики в этом домене называются «хорошими» (good practices), как бы намекая на то, что существуют альтернативы. К практикам этого домена мы можем отнести PMBOK, PRINCE2, ITIL.
Ярким примером из IT будут проекты по внедрению на предприятиях, скажем, SAP-решений. У таких проектов есть несколько признаков:
- у исполнителя есть опыт выполнения подобных проектов;
- заранее известно, что представляет собой готовое решение;
- решение не начнет приносить пользу до тех пор, пока не будет выполнен основной объем работ.
В качестве аналогии можно привести задачу строительства бассейна, где вырытый котлован и подведенные коммуникации будут абсолютно бесполезны до тех пор, пока чаша бассейна не будет сконструирована и наполнена водой. При этом один и тот же проект бассейна не гарантирует успешной реализации без привлечения эксперта, который сможет проанализировать, все ли идет по плану, заменить материал на аналогичный в случае, если необходимый невозможно купить, или решить, какие изменения нужно внести из-за особенностей почвы в данном районе.
Домен III. Запутанный (Complex). В этом домене среда уже не является упорядоченной (unordered). Важно не путать ее с беспорядком (disorder), о котором мы поговорим дальше. Здесь приходится иметь дело с отсутствием и непониманием связей между причиной и следствием. Лучший вариант найти их — это собрать данные, основываясь на предпринятых действиях (экспериментах). Решения принимаются по схеме:
Предпринять действия, которые помогут собрать данные о ситуации → Осознание ситуации на основании полученных данных → Получение ответа на ситуацию, который позволит перевести ее в домен II (запутанный).
В этом домене нет хороших решений. Все, что мы делаем, это ищем свой путь и изучаем правила игры. Практики в этом домене называются появляющимися (emerging); к ним мы отнесли Agile. Чаще всего в такой ситуации оказываются стартапы: у бизнеса есть предположение, что определенная гипотеза может сработать. Для подтверждения гипотезы создается минимально жизнеспособный продукт, после запуска которого у компании появляется необходимая информация для планирования следующих шагов.
Это можно сравнить с тарелкой спагетти: сложно сказать, как именно переплетены отдельные макаронины между собой, и лучшее, что можно сделать, это потянуть за одну из них и посмотреть, какие еще спагетти с ней соприкасаются.
Домен IV. Хаотичный (Chaotic). В этом домене приходится иметь дело с неупорядоченной (unordered) средой. Если в предыдущем домене связи между причиной и следствием были неясными, то в этом их просто нет. Схема действий такая:
Необходим лидер, который, основываясь на своем чутье, предпримет действия, которые предотвратят агонию → Основываясь на результатах действия и факте, что «кровотечение купировано», лидер может продумать следующие действия по стабилизации ситуации → Получение ответа на ситуацию, который переведет ее в домен III.
Практики, которые рождаются в этом домене, называются инновационными (novel). Ситуации в данной среде можно сравнить с городом во время стихийных бедствий. В качестве примеров мы можем взять дефолт в России 1998 г. или крах Enron в 2001 г.
Несколько примеров из IT-отрасли:
- в проекте горят сроки, команда отказывается от всех подходов, использовавшихся ранее, и лихорадочно начинает доделывать работу;
- во время очередного релиза что-то идет не так: система, которой уже активно пользуются, перестает функционировать, но при этом все еще неясно, что произошло с технической точки зрения;
- система подвергается атаке злоумышленников, которые нашли уязвимость, а сотрудники компании пытаются применить несогласованные меры для решения ситуации.
Если мы снова призовем на помощь аналогию, то все примеры, приведенные выше, можно сравнить с пожаром среди ночи. В такой ситуации нет времени на планирование и обдумывание — нужен лидер, который даст четкие распоряжения по спасению жизней жильцов дома, а заодно и некоторого имущества. Только после этого, избежав угрозы, можно все обдумать и спланировать следующие шаги.
Домен V. Беспорядок (Disorder) — именно так автор данной модели назвал ситуацию, в которой люди, принимающие решения, не осознают, в каком домене они находятся и какие практики следует применять.
Модель предполагает, что в любой ситуации необходимо двигаться по часовой стрелке: от хаотичного домена к упрощению. Благодаря этому основная масса неблагоприятных ситуаций останется между сложным и запутанным доменами, и лишь некоторая часть перейдет в первый домен, где среда упорядочена.
Правда, стоит помнить, что пренебрежение сложностью и чрезмерное стремление к простоте могут привести к обрыву (Cliff) VI, который мгновенно переведет ситуацию в хаотичный домен без возможности так же легко вернуться назад.
Итак, давайте вернемся к тому, с чего начали: какую методологию использовать? Мы выяснили, что для ответа на этот вопрос необходимо сначала разобраться в том, какую задачу нужно решить, а затем выбрать соответствующий домен:
- Простой I (McDonald’s) — «лучшие» практики, в которых используются процессы по ГОСТ, ISO или от признанных лидеров отрасли;
- Сложный II (бассейн) — «хорошие» практики, в которых используются классические подходы к управлению проектами, например PMBOK или PRINCE2;
- Запутанный III (спагетти) — появляющиеся практики. В этом домене используются Agile-практики;
- Хаотичный IV (пожар) — инновационные практики. В этом домене нужно положиться на сильного лидера, который поможет уйти с линии огня, а затем перейти в домен со спагетти;
- Беспорядок V (нет понимания ситуации) — здесь нет практик. Для начала нужно разобраться в том, где мы вообще находимся.
Хотелось бы отметить, что Agile-подходы уже нельзя на 100% отнести к домену III, ведь за последние десять лет они сильно повзрослели и обросли процессами, что постепенно передвигает их в домен II. В то же время граница между классическими подходами и Agile еще явно прослеживается.
Если речь идет о стартапе, то он, скорее всего, в домене III, и Agile ему подойдет больше. Если же речь о типовых проектах с фиксированной стоимостью, за которые еще сначала придется побороться в тендере, то мы предлагаем обратиться к классическому подходу.
