В деятельности менеджера всегда есть какая-то доля работы связанная с постановкой бизнес-процессов. Как правило это необходимо когда появляются новые потребности компании, бОльший оборот, лучшая стабильность по денежному потоку или просто внедрить каике-то улучшения. Иногда бывает, что мы сталкиваемся только с симптомами или нежелательными явлениями, когда что-то идет не так: «продалбываем» сроки, заказчик недоволен, слишком большие расходы на содержание инфраструктуры или иные издержки. Между этими двумя позициями есть общая деталь: если есть потребность к изменению значит что-то эти улучшения сдерживает, и это можно расценивать как нежелательное явление. Когда мы начинаем разбираться в ситуации, то можем собрать множество разрозненных фактов из которых понятно только то, что изменения требуются. но с чего начать? Как минимальными усилиями провести изменения?
И тоже самое можно сказать о конфликтах в команде. Когда видишь конфликт интересов но решить его в лоб, административным рычагом, будет не самым правильным выходом. Нужно искать корневую причину конфликта и решать ее.
Ищем причины
Часто, анализируя деятельность компании мы видим множество разрозненных но очевидных фактов типа:
- заказчик недоволен
- много ошибок в коде
- много доработок при сдаче
- не успеваем со сроками
- долго разрабатываем
Могут ли эти факты быть ключевой проблемой которую. надо решать? — Могут, а могут и не быть. Пока мы не попытаемся связать их в дерево причинно следственных связей.
![](https://habrastorage.org/files/32e/81a/95b/32e81a95b5d54456b722b30f17fd6033.png)
Диаграмма называется «дерево текущей реальности» и её следует читать как: «ЕСЛИ мы не успеваем со сроками ТО заказчик недоволен».
Можно на этом и остановиться, и сказать «Ура! я нашел проблему и пойти долбать разработчика.» И даже если вы найдете идеальных разработчиков проблемы не решатся.
Потому что скорее всего это не является истинной причиной проблемы. И нужно копать дальше.
Именно об этом говорит пятый шаг 5 ТОС «не поддавайтесь инерции». Конечно дерево не полное, И факт «много ошибок в коде» тоже может быть следствием какой-то другой более системной проблемы. Для того чтобы это выявить нужно просто задать вопрос «Почему?» Почему у нас много ошибок в коде?
И при ответе на эту группу вопросов можно выявить что:
- Много ошибок в коде ПОТОМУ ЧТО нет тестирования
- Нет тестирования ПОТОМУ ЧТО не хватает времени
- Не хватает времени ПОТОМУ ЧТО контракт заключен поздно.
- Не хватает времени ПОТОМУ ЧТО неправильно оценен объем проекта до заключения контракта.
- Неправильно оценен объем проекта ПОТОМУ ЧТО не существует готовых метрик.
- Не существует готовых метрик ПОТОМУ ЧТО не проводится анализ проектов.
Ух ты, оказывается что проблема лежит вовсе не на стороне разработки, а закопана глубже, и лежит еще в области подготовки к заключению договора.
Но ВАЖНО что на поверхности эти проблемы не лежали. И строя полную картинку
![](https://habrastorage.org/files/062/100/da1/062100da11bc483b920ee2edd28f6d68.png)
Можно найти ключевую проблему с которой и нужно применять изменения бизнес процессов. Данный пример короткий, но показывает что не все что лежит на поверхности действительно является ключевой проблемой. И при анализе состояния может выявиться еще 50 различных фактов влияющих на систему, а встраивая их всех в дерево причинно следственных связей и выявляя что является следствием а что причиной можно найти именно то самое ограничение системы которое нужно исправлять в первую очередь.
Решаем проблемы
При разборе этого примера мы нашли что ключевой проблемой является отсутствие учета результатов ретроспектив, Для которых, хорошо было бы иметь какие-то артефакты проекта типа проектной документации. Да и результаты ретроспективы тоже имеет смысл оформлять в виде документа о выученных уроках.
И здесь мы можем прийти к конфликту.
Для того чтобы делать проект быстро мы должны экономить время, и соответственно не должны писать документов (Коммуникации важнее документации). Одновременно с этим мы должны думать о поддержке проекта и перспективах развития поэтому мы должны писать документацию.
И здесь мы приходим к еще одному инструменту ТОС «Диаграмма Ключевого конфликта» или «грозовая туча», которая представляет собой маленькую схему показывающую не конфликтующие между собой условия достижения цели, но конфликтующие методы обеспечения условий.
![](https://habrastorage.org/files/9a1/6ed/3b8/9a16ed3b8f254ffb96a9084fde3906bb.png)
Для того чтобы решить эту «тучу» можно применить несколько различных методов
- мозговой штурм.
- теорию решения изобретательских задач. (ТРИЗ)
- шесть шляп мышления
Или применить тот же самый логический подход, и выявить ложные предпосылки приводящие выбору методов обеспечения наших условий. Такак метод выбирается не только для обеспечения условия но на основании каких-то еще влияющих факторов. Иногда бывает что метод выбран правильно, но ошибка может крыться в условиях которые приводят к этим методам и тогда нужно поставить под сомнение сами условия приводящие к конфликту. Для этого тоже нужно исследовать предпосылки.
Для выявления предпосылок применяется рассмотренное ранее дерево текущей реальности, которое мы достраиваем с использованием вопросов «Почему?» «Зачем?» и соответственно ответов а них «ПОТОМУ ЧТО...» и переводя из абстрактной плоскости «экономить время» в конкретную «сэкономить 20 часов» задавая вопросы «Сколько вешать в граммах?», «А в чем это выражается?» чтобы получить измеримые факты. (да-да критерии SMART)
- Экономия времени — Зачем? Сколько времени даст экономия? Есть ли другие способы экономии времени?
- Долгая поддержка — Насколько долгая? Как часто меняются команды? Какой прогноз темпов развития? Есть ли другие способы обеспечения условия?
- Не писать документацию — К чему это приведет? Какие будут нежелательные явления? Какие риски возрастут? Какой будет положительный эффект? Какие будут убытки?
- Писать документацию — Сколько это стоит? Сколько денег это принесет? Что для этого нужно? Какую именно документацию нужно писать? Как определить что это мы пишем а это не пишем?
Прорабатывая каждую из этих веток можно выявить каике-то ложные предпосылки лежащие в основе условия или выбранного метода, которые могут быть ложными или исходят из более других корневых причин.
Проверяем последствия
Если в результате анализа выявлено что наши условия действительно верные, но грозовая туча не решается, то можно проверить воздействия каждого из методов на систему в целом анализируя желательные эффекты (ЖЭ) и нежелательные явления (НЖЯ). Это можно проверить построив дерево будущей реальности:
Например:
Если мы будем писать документацию то
- ЖЭ. У нас будет больше информации о принятии решений в будущем что повысит нашу стабильность выполнения работ.
- НЖЯ. Но одновременно с этим нужно будет тратить время на документирование
- Но мы можем встроить документирование в процесс обдумывания проектных решений
- ЖЭ. ТОГДА документы будут рождаться как побочный продукт и
- ЖЭ. Проектные решения будут лучше продуманы.
- ЖЭ. ТОГДА документы будут рождаться как побочный продукт и
- Но мы можем встроить документирование в процесс обдумывания проектных решений
- НЖЯ. любой документ устаревает в момента написания
- Описание на уровне свойств, характеристик и поведения без детализации снизит скорость устаревания
- ЖЭ. Большая часть документов будут актуальны долгое время.
- ЖЭ. Большая часть документов будут актуальны долгое время.
- Описание на уровне свойств, характеристик и поведения без детализации снизит скорость устаревания
![](https://habrastorage.org/files/705/541/495/7055414950e94fc1833bfa5ad4abb37d.png)
Если мы НЕ будем писать документацию то
- ЖЭ. мы сможем быстрее делать продукт
- НЖЯ. при смене разработчика вся информация уйдет с ним
- НЖЯ. Стоимость замены сотрудника возрастет
- НЖЯ. появляются непредсказуемые финансовые риски.
![](https://habrastorage.org/files/6e4/2c7/0a3/6e42c70a321c486caf6b83f7220fa2b6.png)
Оценка на уровне дерева будущей реальности последствий наших действий дает понимание о стоимости внедрения того или иного метода и всех нежелательных явлениях которые могут возникнуть в процессе внедрения.
Выбранное решение называется «прорывом» и оно влияет сразу на всю тучу. Решение может лежать и за пределами тучи и может быть найдено через методики мозгового штурма ТРИЗ и «шести шляп мышления».
Но полученное решение нужно будет проверить на логическом дереве с анализом последствий нашего воздействия на систему в целом. И решение о выбранном варианте можно проверить на предмет желательных эффектов и нежелательных явлений. И количество нежелательных явлений может сыграть существенную роль в выборе решения прорыва.
Данные методики также могут быть использованы и в оценке какой-то ситуации или при переговорах. Однако, при моделировании сценария вместо решения прорыва и инъекций можно использовать ваши действия с ответную реакцию оппонента которая может быть положительной (желательный эффект) и отрицательной (нежелательное явление).
Что почитать по теме
- Цель. Процесс непрерывного совершенствования. Элия М. Гольдратт, Джеф Кокс
- Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию. Уильям Деттмер