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

Три года назад волею судеб оказался в одном поволжском городе с корпоративным тренингом. Тогда впервые узнал, что люди в ИТ компаниях могут приходить на работу к 8:30, и тогда же у меня случилась история, с которой больше никогда не сталкивался — ни до, ни после.
Взрослые люди, как известно, учатся на получении конкретного опыта. Собственно, теоретик образования Дэвид Колб на эту тему даже придумал цикл имени себя, который лежит в основе многих семинаров и тренингов. Поэтому в стандартном тренерском чемоданчике находится несколько десяткой упражнений и кейсов, основная цель которых — сделать так, чтобы у слушателей что-то не получилось или получилось не до конца. Делается это не с целью поглумиться над слушателями (хотя некоторые тренеры не упускают этой возможности), но основная цель — запустить рефлексию и вместе прийти к нужным концепциям и моделям, чтобы потом опробовать и закрепить их на практике.
Так вот, на том тренинге в поволжском городе в группе нашелся один слушатель (назовем его Никита), который все задания щелкал как орешки. При этом Никита не был менеджером. Но это не мешало ему из раза в раз предлагать правильные, устойчивые решения непростых ситуаций. Сидящие рядом действующие менеджеры ошибались как надо, а Никита решал все — машина-решатель.
К концу первого дня я уже сгорал от нетерпения узнать, что происходит! Может быть, человек долго работал генеральным директором и потом вернулся в инженеры? Ну, так не бывает — нельзя не имея опыта, решать сложные управленческие задачи.
Как выяснилось за вечерним пивом, Никита издавна играет в World of Warcraft (могу напутать, поскольку не специалист в играх, по-моему, это был таки Warcraft). Причем играет на серверах, где люди объединяются в большие команды. Выяснилось, что Никита продолжительное время руководит очень большой группой игроков. Убеждает объединяться в какие-то группы, решает конфликты, принимает решения и т.д. Поскольку продолжается это уже много лет, то человек просто наработал практику принятия управленческих решений — не на работе, а в игре.
Меня постигло жестокое разочарование. Я практически уже открыл таблетку, как стать опытным управленцем, и на тебе — опять многолетняя практика, опять надо работать. С другой стороны, эта история еще раз подтвердила мысль Капитана Очевидности, что научиться можно на кошках. Главное — делать это регулярно. Поехали!

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

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

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

У главного руководителя тестирования (назовем его Сергей) тут же приключилась головная боль, чьи скрипты выбрать, чтобы никого не обидеть. По сути скрипты делали одно и то же. Но поскольку проактивность и нанесение пользы как раз учитывалось на грядущей аттестации, то обе команды хотели получить плюс в графу «Проактивно сделанные задачи».
Хорошо, сказал Сергей, давайте сравним скрипты. А как сравнить? Нужны метрики. Команды начали обсуждать метрики и сравнивать скрипты. И за два дня не продвинулись в этом вопросе. Получалось, что по метрикам команды А побеждают их скрипты, по метрикам команды Б — их.
Происходило ровно то, что происходит, когда правила начинают придумываться после игры. Тебе хочется, чтобы по вновь выдуманным правилам побеждал ты. Если ты проигрываешь — очевидно, правила не справедливы и не учитывают какой-то ключевой вещи.
После двух дней ярких обсуждений Сергей принял волевое решение: скрипты одинаково хорошие, давайте их смержим (срастим, то есть). Тут нужно заметить, что скрипты команды А были написаны на Perl, скрипты команды Б на Shell-овских скриптах. Скрещивать ужа с ежом было доверено двум инженерам из каждой команды. Бедняги провели сутки на телефоне, чтобы сведенный дикобраз начал работать.
Что произошло дальше. Дальше скрипты передали команде Б на поддержку и забыли об этом страшном сне. Как выяснилось через полгода, инженер из команды Б вычистил оттуда все чужие куски кода («так проще поддерживать»).
По итогу: потеряно несколько дней работы инженеров и менеджеров, и де-факто все равно выбран один из двух вариантов.
Вопрос: как нужно было поступить руководителю тестирования Сергею в момент, когда команды принесли ему написанные скрипты?
(ДАЛЬШЕ НЕ СМОТРИТЕ, ПОКА НЕ ПРИДУМАЕТЕ СВОЕ РЕШЕНИЕ)
Кейс №1. Решение.
В свое время мне на глаза попалась отличная книга Роберта Таунсенда «Сломай систему! Лекарство от управленческой изжоги». Легендарный CEO компании Avis делился своим опытом в кратких заметках. Что довольно удобно, когда времени ни на что не хватает — а тут выкроил пять минут в укромном месте, сел и проникся управленческой мудростью господина Таунсенда.
Так вот в главе о принятии решений он писал: «Когда два ваших сотрудника приносят вам два решения одной и той же задачи, выберите чье-нибудь одно. В этом случае вы получите хотя бы одного человека, мотивированного к воплощению этого решения».
Что мог бы сделать руководитель тестирования Сергей в этой ситуации? Как нам кажется, есть четыре важных шага.
Шаг №1. Спросить: «Друзья, а кто будет поддерживать эти скрипты?» Все любят писать интересные программы, не все любят их поддерживать. Этим вопросом руководитель а) ввел бы принцип, по которому принимается решение и б) выбрал бы тех, кто готов на бОльшее, чтобы его решение было принято.
Как в старой истории, помните? Директору компании нужно выбрать, кого послать на конференцию. Желающих 10 человек, бюджет только на двоих.

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

Шаг №2 (если поддерживать скрипты готовы обе команды). Просто выбрать чьи-то одни — по подкидыванию монетки, например. Это тоже принцип. Но тем самым, он бы показал, что важны не только проактивность, но и скорость принятия решений и то, что работа и скорость получения результатов важнее разборок по поводу того, кому что зачтется.
Шаг №3. Объявить, что на аттестации зачет получат обе команды.
Шаг №4. Обсудить с командами, как сделать так, чтобы таких коллизий больше не возникало.
Как нам кажется, эти четыре шага могли бы а) сэкономить время на принятие решения б) сделали решение более устойчивым (ответственные за скрипты поддерживали бы написанный ими же код в) показали принцип принятия решения, чтобы минимизировать взаимные обиды и осадок от ситуации.
Если есть чем дополнить разбор этой ситуации, или аргументированно возразить — будем рады увидеть ваше мнение в комментариях. Если у вас была аналогичная ситуация на работе — поделитесь историей, вместе дополним кейс и базу его решений.
Если вы хотите анализировать такие ситуации чаще, и обсуждать их с мотивированными коллегами — мы приглашаем вас в наш Case-клуб Стратоплана.