Здравствуйте! Я работаю проектным менеджером около года. Одни проекты складывались удачно — подводные камни не топили продукт, и теперь он живёт и развивается. Другие сопровождались непрофессиональным поведением и глупыми ошибками.

Однако мне нравится моя работа, и мне не лень покопаться в этих ошибках, чтобы найти их причину. А она, как правило, следующая: кто-то что-то не понял. Разработчик не понял задачу, клиент не понял команду, менеджер не понял смысл проекта, и так далее. Недопонимание ведёт к срыву сроков и бюджетов, к неправильным ожиданиям клиента, к недоумению конечных пользователей и к беспокойному сну менеджера.

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

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

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

Правило номер один: будь здесь и сейчас

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

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

Правило номер два: уважайте время своего собеседника

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

Правило номер три: готовьтесь ко встречам

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

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

Влад Коробов, CEO Лайв Тайпинг:

«Каждая встреча должна оставлять после себя документальное подтверждение того, что она состоялась. Поэтому встречи всегда нужно записывать — в процессе (например, с помощью Monosnap) или после. Самое простое — это подтвердить договорённость в письме, а ещё лучше, когда созданы задачи в системе управления. Мы пользуемся системами Trello, YouTrack и Basecamp).

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

Даже если менеджер владеет искусством экспромта, он проведёт всю встречу с ощущением неловкости, если не подготовится к ней.

Анонимно:

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

Правило номер четыре: овладейте рефлексивным слушанием

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

Иногда клиенту самому далеко до состояния божественного просветления. Он ругается и нервничает почём зря. А может быть, наоборот радуется вашему совместному успеху. В таких случаях нужно вести себя наоборот: пускать в ход нерефлексивное слушание. Говорите «Я тоже очень рад» или «Я сожалею, что это произошло», согласно кивайте и хмыкайте. Будьте эмпатичным, будьте в моменте с клиентом, переживайте его эмоцию — это сближает.

Правило номер пять: не доверяйте важную информацию своей памяти

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

Правило номер шесть: токсичные эмоции не нужны

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

Правило номер семь: доводите вовлечённость команды до максимума

Обязательно расскажите каждому участнику команды (даже пришедшему ради одной маленькой задачки), в чём соль проекта. Масштабы последствий неинформированности невозможно предсказать: так один мой проект из десятичасового превратился в полуторамесячный.

Ситуация была абсурдной: в одной команде со мной работал фрилансер, задача которого состояла в том, чтобы заменить в приложении тексты и картинки. В нормальной ситуации картинки обновлялись с сервера, но в период работы фрилансера сервер клиента «лежал». Фрилансер, решив, что так и надо, просто удалил из приложения всю серверную часть, а контент «зашил». В то время у меня было мало опыта, и подозрений, почему ему вдруг понадобилось больше времени, не возникло. И только когда от клиента пришло «А где кнопка “Обновить”?» я разобралась, что сделал фрилансер, и схватилась за голову.

Правило номер восемь: один язык на всех

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

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

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

Дарья Абрамова, менеджер Лайв Тайпинг:

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

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

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

Александра Абакумова, менеджер Лайв Тайпинг.

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

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

«Позитив» — что удачного всё же есть в идее клиента («Красный цвет можно сделать акцентом и добавить в некоторые другие элементы»)
«Интерес» — что из предложенного можно обыграть иначе («Анимацию можно сделать вот так, и она не будет навязчивой, но привлечёт внимание»)
«Негатив» — от чего вы решительно отказываетесь: «Вот для примера скриншоты топовых интернет-магазинов. Смотрите, у них нет большой кнопки “Купить” в центре страницы, потому что (а)…, б)…, в)…). Я не советую поступать так».

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

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

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

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

Подведём итоги

С задачами на вашем проекте всё будет ок, если вы:

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

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

Автор:

Источник