Переговоры в цифре: о чем нужно знать в бизнес-коммуникации IT-компаний и клиентов

Согласно исследованию ITFB, 52% IT-специалистов считают умение договариваться одним из наиболее ценных навыков для развития в tech-индустрии. Специфика сферы предполагает использование мало понятной бизнесу терминологии и обсуждение сложных продуктов. Это затрудняет переговоры IT-компаний с заказчиками и кратно увеличивает риски несоответствия ожиданий и реальности. Расскажу о том, как особенности индустрии отражаются на разных этапах переговоров с бизнес-заказчиками.

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

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

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

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

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

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

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

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

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

Именно в этом блоке мы анализировали, почему клиент считает, что демонстрируемый функционал не отвечает его ожиданиям, и подготовили для него вопросы:

Бюджет: «что мы можем потратить?». Решить, какие ресурсы и в каком объеме мы готовы отдать проекту: время, энергию, деньги, эмоции.

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

Решение: «как мы планируем действовать?». Сформулировать дальнейшие конкретные шаги. Проанализировать варианты развития событий, исходя из ответов заказчика и нашего понимания ситуации.

Мы ответили сами себе на вопросы:

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

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

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

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

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

Минимальный. Позволяет закрыть ключевые операционные вопросы.

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

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

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

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

Сегодня такие ситуации не редкость: бизнес-заказчики не всегда понимают свои потребности на быстро меняющемся рынке ERP-систем. В 2023 году сектор Enterprise-разработок в России вырос до 90 миллиардов рублей, и ожидается 15-20% рост к концу 2024 года.

Анализируя взаимодействие с клиентами, мы открыли направление IT-консалтинга и аналитики, предоставляя услуги по системному и бизнес-аудиту, UX/UI веб-аналитике и CustDev. Теперь перед реализацией желаний заказчика мы подбираем оптимальные продукты и решения, что помогает минимизировать расхождения между результатом и ожиданиями.