О принятии устойчивых решений или кейс-клуб на Хабре

    Три года назад волею судеб оказался в одном поволжском городе с корпоративным тренингом. Тогда впервые узнал, что люди в ИТ компаниях могут приходить на работу к 8:30, и тогда же у меня случилась история, с которой больше никогда не сталкивался — ни до, ни после.

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

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

    К концу первого дня я уже сгорал от нетерпения узнать, что происходит! Может быть, человек долго работал генеральным директором и потом вернулся в инженеры? Ну, так не бывает — нельзя не имея опыта, решать сложные управленческие задачи.

    Как выяснилось за вечерним пивом, Никита издавна играет в World of Warcraft (могу напутать, поскольку не специалист в играх, по-моему, это был таки Warcraft). Причем играет на серверах, где люди объединяются в большие команды. Выяснилось, что Никита продолжительное время руководит очень большой группой игроков. Убеждает объединяться в какие-то группы, решает конфликты, принимает решения и т.д. Поскольку продолжается это уже много лет, то человек просто наработал практику принятия управленческих решений — не на работе, а в игре.

    Меня постигло жестокое разочарование. Я практически уже открыл таблетку, как стать опытным управленцем, и на тебе — опять многолетняя практика, опять надо работать. С другой стороны, эта история еще раз подтвердила мысль Капитана Очевидности, что научиться можно на кошках. Главное — делать это регулярно.

    И сегодня мы хотели бы предложить небольшой практикум. Ну, просто читать статью же скучно — а думать интересней!

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

    Как это сделать? Читаете описание ситуации — в конце есть вопрос. Берете паузу на подумать. Прикидываете, что и как сделали бы вы в этой ситуации. И потом сверяетесь с решением во второй половине статьи. (Если мозги тренировать не хочется, то можно сразу перейти ко второй половине статьи). Если решение кажется вам спорным — пишите в комментариях. Будет здорово, если мы с вами эти решения доработаем.

    Поехали!

    Кейс «Выберите наше решение!»

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

    В итоге, на очередной планерке случился примерно такой диалог:
    — Коллеги, мы тут посидели и написали скрипты для запуска бенчмарков!
    — О, и мы написали такие скрипты!

    У главного руководителя тестирования (назовем его Сергей) тут же приключилась головная боль, чьи скрипты выбрать, чтобы никого не обидеть. По сути скрипты делали одно и то же. Но поскольку проактивность и нанесение пользы как раз учитывалось на грядущей аттестации, то обе команды хотели получить плюс в графу «Проактивно сделанные задачи».

    Хорошо, сказал Сергей, давайте сравним скрипты. А как сравнить? Нужны метрики. Команды начали обсуждать метрики и сравнивать скрипты. И за два дня не продвинулись в этом вопросе. Получалось, что по метрикам команды А побеждают их скрипты, по метрикам команды Б — их.

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

    После двух дней ярких обсуждений Сергей принял волевое решение: скрипты одинаково хорошие, давайте их смержим (срастим, то есть). Тут нужно заметить, что скрипты команды А были написаны на Perl, скрипты команды Б на Shell-овских скриптах. Скрещивать ужа с ежом было доверено двум инженерам из каждой команды. Бедняги провели сутки на телефоне, чтобы сведенный дикобраз начал работать.

    Что произошло дальше. Дальше скрипты передали команде Б на поддержку и забыли об этом страшном сне. Как выяснилось через полгода, инженер из команды Б вычистил оттуда все чужие куски кода («так проще поддерживать»).

    По итогу: потеряно несколько дней работы инженеров и менеджеров, и де-факто все равно выбран один из двух вариантов.

    Вопрос: как нужно было поступить руководителю тестирования Сергею в момент, когда команды принесли ему написанные скрипты?

    (ДАЛЬШЕ НЕ СМОТРИТЕ, ПОКА НЕ ПРИДУМАЕТЕ СВОЕ РЕШЕНИЕ)

    Кейс №1. Решение.

    В свое время мне на глаза попалась отличная книга Роберта Таунсенда «Сломай систему! Лекарство от управленческой изжоги». Легендарный CEO компании Avis делился своим опытом в кратких заметках. Что довольно удобно, когда времени ни на что не хватает — а тут выкроил пять минут в укромном месте, сел и проникся управленческой мудростью господина Таунсенда.

    Так вот в главе о принятии решений он писал: «Когда два ваших сотрудника приносят вам два решения одной и той же задачи, выберите чье-нибудь одно. В этом случае вы получите хотя бы одного человека, мотивированного к воплощению этого решения».

    Что мог бы сделать руководитель тестирования Сергей в этой ситуации? Как нам кажется, есть четыре важных шага.

    Шаг №1. Спросить: «Друзья, а кто будет поддерживать эти скрипты?» Все любят писать интересные программы, не все любят их поддерживать. Этим вопросом руководитель а) ввел бы принцип, по которому принимается решение и б) выбрал бы тех, кто готов на бОльшее, чтобы его решение было принято.

    Как в старой истории, помните? Директору компании нужно выбрать, кого послать на конференцию. Желающих 10 человек, бюджет только на двоих.
    — Кто хочет поехать на конференцию?
    — (10 рук)
    — Но по результатам конференции нужно будет провести мастер-класс для своей команды…
    — (Пара рук опускается)
    — И конференция пройдет в выходные…
    — (Еще пара человек отвалилась)
    — И потом нужно будет отработать рабочие дни…
    — …
    — И компания оплатит только половину…
    — (Остаются две руки)
    — Да, кстати, конференция пройдет в Лас Вегасе, дорога, отель и развлечения за счет компании.

    Шаг №2 (если поддерживать скрипты готовы обе команды). Просто выбрать чьи-то одни — по подкидыванию монетки, например. Это тоже принцип. Но тем самым, он бы показал, что важны не только проактивность, но и скорость принятия решений и то, что работа и скорость получения результатов важнее разборок по поводу того, кому что зачтется.

    Шаг №3. Объявить, что на аттестации зачет получат обе команды.

    Шаг №4. Обсудить с командами, как сделать так, чтобы таких коллизий больше не возникало.

    Как нам кажется, эти четыре шага могли бы а) сэкономить время на принятие решения б) сделали решение более устойчивым (ответственные за скрипты поддерживали бы написанный ими же код в) показали принцип принятия решения, чтобы минимизировать взаимные обиды и осадок от ситуации.

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

    P.S. Мы сейчас запускаем кейс-клуб нашей Школы менеджеров, где такие кейсы (как наши, так и из вашей практики) сможет обсуждать все сообщество кейс-клуба. Плюс разборы, плюс необходимые видео-материалы и т.д.

    Если интересно присоединиться — будем рады вас там видеть (это платный проект, недорогой, но платный):

    Кейс-клуб «Системные люди»

    А на этой неделе мы думаем открыть такой, что ли, филиал кейс-клуба на Хабре. Если идея окажется интересной, то мы эту инициативу на Хабре постараемся сделать постоянной.

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

    Стратоплан

    47,00

    Компания

    Поделиться публикацией
    Комментарии 31
      +4
      В случае с выбором одного варианта из двух предложенных мы, конечно, получим одного человека (команду), мотивированную внедрить решение. Но мы также гарантированно, с вероятностью 100% получим одного обиженного на ровном месте человека (команду), которая старалась, а получила шиш.

      В случае с набором скриптов для бенчмарка я бы сказал: «Окей, отлично, давайте посмотрим теперь насколько хорошо ваше решение расширяемо и масштабируемо. Мне кажется нужно добавить ещё бенчмарки Х, Y и Z, запускать тесты параллельно на трёх серверах, а суммарный отчёт высылать на почту разработчикам. Давайте посмотрим, в каком решении это всё будет сделать быстрее.» Да, мы потратим ещё 1 день на выполнение этих задач, но в итоге:
      • в продакшн пойдёт действительно более лёгкое в поддержке и расширяемости решение
      • поддерживать его будет гордая за результат своей работы команда
      • вторая команда, решение которой было забраковано, лично убедиться, что произошло это не «от балды» и не по причинам каких-то подковёрных интриг, а потому, что они не смогли добавить 3 новых бенчмарка быстрее конкурентов или потому, что их решение не масштабируется на несколько серверов. Никаких «собственноручно придуманных метрик», только соответствие реалий поставленным задачам.
        +2
        Вы не учитываете вариант, что обе команды справятся. Этак вы до бесконечности будете тратить ресурсы на доработку скрипта.
        Принудительный выбор варианта с обязательством поддержки и гарантией поощрения (в виде плюса при аттестации) проблему «обиженных» снимает.

          0
          Принудительный выбор варианта с обязательством поддержки и гарантией поощрения (в виде плюса при аттестации) проблему «обиженных» снимает.

          тут несколько меняется полярность проблемы:
          Одна команда получит плюсик и премию, а другой ещё придётся поддерживать и развивать проект.
            0
            Во-первых, справятся они не одновременно.
            Во-вторых, никогда в жизни не поверю, что сделанное изначально было идеально — всегда есть, что поправить.

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

              Добавлю, что там в реальной ситуации скрипты были одинаково неплохими. Устроить соц.соревнование команд — интересная идея, но в случае более-менее одинаковых решений имхо спросить. кто будет поддерживать — проще.
          +3
          Я не менеджер ни разу, но кейсы очень интересные. С нетерпением жду продолжения) Спасибо!
            0
            Спасибо, продолжим!
            +1
            1) Кто поддерживает решение в дальнейшем, тот и выбирает вариант реализации скриптов.
            2) Обеим командам объявить по 50% бонуса (половина лучше, чем ничего) и объявить на будущее, что для получения 100% надо убедиться, что решение будет актуальным, то есть выяснить, кто будет ответственным и согласовать свои проактивные действия с ним.
              0
              Без критериев усточивости решения писать о принятии таких решений, мягко говоря, странно, но это же тренинг да.
                0
                Справедливое замечание. В следующей статье как раз про критерии устойчивости поговорим.
                0
                Ребята, интересно было бы увидеть побольше новых (буквально – свежих) кейсов. Всё что на хабре, в основном, повторение белой и черной книги, ну и прочих ваших материалов. Они все отличные! Но давайте же и свежести, буду искренне благодарен. Но мне вот что интересно ещё было бы. Вы черпаете эти кейсы из России середины нулевых, а каков расклад кейсов России середины десятых? Можно было бы сравнить тогда-сегодня, ведь наверняка есть изменения.
                  0
                  Спасибо за то, что следите за нами! )) Старые кейсы хороши тем, что они проверенно интересные, но плохи тем, что кто-то про них еще знает. Свежих кейсов есть вагон и маленькая тележка, дойдем и до них.

                  Сравнить кейсы не возьмусь — несмотря на то, что лично проанализировал под 400 кейсов, какой-то закономерности, которая бы отличала десятые от нулевых, не заметил. Все те же проблемы с людьми в команде, с заказчиками, начальниками и т.д.

                  Мне кажется, тут дело не во времени, а в том, что даже мир ИТ компаний — это, на самом деле, несколько миров. Есть компании, скажем так, западного толка, которые хотят быть похожими на корпорации, модные стартапы или еще что-то, есть компании со своей историей (тяжелой или интересной), там своя специфика — и так далее.
                    +1
                    Давно слежу и вдохновляюсь, спасибо за ваш труд!
                    На мой взгляд, должны были повлиять вот такие моменты.
                    1. Способы коммуникации: больше онлайна, нормальный интернет в моём Нижнем Новгороде заполучился только в 2007. Сейчас у нас огрномный выбор: тут тебе и тикеты на гитхабе, и почта с гугл.инбоксом, и slack. Google.Hangouts, из которого я так и не смог дёрнуть историю. Хотя логи ICQ с 2003 по 2013 у меня отлично хранятся до сих пор :) Хорошо или плохо такое разнообразие?
                    2. Модные течения: писать будем на Node.JS, или может быть возьмём его форк (пока ещё только один известен), или ничего не признаем кроме Эрланга, а какой из 100 фреймворков для клиента выберем? Руби уже не тот? На мой взгляд, в 2005 выбор инструментов был весьма скуднее.
                    3. Больше интересных работодателей, больше контрактников и фрилансеров (в силу удобства взаимодействия). Сейчас найти отличного исполнителя – это (часто) очень эффективно решаемая на биржах задача. Люди стали более мобильными, и более легко меняют места работы. Высокое проникновение ИТ в России в целом, много мест, где на тебя будет хороший спрос.
                    4. Методологический холивар: раньше как-то просто работали, вот есть цель, вот мы к ней движемся. И тесты, знаете ли, были, и планёрки. Теперь у вас большая проблема – 5 или 10 минут делать стендап, в 10 или 11 утра? Как там у нас считают лучшие мастера. А может быть ну его скрам, давайте по канбану? Скрамбан? Или вот давайте выберем одну из 25 доступных таск-трекеров. Сидишь на битбакет вместо гитхаба, верстаешь в ворде вместо маркдаун, ну ты странный. TDD/DDD/CQRS. И т.д.
                    То есть, возможность огромного выбора – это явно и хорошо, но явно и плохо. Обостряет, если хотите, аналитический паралич, провоцирует ненужные обсуждения и потери времени, обостряет субъективные суждения. Как-то так мне это видится. Поправьте ход моих мыслей, если я сильно не прав :)
                  0
                  Мне вот кажется, что шаг №2 именно в таком виде — вреден. Если о подбрасывании монетки узнают обе команды, то они вполне могут решить, что менеджеру — плевать на их работу, т.к. он даже разбираться не стал. Это может убить всякую инициативу.

                  Думаю, что при частом использовании такого трюка возможна докладная начальству от обиженных работников, причём с детальным указанием — какие обязанности он «вследствие своей некомпетентности» перекладывал на волю случая. И оправдаться будет тяжело (хотя, это вполне может быть идеей нового кейса).

                  Шаг №3 поддерживаю. Мой вариант, помимо него содержал нечто наподобие варианта который предложил tangro, но его вариант мне нравится больше.
                    0
                    Спасибо за комментарий. Монетку если уж подбрасывать, то конечно, на глазах всех участников. С объяснением, для чего вы это делаете: чтобы не тратить время на сравнение одинаково хороших вариантов.
                    0
                    Странно, что оценивать работу должны были сами работники. Зачем тогда нужен Сергей? Поставить автоматическую монетку и пусть все решения принимает)
                    Дальше, раз была договоренность о проактивности и оба решения хороши, то логично дать бонус обоим, а задуматься опять же о Сергее, который не в состоянии распределить задачи или о таск-менеджере, в котором не видно, что эта задача уже выполняется другой командой.
                    Про поддержку опять же — очень странно, что такой вопрос вообще возникает. Написание кода и поддержка суть весь продукт, неотделимы.

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

                          Кстати, меня давно интересует вопрос, а смог ли бы кто нибудь из «профессиональных тренеров» успешно управлять большим алли в евке. Ну или хотя бы небольшой но хорошо координированной компашкой типа RAISA Shield. Тоже, знаете ли, вызов и практика.
                            0
                            Может ли хороший спортсмен стать хорошим тренером? Обязательно ли хорошему тренеру быть хорошим спортсменом?.. Сейчас по факту приходится совмещать три деятельности: тренерскую, предпринимательскую и управленческую. Все это в рамках одной компании, которая занимается обучением. И чем дальше этим занимаюсь, тем четче Капитан Очевидность шепчет на ухо, что это абсолютно разные виды деятельности. :)
                            0
                            Можно ли сказать, что при решении любой проблемы нужно держать в уме три вопроса вместо одного?

                            * собственно решить проблему
                            * утрясти при этом взаимоотношения людей
                            * выяснить как сделать, чтобы проблема не повторялась

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

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

                                И мое мнение — никаких монеток. Цитируя Шекспира с переводе Пастернака: "… Так погибают замыслы с размахом, в начале обещавшие успех..." Я к тому, что видеть, как решается результативность твоей работы монеткой — не самое приятное.

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

                                  С другой, стороны раз люди (да еще и 2 разные команды!) этим занимались, то, скорее всего, автоматизации действительно не хватает.
                                  Значит, можно попробовать вычленить проблему которую пытались решить команды автоматизацией и ОФИЦИАЛЬНО выделить ресурсы для ее решения. При этом к официальному решению проблемы нужно привлечь обе команды (ключевых людей причастных к автоматизации). Если все пройдет хорошо, то в результате обе команды будут довольны тем что их (уже) общее решение теперь выполняется на регулярной основе и выделенном железе, а также получат неоценимый урок о том как правильно продавать идеи наверх чтобы не делать их «втихую» на практике.

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

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