Осенью 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. После предыдущей статьи про мощный вопрос поступило несколько комментариев про особенности общения с руководством. В следующей статье как раз думаем раскрыть эту тему.
Автор: eagleson
