Читать книгу Триединство проекта: Стейкхолдеры, Команда, Коммуникации - Сергей Барамба - Страница 25

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

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

«Легко»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"Прошу…".

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

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

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

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

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

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

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

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

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

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

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

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

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