Триединство проекта: Стейкхолдеры, Команда, Коммуникации

О стоимости решения задачи из-за вовлечения дополнительных получателей

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

Ничто так хорошо не демонстрирует, как пример из реальной жизни. На балансе команды проекта постоянно находилась огромная мультимедиа панель для участия в редких выставках. О её текущем нахождении знал только РП, назовём его Евгений Петров, т.к. несколько ответственных людей которые в команде проекта обладали информацией о данном устройстве уволились. В один день, данная панель понадобилась руководителю другой команды проекта, назовём его Андрей Сидоров. В Компании, где осуществлялись эти два проекта много лет была традиция помогать друг другу и не впадать в формализм и бюрократию с бумажками, поэтому процесс «дать на время попользоваться ТМЦ» происходил легко и быстро, по простому запросу. Надо отметить, что в этот момент Евгений Петров был в командировке и не мог оперативно ответить на запросы из команды проекта. За старшего остался заместитель РП, Матвеев, который будучи не в курсе, начал розыск устройства и включил в письмо руководителя склада Компании – Анна Марковкину, в надежде что устройство находится не в офисе, а на складе. На складе панели не оказалось, зато в почту всем участникам проекта от Анны пришло письмо следующего содержания:

«Добрый день!

Коллеги, прошу уточнить, на основании каких документов передается данная панель Андрею Сидорову? Так же, прошу уточнить, на кого введена в эксплуатацию данная номенклатурная позиция, кто будет отвечать за ее возврат? Как она называется в 1С?»

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

Рис. 1.8. Таблица результатов

В задачу оказались вовлечено все руководство компании, бухгалтерия, члены обоих команд и ИТ отдел, а трудозатраты на решение такой задачи составили несколько человеко-часов на оформление перемещений ТМЦ в 1С и подписание двух комплектов документов - на выдачу, а зачем на возврат. А сами комментарии в задачах от Анны Марковкиной выглядели достаточно провокационно - «Вопрос у меня на контроле. Неучтенных ТМЦ в Компании быть не должно, а тем более, неотраженных перемещений» и «Вам не важно, когда будет возвращено имущество компании?», на который мало просто ответить, требуют дополнительных действий от исполнителя, которые по логике не входят в круг его обязанностей при решении такой задачи. В командах проектов в рамках исполнения вновь возникших требований появилась напряжённость, а в целом, дружеские «зеленые» коммуникации с соседней командой проекта резко изменились в «синюю» тональность.

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

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

Коммуникации в моменты претензий к команде проекта

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

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

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

Фаза «Нападение»: На действия или бездействия вашего специалиста от руководителя вашего уровня или выше из смежного подразделения предъявляется претензия

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

Главная ошибка РП сразу крыть претензию своими аргументами и защищаться

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

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

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

РП должен обязательно практиковать жесткое наказание за "я подумал и решил ответить». И РП с этого момента замыкает все общение на себя.

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

Фаза «Оборона»

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

Поддерживаем коммуникации во вне в стиле "Задача в работе, дадим информацию в 14:00), запускаем таймер.

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

Основная цель этого этапа – сохранение репутации.

"Красные" коммуникации на практике: как не надо гасить конфликт с заказчиком

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

В одной компании руководитель ИТ отдела, назовём его Александр, получил задачу от заказчицы — назовём её Кристина Павлова. Требовалось доработать корпоративный портал: разместить обязательные уведомления, настроить политики обработки данных, добавить видео-ролик на главную страницу. Срок был установлен на 1 апреля 2026 года.

Задача была создана 1 июля 2025 года. Девять месяцев работы. И вот что произошло.

Фаза "Нападение" — как это выглядит в реальности

Когда руки добрались до этой задачи, Кристина Павлова начала проверять результат. Она обнаружила, что:

- видео-ролик на главной странице отсутствует;

- ссылки на инструкции ведут на несуществующие страницы (ошибка 404);

- навигация "назад" работает некорректно;

- нарушена логика отображения пароля при авторизации;

- настройка обработки cookie сделана "костылём" — данные хранятся на внешнем ресурсе.

Кристина написала письмо с перечнем замечаний. Это был акт "Нападения" — она предъявила претензию с доказательствами. Что сделал Александр? Вместо того чтобы взять паузу, разобраться и дать профессиональный ответ, он тут же начал защищаться.

Главная ошибка РП на этом этапе — крыть претензию своими аргументами. Именно это и сделал Александр. Он начал объяснять, что "функционал уже есть", "сроки были сложные", "заказчик не дал чётких требований". И самое опасное — он попытался закрыть задачу, не устранив замечания.

Кристина увидела это и написала в ответ:

"Я не могу закрыть задачу, потому что..." — и снова перечислила все недостатки.

Она была вынуждена делать это трижды. 29 сентября 2025 года, 20 апреля 2026 года, и ещё раз после очередного промежуточного исправления. Каждый раз она подробно, с фактами, объясняла, что именно не сделано.

Фаза "Анализ" — чего не сделал Александр

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

Вместо того чтобы:

- запретить членам команды общаться с заказчиком вне его контроля;

- изучить переписку и технические решения;

- понять реальную картину;

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

Фаза "Оборона" — как конфликт вышел на уровень топ-менеджмента

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

На этом этапе Александр должен был лично предоставить ответ — с извинениями, если требовалось, и с планом исправления ситуации. Но вместо этого он продолжал спорить. Он настаивал, что "всё работает", что "заказчик просто не понимает", что "проблема в инструкциях".

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

Последствия — чем всё закончилось

Полная потеря доверия. Ольга Соколова заявила о полной потере доверия к команде Александра.Ещё один проект автоматизации склада, который вёл Александр, был изъят из его ведения и перезапущен под личным контролем директора ДИТ.

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

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

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

Какие уроки мы можем извлечь

Никогда не защищайтесь сразу. Когда вам предъявляют претензию, первая реакция — дать отпор. Но это самая большая ошибка. Александр начал защищаться — и только усугубил ситуацию. Правильный шаг: "Я понял, дайте мне время разобраться". Никаких оправданий, никаких объяснений. Только пауза.

Фаза "Анализ" — это святая обязанность руководителя. Запретите команде общаться с заказчиком. Заберите всю переписку на себя. Только вы должны давать ответы. Александр нарушил это правило — и команда начала давать противоречивые ответы, подливая масла в огонь.

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

1

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

2

Ильф и Петров, 12 Стульев, Глава XII. Знойная женщина — мечта поэта.

3

Keep satisfied – Поддержание состояния удовлетворённости.

4

A Guide to the Project Management Body of Knowledge (PMBOK® GUIDE)

Sixth Edition, 2017 Project Management Institute

5

Stakeholder Performance Domain (Область результатов, связанная с заинтересованными сторонами) — это одна из восьми Областей результатов (Performance Domains), которые представляют собой группы связанных видов деятельности, критически важных для эффективного выполнения работы в проекте. Если просто, то это не процесс, а сфера внимания, в которой проектная команда должна демонстрировать высокие результаты на протяжении всего жизненного цикла проекта.

6

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf, English (November 2020) - Official Current Version Ken Schwaber & Jeff Sutherland

7

https://kanbanguides.org/the-kanban-guide/2025.5/pdf/kanban-guide.v2025.5.en.pdf

8

Face-to-Face – анг, лицом к лицу

9

Подробнее в Барамба С., Проектная команда под контролем: Как достигать результатов вместе, Глава 4, https://www.litres.ru/book/sergey-baramba-33344/proektnaya-komanda-pod-kontrolem-kak-dostigat-rezulta-71745784/

10

Барамба С., Проектная команда под контролем: Как достигать результатов вместе. 2025

11

Легитимизировать - Признать законным, правомерным.

12

Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th ed.). Newtown Square, PA: Author.

13

Более подробно можно с формулами ознакомится книге Барамба С., «Проектная команда под контролем: Как достигать результатов вместе», 2025, https://www.litres.ru/71745784/

14

ROI – Return of Investvent, термин из финансов показывающий насколько эффективная инвестиция.

15

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

16

ЛПР – сокращение обозначающее Лицо принимающее решение.

17

Подробнее про цвета коммуникаций читайте в Главе 1

18

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

19

Паразитные каналы – термин пришёл из электроники где возникают различные наводки на оборудование ухудшающие их характеристики, а в современной бизнес-среде обозначающий передачу информации по каналам связи, не предусмотренной схемой или регламентом. Часто в компаниях официальным каналом связи является электронная почта, она закреплена в уставе и договоре, но сотрудникам удобнее решать вопрос в Whatsapp или Telegram. Вот последние и будут паразитными каналами, потом что сложно установить всю картину, и они производят "наводку" на общий объём информации, внося дополнения.

20

Барамба С. Проектная команда под контролем: Как достигать результатов вместе. 2025, https://www.litres.ru/book/sergey-baramba-33344/proektnaya-komanda-pod-kontrolem-kak-dostigat-rezulta-71745784/