Переговоры с клиентом, манипуляции и выбивание уступок

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

Я не буду описывать все возможные книжные переговорные сценарии и приёмы — с базой можно легко ознакомиться по многочисленным бесплатным видео тренингам (чаще всего они сделаны для продавцов чего либо). Расскажу какие приемы применяли клиенты в моей практике.

  • «У вас всё плохо». Клиент жалуется на низкое качество результатов (не важно из-за чего возникли баги, но они гарантированно будут в 99% проектов) и поднимая скандал выбивает себе скидку или дополнительную бесплатную работу.
    Что делать: в первую очередь, проанализируйте что является основной причиной низкого качества результата (низкая квалификация исполнителей, недостаточная детализация требований и так далее), исходя их этого делайте выводы, обоснованы ли претензии клиента или он действительно пытается использовать это чтобы выторговать себе у вас скидку или лучшие условия. Повышайте качество, чтобы убрать основания для подобных манипуляций. Понятно, что идеального качества достичь невозможно, но возможно выйти на приемлемый уровень, когда подобные претензии клиента будут выглядеть слишком слабо для оправдания дополнительного задабривания клиента.
  • «Сделайте мне хорошо». Клиент дает размытые требования, постоянно меняет бизнес логику проекта, отказывается утверждать выбранную архитектуру. В итоге постоянно возникающих споров «это не баг, а запрос на изменение (CR)» клиент выходит на конфликт и выбивает себе некоторое количество неоцененной изначально работы бесплатно или со скидкой.
    Что делать: следить за тем, как проходит сбор требований, утверждать максимально полную документацию до начала разработки. Если сбор требований идет параллельно с разработкой — использовать метод «набегающей волны», уточняя требования на следующую итерацию. Если требования не утверждены окончательно до начала разработки — понимать риски разработки по таким требованиям. Договариваться с клиентам заранее о времени ответа и сроках сбора требований. Четко оговаривать, что если клиент затягивает сбор требований, то затягивается и релиз проекта.
  • «Я не буду за это платить и на вас в суд подам!». Клиент использует слабые места заключенного контракта, для получения выгоды для себя в виде бесплатной работы, скидки или существенной отсрочки платежа. Многие крупные корпорации не будут использовать шаблон контракта вашей компании, а будут вынуждать подписать свой, иначе они просто не будут с вами работать. Это позволяет им закладывать туда существенные рычаги давления на партнера. Например, в контрактах с компанией майкрософт прописано, что она оплачивает работу только после полной приёмки результатов, то есть когда менеджер с их стороны согласится с тем, что работа выполнена. Процедура приёмки и критерии, само собой, прописаны только в самом общем виде. В купе с тем, что код хранится в их репозитории с самого начала, если что-то пойдет не так с вашей стороны, они могут оставить у себя код до этого момента и не заплатить вам ни цента.
    Что делать: внимательно изучайте контракт, чем больше опытных людей в вашей компании проверят контракт до подписания — тем лучше. Решайте, принимаете вы некоторые риски контракта, как описанные выше или нет до начала работы по проекту. Список обязательных вещей в контракте достаточно объемный, постоянно улучшайте ваш типовой контракт после каждого проекта и максимально используйте чужой опыт — это дешевле.
    Реальный кейс: проект, связанный с разработкой прототипа девайса для автомобилей, контракт составлял сам заказчик, отказавшись использовать типовой контракт. Несмотря на вроде бы тщательную проверку контракта, в итоге в нем все равно осталось много плохо сформулированных формулировок, которые позволили клиенту требовать больше, чем было изначально оговорено, на возражения от отвечал «я этот контракт сам под себя составлял, я точно знаю что и как там написано».

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

Интересный кейс по манипуляции: клиент участвовал в разработке архитектуры и многократно менял способ реализации того или иного функционала, используя тот факт, что в конракте не было четко прописаны требования к времени отклика и пределу нагрузки, которые должен выдерживать интерфейс. Сроки проекта были многократно превышены по инициативе клиента. Естественно прямо он никогда об этом не просил, но для реализации того, что он задумал, сроки приходилось сдвигать. В конце он обвинил менджера, что тот целых пару дней тянул с ответом, что запрос клиента — не баг, а запрос на изменение и обвинил менеджера в уничтожении проекта, поскольку проект не укладывается в последние крайние сроки. В результате клиент получил несколько тысяч часов бесплатной работы и, вдобавок, моральное право требовать у нас уступок в дальнейшем, потому что мы «виноваты» в затягивании этого проекта. Клиент часто использовал тактику «кнута» и «пряника», то рассказывая, какая прекрасная, замечательная и профессиональная команда с нашей стороны, то угрожая контрактом и неоплатой в случаях оспаривания его новых запросов относительно того, входит ли он в изначальный объем работ.

Добавить комментарий