Необычный метод разрешения проблем с Заказчиком

Осталась у меня одна идея, которую я почерпнул на мастер-классе Наташи Трениной на конференции AgileBC в Днепропетровске. С вами не делился потому, что сначала решил отработать на своей практике, а потом уже писать о результатах. Так вот, тест прошел, теперь рассказываю о методике в своей интерпретации.

У каждой проблемы есть 3 составляющие: Выталкивающая, Удерживающая и Притягивающая. В повседневной жизни мы часто используем только Выталкивающую и Удерживающую. Примером может послужить рефакторинг кода. Мы с Заказчиком будем спорить до хрипоты, что «так дальше жить нельзя» (Выталкивающая составляющая) и код больше невозможно нормально поддерживать. С другой стороны мы знаем, что придется писать кучу юнит тестов, что нужно напрягаться (чтобы не сдвинуть график поставки) и убеждать Заказчика, который явно не будет счастлив платить за «какую-то переделку». Это как раз примеры Удерживающей составляющей проблемы.

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

Но есть Притягивающая составляющая, которая предназначена для того, чтобы откинуть первых 2 и просто «помечтать» о том, как же я вижу себе решение этой проблемы в идеальном мире. Не важно, что меня выталкивает и притягивает, важно то, чего я хочу добиться. В случае с рефакторингом кода это мечта о том, как должен выглядеть наш код и процесс его создания. Если бы начал «мечтать» я, то выяснилось бы, что не мне не хочется править баги, которые накапливаются, а так как они будут, то их лучше фиксить сразу, не откладывая. Продолжая такое упражнение можно дойти до мысли, что если мы внедрим процесс a-la Lean, то это решит проблему с немедленным фиксом багов.

И применив Притягивающую составляющую, вдруг (!) окажется, что, во-первых, мы часто сражаемся за то, что нам не нужно (мы это не описывали в нашей мечте), а во-вторых, мы улучшим нашу мотивацию на достижение этих целей (ведь хорошо же идти к мечте).

Я постоянно стал применять эту практику при общении с командой и Заказчиком. Теперь, когда возникает проблема, которая требует решения, то я спрашиваю: «Опиши ситуацию, в которой этой проблемы нет». И мы начинаем искать подход, как достичь идеала и это не обязательно совпадает с решением той проблемы, которая была поставлена изначально.

P.S. Сначала решил поместить эту методику в рассылку Базового курса по работе с Заказчиком. Но потом понял, что там и так много интересного и полезного материала + куча бонусов. Поэтому публикую тут.

Aug 5th, 2011
  1. Aug 5th, 2011 at 08:39 | #1

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

    там так же сначала описывается проблема в виде “дерева текущей реальности”, описывается цель в виде “дерева будущей реальности”, потом находится корневое противоречие, которое удерживает систему от перехода в желаемое состояние и предпринимается попытка построить диаграмму разрешения конфликтов (“Грозовую тучу”), из него вытекает “дерево перехода” и план преобразований.

    • Aug 5th, 2011 at 08:40 | #2

      подробности у самого Элияхи или у Уильяма Детмера.

    • Aug 5th, 2011 at 08:54 | #3

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

    • Aug 5th, 2011 at 10:08 | #4

      COTOHA :
      сначала описывается проблема в виде “дерева текущей реальности”, описывается цель в виде “дерева будущей реальности”, потом находится корневое противоречие, которое удерживает систему от перехода в желаемое состояние и предпринимается попытка построить диаграмму разрешения конфликтов (“Грозовую тучу”), из него вытекает “дерево перехода” и план преобразований.

      Супер! Краткое и исчерпывающее резюму по всему посту.

  2. Вячеслав
    Aug 7th, 2011 at 10:04 | #5

    да? а по моему в посте всё написано куда более понятнее, чем все эти аллегории с деревьями и тучами.

    • Aug 7th, 2011 at 16:55 | #6

      это не аллегории :) дерево – это просто частный случай графа, а граф – это просто форма представления связанных наборов данных.

      • Aug 7th, 2011 at 17:05 | #7

        СОТОНА
        Стой-стой, любая наша проблема – это всего лишь набор данных. Наша жизнь тоже, и т.д. Не упрощай :)

        Если бы я писал посты в стиле “Посмотрите на дерево проблем и сделайте так у себя” (это весь текст поста), то было бы смертельно скучно. Истории, а особенно жизненные, они связывают теории и практику в формат, который лучше воспринимается мозгом.

  3. Aug 7th, 2011 at 16:37 | #8

    Ну, понятнее, да но никак не кратное.

  4. Aug 7th, 2011 at 17:14 | #9

    Стой-стой, любая наша проблема – это всего лишь набор данных. Наша жизнь тоже, и т.д. Не упрощай

    так я ж тебе ничего и не говорил. объяснил Вячеславу просто, что аллегории тут не при чём :)

Leave a comment