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

Строго следовать распоряжениям своего руководителя;

Докладывать только своему руководителю по определённому им каналу связи;

Начать вести журнал своих действий (например, запись экрана);

Запрещается

Отвечать на любые претензии или провокации;

Реагировать на прямые распоряжение руководителей других подразделений и поддаваться давлению с их стороны;

Нарушать распоряжение о "радиомолчании";

Отвечать на телефонные звонки;

Включать во внутреннее общение внешних получателей;

Без распоряжения выносить наружу какую-либо информацию;

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

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

Briefback и Backbrief

В кризисные моменты хорошей практикой которая должна стать привычкой для РП можно смело рекомендовать применять «Briefback» и «Backbrief».

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

При этом, хоть термины схожие – в них есть небольшая разница

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

Backbrief — более структурированная практика, получатель не просто должен пересказать, а ещё и представляет своё понимание задачи и план действий по её выполнению, дополняет действиями и деталями, которые не были названы постановщиком задачи. Цель: убедиться, что в зоне «свободного плавания» сотрудник будет действовать корректно, в рамках поставленной цели и ограничений, это глубокая "проверка на выход" (не только понял, но и знает, как делать).

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

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

Такая практика - это очень эффективный инструмент борьбы с неопределённостью. Лучше не экономить 3-5 минут, но получить обратную связь как понята исполнителем задача.

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

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

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

В целом можно затронуть несколько дополнительных типов направлений коммуникаций внутри и вне команды:

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

Плохой практикой работы РП является создавать задачу в информационной системе, все детально в ней расписать, а потом позвать исполнителя на встречу и все что написано в задаче рассказать ещё раз, уже голосом. Получается, что РП дважды выполняет работу, сначала через клавиатуру, потом через Face-To-Face встречу, повышая себестоимость управления. Для фиксации в виде задачи в системе, можно использовать такой подход – РП устно даёт распоряжение, а последней фразой просит зафиксировать что было сказано устно в задаче. Таким образом появляется доп. контроль, что задача понята, получается такой разнесённый во времени BackBrief.

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

Какие способы и инструменты помогут:

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

Создание положительного микроклимата и мотивации в команде за счёт оценки стейкхолдерами их работы.

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

Глава 3. Управление внешними и внутренними коммуникациями

Ценность молчания или 8 фраз которые не должен произносить РП.

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

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

«Легко»

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

Когда РП говорит "это легко сделать", он совершает акт семантического вандализма по отношению к работе специалистов.

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

Реакция команды: "Если то, что мы делаем — "легко", значит, и мы сами как специалисты ничего не стоим. Нашу экспертизу не уважают". Это прямая дорога к демотивации и выгоранию. Зачем выкладываться, если результат всё равно назовут "простым"?

Пример: После двух дней решения нетривиальной задачи по оптимизации запроса к базе данных, РП в ответ на вопрос заказчика говорит: "Да, мы там кое-что легко поправили, теперь всё летает". Для разработчика, который провёл 16 часов в глубоком анализе, это — плевок в душу.

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

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

Признание сложности + Уважение к ресурсам + Фокус на решении.

Пример трансформации:

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

Говорите: "Перед нами задача по редизайну главной страницы. Понимаю, что даже точечные изменения выльются в серьёзную работу: нужно будет провести юзабилити-аудит текущего состояния, согласовать правки с маркетингом и backend-разработчиками, аккуратно перенести функционал. Это потребует вашего внимания и времени на стыковки в течение этой недели. Давайте оценим вместе, как распределить эту нагрузку, чтобы сохранить фокус на других текущих проектах. Ваша экспертиза в деталях здесь критически важна".

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

Рис. 1.7. Замена слова "легко" на повышающие ценность фразы

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

Как обычно, немножко «чёрной магии». Использование осознанной противоположности слову «Легко» - умение сразу, без анализа, в лоб просителю сказать: "Это сложная, комплексная задача, требующая тщательной работы, и мы можем это сделать". И если от первого слова надо просто избавиться, то второе — это уже не просто слово, а инструмент. Инструмент, которым нужно уметь пользоваться с умом.

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

Зачем может полезно сознательно подчёркивать сложность?

Чтобы отсеять ерунду. Когда к вам приходят с просьбой "сделать какую-нибудь кнопочку", а вы в ответ начинаете рассказывать про анализ данных, согласования с другими отделами и нагрузочное тестирование — запрос моментально становится серьёзнее. Инициатору придётся самому подумать, действительно ли ему это так нужно, или можно обойтись. Это фильтр, который экономит время и силы команды.

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

Чтобы защитить команду и дать ей время. Заложив в самом начале, что задача нетривиальная, вы сразу создаете правильные ожидания. Тебе поверят, что на это нужно не два дня, а две недели. Это "воздух" для манёвра, защита от авралов и возможность сделать работу качественно, а не костылями.

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

Важное предостережение: Не переиграть. Если вы начнёте описывать как "сложнейшую" каждую вторую задачу, вы очень быстро:

- Потеряете доверие. Вас раскусят, и ваши слова перестанут иметь вес.

- Создадите атмосферу постоянного героизма. Команда выгорит, а заказчик начнёт думать, что вы не справляетесь с базовыми вещами.

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

"Я тебе помогу это сделать"

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

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

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

"Прошу...".

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

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

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

"Мне приказали..."

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

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

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

"Генеральный директор мимолетом вам сообщил что все сотрудники вашего подразделения должны завтра прийти на работу во всем зеленом. Объяснить причину своего решения у него не было времени и уточнить ее уже не представляется возможным. Ваша задача донести информацию до сведения сотрудников вашего подразделения. Какую речь вы произнесете перед ними?".

Вот та ситуация, где можно выбрать между передачей "непонятного распоряжения" руководства вниз подчиненным "As Is" или ставить задачу от себя. В первом варианте на неудобные вопросы "почему-зачем-откуда такая идея", придется придумывать и возможно даже от себя согласиться с бредовостью данной идеи, которая посетила и вас во время встречи с руководителем, если такая ситуация и вправду произошла. С управленческой точки зрения второй вариант требует больше силы и уверенности в себе для руководителя. Вполне приемлемым в данной ситуации будет такой вариант обращения: "Коллеги, завтра всем без исключения требуется прийти в зеленой одежде. На возникшие в ваших головах ключевые вопросы хочу сразу ответить. На вопрос "Зачем? –– Я так захотел и это всё. А на второй вопрос, "А что будет если не выполнить распоряжение?" - я бы вам крайне не рекомендовал проверять это. Остальные вопросы считаю не существенными и не будет на них отвечать".

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

"Это всe виноваты мои подчиненные"

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

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

"Раз и на всегда"

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

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

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

"Я тебе сейчас докажу...."

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

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

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

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

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

"А ты помнишь, что должен к такому-то числу сделать то-то и то-то"

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

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

Если есть беспокойство о состоянии задачи, достаточно в календаре у себя и сотрудника прошить "точку контроля" на которой получить полный отчет том, как движется задача. Достаточно заранее «бросить» встречу, в теме которой указать «Промежуточный контроль по задаче …»

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