[Об авторе: Дмитрий Абрамов — delivery-директор финансовой практики DataArt. Руководит портфелем проектов для крупных бизнесов из финансовой индустрии. Работает в IТ-менеджменте с 2003 года, был в ролях CIO и CTO перед тем, как заняться менеджментом заказной разработки. Сталкивался со многими видами компаний и бизнес-процессов, много внимания уделяет философии работы]
В этой статье рассмотрим, как определить бизнес-среду, в которой существует заказчик, и понять личные мотивы представителей клиента.
Общение между командами разработчиков и заказчиком всегда в фокусе моего профессионального интереса. Сейчас о soft skills в IT говорят очень много, но чаще об их необходимости для инженеров рассуждают HR или проджект-менеджеры. Среди тех, кто пишет или тестирует код, мнения разделились: не все готовы признать, что успех как в проектах, так и в карьере зависит не только от технических знаний. Но вне зависимости от личных убеждений, для инженера здесь есть прозаический аспект: IT-индустрия матереет и разрастается, сюда стремятся многие, и в условиях жесткой конкуренции просто разбираться в технологии бывает недостаточно.
Успех проекта зависит не только от качества кода, но и от эффективности коммуникации с клиентом, причем его чаще представляет не один человек, а целая группа. Казалось бы, эта часть работы ложится на плечи PM и лидов проекта, но в современных условиях за нее отвечает вся команда разработки. Это особенно актуально для сервисных компаний.
Для того, чтобы ваши «мягкие скиллы» нашли применение, стоит проанализировать бизнес клиента в целом и разобраться, с компанией какого типа мы имеем дело, с кем персонально будем поддерживать контакт, чего лично эти конкретные люди хотят от своей компании, от нас и жизни вообще. Ответив на эти вопросы, можно определить ту самую бизнес-среду, в которой существует компания и которую нам необходимо понять. Главная задача — понять бизнес клиента, его структуру и личные мотивы каждого участника коммуникации.
Типы бизнеса
Исходя из типа бизнеса, можно установить ожидания клиента от коммуникаций с нами. Два ярких примера типов бизнеса: enterprise и startup. Энтерпрайз, скорее всего, уже давно на рынке, для него значимы бюрократические ритуалы, а структура здесь часто важнее человека. Мы как поставщики сервиса вряд ли заметно влияем на такой бизнес в целом. Наши продукты всего лишь одни из многих в их ландшафте. На первый план выходит то, как мы общаемся, как выглядим, как и с кем строим коммуникации.
Стартап, разумеется, более демократичен. Здесь мы влияем на бизнес: качество нашего продукта, его финальный вариант и итоговые бизнес-показатели критически важны для заказчика. Общение зачастую строится напрямую с основателями и совладельцами компании, и сложных организационных структур с их стороны нет. Такие бизнесы больше заинтересованы в том, что мы делаем, и в скорости выхода продукта на рынок, чем в ритуалах и церемониях.
Структура коммуникации
Как правило, в контексте своих проектов мы общаемся с CIOи COOзаказчика, которых в идеальном мире волнуют исключительно интересы компании. На деле же у каждого из них есть и свои личные цели: кто-то мечтает запустить проект с блокчейном, чтобы потом щеголять им в LinkedIn, другой хочет спокойно уйти на пенсию, и чтобы до этого момента никто его не трогал. Мало того, в процессе разработки и поставки продукта мы общаемся еще со многими ключевыми сотрудниками заказчика: это могут быть бизнес-пользователи, архитекторы, руководители разработки, вендор-менеджеры и т. д. Не стоит по умолчанию считать всех этих людей заинтересованным в том же, в чём заинтересованы мы или их собственные боссы. Цели и желания у них, конечно, разные, и ради успеха проекта придется их учесть.
Наконец, разобравшись с мотивацией всех перечисленных выше людей, мы думаем, что поняли картину мира нашего заказчика, сформулировали предложения, сделали solution design и, возможно, даже что-то продали или заделиверили. Здорово, правда? Но тут оказалось, что на пути к запуску нашего продукта в прод есть еще совет директоров с собственным представлением о прекрасном и отдел маркетинга, якобы готовый поддержать любые проекты, которые повысят конверсию по воронке, но в реальности мечтающий только о Каннском льве за рекламный ролик.
Каждый участник процесса выберет из предложенных вариантов тот, который приблизит его к личным целям. Так устроен мозг человека — никто не откажется от своих амбиций. В итоге после долгой работы мы оказываемся в совершенно новой для нас бизнес-среде, требующей других решений.
Как не запутаться
Прочитать бриф о компании прежде, чем вы начнете общаться с ее представителями. Сходить на их сайт, изучить, что они сами пишут о своем бизнесе и кого называют своими клиентами. При общении, особенно на старте, старайтесь задавать больше вопросов, например:
- Как заказчик предпочитает строить общение в проекте?
- Был ли у заказчика опыт работы с другими командами и продуктами? Что они хотели бы изменить по сравнению с прошлым опытом?
- Есть ли у стейкхолдеров пожелания по выбору инструментов, фреймворков и подходов к написанию кода или они ожидают предложения вариантов от нас?
- Давно ли люди, с которыми вы непосредственно общаетесь, работают в компании и какой у них был опыт работы перед ней?
В общем, спрашивайте обо всём, старайтесь лучше представить себе структуру отношений и каждого конкретного человека «с той стороны». В конце концов именно вопросы помогут избежать финансовых рисков. Если мы не задаем вопросы, то продолжаем жить в выдуманной реальности и работать внутри системы допущений. Чем больше допущений мы делаем (а допущение на допущении создает нездоровую структуру), тем больше вероятность того, что рано или поздно кто-то откажется платить за наш труд. И скорее всего будет прав, ведь делая сервис или продукт для бизнеса, который нам непонятен, мы, скорее всего, потерпим неудачу.
Каковы цели проекта
Разобравшись со структурой и личными целями заинтересованных лиц, пора переходить к целям вашего совместного проекта. К примеру, клиент хочет поработать с новой технологией вместе с другой важной компанией, для него важно указать это на официальном сайте и чтобы о проекте написали СМИ. Цель — маркетинг, реального запуска на рынке не предполагается. Такой проект можно сделать наскоро, все равно его скоро закроют и забудут. В этой ситуации делать допущение, что нужна глубокая продуманная архитектура, было бы в корне неверно. Можно опрометчиво потратить ресурсы на то, что просто не пригодится. Да, многие из нас перфекционисты, и конечно, делать свою работу хочется максимально хорошо. Но оптимальным решением будет как раз здравая оценка целей заказчика, которая позволит реализовать проект с выгодой для всех.
Главное — доверие
Построение доверительных отношений с клиентом не только этически важно, но и прибыльно. Чтобы нам доверяли нужно, чтобы нас понимали. Для этого мы должны говорить на понятном заказчику языке. Иными словами, с клиентами нужно говорить на языке бизнеса, используя минимум технических терминов.
Классический пример: у одной команды не ладились коммуникации с заказчиком. Тот периодически жаловался Delivery- и Engagement-менеджерам, что не понимает, чем занята команда. Стали разбираться. Оказывается, команда регулярно информировала клиента обо всем — они писали подробные отчеты о сделанном, но в понятных только им терминах — «скрам», «велосити», «джира айтемс», «код ревью» и т. д. Никто даже не задумался, что репорт читает CEO заказчика, который не разбирается в технологии и интересуется только тем, что случилось с продуктом, за который он платит, и будет ли работа закончена в срок. В подобных случаях технические детали должны оставаться внутри команды разработчиков.
Еще один совет — будьте готовы проявить лояльность. Точно стоит запомнить слоган клиента и сюжет его последней рекламы. Не нужно в присутствии клиента расхваливать конкурентов или распространяться о недостатках его продукта. К вашему мнению все равно не прислушаются, а отношения будут испорчены.
Трудности перевода
Многие клиенты, которые работают с Восточной Европой, отмечают, что наши люди не привыкли отвечать на письма. Если вопросов нет, мы склонны считать диалог оконченным, и это ошибка. Важно не оставлять без ответа ни одного сообщения. Если вы не можете ответить немедленно, скажите об этом прямо и обозначьте, когда возможность для этого появится: «Отвечу через пару часов».
Множество коммуникационных рисков возникает из-за того, что мы проговариваем детали, но не ведем понятных всем записей. Недостаточный уровень владения языком или сам факт того, что устная речь — не самый совершенный инструмент передачи деловой информации, могут создать серьезные проблемы.
Нередки случаи, когда команда общается с заказчиком, выясняя сложные вопросы и договариваясь про детали реализации того или иного решения. В процессе беседы неизбежно возникают соглашения о границах ответственности: это будем делать мы, а это вы. Например, наша команда деплоит продукт на одно из окружений, а за дальнейшее раскатывание кода, синхронизацию данных и конфигураций отвечает заказчик. Проговорив всё устно на созвоне, стороны разошлись довольными, но затем, во время выкатывания релиза, оказалось, что все поняли друг друга по-разному, и заказчик считал, что данные на промежуточном окружении обновит наша команда. Поэтому девопс с их стороны сегодня в отпуске, а наш релиз не будет доставлен вовремя. Сроки сорваны, скандал, разбирательства и неприятный осадок гарантированы. Доказать постфактум что-то, аргументируя свою правоту устными переговорами, не удастся.
Самое же обидное, когда стороны не поняли друг друга «всего лишь» из-за несовершенства владения языком. За всеми этими would, should, can, may и must порой сложно бывает точно уловить, кто что мог бы сделать, а что сделать твёрдо пообещал. Зафиксировав все частности письменно и получив подтверждение от заинтересованных сторон, вы легко застрахуетесь от ненужных рисков.
Ложные тезисы
Можно легко составить список фраз, которые часто и с удовольствием используют эксперты, считая некоторые вещи очевидными. Вооружившись всего несколькими тезисами, можно удивительно быстро и легко разрушить даже сложившиеся доверительные отношения.
- «Сами догадаются».Нет, не догадаются. Это не интеллектуальная игра, в которой клиент должен сам искать ответы на вопросы.
- «Это понятно любому». Аналогично. Технические аспекты продукта или наши внутренние процессы — вещи неочевидные.
- «Все читают почту».Увы, это не так. Письмо легко пропустить в общем потоке, поэтому через некоторое время смело уточняйте, все ли видели ваше сообщение. Можете даже продублировать то же самое письмо.
FWD:FWD:FWD
Внимательно следите за каналами общения. Стейкхолдеров много, держать всех в курсе деталей продвижения проекта не нужно, а иногда даже вредно. Кто-то отвечает на любые письма, даже если его адрес просто стоит в копии, кто-то участвует в общей переписке исключительно из личных интересов. Важно понять, кого нужно включить в обсуждение вопроса, а кого, скорее, не стоит. Кого-то нужно позвать на встречу, кому-то отправить личное письмо, кому-то позвонить, а кого-то позвать на общий созвон, кого-то нужно приглашать на демо, кого-то — на ретроспективы и т. д.
Очень важно информировать клиентов о статусе работы, иначе они начнут нервничать, решат, что пропускают нечто важное и начнут задавать вопросы, отнимая время и расшатывая ваши нервы.
Есть еще один замечательный нюанс. Необходимо каждый раз думать о том, какая аудитория присутствует в вашем канале коммуникации в конкретный момент. Если вы пишете письмо на 15 человек или сообщаете в групповом чате важную негативную информацию (перенос сроков, снижение качества, уязвимость системы) — разберитесь, кому именно вы это говорите.
Бывают ситуации, когда один из представителей заказчика зависит от вашего сообщения, скорее всего, именно с этим человеком, вы и поддерживаете непосредственный контакт. Если среди аудитории есть его руководство или, возможно, недоброжелатели, вы можете нечаянно его подставить. Человека, который за вас поручился. Лучше заранее договориться с ним, как доносить месседж до других участников коммуникации. Если этого не сделать, то можно разрушить отношения внутри компании и ухудшить собственную репутацию.
В моей практике был неприятный случай, когда я узнал, что параллельный проект заказчика, с которым мы жёстко конкурировали за ресурсы, задерживается. На очередных переговорах я, не долго думая, заявил: раз ваш второй проект не успевает в срок, не мешайте нам работать и дайте нам приоритет. Оказалось, что про срыв сроков второго проекта пока никто не знал, к этому не была готова большая часть подразделений заказчика, и своей поспешностью я сорвал подготовку спланированной минимизации последствий. Был скандал, которого вполне можно было избежать, немного подумав. Тот инцидент научил меня лучше просчитывать каналы коммуникаций и никогда не спешить с подобными новостями.
Немного о смысле жизни
Очень важно понять, для чего существует бизнес клиента и какова ваша роль в его бизнес-процессах. Для этого можно использовать очень простую методику: нужно несколько раз последовательно задать себе вопрос «зачем». Зачем существует наш клиент, его бизнес, что было бы, если бы этого бизнеса не существовало, зачем клиенту нужна наша компания, компании — наша команда, зачем нашей команде нужен я? Ответы на эти вопросы станут своеобразной матрицей при формировании коммуникации и ваших приоритетов в том, что вы делаете и как общаетесь с людьми.
Туман неизвестности
Еще один важный момент — изменчивость. Тренды меняются не ежегодно, но ежемесячно, а порой и быстрее. В любой момент может произойти событие, которое перетряхнет индустрию и заставит пересмотреть все планы, как это было, к примеру, с GDPR. Новые тенденции быстро разлетаются по всему миру: AI в коммерческой сфере, зеленые технологии, блокчейн, машинное обучение. Есть усиливающаяся децентрализация, которая сегментирует интернет не только по странам, но и по интересам: соцсети и таргетинг формируют для каждого пользователя собственное информационное поле. Добавьте к этому стартапы с новыми технологиями, которые грозят разительнымии переменами уже существующему бизнесу — уследить за всеми переменами бывает очень сложно. И, как ни странно, главный вывод здесь простой — спланировать будущее практически невозможно.
Допустим, в индустрии путешествий вся прекрасная система букинга с ее удобными сервисами, специально придуманными для максимального комфорта пользователей, не позволяет проводить полноценный мониторинг и планировать загрузку. Просто потому что кто-то до сих пор составляет план поездки, сидя с ручкой и блокнотом.
Нельзя сказать, что эта непредсказуемость приводит наших с вами заказчиков в панику или ступор. Просто они часто могут рассказать вам о будущем своего бизнеса не намного больше, чем вы сами. И если вы всегда начинаете общение, требуя дорожную карту на три года вперед, готовьтесь к отказу. Может быть, и раздражению.
Значит, искать, анализировать и делать прогнозы тоже придется самостоятельно. Просто писать код не получится — вам понадобится индустриальная экспертиза. Нужно проникать в то, что нужно клиенту, и пытаться понять тренды, существующие на рынке.