• О чем говорят менеджеры

    Posted on March 2nd, 2011 Александр Орлов 13 comments

    В свое время Слава Панкратов устраивал у себя на сайте опрос что вам интересно на www.it4business.ru в 2011году, лидером получился раздел «Разбор управленческих кейсов».

    Мини-книжку “18 кейсов от Happy-PM.com” за прошедшие пару дней скачали около 2000 раз.

    Это нас натолкнуло на мысль записать небольшой подкаст на тему “О чем говорят менеджеры”. О чем говорят менеджеры? Да в общем, о том же самом, что и все остальные люди. Что, менеджер – не человек, что ли? :)

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

    На эту тему мы и записали подкаст – там несколько реальных историй, непростых историй для их героев:

    1. Про непрерывность бизнеса и сгоревший дата-центр

    2. Эксперимент с региональным офисом

    3. Open source для менеджера и команды

    4. Ловкие в общении ПМ-ы

    5. Невидимость отечественных менеджеров

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

    Подкаст получился коротким – мы снова превзошли себя и проговорили всего 17 минут. :) В силу этого он, возможно, получился немного сумбурным, будем работать над собой, если вообще идея кейсов в подкастах заживет.

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

    А мы через какое-то время разберем все ситуации и напишем, что мы думаем по их поводу.

     

    13 responses to “О чем говорят менеджеры”

    1. 1. Про непрерывность бизнеса и сгоревший дата-центр

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

    2. Про 40-летнего программиста:
      Конечно, это задача менеджера — сделать так, чтобы разработчик не делал ненужной работы.

      Более того, если разработчик делает ненужную работу порядка недели, непонятно, что за план разработки у его менеджера.

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

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

      Дальше, по поводу того, что менеджер сказал – “будешь программистом до 40 лет”. Так говорить, конечно, неправильно. Программистом быть не стыдно. И в 40 лет и в 50. И Джон Кармак это подтвердит. Надо что-то менять в голове.
      Не буду про это больше писать.

    3. По поводу “Регионального офиса”.
      Наверное, менеджеру стоило перед тем, как соглашаться – узнать о предполагаемых новых проектах, об их планах разработки. Посмотреть на их документацию, бизнес-планы, маркетинговые планы. Собственно, на основе этих планов уже и делать свой план по развитию нового офиса.

    4. По-поводу “40-летнего программиста”.
      Если предположить, что программист ничего не напутал, приняв задание согласно установленной процедуре, то возникшая проблема полностью на совести менеджера.
      Более того, становится ясно, что он вообще не контролировал, что и как делал разработчик.

      В создавшейся ситуации менеджер просто обязан взять вину на себя (тем более, что так оно и есть). Однако, скорее всего в его мозгу сидит парадигма “до 40 лет надо ОБЯЗАТЕЛЬНО выбиться в менеджеры, иначе жизнь не удалась”. А такие люди брать вину и ответственность на себя чаще всего избегают.

      Поэтому этот кейс не для программиста и менеджера, а скорее всего для руководства, которое сопоставив факты (“бесхозный” программист, “неконтролируемый” процесс разработки, непризнание вины за явный ляп менеджером, уход – предположим – ценного разработчика) должно было бы сделать выводы об уровне управленческих навыков менеджера.

    5. (облизываясь) ка-акие интересные кейсы! спасибо, Саша. Надо будет на досуге еще переслушать и поломать голову.

      По ходу – советую изготовить и выложить транскрипт – чтобы легче было анализировать и обсуждать эти ситуации. Может быть даже по отдельному посту на каждый кейс… по моим ощущениям, в письменном виде они не очень хорошо уложатся в формат 5-в-1.

    6. очень интересно, в самом деле!
      по 2-му кейсу “Региональный офис” – думаю, после сообщения о закрытии уже мало, что можно исправить…а вот при его открытии, региональный директор мог договориться о каких-то гарантиях для сотрудников, на случай закрытия (например о выплате выходного пособия). Ну и, разумеется, в процессе работы постараться стать “интересными и ценными”, например преобрести уникальную экспертизу, необходимую компании. При чем, обладать ею должен не один человек, а команда. Иначе выгоднее будет просто забрать в хед офис этого одного человека.

      по поводу кейса “об архитекторе, который всех подвел” – на мой взгляд тут 2 пути:
      а) бюрократический – нужно было при заключении контракта с сотрудником обсудить, что он обязан сообщать об уходе заранее и до ухода закончить все текущие таски, а в противном случае несет материальную ответственность
      б) человеческий – раз уж человек “подостыл” к моменту визита к нему менеджера, то можно попросить его довести эту задачу, хотя бы удаленно и предложить оплатить это как разовую услугу. Раз ему неудобно, что он всех подвел, то думаю он согласится с радостью. И стороны расстанутся по-хорошему.

      кейс “40-летний программист”: ну во-первых, такое впечатление, что программист “вещь в себе” – он всю неделю ничего вокруг не видел и не слышал?
      во-вторых, менеджер не довел до ведома сотрудника изменения документации и за неделю не узнал статус таска?
      решения тут такие: либо проводить статус митинги, либо письменно сообщать команде об изменениях, либо ввести правило каждое утро скачивать себе новую версию документации, если работаете с ней локально.
      пост-фактум ошибка – нельзя говорить людям нечто типа “будешь плохо кушать – не выростешь”. нужно понимать, что это чревато именно такими последствиями.
      лучше бы было договориться с ним “это наш общий провтык и давай придумаем как решить эту проблему”

    7. (переслушавши запись)

      …по отдельному посту на каждый кейс… по моим ощущениям, в письменном виде они не очень хорошо уложатся в формат 5-в-1…

      …хм а впрочем почему бы нет? Если рассматривать истории именно как все-в-1, то похоже, что все они связаны с управлением рисками. Выявление рисков, анализ и оценка, страхование, планирование, извлечение бенефитов из рисков (да-да, бенефитов – “кто не рискует, тот не пьет щампанское”). В общем, управление.

      Итак, посмотрим на наши истории в перспективе управления рисками…

      1. Про непрерывность бизнеса и сгоревший дата-центр

      Учим риск-менеджмент, раздел basics. Идентификация рисков, рассмотрение worst-case сценариев, негативное и стресс-тестирование. Ну и учим стандартные хорошо известные методы управления рисками, имя им легион. Например ACAT – Avoid, Control, Accept, Transfer.

      2. Эксперимент с региональным офисом

      Не стоит пренебрегать трекингом риска в долгосрочных проектах. В начале проекта риск по определению высок – это тривиально. Менее тривиально то, что со временем риск не обязан автоматически уменьшаться, на что похоже рассчитывал персонаж этой истории (случайно не директор ли киевского офиса Яндекса?).

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

      3. Open source для менеджера и команды

      Apache Harmony – рискованный проект. Не из-за того, что опен сорс, а из-за того, что для спонсора (Интела) не было в нем перспективы получения надежной и/или быстрой прибыли. Таких проектов в “богатые времена” бывает немало, и большинство из них подозреваю вовсе даже не open source. И… таки да, если наступают проблемы, то такие проекты первыми идут под нож. Не глядя, опен сорс там или нет.

      Как управлять этим риском? ну, простой способ это подстраховаться планом Б – с переходом на менее рискованный проект. А еще можно попробовать извлечь пользу из риска. Например, написать за один уик-енд работающий garbage collector для той же самой Гармонии, а если окажется что компания-”чиподел” не оценила тебя как программиста, уйти из нее нафиг в Google. Заметим, что поскольку это опен сорс, то ты можешь просто снабдить свое резюме публично доступными ссылками на твой код – и если ты хороший кодер, это будет ОЧЕНЬ сильным козырем при устройстве на другую работу (вариант для резюме тестера – публичные ссылки на открытые тобой баги, для менеджера – на выпущенные при твоем участии релизы).

      Замечу, что и план Б – ну то есть уход на менее рискованный проект – тоже может оказаться выгодным, если грамотно планировать. Например, можно уйти из той же Гармонии и переключиться на написание кодеков. И если у тебя это хорошо получается, то ты станешь по существу “неприкасаемым” – потому что компанию-”чиподела” без хороших кодеков очень быстро сожрут конкуренты, и руководство это отлично понимает.

      4. Ловкие в общении ПМ-ы

      Типовая ошибка – пропущена идентификация стандартного риска. Не, ну на поверхности ситуация выглядит нестандартно – человек неожиданно сорвался, ах как внезапно! На самом деле, такую же проблему в проекте можно получить и без экзотики – тот же человек может например совершенно обыденно заболеть. Или уйти в Интел на в 5 раз большую зарплату. Это совершенно типичный риск в софтверных проектах и думаю есть смысл поучить знания накопленные на эту тему за последние 10-20-30 лет, чтобы понимать как с этим жить (а ведь все так живут и – нормально!)

      История без номера. “40-летний программист”

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

      Меня пожалуй печалит только то, что ни менеджер, ни разработчик, ни тестеры не смогли распознать в этой истории совершенно штатную ситуацию agile/iterative процесса разработки. Ну да, спецификация меняется – это не повод нервничать, есть куча хорошо известных способов, как с этим жить и работать.

      5. Невидимость отечественных менеджеров

      Риск, который можно было бы легко идентифицировать… если конечно заниматься идентификацией рисков. Работаешь в удаленном небольшом филиале, на не очень приоритетных проектах – значит, ты в первых кандидатах на сокращение. И методы страхования/профилактики достаточно очевидны. Поплотнее работать с головным офисом, завязывать там связи и поднимать визибилити, протискиваться в ключевые проекты и так далее.

      По ходу, стоит все же иметь в виду, что 100% гарантии безопасности не бывает, и plan B не повредит никому. Ты можешь работать в Самом Головном Офисе, быть лепшим другом Самого Большого Начальника и изобретателем Самого Главного Проекта Компании, но в какой-то момент все равно оказаться эгм on a new road (есть примеры)

    8. поглядел тут некоторые комментарии на кейс про 40-лет-программиста. “Не могу молчать” :)

      …от разработчика обязательно нужна в этом случае обратная связь…

      …“неконтролируемый” процесс разработки…

      …проводить статус митинги, либо письменно сообщать команде об изменениях…

      Хм вслепую применять в таких случаях накатанные менеджерские шаблоны может быть эгм неоптимально.

      Скажем, если спецификация меняется часто, но понемногу, то стоит рассмотреть минимум две опции:
      1. Дать человеку поработать какое-то время спокойно (примирившись с тем, что какая-то часть его работы за неделю увы устареет)
      2. Непрерывно дергать разработчика апдейтами и ежедневным контролем

      В чем тут дело? да все в том же риск-менеджменте. Стоит иметь в виду, что “слишком плотный контроль”, увы, включает в себя риск – риск снижения продуктивности программиста.

      Попросту говоря, выбрав опцию 1 выше, можно ожидать, что программист за неделю сделает скажем 100% “старой” спецификации, из которой ай-яй-яй процентов 10-20 устареют (см выше “если спецификация меняется часто, но понемногу“). Иными словами, по этой опции можно получить 80-90% от новой спецификации. А вот опция 2, она конечно гарантирует, что не будет устаревшей функциональности, но вот “новая” вполне возможно будет реализована всего на четверть – на треть.

      Теперь осталось только сравнить 80-90% в первом варианте против 25-30% во втором и выбрать, что нас больше устраивает. :)

      Тем, кому интересно, как может получиться указанная выше 3-4-кратная разница в продуктивности, рекомендую прочесть Не будите программиста!. По ходу это еще и замечательное противоядие от штампов, прививаемых на некоторых менеджерских тренингах по communication skills. Ах я его вусмерть закоммуницирую и ух, как нам будет хорошо. Ага, щазз.

      …такое впечатление, что программист “вещь в себе” – он всю неделю ничего вокруг не видел и не слышал?

      Ну да, а что? Большинство моих знакомых программистов наиболее продуктивны, когда работают именно в таком режиме.

    9. [quote]А вот опция 2, она конечно гарантирует, что не будет устаревшей функциональности, но вот “новая” вполне возможно будет реализована всего на четверть – на треть.[/quote]
      т.е Вы хотите сказать, что 15-20 мин в день, потраченные на скачку новой версии\чтение 1 письма\статус митинг уменьшит эффективность коддинга на 70-75%?
      кроме того, не могу согласиться, что это хороший вариант – дать человеку задачу и забыть о нем пока сам не прийдет с результатом.

    10. 15-20 мин в день говорите?

      Ну, например, если эти 15-20 минут разбиты на 20 раз по минуте, то вполне реально падение производительности и на 70-75%. Если разбиты на 5-10 раз, то падение продуктивности вполовину вполне реально (проверял на себе, ну и на других тоже). Если непонятно, как это получается, могу только еще раз посоветовать почитать “Не будите программиста”. Цитирую,

      …Это вам со стороны кажется что вы просто подошли и спросили который час.

      А давайте я вас подойду и спрошу в три часа ночи который час?
      Чего страшного-то? Ну и что такого что вы только что заснули?
      Я просто спрошу, вы ответите и спите дальше. Чего такого-то?

      Так легче понять я думаю будет. На таком примере.

      Вот вы представляйте что от вашего сна зависит ВСЁ! Всё при всё. Вот от того как вы сегодня поспите зависит будет завтра чего дома жрать или нет. Зависит будет ваша дочть замужем или нет. Вырастет ваш сын неудачником или добьётся чего-то в жизни. Всё это зависит от того как продуктивно вы сегодня поспите.

      Представили?

      И вот вы собираетесь начать этот сон. Этот вот самый сон от которого ВСЁ зависит и вы это отчётливо осознаёте.

      Скажите вот теперь. Как насчёт спать и одновременно немножко, краем глаза разговаривать, чуть чуть помогать сыну решать арифметику, немножко подглядывать в телевизор и чуть чуть так совсем немного съездить в магазин? Не на долго…

      Как спится, сладко?

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

      Вы бы так смогли КАЖДЫЙ ДЕНЬ?

      По ходу вопрос – считаете ли Вы, что проанализировать и применить в коде типичный апдейт спецификации включает в себя только скачку новой версии\чтение 1 письма\статус митинг и занимает 15-20 минут?

      “…не могу согласиться, что это хороший вариант – дать человеку задачу и забыть о нем пока сам не прийдет с результатом.” Полностью подписываюсь – забыть о человеке пока он сам не придет с результатом это не хороший вариант. А уж раз речь идет о программистах, тем более – это просто крайне рискованный вариант.

    11. [...] подкасте «О чем говорят менеджеры», мы со Славой Панкратовым подняли несколько [...]

    12. “Полностью подписываюсь – забыть о человеке пока он сам не придет с результатом это не хороший вариант. А уж раз речь идет о программистах, тем более – это просто крайне рискованный вариант.”

      вот это и была моя главная мысль :) коммуницировать надо и достаточно много и плотно! ну разумеется соблюдая баланс.

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

      1. Про непрерывность бизнеса и сгоревший дата-центр
      В бизнесе менеджеры часто не работают с рисками. И тем более не помнят прописной истины: не клади все яйца в одну корзину (народная пословица). Это значит, что не стоит концентрироваться на одном направлении – работайте в нескольких. Если одно из направлений “сдохнет”, то удар будет не такой серьезный при наличии других источников дохода.
      Здесь риски не учли владельцы ЦОДа (обычно где-то относительно далеко строится резервный ЦОД и осуществляется их распараллеливание для обеспечения отказоустойчивости), владельцы бизнес-системы (зачастую не стоит полагаться на одного поставщика вычислительных мощностей) и потребители сервисов бизнес-системы (всегда готовь план действий на случай форс-мажора – бэкапы данных никто не отменял в случае отказа системы или перехода к другому поставщику услуг).

      2. Эксперимент с региональным офисом
      Руководитель регионального офиса – достаточно неопытный менеджер. Открытие нового офиса – это проект. У проекта должны быть результаты. Заказчик всегда должен иметь понимание, по каким критериям он будет оценивать эффективность проекта. Вот и получилось, что менеджер не выполнил своих обязанностей, когда не спросил при найме, что хочет в результате получить заказчик и по каким критериям он будет оценивать результаты проекта.

      3. Open source для менеджера и команды
      Проекты типа Open Source в основном для коммерческих организаций предназначены для проработки новых технологических или бизнес-решений, а так же для работы над положительным имиджем компании. Зачастую компании на базе Open Source проектов строят расширения, которые превращают в коммерческие продукты (продажи дополнительных сервисов, показ рекламы и т.п.). Вполне понятно, что финансирование этих проектов идет из общей прибыли компании от коммерческой деятельности. Если прибыль снижается, то первыми под нож попадают проекты с туманной перспективой коммерческой отдачи, а потом проекты, потенциально важные, но убыточные или не приносящие прибыли.
      Что касается работы в проектах Open Source, то любой человек, идя в такой проект, должен понимать, что его рабочее место менее стабильно, чем в коммерческом проекте. При этом ему необходимо понимать, какие перспективы есть у проекта в долгосрочной перспективе. Только после этого можно определить для себя, стоит ли идти.

      4. Ловкие в общении ПМ-ы
      С архитектором произошла распространенная ошибка, которая стала началом крутого пике. Менеджер не обеспечил обратной связи с участниками проекта. Еще при выполнении работ сотрудниками необходимо регулярно работать со всеми членами проектной команды, понимая их уровень внутренней мотивации, работая с проблемами на ранних этапах их возникновения. Почему нельзя было регулярно встречаться в курилке или на ежедневных встречах и в относительно неформальной обстановке интересоваться о различных трудностях? Ведь намного проще решить проблему в самом начале ее проявления, чем ждать нарыва и острого разрешения проблемы. Поговорив с архитектором заранее, менеджер понял бы, что предстоит сдвиг окончания работ. При этом он мог бы организовать мозговой штурм из ключевых сотрудников в помощь архитектору (не стоит забывать и про предварительную “обработку” архитектора, чтобы не обиделся – “лучше собраться всей командой, может кто и предложит что-то интересное, за что можно будет зацепиться и сдвинуться с мертвой точки”). Ну а если менеджер уже успел наступить на грабли, то в любом случае не стоит давить на человека, пусть даже и по неосторожности – будет только хуже. Если человек обиделся, то стоит как можно раньше “разгребать Авгиевы конюшни”, предлагаю совершенно разные варианты, не ограничиваясь на одном. Если уж не удалось вернуть человека в команду, то хотя бы обговорите с ним период времени, в течение которого он смог бы передать свои компетенции другим сотрудникам. При достаточно большом периоде и интенсивной работе с коллективом есть возможность исправить отношения и полноценно вернуть человека в коллектив, сохранив хорошие отношения в команде.
      С 40 летним программистом та же самая проблема – нет обратной связи. Если ситуация изменилась, то менеджер обязан удостовериться, что все члены команды получили изменения, понимают их и дают свой фидбэк по ним. Возможны такие ситуации, когда какой-то член команды может сказать, что изменение описано не достаточно и требуется дополнительная проработка в таком-то направлении. Так же тут отражена ситуация, когда менеджер совершенно не работает с командой в плане развития – практически все оперируют работниками, как статичными единицами, а люди всегда хотят развиваться. Тут надо просто спрашивать, что интересно тому или иному сотруднику и давать в проекте новые некритичные задачи для развития. Естественно, что без работы с линейным руководителем так же не обойдешься – он тоже должен участвовать в развитии своих сотрудников.

      5. Невидимость отечественных менеджеров
      Здесь ситуация подобная “ловким менеджерам”, но в обратном направлении. Если в региональное подразделение прислали “разнорядку” на увольнение менеджеров, то плохо было поставлено информирование наверх о результатах деятельности. Впрочем это стандартная ситуация, когда отчетность может не учитывать оценку качества работы, а только финансовую часть. Если уж поступило такое “предложение” от руководства, то следует реально оценить ситуацию и понять, кто и какую отдачу дает, какие перспективы есть у каждого. После этого необходимо оценить, что произойдет с проектами при исключении каждого из менеджеров – может быть ситуация, когда в финансовом плане лучше оставить менеджера, чем тратить деньги на исправление ситуации в проектах. Ну а дальше следует трезво подойти ко всем оценкам и понять, требуются ли вообще сокращения, может можно оптимизировать процессы и сократить затраты на этом. Ну а дальше выходить к руководству с конкретными предложениями и реалистичной оценкой ситуации.

    Leave a reply

    You must be logged in to post a comment.