Тонкости переговоров в ИТ: как проектной команде договориться с клиентом

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

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

Отсылка к корпоративным регламентам и процедурам

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

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

Границы обязанностей, прописанные в договоре

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

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

Взаимные уступки

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

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

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

Постоянное информирование

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

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

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

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

Четкая формулировка задачи

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

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

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

Наличие «плана Б»

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

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

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