Второй пункт моей конфликтной стратегии: «Я вправе требовать исполнения договоренностей».

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

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

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

«Побазарить по понятиям» с коллегой — не такая плохая идея

Однажды в той суровой производственной компании из прошлого поста мне потребовалось согласовать один договор, на пути которого встала служба безопасности (СБ). Я пошел к безопаснику, подробно изложил ему суть договора, объяснил, почему проблем никаких нет и его можно согласовывать. Тот позадавал вопросы, покивал и дал понять, что согласен с моими аргументами.

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

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

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

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

«Наезд» тоже должен быть правильным, чтобы не облажаться

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

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

Сила наезда тоже должна увеличиваться постепенно: если нарушение повторяется/продолжается, то можно наехать уже жестче.

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

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

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

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

Отчетность в стиле «как мы провели прошлую неделю» работает очень ограниченно

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

За эту неделю закончили разработку модуля Х.
Пилотирование модуля задерживается из-за проблем на стороне департамента А. Они загружены отчетностью и не могут приступить к тестированию. Обещают на этой неделе начать.
На следующей неделе планируем пройти тестирование модуля Х.
Также приступаем к разработке бэкенд функционала для модуля Y.

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

Но можно ли из этого отчета сделать уверенные выводы о том,

1. Успеваем ли мы к важному дедлайну, вроде окончания этапа, проекта, старту продаж?
2. На что влияет задержка тестирования модуля Х? Задержка на неделю — это много или мало?
3. Насколько серьезные проблемы у проекта, надо ли руководителю вмешиваться?

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

Если у спонсора один-два-три проекта, с этим еще можно жить: все-таки память у него хорошая. Но можно ли так курировать десять, двадцать, пятьдесят проектов? Нет.

Каким же критериям должна соответствовать отчетность, лишенная этих проблем?

Отчет показывает прогресс, прогноз и отклонение

Прогресс надо показывать через соотнесение плановых, прогнозных и фактических значений. Пример:

Ранее мы договаривались, что разработка модуля Y должна закончиться к 30-му ноября. Это план.
Сегодня менеджер понимает, что команда успевает только к 6-му декабря. Это прогноз.
Модуль Х был разработан 16 ноября. Это — факт. А план был — 1 ноября.

Теперь мы видим следующую картину:

Разработка модуля Х. Готово. План: 01.11. Факт: 16.11
Тестирование модуля Х. В работе. План: 19.11. Прогноз: 26.11
Разработка модуля Y. В работе. План: 30.11. Прогноз: 06.12

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

Отчет подсказывает, куда смотреть и не жрет «мыслетопливо»

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

Стало лучше? Красные циферки прямо «прыгают в глаза».

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

Если мы представим, что у нас не один менеджер, а пять, и у каждого по три-пять-десять задач, или календарный план больше 1000 задач, то на планерке вы это никогда не обсудите. Зато вы можете обсудить только те, где ∆ больше 5 дней, например. Таких задач будет всего несколько штук.

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

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

Новые перспективы открывает календарно-сетевой график. Если работы в плане связаны с другими и, уезжая вправо по линии времени, толкают своих последователей, то мы можем заметить, что задержка тестирования модуля Х приведет к сдвигу опытно-промышленной эксплуатации (ОПЭ), а это уже живые деньги, которые мы могли бы заработать, начав применять систему. А если речь идет о запуске продаж? Олимпиады? Там даже один день просрочки — это очень дорогой провал.

Отчет помогает принять решение

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

В частности, непонятно, как реагировать на выявленные отклонения. Что, если все эти модули нам понадобятся только в марте, когда будет разработана система, с которой нам предстоит интегрироваться? До тех пор +/- пара недель нас вообще не очень волнуют.

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

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

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

Отчетность должна быть полна, а не «тут отчитываемся, тут — забыл»

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

1. Календарный план.
2. Поручения.
3. Проблемы/открытые вопросы. Очень полезный инструмент менеджера проекта. Когда-нибудь напишу о нем отдельно. Если в двух словах, то это какая-то ситуация или вопрос, с которой нужно что-то делать, иначе будет плохо. Например, уволился разработчик — это проблема. Связанные задачи: «Написать бриф вакансии и отравить в эйчар», «Обзвонить своих знакомых разработчиков» и т. п.
4. Риски. В отличие от проблемы, это какая-то вероятностная штука, т. е. не факт еще, что произойдет. Например, «В январе может выйти новый ФЗ, который изменит требования к нашей системе, что увеличит объем работ». Добавлю, что идентифицировать риски и управлять ими довольно сложно, поэтому это продвинутый уровень РП.

Оставляю за скобками бюджет: финансовая отчетность — отдельная тема.

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

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

Или:

Менеджер пишет комментарий по тем работам календарного плана, где есть отклонение более 5 дней.

Вот, во что превращается наша секси-экселька.

Уже не очень секси, хотите сказать? Посмотрели бы вы на БДДС или БДР у финансистов. С любой отчетностью надо учиться работать. Но за счет того, что она единообразна, подсвечивает отклонения и компактна, вы довольно быстро к ней привыкнете, и сможете например, читать с листа А4 отчет о состоянии портфеля из 50 проектов.

Отчет должен быть многоуровневым

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

1. Руководитель проекта смотрит все работы календарного плана, все поручения и т. д.
2. Спонсор/куратор смотрит только важные вехи календарного плана: старт ОПЭ, сдача функционала, заключение контрактов, ключевые риски, отклонения по бюджету.
3. Топ-руководство в составе Проектного комитета интересует только когда результаты проекта начнут приносить пользу компании (генерить прибыль), поэтому им важны только окончания этапов и проекта в целом, а также сводные индикаторы по бюджету и рискам.

В сводном отчете по портфелю каждому проекту может быть посвящена вот такая строка:

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

Отчет формируем по графику, а не «когда есть, что показать»

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

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

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

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

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

Да, кстати, подписывайтесь на меня в Телеге, если еще не. Пишу туда довольно регулярно про проектное управление, управление собственной продуктивностью и лидерство.

Некоторое время назад в одном профессиональном сообществе руководитель проектов просит помощи в следующей ситуации:

Ребят, ситуация стандартная: я PM, на удаленке вижу, что разработчики начали со временем вафлить и делать меньшее количество задач, чем подразумевается и чем это возможно, уже причем объективно.

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

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

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

Не надо считать людей тупыми баранами

Давайте посмотрим на ситуацию:

Люди: <почему-то> стали менее продуктивно работать.

Менеджер: «Людям лень, они пытаются откосить. Дай ка я им вкручу».

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

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

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

Вместо этого дайте им кредит доверия

Я предлагаю заменить отношение «по умолчанию» на «сотрудник редко делает что-то со зла». Тогда наша ситуация изменится:

Люди: <почему-то> стали менее продуктивно работать.

Менеджер: «Что-то случилось. Дай ка я узнаю, в чем проблема».

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

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

(Политические игры, организацию-болото и иные ситуации «не про дело» не берем сейчас).

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

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

Что я в итоге посоветовал тому РП

В описанной ситуации я предложил:

1. Опубликовать метрики продуктивности и всем вместе на них смотреть.
2. Когда снижение станет всем очевидно, провести толковую сессию ретроспективы, на которой дать людям возможность в безопасной среде высказать наболевшее.
3. Потом со стороны РП дать полный коммитмент на решение этих проблем (и сдержать).

Тогда а) решатся наболевшие проблемы, б) у команды не останется морального права косить, ведь ты с ними по-хорошему. А если ты с ними по-хорошему, а они с тобой — по-плохому, то ты вправе реагировать решительно и жестко.

В запущенной ситуации может потребоваться пара ретроспектив.

Нет, это не задротство

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

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

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

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

Этап 1: Выделить ключевые результаты

Что собой представляет «ключевое достижение» (КД)? Это результат, который продвинет вас вперед по проекту. Чаще всего, это:

1. Создание чего-то готового к использованию, например, другой командой (командой заказчика) или пользователями. Ключевое здесь — это готовое к использованию. Отсылаю к исчерпывающему материалу о том, что значит «сделать» (кстати, абсолютный мастрид, который когда-то перевернул мой взгляд на мир).
2. Снятие блокировки, которая мешает запустить другие работы. Блокировка может быть технической — нет доступов для подрядчика, не может приступить к работе, но не только. Например, блокировать прогресс может принятие какого-то важного поворотного решения, отсутствие ресурсов и т. д.

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

Возьмем пример КД:

Функционал модуля расчетов передан заказчику в тестирование.

Этап 2: Спланировать

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

1. Сформулировать критерии готовности для каждого из КД. В эджайле это называется definition of done (DoD). Признак хорошего ДоД — при прочтении его у вас рисуется в голове картинка.
2. Согласовать эти критерии с ключевыми заинтересованными лицами, например с командой, которой вы передаете результат. Лучше всего — когда это делается на совместной сессии планирования.
3. Сформулировать открытые вопросы, без решения которых невозможно достичь этих результатов.
4. Накидать задачи для достижения КД и решения открытых вопросов.
5. Распределить сроки и ответственность.
6. Запланировать встречи на неделю. Один из распространенных факапов, кстати: забыть о том, что календарь ключевых людей может быть забит на несколько дней вперед. Тысячу раз так факапил(((
7. Идти фигачить, хватит уже планировать.

В нашем примере ДоД может быть таким (иллюстративно):

Функционал модуля расчетов передан заказчику в тестирование.

1. Функционал протестирован и перенесен на прод

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

3. У пользователей забито время в календаре, когда они будут тестировать (согласовано с их руководителем)

4. Поставлено демо

Я специально выбрал этот пример, потому что часто РП забывают, что накатить функционал мало, надо еще и передать его в тестирование/ в эксплуатацию. Но, на самом деле, можно вычеркнуть ИТ и аналогично описать разработку документов, запуск продаж и т. д.

Этап 3: Сфокусироваться

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

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

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

Система должна позволять:

1. Легко отделить ключевые результаты от задач по их исполнению, например, быстрым фильтром или разными представлениями. Чтобы посмотреть ключевые результаты на неделю должно уйти не больше 20 секунд.
2. Легко (меньше 30 секунд на доступ к этой информации) посмотреть только задачи, относящиеся к одному ключевому результату. При этом должны быть наглядно показаны: сроки, ответственные, и статус этих задач. Выполненные задачи не болтаются вперемешку с актуальными. Можно оценить отклонение от плана или понять, что член команды сигнализирует о проблеме.
3. (Желательно) Можно посмотреть задачи, сгруппированные по ключевым результатам.
4. (Желательно) Легко посмотреть только задачи, относящиеся хоть к какому-либо ключевому результату, или не относящиеся. Очень прочищает мозги, когда включаешь этот фильтр и понимаешь, что 60% задач не ведут тебя к конкретному результату. Что-то сродни сдвигу парадигмы.

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

Забегая вперед, скажу, что можно настроить такую систему:

• В Джире, правда с п.2 будет проблема: потребуется доп. плагин (кому надо — пишите, скажу название).
• В гуглдоке или в экселе. С определенной долей кривизны и ограничениями юзабилити, но тем не менее. Самый бюджетный и «быстрорастворимый» вариант.
• В Ноушене. В Ноушене хорошо получается, на моем Бусти есть шаблон. Опять же, пишите.
• В Coda.io. Не самая пока известная система, но очень мощная. Правда, конкретно работа с ключевыми результатами мне нравится меньше, чем в Ноушене. У меня на Бусти есть шаблон.

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

Да, кстати — подписывайтесь на меня в Телеге, если еще не.

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

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

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

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

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

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

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

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

В чем прикол:

1. Содержит все координационные вопросы, ничего не забудешь. Кажется мелочью, но когда тебя с утра перед встречей уже успел нагрузить заказчик возмущенными комментариями по поводу вчерашнего релиза, это очень помогает.
2. Не надо вспоминать, что надо обсудить. Больше «мыслетоплива» остается на содержательные задачи. Также можно запилить ссылку на относящиеся к вопросу системы/разделы, и это просто удобно.
3. Делегируема: любой член команды может проводить стендап.
4. Содержит опыт команды: дополняется по итогам всех «факапов».

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

Речь о трех стратегиях руководителя (см. рисунок).

I. Руководитель «добренький». Сотрудники ведут себя хорошо, руководитель: «Ах вы мои зайчики, вы такие молодцы». Сотрудники ведут себя плохо, руководитель: «Ах вы котики, ну что же вы так меня подставляете, давайте больше так не будем, пожалуйста» (я утрирую).
К чему это приводит? Сотрудники ведут себя все хуже и хуже, дисциплина разваливается.

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

III. Руководитель системный. Сотрудники ведут себя хорошо, руководитель: «Ах вы мои зайчики, вы такие молодцы». Сотрудники ведут себя плохо, руководитель: «Так, ребят, мы же договаривались по-другому, в чем дело?» — и все это без какой-либо агрессии.
К чему это приводит? Это приводит к тому, что в организации формируются правила, способствующие результативной работе. При этом руководитель не играет роль цербера и злодея: люди, которые ведут себя контрпродуктивно, «сами ударяются об систему».