Дерево существующей реальности

    Все мы ежедневно (иногда и ежечасно) дома или на работе сталкиваемся с проблемами разного характера. Некоторые из них решаются сами собой, на некоторых нужно сосредоточить все свое внимание на немалый срок. Мы будем говорить скорее о последних.

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

    Прошу под кат!

    NB: Это первая статья из серии «Техники анализа проблем и принятия решения».

    NB2: Рассмотренные в примере выводы являются приблизительными и основаны на полностью выдуманной ситуации.



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

    Вам понадобятся доска, клейкие листочки post-it (достаточно большой лист бумаги и ручка тоже подойдут, но доска предпочтительней) и собственно проблема, которую мы будем решать. Весь алгоритм будет состоять из 4 – х шагов. Разбирать их мы будем на конкретном примере.
    Предположим, проблема у нас следующая: «Мои программисты не работают!»

    Шаг 1. Сформулируйте проблему.

    Иногда даже на этом этапе возникают затруднения.
    Как вы уже поняли то, что сформулировал я в предыдущем абзаце, проблемой не является.
    Основным индикатором правильно выведенной проблемы является возможность переформулировать ее в вопрос, ответ на который подразумевает действие: «Как я могу … (антитезис проблемы)?»

    Объясню на примере:
    Первоначальный запрос: Мои программисты не работают!

    Проблема: Руководитель не может эффективно организовать работу команды программистов.

    Проверочный вопрос: Как руководитель может эффективно организовать работу команды программистов?

    Все сошлось? Идем дальше.

    Шаг 2. Выпишите на доску минимум 10 признаков (внешних проявлений) вашей проблемы.

    Сделайте это на заготовленных листах post-it и расположите их в одну/две линии.
    Подойдите к этому шагу ответственно! Следите, чтобы признаки не были «призраками», пишите честно и не придумывайте того, чего нет, это очень важное условие. Через несколько желтых листочков (на вкус и цвет товарища нет) вас «прорвет».
    Из следующих ниже 11 признаков на 6 первых я потратил 30 минут времени, а на оставшиеся 5 – 2 минуты.

    Вот, что получилось:

    image

    Шаг 3. Постройте Дерево существующей реальности.

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

    image

    Таким же образом группируем следующие признаки.
    Должно получиться примерно следующее. (Приношу извинения за качество картинок — рисовать в силу некоторых обстоятельств пришлось в Word.)
    image

    Оранжевым цветом обозначены признаки, добавленные в процессе работы над деревом.

    Отрывайтесь от отдельных ветвей время от времени и обращайте свой взгляд на дерево целиком. Так вы сможете увидеть новые связи между признаками.
    Не бойтесь разрушать связи – на их место придут новые.

    Шаг 4. «Дерните за веревочку»

    Помимо того, что ДСР даст вам общую картину происходящего, из которой вы сможете вывести определенные решения, оно также укажет на самое слабое место. Им будет «листок», определяющий наибольшее количество связей.

    Надавите в это место и большая часть проблемы решена. Что делать дальше, я уверен, вы догадаетесь!

    P.S.
    Следующие 2 статьи я планирую посвятить методам «Вопросы Леонардо да Винчи» и «3d-анализ».

    UPD. Совсем забыл уточнить, что автором этой методики является небезызвестный Э.Голдрат.
    Поделиться публикацией

    Комментарии 17

      +5
      ну и за какую веревочку надо дернуть в этой выдуманной ситуации?

      И, кстати, такие картинки надо выкладывать не в jpeg-е.
        0
        А как выложить? Расскажите, у меня опыта совсем нет…
        +1
        Помоему вполне реальная ситуация полного хаоса :)

        Карта расписана не полно. Если работают профессионалы, на мой взгляд, стоит:
        1) Обьяснить разработчикам смысл того, что они пишут
        2) Сделать публичными задания и время их выполнения, устроить соц. соревнование с раздачей пряничных слонов, если разработчики заняты однотипными заданиями, и их результаты можно оценить в одной шкале.
        3) Сделать возможность «плавающего» графика. Задержался утром? Не проблема — отработаешь вечером.
        4) Раздать чай и печеньки, если это еще не было сделано, дать возможность пообщаться в неформальной обстановке.
        5) Сделать более четкую зависимость получаемых денег от результата. В KPI внести качество кода, например по количеству пойманных багов и их критичности в первый месяц после выпуска кода.
        6) Перемены в работе. Нельзя допускать застаивания и скуки.
        7) Проанализировать проблемы коллектива. Если есть «черная овца», разлагающая работу — смело выбрасываем. Если есть врожденный говнокодер, не тешим себя мыслью, что он когда нибудь под вашим чутким руководством научиться все делать хорошо, выбрасываем.
        8 или 0) Если у вас нет ресурсов или возможности чтобы что то поменять, или проблема таки в вас — уходите сами.

          0
          К этим и другим выводам как раз можно придти, если доделать до конца, то ДСР, которое я начал описывать.
          Пример, действительно, выбран не очень удачно…
          Учту в следующих статьях.
        0
        В этом примере не за что дергать. Реальные ДСР получаются сложнее и в них набор признаков намного шире. У меня не хватило места и воображения на этот случай. Попытался хотя бы принцип отобразить.
          0
          ну чем не майндмэп?..

          собственно, в том и вопрос: что тут есть такого, чего нет в интеллект-картах? может стоило чуть развернутее пример объяснить.
            0
            Думаю, Вы правы. Нужно было пример развернуть.
            Просто хотелось привести пример, который соответствовал бы ИТ-тематике Хабра. Неудачная попытка.
            По поводу майндмэпинга. Техники, действительно похожие. Принципиальных отличий 2:
            1. ДСР можно описать по принципу «снизу вверх», то есть оно имеет уровневую структуру. В то время как в майндмэпинге все ветки ведут в центр.
            2. Майндмэпинг больше служит описанию проблемы, представлению ясной картины. ДСР имеет своей целью решение проблемы. В этом смысле ММ имеет смысл сравнить с системами взаимосвязанных компонентов (СВК).
              0
              раскрою подробность не слишком известную: майндмэпы в виде радиальной схемы — не единственный вариант, просто он наиболее распространен, да и ПО реализовано чаще всего именно под него.

              есть т.н. омега-мэппинг — рисуем текущее состояние в одном углу, желаемое — в противоположном и приступаем сначала к более детальному описанию, а затем из 2-х схем пытаемся придумать пути реализации (в некоторых источниках указывают, что нужно только действия указывать, но, по-моему и не только, мнению, это уход в крайности).
                0
                Никогда не слышал про омега-мэппинг. Мне, как тренеру, такая техника интересная.

                Я согласен, что радиальный вариант когнитивных карт более распространен. Это вполне резонно, потому что это именно карта.
                  0
                  рад был подсказать )

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

            ДТР, так же как и дерево будущей реальности, дерево перехода и схема локализации конфликта «грозовая туча» изначально в оборот были введены именно им. Да и практики, описываемые вами были сформулированы им же.
              0
              Да, да это его техники.
              Ссылка сейчас будет.
              0
              Я вижу только две проблемы которые осталось решить для полного счастья, это субъективность восприятия ситуаций, которая не позваляет создать полную модель и неспособность принимать волевые решения, которая не позволяет изменть модель
                0
                Как по мне, так как раз самое интересное начинается уже после того, как выписано ДСР. Как раз построение корневой тучи, дерево перехода, нахождение предпосылок является подходом к решению проблем. Построение ДСР есть первый шаг (ну второй, максимум) из сложной (и, возможно, продолжительной) цепи локализации и устранения проблем в проекте.

                И далеко не обязательно, что предпосылка, которая связана с другими большим количеством связей, является основной проблемой.
                  0
                  В небольших проектах, я думаю, ДСР можно использовать и как самостоятельный инструмент. Все зависит от того, как сформулирован первоначальный запрос.

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

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое