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