Как выбрать методологию для проекта?

06.03.2020
«Классика или гибкие методологии» — тема для бесконечных споров на любой конференции или тренинге по управлению проектами. Дискуссия очень заразная, и любой руководитель проектов хотя бы раз участвовал в таком споре. Каждый участник спора обычно приводит достойные примеры того, как работает его любимый подход и не работает подход визави.

Для решения такого рода вопросов мы предлагаем вам использовать модель Киневина.
модель Киневина
Модель Киневина
Модель Киневина (Cynefin Framework) была разработана в начале 2000 годов в IBM Дейвом Сноуденом. C 1984 года Дейв работал в компании в Data Sciences Ltd, после поглощения которой в 1996 году оказался в IBM, где впоследствии возглавил IBM Cynefin Centre for Organizational Complexity. Модель Кеневина еще называют моделью создания смысла (sensemaking), которая позиционировалась как процесс, посредством которого люди придают смысл своему коллективному опыту. Cynefin в переводе с валлийского означает прибежище, среда обитания, привыкший, знакомый.

Домен I Простой (Simple)

Давайте рассмотрим модель Киневина подробнее и разберемся, причем здесь вообще проекты.
Модель состоит из пяти основных доменов принятия решений, в которых может находиться система. Домены так же могут называть контекстами или средами. В нашем случае в роли контекста выступает проект, поэтому мы будем рассматривать модель в адаптации к проектам.

Домен I Простой (Simple) или Предсказуемый (Obvious). В этом домене речь идет о простой упорядоченной среде, где не возникает проблем с пониманием причинно-следственных связей. Решения принимаются по следующей схеме:
Осознание ситуации → Категоризация ситуации → Ответ на ситуацию, используя хорошо известное решение.

Важно отметить вот что: предполагается, что у ситуации всего одно решение, которое всем кажется очевидным. Ситуации, в которых существует только одно решение, называют лучшими практиками (Best practices). Использование лучших практик встречается в управлении качеством, когда организации разрабатывают внутренние стандарты для ужесточения требований, которые могут являться обязательными и на уровне законодательства. Лучшие практики могут основываться как на текущих результатах компании и желании их улучшить, так и на анализе рынка (benchmarking).

Популярными лучшими практиками являются ГОСТ и ISO. До сих пор, например, колбаса или тушенка с упоминанием ГОСТа на этикетке ассоциируется у потребителей с высоким уровнем качества продукта. Пример лучших практик на уровне компании — это рабочие процессы в компаниях типа McDonalds, которая смогла сделать так, что бургер компании в любой стране мира будет иметь одинаковый внешний вид и вкусовые качества.

Примером из IT-отрасли может послужить тестирование, где есть чек-лист, следуя которому сотрудник может удостовериться, что приложение (или его часть) работает корректно.

Домен II Сложный (Complicated)

В этом домене среда является упорядоченной, но уже не так просто найти связь между причиной и следствием. Для нахождения таких связей требуется определенный уровень компетенции и опыта. Решения принимаются по схеме:

Осознание ситуации → Анализ ситуации экспертом → Ответ на ситуацию, используя одно из нескольких вариантов решений.

Важно отметить, что в отличие от прошлого домена, здесь уже нет единственного верного решения. Любые попытки действовать по принципу Домена I вызывают недоумение у экспертов и потерю всяческой мотивации. Это связано с тем, что они могут быть не согласны с навязываемым «единственным правильным решением».

Практики в этом домене называются «хорошими» (Good practices), как бы намекая на то, что существуют альтернативы. К практикам этого домена мы можем отнести PMBoK, PRINCE2, ITIL.

Ярким примером из IT отрасли будут проекты по внедрению на предприятиях, скажем, SAP-решений. У таких проектов есть несколько признаков:
  • у исполнителя есть опыт выполнения подобных проектов;
  • заранее известно, что собой представляет готовое решение;
  • решение не будет приносить пользу до тех пор, пока не будет выполнен основной объем работ.
В качестве аналогии можно привести задачу строительства бассейна, где вырытый котлован и подведенные коммуникации будут абсолютно бесполезны до тех пор, пока чаша бассейна не будет сконструирована и наполнена водой. При этом один и тот же проект бассейна не гарантирует успешной реализации без привлечения эксперта, который сможет проанализировать, все ли идет по плану, заменить материал на аналогичный в случае, если необходимый невозможно купить или решить какие изменения нужно внести из-за особенностей почвы в данном районе.

Домен III Запутанный (Complex)

В этом домене среда уже не является упорядоченной (unordered). Важно не путать ее с беспорядком (disorder), о котором мы поговорим дальше. Здесь дело приходится иметь с отсутствием и непониманием связей между причиной и следствием. Лучший вариант найти их — это собрать данные, основываясь на предпринятых действиях (экспериментах). Решения принимаются по схеме:

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

В этом домене нет хороших решений. Все, что мы делаем, это ищем свой путь и изучаем правила игры. Практики в этом домене называются появляющимися (emerging), к которым мы отнесли Agile. Чаще всего в такой ситуации оказываются стартапы: у бизнеса есть предположение, что определенная гипотеза может сработать. Для подтверждения гипотезы создается минимально жизнеспособный продукт, после запуска которого у компании появляется необходимая информация для планирования следующих шагов.

Это можно сравнить с тарелкой спагетти: сложно сказать, как именно переплетены отдельные макаронины между собой и лучшее, что можно сделать, это потянуть за одну из них и посмотреть, какие еще спагетти с ней соприкасаются.

Домен IV Хаотичный (Chaotic)

В этом домене приходится иметь дело с неупорядоченной (unordered) средой. Если в предыдущем домене связи между причиной и следствием были неясными, то в этом их просто нет. Схема действий такая:

Необходим лидер, который, основываясь на свое чутье, предпримет действия которые снимут агонию → Основываясь на результатах действия и факте, что «кровотечение купировано», лидер может продумать следующие действия по стабилизации ситуации → Получение ответа на ситуацию, который переведет ее в Домен III.

Практики, которые рождаются в этом домене, называются инновационными (novel). Ситуации в данной среде можно сравнить с городом во время стихийных бедствий. В качестве примеров мы можем взять дефолт в России 1998 года или крах Enron в 2001.

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

Если мы снова призовем на помощь аналогию, то можно сравнить все примеры, приведенные выше, с пожаром среди ночи. В такой ситуации нет времени на планирование и обдумывание — нужен лидер, который даст четкие распоряжения по спасению жизней жильцов дома, а заодно и некоторого имущества. Только после этого, избежав угрозы, можно все обдумать и спланировать следующие шаги.

Домен V Беспорядок (Disorder)

V Беспорядок (Disorder) — именно так автор данной модели назвал ситуацию, в которой люди, принимающие решения, не осознают в каком домене они находятся и какие практики следует применять.

Модель предполагает, что в любой ситуации необходимо двигаться по часовой стрелке: от хаотичного домена к упрощению. Благодаря этому основная масса неблагоприятных ситуаций останется между сложным и запутанным доменами, и только лишь некоторая часть перейдет в первый домен, где среда упорядочена.

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

Какую методологию использовать?

V Итак, давайте вернемся к тому с чего начали: какую методологию использовать?

Мы выяснили, что для ответа на этот вопрос нужно сначала разобраться в том, какую задачу нужно решить, а затем выбрать соответствующий домен:
  • Домен I (McDonalds) — «лучшие» практики. Здесь используются процессы по ГОСТ, ISO или от признанных лидеров отрасли.
  • Домен II (Бассейн) — «хорошие» практики. Здесь используются классические подходы к управлению проектами. Например, PMBoK или PRINCE2.
  • Домен III (Спагетти) — появляющиеся практики. В этом домене используются Agile-практики.
  • Домен IV (Пожар) — инновационные практики. В этом домене решением будет положиться на лидера, который поможет уйти с «линии огня», а затем перейти в домен со «спагетти».
  • Домен V (Беспорядок) — здесь нет практик. Для начала нужно разобраться в том, где мы находимся на самом деле.
Хотелось бы отметить, что Agile-подходы уже нельзя на 100% отнести к Домену III, ведь за последние десять лет они сильно «повзрослели» и «обросли» процессами, что постепенно двигает их в Домен II. В то же время граница между классическими подходами и Agile еще явно прослеживается.

Если речь о стартапе, то он, скорее всего, в Домене III, и Agile ему подойдет больше. Если же речь о типовых проектах с фиксированной стоимостью, за которые еще сначала придется побороться в тендере, то мы бы предложили обратиться к классическому подходу.

С вами был Сергей Дерцап.

Успешных вам проектов!