Личный опыт: как наладить коммуникацию с заказчиком

С заказчиками в IT-компаниях обычно много общаются менеджеры проектов и бизнес-аналитики – это их основная работа. Инженеры, как правило, с ними взаимодействуют меньше, но это не значит, что налаживать отношения не нужно. Здесь правила кажутся простыми – внимательно слушать, подробно объяснять свою точку зрения, – но соблюдать их на практике бывает сложно. Если уделить коммуникации чуть больше внимания, можно испытывать меньше стресса и быстрее решать проблемы на проекте. Анастасия Ханина – менеджер проектов в ЕРАМ – поделилась с «Клевером» несколькими универсальными советами на тему того, как наладить общение с заказчиками.


 

Инициируйте регулярные встречи с самого начала проекта

 

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

 

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

 

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

 

Объясняйте свои идеи как можно подробнее

 

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

 

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

 

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

 

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

 

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

 

Не отвергайте идеи заказчика сразу

 

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

 

 

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

 

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

 

Постарайтесь быть открытыми, даже если допустили ошибку

 

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

 

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

 

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

 

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

 

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

 

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

 

Не шутите, если не уверены, что это оценят

 

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

 

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

 

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

 

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

 

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

 

Источник фото: unsplash.com