- PVSM.RU - https://www.pvsm.ru -
В деятельности менеджера всегда есть какая-то доля работы связанная с постановкой бизнес-процессов. Как правило это необходимо когда появляются новые потребности компании, бОльший оборот, лучшая стабильность по денежному потоку или просто внедрить каике-то улучшения. Иногда бывает, что мы сталкиваемся только с симптомами или нежелательными явлениями, когда что-то идет не так: «продалбываем» сроки, заказчик недоволен, слишком большие расходы на содержание инфраструктуры или иные издержки. Между этими двумя позициями есть общая деталь: если есть потребность к изменению значит что-то эти улучшения сдерживает, и это можно расценивать как нежелательное явление. Когда мы начинаем разбираться в ситуации, то можем собрать множество разрозненных фактов из которых понятно только то, что изменения требуются. но с чего начать? Как минимальными усилиями провести изменения?
И тоже самое можно сказать о конфликтах в команде. Когда видишь конфликт интересов но решить его в лоб, административным рычагом, будет не самым правильным выходом. Нужно искать корневую причину конфликта и решать ее.
Часто, анализируя деятельность компании мы видим множество разрозненных но очевидных фактов типа:
Могут ли эти факты быть ключевой проблемой которую. надо решать? — Могут, а могут и не быть. Пока мы не попытаемся связать их в дерево причинно следственных связей.
Диаграмма называется «дерево текущей реальности» и её следует читать как: «ЕСЛИ мы не успеваем со сроками ТО заказчик недоволен».
Можно на этом и остановиться, и сказать «Ура! я нашел проблему и пойти долбать разработчика.» И даже если вы найдете идеальных разработчиков проблемы не решатся.
Потому что скорее всего это не является истинной причиной проблемы. И нужно копать дальше.
Именно об этом говорит пятый шаг 5 ТОС «не поддавайтесь инерции». Конечно дерево не полное, И факт «много ошибок в коде» тоже может быть следствием какой-то другой более системной проблемы. Для того чтобы это выявить нужно просто задать вопрос «Почему?» Почему у нас много ошибок в коде?
И при ответе на эту группу вопросов можно выявить что:
Ух ты, оказывается что проблема лежит вовсе не на стороне разработки, а закопана глубже, и лежит еще в области подготовки к заключению договора.
Но ВАЖНО что на поверхности эти проблемы не лежали. И строя полную картинку
Можно найти ключевую проблему с которой и нужно применять изменения бизнес процессов. Данный пример короткий, но показывает что не все что лежит на поверхности действительно является ключевой проблемой. И при анализе состояния может выявиться еще 50 различных фактов влияющих на систему, а встраивая их всех в дерево причинно следственных связей и выявляя что является следствием а что причиной можно найти именно то самое ограничение системы которое нужно исправлять в первую очередь.
При разборе этого примера мы нашли что ключевой проблемой является отсутствие учета результатов ретроспектив, Для которых, хорошо было бы иметь какие-то артефакты проекта типа проектной документации. Да и результаты ретроспективы тоже имеет смысл оформлять в виде документа о выученных уроках.
И здесь мы можем прийти к конфликту.
Для того чтобы делать проект быстро мы должны экономить время, и соответственно не должны писать документов (Коммуникации важнее документации). Одновременно с этим мы должны думать о поддержке проекта и перспективах развития поэтому мы должны писать документацию.
И здесь мы приходим к еще одному инструменту ТОС «Диаграмма Ключевого конфликта» или «грозовая туча», которая представляет собой маленькую схему показывающую не конфликтующие между собой условия достижения цели, но конфликтующие методы обеспечения условий.
Для того чтобы решить эту «тучу» можно применить несколько различных методов
Или применить тот же самый логический подход, и выявить ложные предпосылки приводящие выбору методов обеспечения наших условий. Такак метод выбирается не только для обеспечения условия но на основании каких-то еще влияющих факторов. Иногда бывает что метод выбран правильно, но ошибка может крыться в условиях которые приводят к этим методам и тогда нужно поставить под сомнение сами условия приводящие к конфликту. Для этого тоже нужно исследовать предпосылки.
Для выявления предпосылок применяется рассмотренное ранее дерево текущей реальности, которое мы достраиваем с использованием вопросов «Почему?» «Зачем?» и соответственно ответов а них «ПОТОМУ ЧТО...» и переводя из абстрактной плоскости «экономить время» в конкретную «сэкономить 20 часов» задавая вопросы «Сколько вешать в граммах?», «А в чем это выражается?» чтобы получить измеримые факты. (да-да критерии SMART)
Прорабатывая каждую из этих веток можно выявить каике-то ложные предпосылки лежащие в основе условия или выбранного метода, которые могут быть ложными или исходят из более других корневых причин.
Если в результате анализа выявлено что наши условия действительно верные, но грозовая туча не решается, то можно проверить воздействия каждого из методов на систему в целом анализируя желательные эффекты (ЖЭ) и нежелательные явления (НЖЯ). Это можно проверить построив дерево будущей реальности:
Например:
Если мы будем писать документацию то
Если мы НЕ будем писать документацию то
Оценка на уровне дерева будущей реальности последствий наших действий дает понимание о стоимости внедрения того или иного метода и всех нежелательных явлениях которые могут возникнуть в процессе внедрения.
Выбранное решение называется «прорывом» и оно влияет сразу на всю тучу. Решение может лежать и за пределами тучи и может быть найдено через методики мозгового штурма ТРИЗ и «шести шляп мышления». Воздействия на систему в процессе модулирования дерева называются «инъекциями».
Но полученное решение нужно будет проверить на логическом дереве с анализом последствий нашего воздействия на систему в целом. И решение о выбранном варианте можно проверить на предмет желательных эффектов и нежелательных явлений. И количество нежелательных явлений может сыграть существенную роль в выборе решения прорыва.
Данные методики также могут быть использованы и в оценке какой-то ситуации или при переговорах. Однако, при моделировании сценария вместо решения прорыва и инъекций можно использовать ваши действия с ответную реакцию оппонента которая может быть положительной (желательный эффект) и отрицательной (нежелательное явление).
Автор: sbase
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/91686
Ссылки в тексте:
[1] мышления: http://www.braintools.ru
[2] Источник: http://megamozg.ru/post/16194/
Нажмите здесь для печати.