Как правильно не соглашаться с идеями: Perfection Game и 3 шага проверки решения на устойчивость

    Осенью 2006 года судьба в лице руководства забросила меня на тренинг к Джиму Маккарти. Джим в свое время был руководителем проекта первой версии MS Visual Studio, после чего вместе с супругой Мишель ушел в тренеры-консультанты.

    На тот момент я про Джима уже знал, поскольку на полке пылилась его книга “Программируем командный дух” (в оригинале “Software for Your Head”). Сквозь книгу я продраться не смог, поэтому ехал на тренинг с тяжелым чувством, что два дня проведу, скучая по работе.

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

    Джим сел на стульчик и… начал жечь. Он рассказывал про простые но необычные инструменты. Про вроде бы знакомые проблемы, которые неожиданно легко решались элементарными способами, до того в голову не приходившими. Что-то из этих техник потом прижилось, что-то нет. Скажем, технику переформирования команд снизу мы потом дважды применили в Intel, и оно реально сработало. Но это тема отдельной статьи.

    Короче говоря, два дня пролетели как один час. И в частности, Джим рассказывал про такую технику обсуждения идей и решений как Perfection Game.

    Perfection Game


    В чем суть. Когда кто-то предлагает решение какой-то проблемы или задачи, ты должен оценить ее от 0 до 10. При этом, если ты оцениваешь идею, скажем, на 7, ты должен предложить еще 3 пункта, которые бы ее улучшали.

    Ты не можешь сказать: “Ну, это идея на троечку...”, потому что к этому ты должен добавить 7 пунктов, которые бы ее улучшали. Если ты не можешь предложить ничего, что бы идею улучшило, говори: “Я оцениваю эту идею на 10.”

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

    Мы как раз обсуждали, что делать, когда все с проблемой согласны, но человек предлагает решение, с которым ты не согласен. slavapankratov предлагал разные идеи, я возражал, что это не сработает, потому что… Коллега вскипал, начинал объяснять, почему сработает. Короче говоря, в первый раз мы так и не договорились. После чего, разошлись думать дальше. И вот к чему пришли.

    То, как мы обсуждали этот вопрос — это именно то, что обычно и происходит. Есть:

    Две обычные модели обсуждения решений


    1. “Мое решение лучше”. Один человек говорит: давай делать так. Второй говорит: давай делать этак, потому что… Первый: да нет, давай так, потому что… И дальше они толкаются на уровне решений, пытаясь доказать, что его решение лучше.

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

    Люди ощущают бОльшую ответственность за свои решения. За чужие решения они ответственности зачастую не ощущают.

    Пойдет сотрудник воплощать начальническое решение в жизнь. У него не получится. Кто виноват? Очевидно же — автор решения. А дальше начинается классический диалог. Сотрудник:
    — Оно не работает. Что делать?
    — Ну, тогда делай вот так.
    — (попробовав) Тоже не работает. Что делать?
    — Тогда так.
    — …

    И так до бесконечности.

    2. “Твое решение — не правильное”. Человек предлагает решение. Второй говорит:
    — Да нет, оно плохое, потому что…
    — Зато его можно быстро реализовать (варианты: будет дешевле / качественнее / удобнее для клиентов / …)

    Либо включается модель “Зато”, либо человек просто начинает объяснять, что претензии к его решению не состоятельны.

    В жизни эти две модели иногда объединяются прямо в рамках одного диалога. И решение оппонента ругаем, и свое пропихиваем.

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

    Как обсуждать решение, с которым ты не согласен: ТРИ мощных шага.


    1. Конкретизируйте, что не так.

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

    Тут люди делятся на два типа. Первые сразу четко понимают, чем конкретно это решение плохое. Вторые чувствуют одним местом (вероятно. интуицией), что решение плохое. Но почему — сказать не могут.

    Я, например, отношусь ко второму типу. Сначала интуиция подсказывает, а конкретика приходит в голову чуть позже. Кто-то скажет: “Александр, да Вы тормоз”. Я возражу, что это такой психотип.

    Так вот, если вы относитесь ко второму типу — не лезьте в драку возьмите паузу. Например, с такими словами: “Слушай, Я чувствую, что здесь что-то не то, но сформулировать пока не могу. Дай мне полчаса, я поварюсь, подумаю.”

    2. Согласитесь с тем, что предлагаемое решение рабочее.

    Да-да, прямо так и скажите: “Да, это вариант”. Человек только что напряг мозг, родил решение — почему бы его за это не похвалить? Более того, пусть у человека будет ощущение, что это его решение — особенно, если ему его потом воплощать.

    И тут же мы переходим к третьему шагу.

    3. Проверьте решение на устойчивость.

    Можно так и сказать: “Давай проверим его на устойчивость.” Я иногда говорю: “Давай его пожуем.” После чего спрашиваем:
    — А что будет, если [конкретная ситуация, когда как вы видите решение не работает], потому что [причина, почему вас это волнует]?

    Или:
    — А как бы нам сделать так, чтобы оно сработало, когда [конкретная ситуация, когда как вы видите решение не работает], чтобы [причина, почему вас это волнует]?

    Пример. Ваш коллега предлагает архитектуру новой системы. А вы видите, что она не расширяемая, не масштабируемая и вообще не соответствует принципам SOLID (или чему там архитектура не должна соответствовать).

    Вы можете сказать: “Так она же нагрузку не держит. Давай лучше делать так...”, но согласно предлагаемому алгоритму это будет звучать чуть иначе:
    — Да, это вариант. А что будет, если у нас нагрузка вырастет в 100 раз, как мы планируем через 3 месяца? Выдержит архитектура?

    Или:
    — Да, это вариант. А как бы нам сделать, чтобы она держала в 100 раз бОльшую нагрузку, как у нас планируется через 3 месяца?

    Мы не отвергаем решение человека. Мы вообще не спорим, получается. Человеку нечего защищать. Плюс вопросы включают у человека мозг и позволяют доработать ЕГО решение.

    Пример. Допустим, новый тимлид предлагает перейти на новую систему прогона тестов. Аргументы: она там считает какую-то дополнительную статистику + позволяет удобнее анализировать падения тестов.

    Вы понимаете, что с внедрением этой системы 20% тестов перестанут прогоняться вообще, поскольку самолично писали костыли для вашей текущей системы прогона, которые позволяют эти тесты запускать.

    Можно попробовать убедить тимлида отказаться от новой системы прогона тестов, но согласно алгоритму обсуждение можно выстроить так:
    — Новая система? Ну что, хорошая тема. А как бы нам при переходе на нее не просесть по качеству, а то 20% тестов не будут гоняться?

    Пример из жизни. Коллега slavapankratov известен узкому кругу хорошо с ним знакомых лиц тем, что постоянно генерирует разные идеи. Которые обычно посылает смс-ками. То есть, получить от slavapankratov восемь смсок в течение часа — это нормальное явление: мысль пошла. И вот как-то раз приходит смска такого содержания: “Я все придумал, мы будем публиковать вакансии.”

    В обсуждении выясняется суть идеи. Как известно рекрутинговые агентства зарабатывают хорошие деньги на поиске кандидатов. Комиссия агентства за найденного инженера или менеджера может составлять одну-две его месячные зарплаты. В случае директоров — и того больше. Идея: публиковать вакансии в нашей рассылке (у нас на тот момент было 25.000 подписчиков). Рекомендуем вакансии, зарабатываем деньги.

    Идея вроде бы нормальная. Но чувствую, что-то не то. Начинаю возражать — получаю в ответ: “Зато денег заработаем”. После горячих споров, выхожу из разговора: “Дядя Слава, — говорю, — одним местом чувствую подвох, но сформулировать не могу. Дай мне полчаса подумать.”

    Потом доходит. Наши корпоративные клиенты могут воспринять эту инициативу не очень здорово. Можно ли посылать своих сотрудников на обучение к тем, кто помогает другим компаниям искать сотрудников? Большой вопрос…

    Возвращаемся к разговору. “Дядька, — говорю, — а как бы нам сделать так, чтобы от нас не отвернулись наши любимые корпоративные клиенты? А то забоятся к нам людей-то посылать на тренинги.”
    О, это понятный вопрос. Начинаем дорабатывать идею. Решаем, что надо в письме прописать, что эта вакансия публикуется только в рассылке, а не на нашем форуме, где в онлайн программах присутствуют сотрудники корп.клиентов. И что мы заботимся о наших корп.клиентах.

    Уже лучше. А главное — идея-то доработалась. (Мы, правда, так и не стали рекрутинговым агентством, оставшись центром обучения. Ну что ж, не все идеи срабатывают. Это ж не повод их не дорабатывать, верно?)

    В заключение.


    Возможно, вы обратили внимание, что у Джима Маккарти в его Perfection Game и здесь используется один принцип. Мы не критикуем впрямую решение человека. Его идея — это его ребенок, которого он недавно родил. Может быть, кривенький ребенок, но свой. Можно сказать: мой ребенок лучше. Но лучше помочь чужому ребенку.

    Если вы уже используете эту технику — напишите в комментариях примеры. когда она помогала. Примеры лучше закрепляют материал.

    Если не используете — попробуйте. Кстати, проверено, что она неплохо работает не только с коллегами, но и с детьми и супругами. :)

    P.S. После предыдущей статьи про мощный вопрос поступило несколько комментариев про особенности общения с руководством. В следующей статье как раз думаем раскрыть эту тему.
    • +20
    • 26,2k
    • 8

    Стратоплан

    47,00

    Компания

    Поделиться публикацией
    Комментарии 8
      0
      Имхо, чем-то напоминает метод Сократа. Сверился с википедией: «метод часто подразумевает дискуссию, в которой собеседник, отвечая на заданные вопросы, высказывал суждения, обнаруживая свои знания или, напротив, свое неведение».
        0
        Как поговаривает наш коллега Дмитрий Коткин, коммуникацией управляет тот, кто задает вопросы.
        +1
        Саша, а почему ты ситуацию, когда человек сидит на стуле и рассказывает, называешь «тренингом»?
          0
          Дык там и отработки было полно, потому и тренинг.
          +1
          Напомнило историю про мальчика который просил у мамы xbox.
            0
            О, а что это за история?
            0
            Как говориться ничто не ново под луной :)
            Техника по сути является производной нлп-шной технике ОСВК- Обратная Связь Высокого Качества.
            Т.е. первым делом надо поддержать человека, а потом озвучить чего не хватает по вашему мнению.
              0
              Доброго времени суток. Спасибо за статью, интересная тема, часто по факту используем такую методику — когда рождается ее обоснование и описание — многое встает на свои места.
              Правда, имхо, в статье стоит добавить контекст уместного использования методики, так как она эффективна явна не всегда. Проблема кроется в том, что зачастую верно оптимальное решение, а не идеальное (или совершенное). Где «идеальное» — сущность в общем более объективная (т.е. собеседники в решении проблемы, в которой условно одинаково компетентны, имеют в целом схожее представление об идеальности), а «оптимальность» — сущность более субъективная (чуть позже аргумент — «почему»). Соответственно на предложенное оптимальное решение (которое на практике зачастую не совершенное) — методика дает возможность критиковать (методом «на 7-чку, вот тебе 3 предложения к улучшению) и вдаваться порой в полемику. Смысл оптимальности ведь в том, что мы осознанно (или порой неосознанно, на опыте) жертвуем чем-либо (т.е. не достигаем идеала по некоторым позициям) либо когда это невозможно (например, одно преимущество противоречит другому — надо выбрать), либо когда нерационально реализовывать идеал (банально дорого). И здесь самое ключевое в том, что выбор того, чем мы жертвуем — это зачастую намеренный и осознанный „риск“. А риски как раз (в основном „жизненные“ риски) очень субъективное понятие. А если говорить строго: сложность адекватной оценки вероятности и влияния рисков зачастую многократно превосходит по сложности ту проблему, о которой спорим, поэтому оценка рисков — вероятность и влияние — на практике зачастую субъективна. В таком случае методика, например, проверки на устойчивость, превращается в спор „мировоззрений“ (в оценке рисков).
              Т.е. методика становится инструментом неконструктивной манипуляции: „Ну вот смотри, в предложенной архитектуре есть вероятность того, что будут проблемы тут-то, которые нам надо будет мучатся-решать“. Вроде адекватный аргумент — но что значит в конкретике „вероятность“ и что значит „мучатся“ — это очень субъективно: какова вероятность и насколько сильно мучатся, заранее зачастую как то оценить количественно невозможно. И тогда в споре побеждает более харизматичный (главный/сильный/громкий и т.п. ).
              Резюмируя, методика хороша тремя составляющими:
              • Проверка, что оптимальность в конкретном случае отличается от идеальности именно „позициями“ субъективной оценкой рисков, что уже неплохо
              • Таким методом можно оценить насколько твоя субъективная оценка совпадает с субъективноей оценкой оппонента. Это никак не продвинет в вопросе решения конкретной проблемы, но так или иначе расширит кругозор.
              • Отлично подойдет в ситуациях, когда локальный идеал достижим за адекватные ресурсы. Но таких случаев, к сожалению, подавляющее меньшинство.

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

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