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

Суть очень проста:

1. Настроить реестр, в котором хранятся все поручения менеджмента (или одного менеджера).
2. Настроить средство коммуникации по поручениям. В аутлуке можно слать отчеты по задачам, которые будут обновлять исходную задачу у автора (вы знали об этом?).
3. Обучить сотрудника, который все поручения будет вносить и контролировать по срокам. Обычно — ассистент руководителя.
4. Обучить людей, которые будут исполнять поручения.

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

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

Контроль поручений работает так хорошо за счет очень простого принципа:

Задача «попала на карандашик» — «вынь да положь» результат, или обоснуй, почему его нет

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

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

Есть еще один удивительно простой и эффективный принцип, который запускает работу с поручениями в компании:

Нет просроченных поручений

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

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

Ограничения контроля поручений

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

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

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

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

Не только контроль поручений

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

Если в плане проекта выделить ключевые вехи, то они могут превратиться примерно в те же самые поручения, только на весь проект у вас будет не две сотни работ, а семь-десять контрольных точек. Часть — для промежуточного контроля, часть — для итогового.

Контрольные точки вносите в реестр и контролируете примерно так же, как поручения. Просрочилась маленькая промежуточная веха — задаем вопрос: «Что случилось? Не нужна ли помощь?».

Если у вас сто проектов, по каждому из них 10 контрольных точек, то это 1000 контрольных точек. Предположим, что все проекты на год, это означает, что у вас примерно 80 контрольных точек в месяц. С контролем этих точек справится сравнительно небольшой проектный офис.

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

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

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

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

Более того, когда поводов для конфликта нет, вы можете быть просто зайчиком: оказывать команде максимум поддержки, быть со всеми супер-дружелюбными, пить вместе кофе, обсуждать детей и т. д. Лично я предпочитаю такой режим взаимодействия, поэтому новые команды первое время думают, что я что-то типа кота Леопольда и начинают проверять мои границы. Тут я включаю другой режим.

Приведу пример из своей практики руководителя проектов.

Показательная реакция на неприемлемое поведение

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

Я некоторое время присматривался к коллективу, выяснил границы своих полномочий в плане наведения дисциплины с руководителем и заручился его поддержкой — это важно!

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

Вернулся на рабочее место и отправил участникам письмо примерно следующего содержания (в копии — руководство):

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

Следующее совещание по календарям мы можем поставить только на следующей неделе.

Это означает, что у нас на одну неделю меньше времени на <такие-то задачи по проекту, в цифрах>.

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

И приложил к письму следующий слайдик:

В ответ на это некоторые опоздавшие участники написали мне, что они задержались, идя из другого корпуса (8-10 минут хода), на что я предложил сдвинуть начало всех совещаний на 15 минут: 13:15, 14:15, 17:15 и т. п., но приходить вовремя. Этого правила мы в дальнейшем и придерживались на проекте.

Опоздавшие участницы на следующее совещание пришли за пять минут до начала и почему-то спрашивали меня, женат ли я =) А часики со слайда вся компания вспоминала еще как минимум полгода, и друг другу угрожали, дескать «вот Вася сейчас поставит тебе часики».

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

Почему это сработало?

1. Я дождался реального косяка со стороны участников, причем не в адрес себя, а в адрес других участников. Вспоминаем первый пункт конфликтной стратегии!

2. Я наехал «по фактам»: показал, что съезжают сроки, сделал опоздание наглядным.
3. Я облегчил участникам путь навстречу: предложил вариант, который поможет им не опаздывать.

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

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

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

Документ как чек-лист

Давайте для начала посмотрим на содержание какого-нибудь управленческого документа проекта.

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

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

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

И вот здесь как раз кроется первый ключ к пониманию того, что собой представляет «бюрократия здорового человека». Заполнить управленческий документ означает подумать обо всем, о чем надо подумать. То есть, вы можете воспринимать документ как своего рода чек-лист, чтобы ничего не забыть.

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

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

Договориться и зафиксировать договоренности

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

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

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

Ничего не потерять

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

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

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

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

Так вот, первое правило: детализация должна соответствовать сложности проекта.

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

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

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

Задача

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

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

Решение

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

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

На практике выясняется несколько моментов:

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

Трачу еще часа два на то, чтобы перенастроить формулы и «укомпактить» табличку. Для рассмотрения на совещаниях лишние столбцы скрываем.

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

Сложности

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

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

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

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

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

Результаты

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

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

Больше кейсов и полезного контента про менеджмент и продуктивность — в моей Тележке.

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

Сегодня поговорим о том, почему так происходит.

Управление организационными изменениями идет из индивидуальной психологии

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

ADKAR — это аббревиатура от awareness, desire, knowledge, ability и reinforcement, означающих последовательные стадии изменений, которые должен пройти каждый из тех, кто должен измениться. Давайте разберем суть этих стадий на примере: мы хотим заставить близкого родственника бросить курить.

Awareness. Осознание необходимости изменений. Часто это — самая сложная стадия, особенно в нашем примере. Согласитесь, что пока человек не согласен, что курить — вредно, он никуда не сдвинется. Например, говорит: «А, я курю самокрутки (или тонкие сигареты), от них нет такого вреда, как от обычных сигарет».

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

Knowledge. Знание. Положим, человек захотел бросить курить. Возможно даже попробовал, но сорвался. И здесь ему очень пригодится знание о том, как правильно бросить курить. Тут ему зайдет книга Алана Карра, или хотя бы совет тех, кто бросал курить: «Чувак, тяга пройдет через какое-то время и станет легче». Обратите внимание, что шаг «знание» идет на третьем месте. Бесполезно пичкать обучением людей, которые не знают, зачем им это может пригодиться и не хотят этого.

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

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

С курением понятно, но как же это применить для проектов?

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

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

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

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

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

Когда речь заходит о дисциплине, я часто вспоминаю прикольную концепцию из книги Discipline without punishment. И хотя в чистом виде она применима скорее в производственных ситуациях с линейным персоналом, тем не менее, она очень наглядно иллюстрирует экологичный и вместе с тем сильный подход к дисциплине.

Техника состоит из четырех ступеней.

1. Первое нарушение дисциплины. Руководитель реагирует на нарушение в устной форме. Дескать, чувак, эта ситуация сейчас была не желательна, от нее такие-то плохие последствия (или «у нас так не принято»). Пожалуйста, не делай так больше.
2. Второе нарушение дисциплины. Руководитель опять разговаривает с сотрудником, но уже в более формальном режиме. Объясняет, в чем суть нарушения, указывает на то, что уже был разговор, и сообщает, что так дальше не пойдет. Компания требует соблюдения определенных норм, и поведение, которое им не соответствует, неприемлемо. После этого разговора руководитель отправляет формальное письмо с резюме разговора.
3. Третье нарушение дисциплины. Руководитель предоставляет сотруднику отгул за счет компании на целый день со следующим посылом: «Чувак, это поведение неприемлемо, и мы это обсуждали. Пожалуйста, возьми отгул, и в этот день, в спокойной обстановке подумай о том, как ты видишь свое будущее с компанией. После отгула поговорим, что надумал». После отгула руководитель встречается с сотрудником и обсуждает ситуацию, выслушивает, какие меры он примет, чтобы исправиться, договаривается о следующих шагах.
4. Увольнение. Это последний шаг, но это не кульминация дисциплинарной системы, а скорее ее провал.

Естественно, в последовательности речь идет об одном и том же нарушении дисциплины.

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

Понятно, что на практике все несколько сложнее.

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

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

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

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

Пишу письмо: «Чувак, когда будешь знать точно? Встреча с внешним участником, надо его сориентировать».

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

Что происходит? Коллега, разумеется, в запаре, и пишет мне письмо на айфоне левой пяткой, сидя на другом совещании, но ведь он таким образом создает себе лишний головняк на пустом месте. Сэкономил 20 секунд, получил еще два письма, лишний созвон, потратил мое время.

Вместо этого он мог написать в сообщении об отмене встречи: «Вася, сегодня отбой, сорри. Предлагаю завтра до 11 или после 16 ч.». Все!

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

Чтобы избегать таких ситуаций, надо каждое сообщение оценивать:

1. Чего я хочу от респондента? Любая коммуникация (любая!!!) имеет своей целью кого-то к чему-то побудить, даже информационная рассылка.
2. Сможет ли респондент предпринять конкретные действия на основе моего письма? Если нет, ваше письмо будет либо проигнорировано, либо вам будут задавать дополнительные вопросы. Конечно, даже идеально составленное алгоритмическое письмо может быть проигнорировано, но мутное письмо требует гораздо большей мотивации получателя, чтобы его прочли.

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

<сорри, картинку не успеваю нарисовать, статья здоровая получилась>

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

Вот э фак из сессия ретроспективы?

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

Если при этом описании вы внутренне содрогнулись — понимаю вас. Скорее всего, вы представили себе т. н. «разбор полетов» — разъёб-сессию, на которой задают неприятные вопросы типа: «А почему мы просрали эту задачу?» или «Почему Иванов не сделал то, что должен был?», и после которой все выходят немного изнасилованными. Мало кому хочется что-то в таком роде повторять.

Ретроспектива в корне отличается от «разбора полетов» тем, что, несмотря на название, направлена в будущее. Цель ретроспективы — не выяснить, кто где обосрался. Какой в этом прок? Разве мы можем метнуться в прошлое, и не обосраться тогда, в тот раз? Что мы можем, это договориться о том, что делать, чтобы в дальнейшем обсёров было меньше. И этому очень поможет, если в ходе сессии никто не будет чувствовать себя мудаком и «слабым звеном».

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

Шобы шо?

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

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

Ретроспектива — это как раз ваше решение договориться о том, как работать лучше, эффективнее.

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

Приведу пример.

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

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

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

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

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

Что произошло? Я просто сказал команде: ребята, это наше общее дело, мы должны фигачить вместе. Есть идеи, что улучшить — вэлкам, я готов поддерживать, но отсидеться не получится. И вместе со всеми работал над этим процессом.

Окей, как это правильно делать?

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

1. Вводная: цели сессии, тайминг, установочные вопросы. Очень важно проговорить это в самом начале, чтобы люди понимали: что происходит, зачем они здесь, чего от них ожидают, когда их отсюда выпустят. Если этого не сделать, вы посреди сессии получите внезапно покидающих аудиторию участников, или вопросы: «а что мы вообще делаем?» и пр. Не гуд.
2. Айсбрейкер. Небольшое групповое обсуждение, которое помогает участникам расслабиться, заскочить на флоу совместной работы. Хорошо работают штуки типа: «расскажи про себя две правды и одну ложь, а мы угадаем, где что», или «расскажите о чем-то замечательном, что произошло у вас за <период ретроспективы>». Важно, что после айсбрейкера люди на позитиве, открыты и им начинает нравиться происходящее. Что будет, если вы пропустите эту стадию? Большой шанс, что кто-то из участников будет сидеть в позиции «глухой обороны», тухлить и вообще сливать сессию. Можете проверить, но лучше не пренебрегать айс брейкерами.
3. Насколько вы счастливы тем, как мы сработали за <период ретроспективы>? Здесь можно построить «гистограмму счастья»: команда клеит стикеры на горизонтальной оси 1 — 5, стикеры один над другим. Получается, что если на оценке 3 — четыре стикера, то столбик «3» — высотой в четыре стикера. На других оценках — другое количество стикеров, в результате получается столбчатая диаграмма. Обсуждаете с командой, кто какой стикер приклеил и почему. Зачем это нужно? Это очень наглядно показывает, что не «все ОК». Если оценка не 5 из 5, то явно с чем-то можно поработать. Без этого шага у вас может не оказаться предмета для разговора: например, все говорят «да нормально, не хуже, чем у других». А тут вы можете сказать: «Что надо, чтобы было 5 из 5»?
4. Делим маркерную доску на две части, слева пишем: что нам помогает достичь 5 из 5 с точки зрения качества процесса, справа — что нам мешает. Каждый член команды должен написать на стикерах минимум N факторов и на ту, и на другую сторону доски. Почему именно на стикерах, почему нельзя на словах? Потому что это ненавязчиво заставляет даже самых застенчивых что-то написать: хочешь не хочешь, а вынь да положь N стикеров. Это УБЕР важно. Ну, кроме того, позволяет избежать непродуктивной дискуссии, когда все друг друга перебивают.
5. Каждый клеит свои стикеры и рассказывает, что он думает по этому поводу. В этом обсуждении ваша задача — поддерживать фокус на улучшении процесса. Задача группы не в том, чтобы зафиксировать, что <ФИО> обосрался, а выявить сбои в процессе, который надо всем вместе пофиксить. Это очень важно, даже если у вас невероятная культура результативности, и обратную связь все на завтрак едят. Если срач и «разбор полетов» все-таки начался, хрен вы загоните второй раз людей на это упражнение.
6. После этого команда должна разработать решения для всех выявленных мешающих факторов, желательно — с применением способствующих факторов, написать их на стикерах и наклеить на доску. Дублирующие стикеры клеить поверх аналогичных.
7. Дальше вы устраиваете голосование за лучшие решения. Можно использовать специальные метки для голосования, можно — просто маркером ставить точки (n точек на участника).
8. После этого участники команды должны выбрать решения, которые они лично готовы внедрить. Это важный пункт. Скорее всего вы, как инициатор, будете самым ответственным, но очень рекомендую раздать ответственность и другим членам команды тоже, чтобы они не только предлагали классные идеи, но и руками поработали. Если по каким-то стикерам-решениям нет ответственных, то вы их к такой-то матери выкидываете. Тут, конечно, надо тонко чувствовать и культуру организации, и характер предлагаемых улучшений. Не всегда такая жесткость уместна: например, если от действий команды реально мало что зависит, надо все зарешивать вам с руководством.
9. Дальше вы еще раз составляете «гистограмму счастья», но теперь to be: если вы внедрите то, о чем договорились, насколько вы будете счастливы процессом? Показатель должен улучшиться, иначе нахрена вы это все писали.

Вся сессия первое время будет занимать у вас часа три-четыре. Рассчитывайте на это время: с нормальными обсуждениями, выработкой решений и пр. На 10-й ретроспективе — 1,2-2 часа. Вы скажете «много» и «у меня никто не согласится выделить столько времени на это». Понимаю, слышал это тысячу раз. Но давайте посчитаем: команда из 5 человек потратит на четырехчасовую ретроспективу 20 человекочасов раз в две недели. Как вы думаете, как быстро это время окупится, если «отныне и вовеки» команда будет делать какие-то вещи быстрее, экономя на этом 3 часа в неделю? А если вы предотвратите факап, из-за которого вся команда просидела бы выходные?

Короче: это инвестиции времени, которые окупаются.

Как сделать так, чтобы это заработало

Во-первых, если вы не очень уверены в своих навыках фасилитатора, можете пригласить профессионала, который таких ретроспектив проводил десятки и сотни. Гуглите «фасилитация ретроспектива», или пишите мне в Телегу ;)

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

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

Про злоупотребление со стороны руководителей я уже немного писал (и напишу еще), сегодня поговорим о нездоровом отношении к субординации со стороны сотрудников.

Возьмем пример.

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

Руководитель направления маркетинга очень болезненно реагирует на эти вбросы. Он периодически прямо или иносказательно обвиняет шефа в непоследовательности, требует, чтобы его перестали перебивать и «услышали его».

Что происходит?

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

1. Должен выслушивать его до конца,
2. Должен относиться более бережно к его идеям,
3. Мог бы быть более последовательным, не меняя свое мнение от совещания к совещанию.

Все это было бы вполне справедливо, если бы не один нюанс: они с шефом находятся в разном положении.

Разные уровни ответственности означают разный уровень полномочий

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

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

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

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

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

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

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

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

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

Соблюдая субординацию, вы превращаетесь в ценного сотрудника

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

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

С другой стороны, когда вы находите человека, который:

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

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

В субординации нет ничего зазорного

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

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

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

Третий пункт моей конфликтной стратегии: «я уважаю ответственность других людей».

У каждого в компании есть какая-то зона ответственности. Бесцеремонное вторжение в нее — провокация конфликта. Очень важно понимать это, требуя чего-то от коллег, предлагая какие-то улучшения за пределами своего периметра, обижаясь на шефа, который заворачивает твои идеи.

Двигаться к своим целям можно (и нужно), уважая границы других людей

Пример из жизни.

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

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

В течение следующих 15-20 минут я задвигаю следующие тезисы:

1. Чувак, ты делаешь очень важную работу, я это понимаю. Еще и ресурсов не хватает. Очень тяжело.

2. Нам надо для важного проекта: без прав на администрирование мы никуда не сдвинемся.

3. Меньше всего на свете хотим тебя подставлять, давай договоримся, как сделать так, чтобы мы могли сделать свои настройки и тебя не подвести.

4. Мы — ответственные пользователи. Умеем настраивать конфигурацию так, чтобы не задеть ничего лишнего.

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

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

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

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

Субординация — тоже границы

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

Еще один пример.

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

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

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

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

P.S.: Когда-нибудь я разберусь, как в этом движке сделать постоянную ссылку на мой телеграм-канал, а пока просто приглашаю подписаться, если еще не.

Продолжение цикла статей про конфликтную стратегию:
Часть 1
Часть 2
Часть 4
Часть 5

UPD 2024: Кстати, я тут создал Сообщество практикующих менеджеров, в котором можно попрактиковать свою конфликтную стратегию.