Друзья, ну что ж, раз первый кейс получил свои 15 минут внимания плюсов, то продолжим.
Года четыре назад проводили мы в Москве третий семинар из нашей серии тогдашних семинаров. Чтобы разнообразить программу, мы решили выделить пару часов на разбор кейсов участников. Поскольку участников собралось человек 40, то понятно, что все кейсы тут не разберешь. Поэтому была наведена специальная демократия: сбор кейсов, голосование, подсчет результатов авторитетной комиссией в лице нас со slavapankratov.
В итоге, в топ самых интересных кейсов попала следующая ситуация. Кейс реальный, взят из реального опыта наших студентов:
Disclaimer от коллеги slavapankratov. Обращаем ваше внимание, что после того реальная ситуация, которая используется для проектирования кейса, обрабатывается тренером (обезличивается, обрастает формальными вводными, усиливается фактами, без которых ее решение было бы невозможно), она может приобретать «пластиковый вкус»: то есть может казаться несколько искусственной и придуманной. Разбор проблемной ситуации сам по себе всегда несет определенный процент искажений реальности, а кейс, как модель временного отрезка реального мира, может казаться искусственной и притянутой за уши. Предлагаем вам рассматривать эту ситуацию как учебный тренажер, а саму ситуацию как спарринг-партнера, который в отличии от боксерской груши может дать сдачи но при это в его задачи не входит нокаутировать тренирующегося.
Зачем мы сделали это вступление.
Любой тренер, если он ведет именно тренинги, а не просто читает кусок лекции или пересказывает заученный семинар, сталкивается с сопротивлением обучающегося. Как только реальный опыт студента попадает в ситуацию критической оценки тренером или группой, человек склонен его защищать. В прошлом исправить ничего нельзя, а признавать, что когда-то ранее ты был не прав, даже если это было давно и, казалось бы, уже не важно, мы не любим. Другими словами, если в учебной ситуации студент узнает себя и видит, что ранее он мог в подобной ситуации вести себя не самым логичным или эффективным способом, возникает защита: «Кейс какой-то, явно, неправильный» или «Да что могут они знать со своим кейсом о реальной жизни?!!» или (самое любимое для тренеров) «Это вы мне специально кривой кейс подсунули, чтобы поглумиться». Почему любимое? Это хороший маркер запустившейся рефлексии, внутреннего обсуждения в голове у студента. А рефлексия это первый шаг в обучении.
Так что если у вас в процессе рассуждений над решением этого кейса будут возникать подобные защитные реакции или просто желание поискать вокруг виноватых (в самом кейсе, в комментариях других участников или в словах авторов этого разбора) не стоит это в себе держать: просто пошла рефлексия. Наверное, мы натолкнули вас на мысль, что ранее в вашем опыте вы могли себя вести не совсем правильно. Поздравляем, вы включились в кейс, и процесс обучения запустился.
Поехали!
Есть проектная команда: программисты, тестировщики, аналитики и менеджер проекта, за которого мы предлагаем вам поиграть в этом кейсе. То есть, вам нужно будет спроектировать модель поведения менеджера проекта для устойчивого решения создавшейся ситуации.
Команда проекта ведет разработку большой ИТ-системы, которая поставляется заказчику месячными итерациями. То есть, перед началом каждого месяца, команда выбирает и оценивает тот объем работы, который она сможет поставить заказчику. В работы входит анализ требований на итерацию, разработка или доработка кода системы, тестирование новой версии системы, ее развертывание и конфигурирование на стенде заказчика. Первый день-два каждого месяца команда проводит за анализом и оценкой требований, которые могут быть разработаны и протестированы в срок 1 календарного месяца. Работа с заказчиком ведется около года, на текущий момент, с учетом государственных праздников и сезонов отпусков, заказчику было поставлено 10 версий продукта.
Заказчик не просто принимает промежуточную версию системы и ждет следующую, а использует поставленное ПО для автоматизации существенного участка бизнес-процессов. На инфраструктуре заказчика в системе находятся реальные данные. Если в процессе поставки, развертывания или эксплуатации новой версии системы возникают ошибки или задержки, работа большого подразделения компании заказчика теряет рабочее время примерно 300-400 пользователей.
Несмотря на отлаженную процедуру оценки объема итерации, команда проекта в 4 итерациях из 10 срывала сроки поставки новой версии продукта (от 1 до 4-5 рабочих дней). Причины срыва каждый раз разные: проблема с развертыванием и обновлением ПО на инфраструктуре заказчика; возникшие критические ошибки, которые повлекли исправления и повторную поставку; изменения в составе реализуемых требований и недооценка сроков на реализацию изменений. Какой-то одной системной проблемы на ретроспективе после «проблемных» поставок выявить не удалось. Последствия от срыва сроков для бизнеса заказчика также каждый раз разные: проблемой является простой подразделения заказчика, а не просто сам факт задержки даты поставки.
Последние 2 срыва сроков поставки случились подряд в двух месяцах один за одним. Срыв запуска новой версии на 3 дня привел к простою всех 400 сотрудников подразделения заказчика сроком на 3 дня. Разгневанный заказчик в ультимативной форме потребовал у руководства вашей компании принять меры по наведению порядка в проекте.
Технический директор компании, в которой работает проектная команда, вызвал главного героя кейса и донес до него следующее управленческое решение:
Если следующая итерация, в начале которой сейчас находится проект, будет сорвана по срокам, то с целью наведения дисциплины и создания показательного прецедента для других 15 проектных команд компании (всего в вашей компании работает более 1.000 сотрудников) из вашей команды будет уволена половина сотрудников, а проект будет переформатирован по составу людей и срокам будущих поставок.
Решение озвучено как окончательное. Технический директор, возможно под давлением в переговорах с представителем заказчика, пообещал выполнить это решение в случае срыва сроков поставки и отменить его уже не может.
Поставьте себя на место менеджера проектной команды, до которого было донесено такое управленческое решение со стороны его начальства, и попробуйте ответить на несколько вопросов:
1. Говорить или не говорить команде о решение руководства?
2.1 Если говорить, то что именно и какими словами говорить команде или отдельным ее членам?
2.2 Если не говорить команде, то каким будут ваши дальнейшие действия? Будете работать? Не будете? Как будете вести проект дальше? К каким последствиям может привести выбранная вами модель поведения?
Команда работает ровно. Явных аутсайдеров или звезд в команде нет. Предыдущие проблемы не несли системного характера. Ранее вы уже озвучивали команде, что срыв сроков может повлиять на будущее проекта: в практике вашей компании были депремирования сотрудников и увольнения как менеджеров, так и инженеров. Но срывы повторялись. Объяснения есть всегда. Ситуация не изменилась, и теперь заказчик решил надавить на компанию, услугами которой он пользуется.
Возьмите паузу. Подумайте спокойно столько, сколько нужно. Пропишите ваше решение и четко зафиксируйте ваше решение: говорить или не говорить команде про увольнение в случае срыва сроков итерации? Если вы решили «намекнуть» команде про последствия — пропишите формулировки и подумайте как они могут быть восприняты командой. Вы уже озвучивали эти замечания и ранее. Будут ли люди работать по-другому после ваших слов в этот раз?
[ПАУЗА ДЛЯ САМОСТОЯТЕЛЬНОЙ РАБОТЫ НАД КЕЙСОМ — ПУБЛИКОВАТЬ СВОЕ РЕШЕНИЕ В КОММЕНТАРИЯХ НЕ ОБЯЗАТЕЛЬНО, НО ВЫ, КОНЕЧНО, МОЖЕТЕ ЭТО СДЕЛАТЬ, ЕСЛИ ГОТОВЫ ПОКАЗАТЬ, КАК БЫ ВЫ РЕШИЛИ КЕЙС СЕЙЧАС И К КАКОМУ РЕШЕНИЮ ПРИШЛИ ПОСЛЕ РАЗБОРА КЕЙСА В ЭТОЙ СТАТЬЕ.]
Прежде чем предложить вам наш вариант решения, давайте еще раз вспомним, что мы находимся в рамках учебной модели, которая не может учитывать всех факторов, которые повлияют на устойчивость решения. В реальной жизни решение может оказаться как значительно проще, так и не реализуемым совсем.
Обычно «сферический менеджер в вакууме» является слугой трех господ:
Все эти вещи плотно связаны между собой. Если решение сделает хорошо бизнесу, но команда умрет, его выполняя, то что случится с репутацией менеджера? В глазах бизнеса все может быть хорошо, но в глазах команды… А рынок у нас ооочень маленький, после 5 лет работы во всех компаниях есть знакомые.
Если решение сделает хорошо команде, но при этом не будут учтены интересы бизнеса, то что случится с репутацией менеджера?
Вернемся к нашему кейсу. При проектировании решения мы пытаемся учесть наиболее очевидные факторы, которые влияют на устойчивость решения и могут привести к потере контроля над ситуацией. То есть неустойчивое решение, это решение в котором менеджер команды не сможет повлиять на ситуацию, она выйдет из-под его контроля и перейдет в фазу, которой менеджер допустить не хотел.
Говоря проще: оказавших перед поворотом за рулем автомобиля, водитель видит, что кривая покрыта льдом и решает что ему делать, чтобы вывести машину из поворота целой. Неустойчивым будет решение, которое приводит машину в кювет. Если водитель вводит машину в управляемый занос и красиво выводит машину из поворота, решение считается работающим, но применимым в ограниченном пространстве — водитель профессионал, готов действовать в подобной ситуации и неоднократно это делал. «Повезло», как вариант решения рассматривается как случайность.
Говоря условиями кейса — решение полететь к заказчику и путем шантажа или угроз убедить его отменить решение и повлиять на технического директора принимается как рискованное. «А у нас с ним замечательные отношения и бухаем вместе» — поправка, которой вы изменяете условия кейса и решаете его в своей реальности, а не в условиях нашего учебного тренажера.
При этом и мы со своей стороны можем случайно изменить реальность кейса своим вариантом решения или сделанными допущениями. Правила и для вас, и для нас. И мы, и вы вправе сказать, что решение вносит изменение в первоначальные условия кейса.
Готовы?
Мы приведем несколько совсем неустойчивых, на наш взгляд, решений, которые чаще всего звучат от студентов в тренингах и наших онлайн-программах. Разбирая эти ответы, мы, заодно, приведем примеры того, что называем «не устойчивое решение».
Пройдем по первой развилке дерева решений.
Аргументация разная: чтобы не сеять панику, чтобы никто не отвалился сам (как только узнает о нависшей угрозе), чтобы не возник раскол в команде (кого уволят?), чтобы никто не пошел вместо работы над своими задачами искать другую работу и так далее.
С точки зрения теории систем, менеджер принимает на себя риск решения «Не говорим», оставляет команду без информации и надеется (другого слова тут не подберешь) что «Все как-то рассосется.» А надежда — не самый устойчивый управленческий план…
Что чаще всего не учитывается при проектировании решения этого кейса?
Достаточно часто не рассматривается, что информации об угрозе увольнения станет известна команде в середине итерации. При этом, на самом деле, в реальном мире, модель которого мы все-таки рассматриваем, информация ходит по компании самыми неожиданными путями в дополнение к официальным: «Ты только никому… но вас скоро порежут, ты присмотри себе работу» (как вариант, люди работали или учились ранее вместе), «Слышал у вас скоро сокращения будут, может давай к нам в проект? Как раз вакансия открылась» (случай внутренней конкуренции за ресурсы между менеджерами одной компании), «Эти из проекта А совсем офигели с такими задержками! Уволю половину, если попробуют еще раз такое вымочить!» (рассерженный тех.дир по секрету кому-то из доверенных менеджеров или просто вблизи ушей посторонних: секретари, HR, просто проходящие по коридору люди из числа сотрудников).
Мы работаем в компаниях, которые представляют собой тарелку вермишели, где связи между людьми существуют независимо от штатного расписания и устными коммуникациями (ака сплетнями) управлять практически нет реальной возможности).
Что будет делать менеджер в ситуации, когда он не сказал команде о возможном увольнении, а информация просачивается в команду? Говорить, что не знал? Говорить, что скрыл, чтобы не сеять панику? Люди не могут жить в условиях неопределенности. И осознание того, что менеджер по причине не информированности или (что еще хуже!) осознанно скрыл от команды информацию об общей участи с большой долей вероятности рвет доверие команда-менеджер. Заканчивать проект и работать дальше в такой ситуации менеджеру будет очень и очень сложно.
Это не изменение условий кейса: мы не говорим, что обязательно узнают. Мы проверяем решение «Не говорить команде» на устойчивость. Устойчивость определяется возможностью ответить на вопрос «А что делать, если?» и иметь возможность продолжить реализацию решения в случае срабатывания подобного риска.
В чем могут быть риски этого варианта? В сериале «Интерны» была прекрасная серия, когда доктор Быков говорит 4 интернам: «В конце дня я уволю одного из вас. Я еще не решил кого. Ага, вот! Уволю того, то больше всех накосячит!»
Что происходит дальше? Дальше люди всеми способами пытаются оказаться в группе тех, кого карающая десница не коснется. В рабочую реальность приходят нерабочие игры: подставы, сознательное решение не делиться информацией с другими коллегами и т.д.
Будет ли в таких условиях итерация закончена в срок? Вряд ли. Люди думают не о том. как что-то сдать в срок. а о том, чтобы не оказаться в половине неудачников. Энергия направлена не туда.
Постойте, скажете вы. Не говорить нельзя. Говорить тоже нельзя. Как так-то? Где решение?..
В результате часового обсуждения с 40 менеджерами мы тогда пришли к следующему варианту, который до сих пор кажется нам самым устойчивым:
Шаг №1. На общем собрании с командой описать ситуацию. И сообщить, что если итерацию не сдадим. то уволят всех. И меня. как менеджера, в первую очередь.
Комментарий: не «половину команды», а всех. Чтобы не рождать «игр» в команде. Если кто-то где-то услышит, что уволнять вроде будут пол-команды, менеджер всегда может возразить: а по моим данным всех, по крайней мере, я точно уйду.
При этом, сама угроза увольнения может на разных людей повлиять по-разному. Кто-то может начать тут же искать работу, что повышает риск ухода человека в середине итерации. Поэтому нужен:
Шаг №2. Тут же на общем собрании сказать буквально следующее: «Я понимаю, что эта информация может быть воспринята по-разному. Если вы для себя решите уйти до конца итерации — большая просьба в течение ближайших 2-3 дней сообщите мне об этом. После нашей встречи я хотел бы с каждым из вас встретиться один на один, чтобы понять, что вы по этому поводу думаете».
Шаг №3, необходимый, чтобы вселить уверенность в сомневающихся. В конце общего собрания сказать: «Друзья, чтобы минимизировать риск нашего непопадания в сроки, я предлагаю целиться на 5 дней раньше. Просто чтобы подстраховаться. Более того, каждый день мы будем все вместе собираться и видеть общую картину как идем — успеваем или не успеваем».
Шаг №4. Провести встречи 1:1 с каждым членом команды. И если кто-то таки собрался уходить, то сообщить об этом через пару дней на всех, и еще раз собраться вместе и решить, как будем справляться без уходящих.
Успеет команда сдать релиз, не успеет — жизнь покажет. Но с точки зрения трех составляющих:
Это решение выглядит, пожалуй, самым устойчивым из всех вариантов. Вы можете сказать: постойте, так менеджеру что, нужно уметь врать? Ложь во благо? Может быть. По крайней мере, менеджер точно не знает, что случится, если проект не будет сдан в срок. И имхо иногда лучше сгустить краски и подстраховаться, тем более, что всегда есть возможность сказать, что у вас не было четкой уверенности, что уволят именно половину.
Ну что же, за нашими с вами плечами остался второй кейс. Будем рады услышать ваше мнение — как позитивное, так и конструктивное.
А мы параллельно с запуском закрытого кейс клуба «Системные люди» продолжим публикацию непростых ситуаций на Хабре.
Года четыре назад проводили мы в Москве третий семинар из нашей серии тогдашних семинаров. Чтобы разнообразить программу, мы решили выделить пару часов на разбор кейсов участников. Поскольку участников собралось человек 40, то понятно, что все кейсы тут не разберешь. Поэтому была наведена специальная демократия: сбор кейсов, голосование, подсчет результатов авторитетной комиссией в лице нас со slavapankratov.
В итоге, в топ самых интересных кейсов попала следующая ситуация. Кейс реальный, взят из реального опыта наших студентов:
Кейс «Уволим пол-команды»
Disclaimer от коллеги slavapankratov. Обращаем ваше внимание, что после того реальная ситуация, которая используется для проектирования кейса, обрабатывается тренером (обезличивается, обрастает формальными вводными, усиливается фактами, без которых ее решение было бы невозможно), она может приобретать «пластиковый вкус»: то есть может казаться несколько искусственной и придуманной. Разбор проблемной ситуации сам по себе всегда несет определенный процент искажений реальности, а кейс, как модель временного отрезка реального мира, может казаться искусственной и притянутой за уши. Предлагаем вам рассматривать эту ситуацию как учебный тренажер, а саму ситуацию как спарринг-партнера, который в отличии от боксерской груши может дать сдачи но при это в его задачи не входит нокаутировать тренирующегося.
Зачем мы сделали это вступление.
Любой тренер, если он ведет именно тренинги, а не просто читает кусок лекции или пересказывает заученный семинар, сталкивается с сопротивлением обучающегося. Как только реальный опыт студента попадает в ситуацию критической оценки тренером или группой, человек склонен его защищать. В прошлом исправить ничего нельзя, а признавать, что когда-то ранее ты был не прав, даже если это было давно и, казалось бы, уже не важно, мы не любим. Другими словами, если в учебной ситуации студент узнает себя и видит, что ранее он мог в подобной ситуации вести себя не самым логичным или эффективным способом, возникает защита: «Кейс какой-то, явно, неправильный» или «Да что могут они знать со своим кейсом о реальной жизни?!!» или (самое любимое для тренеров) «Это вы мне специально кривой кейс подсунули, чтобы поглумиться». Почему любимое? Это хороший маркер запустившейся рефлексии, внутреннего обсуждения в голове у студента. А рефлексия это первый шаг в обучении.
Так что если у вас в процессе рассуждений над решением этого кейса будут возникать подобные защитные реакции или просто желание поискать вокруг виноватых (в самом кейсе, в комментариях других участников или в словах авторов этого разбора) не стоит это в себе держать: просто пошла рефлексия. Наверное, мы натолкнули вас на мысль, что ранее в вашем опыте вы могли себя вести не совсем правильно. Поздравляем, вы включились в кейс, и процесс обучения запустился.
Поехали!
Ситуация
Есть проектная команда: программисты, тестировщики, аналитики и менеджер проекта, за которого мы предлагаем вам поиграть в этом кейсе. То есть, вам нужно будет спроектировать модель поведения менеджера проекта для устойчивого решения создавшейся ситуации.
Команда проекта ведет разработку большой ИТ-системы, которая поставляется заказчику месячными итерациями. То есть, перед началом каждого месяца, команда выбирает и оценивает тот объем работы, который она сможет поставить заказчику. В работы входит анализ требований на итерацию, разработка или доработка кода системы, тестирование новой версии системы, ее развертывание и конфигурирование на стенде заказчика. Первый день-два каждого месяца команда проводит за анализом и оценкой требований, которые могут быть разработаны и протестированы в срок 1 календарного месяца. Работа с заказчиком ведется около года, на текущий момент, с учетом государственных праздников и сезонов отпусков, заказчику было поставлено 10 версий продукта.
Заказчик не просто принимает промежуточную версию системы и ждет следующую, а использует поставленное ПО для автоматизации существенного участка бизнес-процессов. На инфраструктуре заказчика в системе находятся реальные данные. Если в процессе поставки, развертывания или эксплуатации новой версии системы возникают ошибки или задержки, работа большого подразделения компании заказчика теряет рабочее время примерно 300-400 пользователей.
Несмотря на отлаженную процедуру оценки объема итерации, команда проекта в 4 итерациях из 10 срывала сроки поставки новой версии продукта (от 1 до 4-5 рабочих дней). Причины срыва каждый раз разные: проблема с развертыванием и обновлением ПО на инфраструктуре заказчика; возникшие критические ошибки, которые повлекли исправления и повторную поставку; изменения в составе реализуемых требований и недооценка сроков на реализацию изменений. Какой-то одной системной проблемы на ретроспективе после «проблемных» поставок выявить не удалось. Последствия от срыва сроков для бизнеса заказчика также каждый раз разные: проблемой является простой подразделения заказчика, а не просто сам факт задержки даты поставки.
Последние 2 срыва сроков поставки случились подряд в двух месяцах один за одним. Срыв запуска новой версии на 3 дня привел к простою всех 400 сотрудников подразделения заказчика сроком на 3 дня. Разгневанный заказчик в ультимативной форме потребовал у руководства вашей компании принять меры по наведению порядка в проекте.
Технический директор компании, в которой работает проектная команда, вызвал главного героя кейса и донес до него следующее управленческое решение:
Если следующая итерация, в начале которой сейчас находится проект, будет сорвана по срокам, то с целью наведения дисциплины и создания показательного прецедента для других 15 проектных команд компании (всего в вашей компании работает более 1.000 сотрудников) из вашей команды будет уволена половина сотрудников, а проект будет переформатирован по составу людей и срокам будущих поставок.
Решение озвучено как окончательное. Технический директор, возможно под давлением в переговорах с представителем заказчика, пообещал выполнить это решение в случае срыва сроков поставки и отменить его уже не может.
Поставьте себя на место менеджера проектной команды, до которого было донесено такое управленческое решение со стороны его начальства, и попробуйте ответить на несколько вопросов:
Вопросы:
1. Говорить или не говорить команде о решение руководства?
2.1 Если говорить, то что именно и какими словами говорить команде или отдельным ее членам?
2.2 Если не говорить команде, то каким будут ваши дальнейшие действия? Будете работать? Не будете? Как будете вести проект дальше? К каким последствиям может привести выбранная вами модель поведения?
Дополнительные данные
Команда работает ровно. Явных аутсайдеров или звезд в команде нет. Предыдущие проблемы не несли системного характера. Ранее вы уже озвучивали команде, что срыв сроков может повлиять на будущее проекта: в практике вашей компании были депремирования сотрудников и увольнения как менеджеров, так и инженеров. Но срывы повторялись. Объяснения есть всегда. Ситуация не изменилась, и теперь заказчик решил надавить на компанию, услугами которой он пользуется.
Возьмите паузу. Подумайте спокойно столько, сколько нужно. Пропишите ваше решение и четко зафиксируйте ваше решение: говорить или не говорить команде про увольнение в случае срыва сроков итерации? Если вы решили «намекнуть» команде про последствия — пропишите формулировки и подумайте как они могут быть восприняты командой. Вы уже озвучивали эти замечания и ранее. Будут ли люди работать по-другому после ваших слов в этот раз?
[ПАУЗА ДЛЯ САМОСТОЯТЕЛЬНОЙ РАБОТЫ НАД КЕЙСОМ — ПУБЛИКОВАТЬ СВОЕ РЕШЕНИЕ В КОММЕНТАРИЯХ НЕ ОБЯЗАТЕЛЬНО, НО ВЫ, КОНЕЧНО, МОЖЕТЕ ЭТО СДЕЛАТЬ, ЕСЛИ ГОТОВЫ ПОКАЗАТЬ, КАК БЫ ВЫ РЕШИЛИ КЕЙС СЕЙЧАС И К КАКОМУ РЕШЕНИЮ ПРИШЛИ ПОСЛЕ РАЗБОРА КЕЙСА В ЭТОЙ СТАТЬЕ.]
Прежде чем предложить вам наш вариант решения, давайте еще раз вспомним, что мы находимся в рамках учебной модели, которая не может учитывать всех факторов, которые повлияют на устойчивость решения. В реальной жизни решение может оказаться как значительно проще, так и не реализуемым совсем.
Обычно «сферический менеджер в вакууме» является слугой трех господ:
- Бизнес — интересы заказчика, компании, руководства
- Интересы команды
- Собственные авторитет (неформальный и формальный) и репутация
Все эти вещи плотно связаны между собой. Если решение сделает хорошо бизнесу, но команда умрет, его выполняя, то что случится с репутацией менеджера? В глазах бизнеса все может быть хорошо, но в глазах команды… А рынок у нас ооочень маленький, после 5 лет работы во всех компаниях есть знакомые.
Если решение сделает хорошо команде, но при этом не будут учтены интересы бизнеса, то что случится с репутацией менеджера?
Пример из реальной жизни. Не так давно общались с участником нашей годовой программы, который в числе реальных перспектив рассматривал переход в другую компанию вместе со своей командой. Вне зависимости от ситуации, это очень неустойчивый шаг. Потому что собственники другой компании могут пойти на это, чтобы получить команду, но захотят ли они дальше работать с менеджером, который уводит из компаний команды? Большой вопрос...
Вернемся к нашему кейсу. При проектировании решения мы пытаемся учесть наиболее очевидные факторы, которые влияют на устойчивость решения и могут привести к потере контроля над ситуацией. То есть неустойчивое решение, это решение в котором менеджер команды не сможет повлиять на ситуацию, она выйдет из-под его контроля и перейдет в фазу, которой менеджер допустить не хотел.
Говоря проще: оказавших перед поворотом за рулем автомобиля, водитель видит, что кривая покрыта льдом и решает что ему делать, чтобы вывести машину из поворота целой. Неустойчивым будет решение, которое приводит машину в кювет. Если водитель вводит машину в управляемый занос и красиво выводит машину из поворота, решение считается работающим, но применимым в ограниченном пространстве — водитель профессионал, готов действовать в подобной ситуации и неоднократно это делал. «Повезло», как вариант решения рассматривается как случайность.
Говоря условиями кейса — решение полететь к заказчику и путем шантажа или угроз убедить его отменить решение и повлиять на технического директора принимается как рискованное. «А у нас с ним замечательные отношения и бухаем вместе» — поправка, которой вы изменяете условия кейса и решаете его в своей реальности, а не в условиях нашего учебного тренажера.
При этом и мы со своей стороны можем случайно изменить реальность кейса своим вариантом решения или сделанными допущениями. Правила и для вас, и для нас. И мы, и вы вправе сказать, что решение вносит изменение в первоначальные условия кейса.
Готовы?
Мы приведем несколько совсем неустойчивых, на наш взгляд, решений, которые чаще всего звучат от студентов в тренингах и наших онлайн-программах. Разбирая эти ответы, мы, заодно, приведем примеры того, что называем «не устойчивое решение».
Пройдем по первой развилке дерева решений.
Вариант №1. Команде не говорится про последствия.
Аргументация разная: чтобы не сеять панику, чтобы никто не отвалился сам (как только узнает о нависшей угрозе), чтобы не возник раскол в команде (кого уволят?), чтобы никто не пошел вместо работы над своими задачами искать другую работу и так далее.
С точки зрения теории систем, менеджер принимает на себя риск решения «Не говорим», оставляет команду без информации и надеется (другого слова тут не подберешь) что «Все как-то рассосется.» А надежда — не самый устойчивый управленческий план…
Что чаще всего не учитывается при проектировании решения этого кейса?
Достаточно часто не рассматривается, что информации об угрозе увольнения станет известна команде в середине итерации. При этом, на самом деле, в реальном мире, модель которого мы все-таки рассматриваем, информация ходит по компании самыми неожиданными путями в дополнение к официальным: «Ты только никому… но вас скоро порежут, ты присмотри себе работу» (как вариант, люди работали или учились ранее вместе), «Слышал у вас скоро сокращения будут, может давай к нам в проект? Как раз вакансия открылась» (случай внутренней конкуренции за ресурсы между менеджерами одной компании), «Эти из проекта А совсем офигели с такими задержками! Уволю половину, если попробуют еще раз такое вымочить!» (рассерженный тех.дир по секрету кому-то из доверенных менеджеров или просто вблизи ушей посторонних: секретари, HR, просто проходящие по коридору люди из числа сотрудников).
Мы работаем в компаниях, которые представляют собой тарелку вермишели, где связи между людьми существуют независимо от штатного расписания и устными коммуникациями (ака сплетнями) управлять практически нет реальной возможности).
Что будет делать менеджер в ситуации, когда он не сказал команде о возможном увольнении, а информация просачивается в команду? Говорить, что не знал? Говорить, что скрыл, чтобы не сеять панику? Люди не могут жить в условиях неопределенности. И осознание того, что менеджер по причине не информированности или (что еще хуже!) осознанно скрыл от команды информацию об общей участи с большой долей вероятности рвет доверие команда-менеджер. Заканчивать проект и работать дальше в такой ситуации менеджеру будет очень и очень сложно.
Это не изменение условий кейса: мы не говорим, что обязательно узнают. Мы проверяем решение «Не говорить команде» на устойчивость. Устойчивость определяется возможностью ответить на вопрос «А что делать, если?» и иметь возможность продолжить реализацию решения в случае срабатывания подобного риска.
Вариант №2. Сказать команде: «Если не справимся, половину разгонят».
В чем могут быть риски этого варианта? В сериале «Интерны» была прекрасная серия, когда доктор Быков говорит 4 интернам: «В конце дня я уволю одного из вас. Я еще не решил кого. Ага, вот! Уволю того, то больше всех накосячит!»
Что происходит дальше? Дальше люди всеми способами пытаются оказаться в группе тех, кого карающая десница не коснется. В рабочую реальность приходят нерабочие игры: подставы, сознательное решение не делиться информацией с другими коллегами и т.д.
Будет ли в таких условиях итерация закончена в срок? Вряд ли. Люди думают не о том. как что-то сдать в срок. а о том, чтобы не оказаться в половине неудачников. Энергия направлена не туда.
Вариант №3. Есть ли он?
Постойте, скажете вы. Не говорить нельзя. Говорить тоже нельзя. Как так-то? Где решение?..
В результате часового обсуждения с 40 менеджерами мы тогда пришли к следующему варианту, который до сих пор кажется нам самым устойчивым:
Шаг №1. На общем собрании с командой описать ситуацию. И сообщить, что если итерацию не сдадим. то уволят всех. И меня. как менеджера, в первую очередь.
Комментарий: не «половину команды», а всех. Чтобы не рождать «игр» в команде. Если кто-то где-то услышит, что уволнять вроде будут пол-команды, менеджер всегда может возразить: а по моим данным всех, по крайней мере, я точно уйду.
При этом, сама угроза увольнения может на разных людей повлиять по-разному. Кто-то может начать тут же искать работу, что повышает риск ухода человека в середине итерации. Поэтому нужен:
Шаг №2. Тут же на общем собрании сказать буквально следующее: «Я понимаю, что эта информация может быть воспринята по-разному. Если вы для себя решите уйти до конца итерации — большая просьба в течение ближайших 2-3 дней сообщите мне об этом. После нашей встречи я хотел бы с каждым из вас встретиться один на один, чтобы понять, что вы по этому поводу думаете».
Шаг №3, необходимый, чтобы вселить уверенность в сомневающихся. В конце общего собрания сказать: «Друзья, чтобы минимизировать риск нашего непопадания в сроки, я предлагаю целиться на 5 дней раньше. Просто чтобы подстраховаться. Более того, каждый день мы будем все вместе собираться и видеть общую картину как идем — успеваем или не успеваем».
Шаг №4. Провести встречи 1:1 с каждым членом команды. И если кто-то таки собрался уходить, то сообщить об этом через пару дней на всех, и еще раз собраться вместе и решить, как будем справляться без уходящих.
Успеет команда сдать релиз, не успеет — жизнь покажет. Но с точки зрения трех составляющих:
- Бизнес
- Команда
- Авторитет и доверие
Это решение выглядит, пожалуй, самым устойчивым из всех вариантов. Вы можете сказать: постойте, так менеджеру что, нужно уметь врать? Ложь во благо? Может быть. По крайней мере, менеджер точно не знает, что случится, если проект не будет сдан в срок. И имхо иногда лучше сгустить краски и подстраховаться, тем более, что всегда есть возможность сказать, что у вас не было четкой уверенности, что уволят именно половину.
Ну что же, за нашими с вами плечами остался второй кейс. Будем рады услышать ваше мнение — как позитивное, так и конструктивное.
А мы параллельно с запуском закрытого кейс клуба «Системные люди» продолжим публикацию непростых ситуаций на Хабре.
