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