Теория большого провала [3/5]: как выглядит провал с точки зрения менеджера менеджеров

Напомним, мы решили разобрать большой кейс: http://blog.stratoplan.ru/the-theory-of-project-failure/
Большой проект, а точнее несколько проектов в аккаунте на 150-200 человек, 20 команд. Все начиналось хорошо, потом немного как-то средне, потом подкрался непонятный конфликт, который перерос в системное недовольство заказчика, что в конце-концов привело к остановке сотрудничества и штрафным санкциям.
Во второй части разбора http://http:/blog.stratoplan.ru/the-theory-of-project-failure-2/ мы немного увлеклись систематизацией того, «как бывает вообще», и ушли в сторону от анализа конкретной ситуации. Читатели нас в этом поправили — а что именно в этом кейсе было не так? Исправляемся и конкретизируем.
Напомним, что во второй части разбора мы углубились в историю того, как менеджеры становятся менеджерами и какие этапы становления и взросления они проходят.
Основных причин роста чаще всего встречается две:
1 руководитель проекта или команды уходит и ему нужна замена;
2 проект резко становится больше, может быть, выделяется новая команда, и руководитель рекомендует тебя на эту роль.
Времени на систематическую подготовку нового менеджера, обычно, нет или оно сильно ограничено.
Обратите внимание. Нам кажется, что именно тут кроется одна из системных причин того, что мы наблюдали со стороны в этой кейсе и видим так или иначе в тех компаниях, куда приходим как консультанты или тренеры.
И, конечно, так случается не везде, у всех и постоянно (как говорит Максим Дорофеев), а иногда и в конкретном случае.
Напомним достаточно часто встречающийся вариант развития событий и посмотрим, но уже с точки зрения менеджера менеджеров / руководителея группы проектов / руководителя 2-3 уровня (смотря как считать), какие ветки сценария «сработали» или какие риски «выстрелили» в этом конкретном кейсе.
Вспоминаем. Этап первый. Новый / неопытный менеджер, естественно хочет выглядеть менеджером опытным.
Не будешь же ты сразу «бегать» с вопросами к начальству? Что придаёт особой уверенности? Внедренные изменения твоего имени.
Эксперименты над командой и процессом. Инженерное прошлое склоняет к «проталкиванию» личных / авторских технических предпочтений. Попытки «отстоять территорию» перед заказчиком принимают вид «внедрения правильных архитектурных решений». Интересы и мнение команды отодвигается на второй план. Помните первую историю про взгляд со стороны инженеров? Некая «культура» невмешательства (все люди взрослые, у каждого своя зона ответственности) умножается на потерю сопричастности к общему делу. Если важные вопросы в проекте решаю не я, то почему весь проект в целом — мое детище и «дело моей жизни»?
Если с точки зрения менеджера менеджеров такое поведение нового руководителя проекта или команды трактуется как «активная менеджерская позиция» — он не будет вмешиваться в работу менеджера.
Как сказал нам один из руководителей группы проектов, в руководстве у которого было 6 менеджеров команд этого аккаунта: «Я же сам его только что назначил. Буду вмешиваться — сам же подрываю его авторитет на старте работы. Да и технически он ближе к команде и ещё помнит как там чего внутри технически устроено. Да, я видел, что он немного резковат на созвонах с заказчиком, но дело-то идёт? Заказчик особо не бунтует. Ок, значит, это его модель коммуникации, и она работает».
Что мы можем тут выделить из отмеченного в других проблемных проектах плюс к озвученному непосредственными «фигурантами дела»:
— Новый менеджер ещё не очень опытный переговорщик / коммуникатор и он «гнёт своё» в рабочих совещаниях: появляется недовольство заказчика, которое накапливается со временем;
— Менеджер менеджеров далеко не всегда успевает отследить все коммуникации нового руководителя + очень много чего остаётся в почте и мессенджерах (это вообще «слепая зона» контроля);
— Инженеры теряют сопричастность к проекту и склоняются к формальному отношению к делу: накапливаются незавершенные вовремя задачи, появляется отставание, переносы сроков (иногда, закреплённые методологически) становятся хроническими.
При этом, нового менеджера условно «никто не останавливает». Нельзя сказать, что вчерашний инженер похож на «чувствительный барометр», который ощущает начинающееся напряжение в отношениях с менеджерами заказчика. Системное напряжение растёт. Растет и уверенность менеджера, что он поступает правильно.
«Я видел, что не все расходятся с созвонов на подъёме, но я знаю, что так будет лучше. Даже если не все согласны сейчас, по факту будет лучше так, как я предлагаю, потом не будет лишних головняков на переделки». Почти дословная цитата из анкеты обратной связи менеджера, проект которого получил заказчиком оценку «неудовлетворительно» по итогу «разбора полетов».
Шаг в сторону: то что потом проблем не будет — это хорошо, но отсутствие проблем с той же архитектурой проекта потом — это результат ожидаемый, и вряд ли кто-то со стороны заказчика, через полгода после внедрения предлагаемого сейчас изменения свяжет у себя в голове неприятное совещание и «продавленное решение», с тем, что проблем нет. Нет и нет, это понятно. А вот то, что новый менеджер без опыта и авторитета «продавил» такое решение, отодвинув наши аргументы — это как раз запомнится…
Смена роли «инженер-менеджер» не случается моментально. Так же моментально не меняется и модель коммуникации. Опытный тех.лид за несколько лет привык, что его мнение внутри команды принимается большинством, может и вовсе не оспаривается. Потом он становится руководителем команды, его «выводят» на уровень общения с заказчиком — модель коммуникации, работавшая годами с «технарями», может оставаться прежней. Переход состоялся «де-юре», но не состоялся «де-факто» в голове человека, которого повысили и в его наблюдаемом поведении.
Отсутствие системной подготовки к повышению в менеджеры и контроля в процессе смены позиции — ситуация практически повсеместная. Случилась позиция — выбрали человека — дали повышение — иди работай. Будут сложности — приходи.
В конкретном анализируемом кейсе, подобное «попустительство» на этапе назначения нового менеджера было отмечено в 7 проектах, из которых 4 были указаны заказчиком после остановки работ как «проблемные».
Пойдём дальше.
Помните, мы отмечали как один из этапов становления менеджера «Конфликты в команде?»
Открытый конфликт с настоящими криками и воплями не так часто встречается. Согласны. Чаще конфликт протекает в «скрытом состоянии». В нашем разбираемом кейсе именно эта проблема не была отмечена своевременно руководителями групп проектов. Менеджеры менеджеров о конфликтных ситуациях, как о чём-то существенном, просто не знали.
А вот заказчик, опросив своих менеджеров, прямо указал на постоянные случаи «словесной агрессии» в рабочей переписке и отдельно отметил один случай, когда менеджер достаточно большой команды и технический лидер этой же команды умудрились откровенно переругаться прямо на совещании во время командировки в офис заказчика.
Казалось бы, ну бывает. Чего такого? Рабочий момент. У нас и не такое встретишь. Тем более в переписке. Зато команда у нас — профессионалы. Технологии разработки завтрашнего дня. Методологии, ого-го! Только этого всего, так же как и отличных архитектурных решений, от нас ждут «по умолчанию». Так и должно быть. По-крайней мере, на это заказчик рассчитывает, оплачивая счета. А ещё он рассчитывает, что его систему или проект, часть его Бизнеса(!), будут делать, как минимум, люди интеллигентные, профессиональные: то есть — грамотные, спокойные и уверенные в себе.
Нам не удалось пообщаться с представителями заказчика напрямую. Но руководители проектных групп, с точки зрения которых мы пытаемся сегодня посмотреть на ситуацию, согласились, что это постоянно так или иначе звучало со стороны заказчика.
Со слов руководителя группы проектов:
«Во время одной из неформальных встреч, когда технический директор Заказчика приезжал в наш офис, он достаточно вежливо заметил: «Когда я отдаю свою машину на обслуживание дилеру, я рассчитываю что ее будет обслуживать человек с чистыми руками, и никто в моей машине не будет грязно ругаться».
Я тогда понял, что он намекает на некоторых наших ребят, но не придал этому особого значения».
Что думает заказчик, когда видит неконструктивные споры в почте или на совещаниях?
«Если эти ребята, тим/тех лиды, руководители проекта, могут вести себя «так», то что же «там внутри», под этими ребятами за люди-то работают?»
Ушанки и телогрейки, конечно, далёкий от реальности стереотип, но…
А какой вывод он может сделать, когда без видимой для него причины, вдруг, переносятся сроки сдачи, реализуются устаревшие версии требований, вылазят непротестированные куски функционала? Вряд ли он думает: «Ну, наверное просто это уникальная техническая задача и повышенная цикломатическая сложность кода», верно?
«Руки надо мыть чаще, код ревью проводить и слушать доводы более опытных коллег» — более вероятная, на наш взгляд, цепочка рассуждений.
…
Сразу после первой серии разбора, мы получили много комментариев, которые сводились к тому, что среди озвученных проблем на уровне инженеров не были затронуты «настоящие» инженерные проблемы и проблемы с процессом разработки. Проблемы с требованиями, с согласованием приоритетов, с зажатыми сроками на исследование и так далее.
Может быть, сейчас это прозвучит немного обидно, но (несмотря на кажущуюся нам с вами серьезность этих аспектов разработки ПО), ни в этом конкретном случае, ни в случающихся время от времени разговорах с менеджерами, которых можно отнести к «Заказчикам», это не звучит вовсе или звучит крайне редко. Заказчика, который оплачивает счета, редко волнует сколько уровней приоритетов инцидентов / ошибок, мы настроили в трекинге или насколько строго мы следуем «духу» или «канону» скрама.
Так устроена память, скорее всего. Люди забудут что и как вы делали, скорее всего, даже не вспомнят дословно что вы говорили. Но вот что они чувствовали в тот момент по отношению к вам, они запомнят точно. Это накапливается и становится причиной серьезных проблем в проектах.
…
Этап №4 становления менеджера мы в предыдущей части разбора назвали «Начинаешь делать все сам».
И хотя в прошлый раз мы говорили о менеджерах проектов и команд, в этом конкретном случае, эта проблема неожиданно «выстрелила» и на уровне выше.
В одной группе проектов заказчик озвучил просьбу о смене менеджера команды. В письме фигурировала формулировка «Недостаточный социокультурный и профессиональный уровень руководителя команды» из-за которого, по мнению заказчика, команда систематически не укладывалась по срокам. В ответ на претензии других команд, менеджер никаких заметных вовне действий не предпринимал. Ситуация не улучшалась, заказчик попросил замену.
Мы сейчас не будем уходить на шаг назад и возвращаться к первой части разбора, указывая на «отстранённость» членов команды как одну из причин озвученного заказчиком решения (сроки, «грядка / огород», переносы — помните, да?). Сегодня, нам интересна реакция руководителя группы проектов, когда заказчик попросил заменить менеджера команды.
Он «вывел» менеджера из проекта (по договору заказчик имел право озвучить «замену»), но после этого взял команду в непосредственное руководство. То есть сам стал руководить и другими менеджерами и командой, которая осталась без руководителя. Когда на этапе разбора Заказчик указал на этот случай, руководитель группы проектов ответил, что хотел сам «выровнять» мнение заказчика о команде и вернуть к ней доверие. А кто ещё мог это сделать, после вывода менеджера из проекта по инициативе заказчика? «Начинаешь делать все сам», только на уровень выше.
Руководитель аккаунта об этой ситуации не знал. С точки зрения заказчика это выглядело как «Попытка на лету заткнуть дыру в составе проекта» и явный «Over staffing», то есть использование более квалифицированного сотрудника (руководителя группы проектов) для решения задач более низкого уровня сложности.
…
Ещё один шаг в сторону и время на подумать.
После первой и второй серии разбора мы услышали повторяющийся вопрос: «Так, а на что конкретно жаловался заказчик?!»
Обратите внимание. Дело не в сроках по конкретному проекту. И не в качестве поставляемого продукта. Недовольство росло в нескольких направлениях и «точки напряжения» появлялись не только и не столько в таких «привычных местах», как сроки / приоритеты. Чем глубже нам удавалось закопаться в эту историю (а мы не были «официальными» исследователями причин аварии, а собирали картину, просто общаясь с участниками событий после тренингов, во время рабочих совещаний, в телефонных разговорах с наиболее открытыми людьми в компании), тем более мы убеждались в верности старой мысли:
«Природа проблем в проектах имеет скорее социологическую природу, чем технологическую».
…
Не касаясь сегодня этапа номер шесть под кодовым названием «Дырка в голове: я — плохой менеджер», остановимся на этапе номер пять: «Прикрывание проблем»
Хочется выглядеть хорошим менеджером. А хороший менеджер — это, очевидно, тот, у кого все под контролем. У кого проект идет по плану. Поэтому на вопрос: «есть ли проблемы», ты смело говоришь: «нет». Потому что ты все еще надеешься, что сам вытянешь работу команды.
Помните?
Обвиняя менеджеров проектов или руководителей команд, мы часто забываем, что в основе ошибок управления, скорее всего, лежит неверная модель человеческого поведения. Если тебя наказывали за ошибки, ты эти ошибки прятал, скрывая последствия или откладывая неприятный разговор до последнего. Это черта человеческого поведения, и она не привязана к занимаемой эти человеком должности.
Мы не зря упомянули вскользь о том, что руководитель всего аккаунта из 150-200 человек и 20 проектных команд не знал о конкретной проблеме с заменой менеджера в одной из групп проектов. Прикрывание проблем случается не только на самом первом уровне менеджмента. Так случилось и здесь. Как показал внутренний разбор ситуации после остановки работ, два руководителя проектных групп не сообщали «наверх», руководителю аккаунта информацию о существующих в проектах проблемах. Ситуация с заменой менеджера команды на менеджера группы проектов была для руководителя аккаунта новостью. Одной из многих, за которыми скрывалось окончательное решение заказчика остановить работы.
…
Обращаясь к истории, подобную ситуацию описывал Эрик Шмидт, который когда-то пришёл в (давно почившую на сегодня), корпорацию Novell вытаскивать ее из системного кризиса.
Резюмируя, можно так выразить его мысль: у каждого отдельно взятого вице-президента все в порядке, у каждого руководителя департамента — тоже все хорошо. А в сумме корпорация находится в кризисе.
В нашем кейсе мы хотим показать помимо конкретных ошибок немного более обширную картину развития событий. Дело не только и не столько в инженерах, которые не вкладываются в сроки, или в менеджерах, которые не умеют с этим работать. Базовые технологические процессы создания программного обеспечения и управления проектами наладить можно. Ошибки управления накаливаются, но и с этим теория управления научилась справляться.
Накапливается какое-то системное возмущение, что ли. Когда условные «мы» и «они» работаем в реальной среде. В которой происходят реальные процессы. Кого-то назначают. Кого-то увольняют. Кто-то с кем-то по мелочи или не по мелочи не договорился и «злобу затаил». Потом, когда «вылазит» вполне обычная техническая проблема, то на неё все участники процесса, «отягощенные» предыдущим опытом общения, уже смотрят не просто как на «технический или процессный сбой», а как на продолжение собственного, сформировавшегося мнения: «А что ещё от них ожидать, если у них тех.лид в почте пренебрежительно отзывается о наших замечаниях, а менеджер проекта продавливает свой фреймворк, не вникая в суть проблемы».
У большого провала, как и большой победы, не может быть один отец / один виноватый. Большой провал — всегда «заслуга» большого количества людей.
Сегодня мы затронули ситуацию с уровня «менеджеров менеджеров» и хотим отметить, что руководители проектных групп тоже люди со своей историей вхождения в профессию. И точно так же, как их подчиненные, менеджеры, которых они назначают, могли не получить необходимой системной подготовки и поддержки на этапе transition (входа в должность). Их самих назначили в своё время менеджерами, условно «похлопав по плечу»: «Ну ты там это! Давай! Будут вопросы — приходи». И они как-то выплыли, выбрались из водоворота проблем и задач. Стали как-то руководить командой или проектом. Добились успехов и смогли получить следующую должность — стали руководить менеджерами или группой проектов. Теперь они так же назначают новых менеджеров. Так же «хлопают их по плечу» и надеются, что если будут проблемы, он, новый менеджер, сразу их распознает и придёт их конструктивно обсуждать и решать.
Как мы видим, надежда — не самый устойчивый менеджерский план.
Не переключайтесь 🙂
—
С уважением,
Школа менеджеров «Стратоплан»
Очередной набор стартует феврале 2018 — не пропустите самое интересное
http://http://stratoplan.ru/school/