Управление ожиданиями: точка зрения Эксперта

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

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

Я не удержался и повторю этот контент полностью тут. Каждому человеку, который работает с другими людьми (а особенно с менеджерами и Заказчиками) этот материал будет полезен (Attention: Многа хороших букоф!).

5 способов управления ожиданиями (by Михаил Завилейский)

Как оправдывать ожидания? Непростые правила…

Как говорит Ицхак Адизес, залог процветания компании – в долговременных отношениях с удовлетворенными клиентами, а как говорит Дэвид Майстер, удовлетворенные клиенты – это те, кто получают то, чего ожидают, или чуть больше ;). Таким образом, попадание в ожидания клиентов – это не просто важно, это самое важное, что есть в нашем бизнесе.

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

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

Что же делать? Конечно, надо умело управлять и ожиданиями, и восприятием клиента, вопрос только в том, как это делать. Как водится, простых правил нет, но есть разные способы, один из которых обычно помогает. Опишу основные известные мне, которые или использовал я сам, или другие использовали со мной. Начну с трех немного сомнительных и перейду к двум более симпатичным и одному великому и ужасному ;).

 Способ № 0 – «Все хорошо, прекрасная маркиза…»

Способ этот очень глупый с точки зрения большинства представителей IT-индустрии, но это от того, что особи с пониженной паранойей редко выживают в нашей среде. Однако нехватка коммуникабельных и позитивных персон часто выводит на передний край исполнителей данной техники, и она весьма распространена. Действительно, если все, что вызывает раздражение клиента, – это плохие новости, то не надо ему их сообщать. А если уж сообщать, то максимально приуменьшая их значимость, маскируя в этой области новостями и оптимистичными планами.

Опаздываем по расписанию? Ничего, конечно, нагоним потом! Работает медленно? Разгоним! Падает? Починим! А зато мы сделали суперфичу и применили вот такой архитектурный шаблон, что увеличит крутизну всего проекта на 50%!

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

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

 Способ № 1 – «Армейский»

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

Заказчик, конечно, не новобранец, но вот излечить его от паники при возникновении проблем можно и тренировками. Надо часто менять планы, устраивать показательные авралы и корректировки курса проекта с самого начала. И когда сложность системы возрастет, а подобные акции окажутся неизбежны, клиент уже будет «готов», приучен к циклу «проблема-активность-разрешение».
Такой подход требует определенного хладнокровия, исполнительского мастерства и ценностной пластичности. В норме никто не хочет напрягаться по своей воле раньше времени ради того, чтобы потом напрягаться уже не по своей воле минимально напрягая при этом заказчика ;). Так что обычно эта техника исполняется менеджером несколько «театрального» темперамента, и является манипуляцией по отношению к команде. В отношении клиента, это, кстати, манипуляцией не является – никакой материальной выгоды исполнителю или реального ущерба клиенту тут нет.
Рекомендовать такой подход я бы не стал совсем, но он, увы, как и армейские упражнения, довольно универсален. Даже с самым трудным клиентом он может принести пользу, а к несколько повышенному сверх необходимости уровню эксплуатации люди привыкают. Так что опять, если наблюдается такой расклад, надо оценить его осмысленность и гармоничность, и потом уже решать, что делать. На практике определяется все тем, у кого сила на в проекте и/или на рынке труда. Победить хорошего «сержанта» на его поле почти нереально, а дембель – неизбежен ;).

 Способ № 2 – «Волки, волки…»

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

Сложность с таким подходом даже не в исполнительском мастерстве. Люди часто склонны выбрать плохое, если верят что все так плохо, что другое и неизвестное еще хуже. Проблема в том, что проекты длятся долго, а эмоциональные и легкомысленные клиенты в IT встречаются редко. И мальчики, кричащие «волки-волки», теряют доверие. Их не пытаются переубеждать, просто записывают в пессимисты и начинают игнорировать их мрачные пророчества.

Так что техника плохо работает на долгосрочной перспективе, а на краткосрочной часто раздражает. А мы работаем с западной культурой, где позитивность мышления – must have. Но и тут есть ситуация, когда и этот способ применим.

Когда-то я прочитал, что депрессия – это такое полезное состояние, которое понижает планку наших ожиданий от мира так сильно, что любые изменения оказываются к лучшему. Так запускается цикл глубокой адаптации к реальности и устремления к новым достижениям. Так вот, в кризис часто можно не дожидаться, когда «нарыв созреет», а вскрыть его жесткими коммуникациями с элементами драматизма. И, захватив таким способом инициативу, указать новый путь к свету. Так что если кризис-менеджер пугает, а вам не прикольно, то можно это дело пропустить, и сразу включиться в конструктивную фазу. Она обязательно будет, вы это хорошо знаете, особенно если вы и есть тот самый кризис менеджер ;).

 Способ № 3 – Научный, или разговоры о статистике…

Проекты выполняются живыми людьми в изменчивой социальной и экономической среде. Изменчивость присуща всему живому. Но, когда болеет ребенок, первое желание – постоянно мерять температуру и регулярными порциями таблеток удерживать его температуру в состоянии нормы. Но вот только норма – это не 36.6 °С, это интервал шириной в градус и с индивидуальными границами. А если мы заранее индивидуальные измерения нормы не провели, то переживать надо, только если температура уж совсем высокая.

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

Тут важно не запутаться. Однородность – не есть стабильность, статичность. Ключевая заслуга статистического подхода как раз в признании изменчивости как нормы и умении реагировать только на действительно особенные ситуации. Среднее количество строчек кода может быть хорошей метрикой, но только на каком масштабе? Если в офисе отключают электричество то на час, то на день, надо усреднять за неделю. А за неделю изменится набор задач. Тогда за итерацию? Но у разных итераций разные задачи. Тогда за много итераций? Но новые много итераций – это уже новый проект и новые технологии. Каждый раз, когда меняются параметры среды, внутренней или внешней, нарушается однородность ряда измерений.

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

Потому применимость данного метода ограничена нашей способностью нащупать удачные метрики и договориться с заказчиком о совместной игре по таким правилам. Многие популярные методологии пытаются сделать процесс более плавным (continuous, если хотите), а значит более статистически измеримым. В общем случае измерять можно все, что можно измерять много чаще, чем изменяются макропараметры процесса, и заметно реже, чем изменяются микропараметры. Ежедневные билды, TDD, да весь agile, все методологии ITPM во многом про это… Но вся беда в том, что в сервисах далеко не везде правильный и измеримый процесс хорошо ложится на потребности заказчиков, которым нужно решение их проблем приемлемым для них способом, а совсем не «хороший софт», как удобно думать нам.

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

 Способ № 4 – Разговор о рисках

Разговор о статистике навевает скуку на многих менеджеров, не имеющих соответствующего образования. Однако тот же объект, но вид с боку, а именно – разговор о рисках, воспринимается куда легче. Все зрелые менеджеры знают, что риски есть всегда и ими нужно управлять. К сожалению, меньшее число знает, как управлять рисками, а еще меньшее умеет это делать. Однако разговор о рисках остается едва ли не лучшим соусом для цивилизованного управления ожиданиями.

Риски – это те самые маловероятные события из статистики, которые не вписываются в естественную изменчивость процесса и требуют корректирующих действий. Суть управления рисками – это своевременная и эффективная реализация этих самых корректирующих действий. Управление рисками держится на трех китах – ресурсы, идентификация и компетенции.

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

Идентификация рисков делится на предварительную и оперативную.

Предварительная идентификация рисков – перечисление предположений, которые мы использовали при планировании. Поскольку это предположения, они могут не оправдаться. Чем выше степень нашей неуверенности, тем выше соответствующий риск. Наиболее типичные предположения заключаются в том, что члены проектной команды не будут меняться и болеть, что требования будут стабильны, что платформы и компоненты будут работать так, как описано, что оборудование не будет ломаться и что свет в офисах отключать не будут, ни все такое. Очевидно, что на проекте длинной в месяц многое из перечисленного возможно, а на годовой перспективе случится обязательно. Из опыта (это важно, неуверенность – это статистический факт, не ощущение) мы можем оценить типичные вероятности и «взвесить» риски. Естественно, может случиться и что-то уж совсем непредвиденное – мировые кризисы, атаки террористов, массовое отравление команды пирожком и т.п. Но вероятность таких событий мала, и мы не можем ее измерить, а значит и не должны. И не стоит их включать в базовый риск-план проекта. Риски такого рода обычно адресуются макроуровнями, стоящими над проектом – организациями, индустрией, экономикой, всей цивилизацией, наконец.

Интересно, что исходные гипотезы при планировании иногда имеют совсем не высокую вероятность оправдываемости, но присутствуют повсеместно в силу этических соображений. Например, предположение об эффективной командной динамике редко бывает верным с самого начала проекта, фаза «шторма» почти неизбежна, но попытки планировать ее выглядят довольно странно.
Оперативная идентификация рисков – умение правильно определить, что риск реализовался, маловероятное событие произошло, предположение не оправдалось. В теории за идентификацию рисков отвечает риск-менеджер, но в реальности эта роль чаще всего размазана на всех членов команды с весом, пропорциональным опыту, лидерским и менеджерским функциям. И лидерам и менеджерам важно уметь здесь видеть ситуацию с правильного ракурса. Когда очевидно, что произошло что-то «внешнее», констатация риска дается легко: отключили электричество; заболел член команды; реализация API, предоставленного партнером, не соответствует предоставленной ранее документации и т. п. Сложнее ситуация, когда что-то разладилось, а что – непонятно. Билд не билдится, народ и софт глючат, один баг фиксится ценой двух новых, а ведь так не было и так не должно было быть. Но так бывает, и это тоже реализация рисков, за которыми стоят не замеченные пока факторы или неудачное сочетание множества нормальных флуктуаций. Такого рода явления тоже должны идентифицироваться и вести к организованной реакции. Мешает нам тут чувство вины, нежелание показаться слабыми менеджерами, но, не желая показаться, мы ими оказываемся ;(. Слабый – тот, кто бездействует, а общество и бизнес-среда удивительно терпимы к тем, кто действует, хоть и не совсем правильно или совсем неправильно,.

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

Сложная область – стратегии по предотвращению, читай, «уменьшению вероятности» рисков. С одной стороны, профилактика – лучший способ борьбы с проблемами, и весть современный подход к качеству базируется на выявлении источников нежелательной изменчивости и работе с ними. С другой, стоит потерять четкую связь инвестиций с отдачей на них, как «система качества» или «система борьбы с рисками» превращается в паразитирующий на бюджетах компании и проекта нарост. Компании, специализирующиеся на проектах малого и среднего масштаба (до десятков человеко-месяцев включительно) должны относиться к мерам по улучшению качества «вообще» осторожно, отметая «мутные» по целям или способам реализации затеи.

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

  • Важно, чтобы реализовавшийся риск был идентифицирован и коммуницирован на ранней стадии проектной командой, проактивно. Вместе с этим сообщением,обязательно вместе, должно присутствовать описание уже сделанных шагов и дальнейшего плана действий. Если это план – часть заранее подготовленного проектного риск-плана, то вот он момент торжества, позволяющего заработать очки доверия в неприятной, по сути, ситуации!
  • Важно, чтобы команда продолжала проактивно рапортовать о ходе реализации плана и его успешном завершении. Если возникают корректировки или новые факторы – запускаем вложенные итерации, нам не привыкать.
  • Важно наконец не теряться в ситуации, когда «непонятно что случилось». На этот случай есть универсальный алгоритм: «наблюдаем и анализируем, высказываем гипотезы, проверяем, повторяем до подтверждения» и в тоже время «подпитываем больной организм, как можем – морально и материально». Увы, не всегда мы узнаем, что именно разладилось, и выздоровление может наступить «само по себе». Тут важно не породить «культ карго», не начать лечить, например, детские болезни (типа той же фазы «шторма») наказанием невиновных и награждением непричастных. Многие из практик общего характера – смена команды и/или лидеров, призыв консультанта, смена процесса и т.п. работают, но совсем не обязательно мы способны отследить причинно-следственные связи в процессе излечения с достаточной точностью. Публичная казнь одного «короля» и воцарение другого – хороший рецепт снятия напряжения у народных масс, но редко имеет отношение к личным качества и компетенциям самих «королей».

Способ № 5 – «Переменеджмент»

Наконец, еще один способ «попадать в ожидания» – это уйти в нишу, где можно демонстрировать почти идеальный уровень обслуживания в любых обстоятельствах. Сделать это в общем можно, и даже несколькими путями.

Первый путь – уход в ультрапремиальный сегмент. Если запросить бюджеты в разы больше необходимых и иметь менеджеров, которые не дадут расслабляться никому из исполнителей, то оставшегося избытка хватит и на закрытие непредвиденных ситуаций, и на содержание выделенных коммуникаторов, «облизывающих» клиента. Трудность тут заключается в том, что такая организация работ не всем по вкусу, да и сегмент обычно небольшой.

Второй путь – захват контроля. Точно предсказать дату смерти можно, только убив объект предсказания в назначенный срок. Контроль – лучший инструмент предсказателя. Таким образом, захватив контроль решений, а, главное, оценки результатов их исполнения, можно оставаться на коне столько, сколько продержится контроль. В качестве инструмента захвата контроля может использоваться харизма персон и брендов, воля, вытягивание на свое профессиональное поле, включение в игру по своим юридическим или организационным правилам, использование слабостей клиентов и прочие методы «бытового гипноза». Поскольку реальный результат по-прежнему не гарантирован, важно умение красиво и вовремя уйти, хлопнув дверью и оставив клиента с ощущением «сам дурак и молчи, а то все об этом узнают». Захватывают контроль обычно те, кто могут и потому что могут. Мы, видимо, не можем, и это, ей-богу, не делает нас хуже.

Третий путь аналогичен первому, только реализуется избыточность не за счет hi-end позиционирования, а за счет постепенного, но последовательного отжимания менеджером изредка клиента, а обычно – своей компании и команды. Аврал становится постоянным, напряжение не спадает от начала проекта до конца, все, что можно выпросить «на стороне» и приставить к делу – надо выпросить и приставить к делу. Из позитивного такой подход дает ощущение, что точно сделали все, что могли, а точнее – что сделать больше уже точно не могли. Негатив же в том, что усталость от напряжения и раздражение ведут к росту количества сбоев, на преодоление последствий которых и уходят зачастую все накопленные резервы. А после завершения проекта мало кто хочет продолжать.

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

 (С) Оригиналы всех статей размещены на корпоративном блоге компании ДатаАрт. Спасибо им большое, что делятся такой классной информацией. Михаилу отдельный респект и очень советую вам читать его мысли в Twitter (@Zavileysky).

P.S. В заглавии слово «Эксперт» написано с большой буквы не зря. Такого системного подхода и понятного анализа темы управления ожиданиями я не находил.

Sep 21st, 2011
  1. Oct 4th, 2011 at 08:17 | #1

    Странно, что у такой хорошей и продуманной статьи нет комментариев. Хороший подход и раскрытие темы.

    Как было справедливо отмечено, управлением рисками занимаются далеко не все.

    Ушел читать дальше про фазу шторма и 6 сигма. Хотя по поводу последнего у меня большие вопросы – жена на работе сталкивалась. Такое впечатление, что делается это для галочки в начале проекта, а потом редко когда используется.

  2. Oct 4th, 2011 at 18:44 | #2

    @Merle,

    А че спорить с Экспертом? Он как сказал, так и будет! Тут же главное – правильно представить :)

    А то, что тема раскрыта прекрасно, даже спорить не буду! Это лучшее, что я нашел из управления ожиданиями в ИТ.

Leave a comment