У меня есть простая аналогия для настройки процессов с точки зрения исполнителя.

Представьте себе продавца, который занимается холодным обзвоном. У него в CRMке специально для холодных обзвонов должен быть простейший интерфейс, состоящий из:

• Надо позвонить (стопка, из которой он берет верхнюю карточку)
• Звоню (карточка, скрипт)
• Прозвонил (возможно — «успех»/«неудача»)

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

Как вы думаете, какова будет продуктивность по сравнению с первым сценарием?

Во всех интерфейсах систем, которые предназначены для работы с задачами, стремитесь к однозначности:

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

А у вас в таск-трекере порядок?

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

Как же управляют топ-менеджеры многотысячных корпораций? Ведь у них тоже 24 часа в сутки.

Проиллюстрирую на примере одного своего проекта.

Вместо брейнстормов — управленческое совещание

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

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

Когда я предложил сделать для этого одну встречу, у заказчика был шок: такое совещание будет идти часов шесть!

Я продолжал настаивать, что это возможно, если сделать совещание более концентрированным.

Я прописал процесс подготовки к совещанию:

1. Все материалы к совещанию должны быть готовы за N дней до начала.
2. Все участники должны ознакомиться с материалами до начала совещания.
3. Если в материалах к совещанию выявляется какая-то проблема — например, по одному из проектов выявлено отставание, — участники должны успеть подготовить и согласовать между собой меры по работе с этой проблемой.
4. Если договориться не удается, предмет разногласий должен быть сформулирован в виде альтернатив, для каждой из которых описаны «за» и «против», чтобы председатель мог принять взвешенное решение непосредственно на встрече.

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

Зачем тогда вообще проводить совещание, если мы все обсудили?

Именно такой вопрос задавал заказчик, когда я выдвинул предложения.

Помните мой пост про то, что сотрудник должен приходить с проектами решений, а не с проблемами? Здесь происходит примерно то же самое.

Вместо того, чтобы закатав рукава погружаться в обсуждение насущных вопросов, руководитель передает инициативу сотрудникам: «Думайте сами. Жду от вас проекты решений на утверждение».

При этом результаты инициативы сотрудников рассматриваются публично и торжественно на общем собрании.

Если кто-то пришел неготовый — это видно.

Если на совещании возникают споры — руководитель говорит: «Так, ребят, вы не готовы, идите договаривайтесь».

Очень не хочется облажаться на таком совещании.

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

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

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

Губернатор тратил на эти совещания один час в месяц. Но ради этого часа проделывался целый вагон работы.

Чтобы это заработало, надо соблюдать несколько условий

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

Правила эскалации. Какие проблемы сотрудники решают сами, какие — выносят на совещание.

Требования к выносимым материалам. Шаблоны управленческой отчетности, типовые слайды и пр.

Ответственный за качество процесса подготовки. Например, проектный офис.

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

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

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

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

«Ну да, ты прав: задача усложнилась. Ну и что? Ты рассчитывал пройти этот уровень на easy, а оказался nightmare, но это все та же игра, просто сложнее»

Удивительно, но эта простая мысль переключила меня из режима «уу-у-у-у, все так плохо и несправедливо» в режим азартного поиска решения.

«Тест апельсинового сока» от Дж. Вайнберга

Есть отличная, очень афористичная книга про консалтинг от Джерри Вайнберга, в русском переводе называется «Закон малинового варенья». Она написана в формате притч/баек, и чаще всего я вспоминаю одну, под называнием «Тест апельсинового сока».

Представьте, что вы — менеджер отеля, и к вам обратился заказчик со следующей просьбой.

Он хочет организовать ежегодный слет сотрудников своей компании на 700 человек.

По устоявшейся традиции они завтракают тостами, и ровно в 7:00 основатель произносит напутствие, под которое все 700 человек должны чокнуться большими бокалами свежевыжатого апельсинового сока.

Любой, кто представляет себе организацию мероприятий, понимает, что это весьма сложная логистическая задача: мало того, что надо организовать визит и размещение 700 человек, так еще и завтрак тостами, отжим 700 порций сока в такие сроки, чтобы он оставался свежевыжатым ровно к 7:00...

Звучит как кошмар для организатора.

В притче Вайнберга менеджеры отелей делятся на три категории:

1. Которые говорят, что это невозможно. Их заказчик отметает.
2. Которые говорят «нет проблем». Эти либо не отдают себе отчета в масштабах задачи, либо хотят любой ценой получить заказ, а там хоть трава не расти. Они тоже не прошли тест.
3. Которые говорят: «Окей, мы можем это сделать. Это будет стоить вам столько-то».

Только третий вариант — подход настоящего профессионала.

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

Сложно ≠ невозможно

Внедряя новый процесс, решая сложную задачу, я много раз наталкивался на сопротивление: «Это невозможно» — со стороны сотрудников.

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

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

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

Есть такая технология, очень полезная для менеджеров и переговорщиков: «Управленческие поединки» (УП).

Вам с оппонентом дают кейс, роли в этом кейсе, и вы вступаете в поединок, чтобы достигнуть целей.

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

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

Почитать подробнее можно здесь.

Крутая технология. Реально работает. Прокачанным в ней людям палец в рот не клади.

Однако я сталкивался и с ситуациями, когда владение УП человека подводило.

Всегда ли полезно побеждать в переговорах?

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

Но — удивительно — заказчик почему-то не горит покупать у вас новый проект. Почему?

Есть не только «победил/проиграл», но и «прав/не прав»

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

На мой взгляд, умение побеждать в УП — это примерно как драться. Если вы — мастер спорта по джиу-джитсу, вы сможете отмудохать в лоскуты примерно любого оппонента, который встретился вам в жизни.

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

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

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

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

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

Необходим прочный этический фундамент

Я уже излагал в блоге свою конфликтную стратегию.

Суть ее в том, чтобы вести переговоры с этически-безупречной позиции:

1. Все мои предложения нацелены на общий результат
2. Я соблюдаю договоренности и вправе требовать соблюдения договоренностей
3. Я уважаю ответственность других людей
4. Я общаюсь уважительно и ожидаю такого же отношения к себе
5. Я нетерпим к безразличию

Эта позиция правильная «по понятиям», и она безопасна в применении. Простое следование ей закрывает 95% всех переговорных ситуаций в обычной среде: в командной работе редко возникают ситуации, когда надо драться (не говорю сейчас про токсичные корпорации).

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

Книги Владимира Тарасова — бесконечный источник управленческой и житейской мудрости.

Опыт поединков поможет вам не только в оставшихся 5% жестких конфликтных ситуаций, но и просто быстрее соображать в конфликте.

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

Большинство людей интуитивно неправильно формулируют проблемы.

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

Проблема ≠ отсутствие решения

Классическая ошибка — формулировать проблему через отсутствие решения.

Для примера возьмем проект внедрения системы контроля поручений (СКП) руководителя. В паспорте проекта неопытный менеджер может описать проблему так:

«Отсутствует система контроля поручений»

Не видите здесь ничего странного? Давайте позадаем дополнительные вопросы:

• А нужна ли нам вообще СКП?
• Почему нам нужна именно СКП, а не секретарь?
• Почему СКП нужна именно сейчас?

Все они остаются без ответа.

Теперь попробуем сформулировать иначе.

• Контроль поручений силами секретариата без автоматизации требует целой штатной единицы
• Сбор отчетности по поручениям силами секретарей вызывает резкое раздражение у менеджеров
• Высокая текучка среди работников секретариата, частая причина смены работы: «Меня все ненавидят, потому что я работаю „дятлом“»
• Невыполнение неучтенных поручений привело к финансовым потерям не менее 1,2 млн рублей в ноябре 2022.

Вот тут уже понятно, что секретари не справляются, и потери большие.

В первом случае под проблему замаскировалось конкретное решение, а причины, по которым оно вообще потребовалось, были скрыты.

Во втором случае мы указали, что мы решаем, — то есть, конкретные проблемы, — чтобы предложить решение: систему контроля поручений.

Это не спор об определениях, а очень практичный вопрос

Кто-то может даже сказать: «А для меня именно отсутствие СКП проблема!»

На это можно ответить, что спор о том, что считать проблемой, не лингвистический, а прагматический.

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

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

Вот два прагматичных следствия из правильной формулировки проблемы:

1. Понимаем целесообразность решения.

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

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

Какие есть альтернативные способы внедрения СКП? Только разные варианты СКП.

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

Как формулировать проблемы правильно?

Помогает проверочный вопрос: «Чем это плохо?» Задавайте его, пока он не начнет звучать совсем уж по-идиотски. Чаще всего, это происходит, когда доходит до денег. Обычно понятно, чем плохо, если мы теряем 10 млн в месяц.

Тем не менее, рекомендую и в «идиотских» ситуациях себя преодолеть и спросить еще пару раз. Бывает, открываются новые бездны.

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

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

Там еще выше уровень методологической чистоты формулировок. По опыту, не всегда практично достигать именно этого уровня, но изучение принципов очень помогает ясности мышления.

Кто хоть раз внедрял в компании таск-трекер или систему управления проектами с вероятностью 90% знает на практике, что значит «система не взлетела»:

• Система вроде бы есть, но в нее никто не заходит
• Данные вроде бы есть, но менеджеры все равно звонят исполнителям по телефону, чтобы уточнить статус
• Информация в системе расходится с реальностью

Я знаю, я был там.

Теперь, внедряя такие штуки, я пользуюсь отличным показателем, который говорит, жива ли наша система управления:

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

Давайте разберемся, что означает этот показатель?

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

Исполнитель не обновил либо прогноз по срокам, либо статус задачи, т. е. забил на коммуникацию.

Почему это так важно?

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

А теперь давайте представим, что какой-то неизвестный процент задач в этой системе показывает ошибочную информацию.

Это бесповоротно подрывает доверие к системе.

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

Иными словами, система становится бесполезной.

Что делать?

Когда сотрудники нарушают сроки, не сделывают цели, заваливают проекты — я рекомендую проявлять максимум терпения и принятия (если конечно это не злостный игнор правил и нарушение договоренностей). Обычно человек сам не рад, что завалил проект.

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

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

Приятные и важные следствия

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

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

Часто в околобизнесовых кругах можно слышать про проекты внедрения/трансформации корпоративной культуры и/или внедрения ценностей.

Звучит круто. Сотни сотрудников корпорации, объединенные в едином порыве строят значимый бизнес. При этом мотивированы они не зарплатой, а чувством принадлежности и смыслом, который дает им работа.

И примеры сильных корпоративных культур у всех на слуху.

Однако мне вспоминается фраза, которую сказал операционный директор одного очень большого и серьезного заказчика, для которого мы делали проект:

«Я считаю бесполезно внедрять корпоративную культуру саму по себе. Потому что корпоративная культура — это следствие того, что и как мы делаем»

К сожалению, некоторые руководители считают, что достаточно повесить на стене в офисе плакат: «Наша ценность — развитие!» — и народ вовлечется и не пойдет просить повышения зарплаты в следующий раз.

Есть отличный прием из практик по управлению изменениями.

Как в игре «Крокодил»: топ-руководитель не говорит об изменениях, а показывает конкретными действиями.

Например, у нас диджитализация? Пусть смотрит отчеты на айпаде, а не распечатанные на бумажке.

Внедряем ценность «Результатоориентированность»? Запустите внедрение ОКР.

Часто слышу от менеджеров примерно следующие слова:

«Вася, сорри, что тебя динамлю, но руководство не выделяет мне ресурсы, поэтому...»

И дальше идет:

«...я не могу заниматься твоим проектом»,

«...у меня нет заместителя и я все завязал на себя»,

«...мы завалены делами и факапим задачи».

По этому поводу я могу только повторить слова моего старшего товарища и наставника:

«Один из основных скиллов менеджера — уметь выбить ресурсы»

Приведу пример как это можно сделать из своего опыта.

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

После чего я сел с ним рядом на табуреточку и мы вместе заполнили таблицу: текущие проекты на подразделении, оценка трудозатрат с обоснованием, объем непроектных задач с примерами и категориями и т. п.

(См. скрин ниже)

В общем, я показал на данных, что объем обязательств, возложенных на подразделение, не реалистичен.

В нижней строке на скриншоте вы можете увидеть почти двукратное превышение доступного объема трудозатрат.

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

Важно добавить.

Часто руководство режет ФОТ/штат прямо требуя или косвенно подразумевая, что руководители должны оптимизировать процессы. Это не всегда реалистичные ожидания, т. к. из-за сокращения штата количество текучки на сотрудника увеличивается, что не располагает к тому, чтобы заниматься задачами оптимизации.

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

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

Что значит «сделать»?

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

Речь в нем идет о том, что такое ответственность и что такое настоящая результатоориентированность.

Автор — Николай Товеровский. Кстати мой коллега, руководитель проектов и тренер. У него вокруг принципа «сделывания» целая методология построена. Есть книга и тренинг по управлению проектами в Школе менеджеров Бюро Горбунова.

Вот его сообщество, где можно пообщаться на всякие менеджерские темы.

(Промо абсолютно добровольное и безвозмездное, из респекта к профессиональным заслугам коллеги)

Есть отличный анекдот, как пользователи читают инструкции:

— Положите кирпич на стол.

— Что положить, не понял?

— Кирпич.

— А, да. Куда, говорите положить?

— На стол.

— А, точно. Бросил под стол, так пойдет?

— …

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

Это абсолютно естественно: все занятые, всем очень сложно выделить силы и время на задачу, с которой вы к ним пристали.

Просто это та реальность, которую надо учитывать.

Вот несколько выводов.

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

Не злитесь и не раздражайтесь, потому что происходящее — нормально. Это совет не только для поддержания психического здоровья, но и очень важный навык менеджера. Когда вы сохраняете невозмутимость и терпение, это спокойствие передается команде, вашим заказчикам и т. п. А это значит меньше пустых тёрок, больше дела. Мне много раз давали обратную связь, что я очень терпелив, и это поддерживает.

Облегчайте инструкции по мере возможности или устраняйте их совсем. Если инструкция 16 страниц — мало шансов, что ее кто-то хотя бы откроет (если вы не в госорганах работаете). По мере возможности встраивайте инструкции в процесс: подписывайте поля, кнопки перехода по статусам в Джире. Пишите простым человеческим языком без канцелярита.

Порой инструкция нужна для того, чтобы лишить права на незнание. Если у вас есть инструкция, уже не получится так легко сопротивляться внедрению системы, объясняя, что она сложная и какая-то не такая.