×

«Поймите личные мотивы клиента». Как определить бизнес-среду заказчика и общаться с ним эффективно

[Об авторе: Дмитрий Абрамов — delivery-директор финансовой практики DataArt. Руководит портфелем проектов для крупных бизнесов из финансовой индустрии. Работает в IТ-менеджменте с 2003 года, был в ролях CIO и CTO перед тем, как заняться менеджментом заказной разработки. Сталкивался со многими видами компаний и бизнес-процессов, много внимания уделяет философии работы]

В этой статье рассмотрим, как определить бизнес-среду, в которой существует заказчик, и понять личные мотивы представителей клиента.

Общение между командами разработчиков и заказчиком всегда в фокусе моего профессионального интереса. Сейчас о soft skills в IT говорят очень много, но чаще об их необходимости для инженеров рассуждают HR или проджект-менеджеры. Среди тех, кто пишет или тестирует код, мнения разделились: не все готовы признать, что успех как в проектах, так и в карьере зависит не только от технических знаний. Но вне зависимости от личных убеждений, для инженера здесь есть прозаический аспект: IT-индустрия матереет и разрастается, сюда стремятся многие, и в условиях жесткой конкуренции просто разбираться в технологии бывает недостаточно.

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

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

Типы бизнеса

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

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

Структура коммуникации

Как правило, в контексте своих проектов мы общаемся с CIO и COO заказчика, которых в идеальном мире волнуют исключительно интересы компании. На деле же у каждого из них есть и свои личные цели: кто-то мечтает запустить проект с блокчейном, чтобы потом щеголять им в LinkedIn, другой хочет спокойно уйти на пенсию, и чтобы до этого момента никто его не трогал. Мало того, в процессе разработки и поставки продукта мы общаемся еще со многими ключевыми сотрудниками заказчика: это могут быть бизнес-пользователи, архитекторы, руководители разработки, вендор-менеджеры и т. д. Не стоит по умолчанию считать всех этих людей заинтересованным в том же, в чём заинтересованы мы или их собственные боссы. Цели и желания у них, конечно, разные, и ради успеха проекта придется их учесть.

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

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

Как не запутаться

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

  1. Как заказчик предпочитает строить общение в проекте?
  2. Был ли у заказчика опыт работы с другими командами и продуктами? Что они хотели бы изменить по сравнению с прошлым опытом?
  3. Есть ли у стейкхолдеров пожелания по выбору инструментов, фреймворков и подходов к написанию кода или они ожидают предложения вариантов от нас?
  4. Давно ли люди, с которыми вы непосредственно общаетесь, работают в компании и какой у них был опыт работы перед ней?

В общем, спрашивайте обо всём, старайтесь лучше представить себе структуру отношений и каждого конкретного человека «с той стороны». В конце концов именно вопросы помогут избежать финансовых рисков. Если мы не задаем вопросы, то продолжаем жить в выдуманной реальности и работать внутри системы допущений. Чем больше допущений мы делаем (а допущение на допущении создает нездоровую структуру), тем больше вероятность того, что рано или поздно кто-то откажется платить за наш труд. И скорее всего будет прав, ведь делая сервис или продукт для бизнеса, который нам непонятен, мы, скорее всего, потерпим неудачу.

Каковы цели проекта

Разобравшись со структурой и личными целями заинтересованных лиц, пора переходить к целям вашего совместного проекта. К примеру, клиент хочет поработать с новой технологией вместе с другой важной компанией, для него важно указать это на официальном сайте и чтобы о проекте написали СМИ. Цель — маркетинг, реального запуска на рынке не предполагается. Такой проект можно сделать наскоро, все равно его скоро закроют и забудут. В этой ситуации делать допущение, что нужна глубокая продуманная архитектура, было бы в корне неверно. Можно опрометчиво потратить ресурсы на то, что просто не пригодится. Да, многие из нас перфекционисты, и конечно, делать свою работу хочется максимально хорошо. Но оптимальным решением будет как раз здравая оценка целей заказчика, которая позволит реализовать проект с выгодой для всех.

Главное — доверие

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

Классический пример: у одной команды не ладились коммуникации с заказчиком. Тот периодически жаловался Delivery- и Engagement-менеджерам, что не понимает, чем занята команда. Стали разбираться. Оказывается, команда регулярно информировала клиента обо всем — они писали подробные отчеты о сделанном, но в понятных только им терминах — «скрам», «велосити», «джира айтемс», «код ревью» и т. д. Никто даже не задумался, что репорт читает CEO заказчика, который не разбирается в технологии и интересуется только тем, что случилось с продуктом, за который он платит, и будет ли работа закончена в срок. В подобных случаях технические детали должны оставаться внутри команды разработчиков.

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

Трудности перевода

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

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

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

Самое же обидное, когда стороны не поняли друг друга «всего лишь» из-за несовершенства владения языком. За всеми этими would, should, can, may и must порой сложно бывает точно уловить, кто что мог бы сделать, а что сделать твёрдо пообещал. Зафиксировав все частности письменно и получив подтверждение от заинтересованных сторон, вы легко застрахуетесь от ненужных рисков.

Ложные тезисы

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

  • «Сами догадаются». Нет, не догадаются. Это не интеллектуальная игра, в которой клиент должен сам искать ответы на вопросы.
  • «Это понятно любому». Аналогично. Технические аспекты продукта или наши внутренние процессы — вещи неочевидные.
  • «Все читают почту». Увы, это не так. Письмо легко пропустить в общем потоке, поэтому через некоторое время смело уточняйте, все ли видели ваше сообщение. Можете даже продублировать то же самое письмо.

FWD:FWD:FWD

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

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

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

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

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

Немного о смысле жизни

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

Туман неизвестности

Еще один важный момент — изменчивость. Тренды меняются не ежегодно, но ежемесячно, а порой и быстрее. В любой момент может произойти событие, которое перетряхнет индустрию и заставит пересмотреть все планы, как это было, к примеру, с GDPR. Новые тенденции быстро разлетаются по всему миру: AI в коммерческой сфере, зеленые технологии, блокчейн, машинное обучение. Есть усиливающаяся децентрализация, которая сегментирует интернет не только по странам, но и по интересам: соцсети и таргетинг формируют для каждого пользователя собственное информационное поле. Добавьте к этому стартапы с новыми технологиями, которые грозят разительнымии переменами уже существующему бизнесу — уследить за всеми переменами бывает очень сложно. И, как ни странно, главный вывод здесь простой — спланировать будущее практически невозможно.

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




16 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

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

На рынке присутствуют инструменты совместной работы которые позволяют организовывать эффективную и безопасную совместную работу на основе чатов

Электронная почта в цивилизованных странах признаётся судами в качестве доказательной базы при хозяйственных спорах. А вот насчёт чатов и прочего — сильно не уверен.

Конечно, до судов никто старается не доводить, но, поверьте — бывают случаи, когда подобный «козырь» очень и очень пригождается

Чаты также признаются, и не только в хозяйственных спорах но и в уголовных делах.

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

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

«Все читают почту». Увы, это не так.

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

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

но для собственной безопасности лучше считать, что остальные их не соблюдают.

ну это в Родине там да

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

І ще аутсорсерам варто перестати називати позиції «продакт овнер», якщо там задача транслювати те що сказав дядько із закордону))

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

У наших менеджерів всередині живе закореніле «краще нічого не робити, тоді нічого не поламається». Інколи так клієнт може не потребувати порад в бізнесі)), але наприклад для того щоб продукт розвивався, треба додавати технічні рішення, які треба вміло і під натиском пропихати на верхній рівень замовника, а цього наші бояться як вогню)) Хоча я впевнений, якщо навести приклад і певні КПІ які можуть покращитись, то замовник просто б охринів, що про його бізнес хтось дбає, а не тільки доїть))

Вот я в ДатаАрте (да и в других компаниях) прямо знаю людей и проекты, в которых Product Ownership выполняется на стороне сервисной/аутсорсной команды. А во многих аспектах бизнеса (того самого «далекого и недостижимого») мы еще и консультируем клиентов.
Время, когда все думали, что Продакт-овнершип это магия уже давно прошло. Это набор процессов и инструментов. Да, они сильно завязаны на общение, но оно не обязательно должно быть личным.
Ну и в заключение, одно из правил продукт-менеджмента о том, что вы подвержены «искажению выборки»: Если вы не видели роли РО в сервисной команде, это не значит что ее нет :)

Начніть думати про продажі замовника, про його клієнтів і тоді можливо у вас буде розуміння, що потрібно замовнику))
Якщо у вас не трекаються основні КРІ замовника, ну то ви чорноробочі, хоч з бабосіками.

Дивно як аутсорсери вперто цього не хочуть робити і вважають що вся біда в ненастроєному скрамі)))

P.S. Сама стаття хороша, але наші розробники і менеджери дуже далекі від потреб замовника.

Мабуть саме те, що "

наші розробники і менеджери дуже далекі від потреб замовника

" і стало приводом до написання ціеї статті?

Не спорю, статтю підтримую, тільки там дуже делікатно) А насправді це заслуговує ременя))

Підписатись на коментарі