Обманутые ожидания

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

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

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

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

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

В-четвертых, необходимо сразу проговорить с заказчиком условия ограничений проекта и доработок. Например, если вскроются дополнительные требования в процессе проектирования, то они могут быть учтены, если их суммарная стоимость не будет превышать 10% от стоимости работ по проекту (тем самым, фактически, предоставляется скидка на работы). Иначе – дополнительное соглашение или новый договор.

В-пятых, необходимо максимально продумать, проговорить и прописать в документах техническую реализацию, особенно нетиповых вещей (интеграция, миграция данных). Часто при миграции данных могут всплыть разногласия в понимании типов реквизитов (клиент хочет выгрузить данные в справочник, а исполнитель рассчитывал в текстовое поле) и других вещей, влияющих на увеличение трудоемкости проекта. Заказчик может предполагать интеграцию систем через веб-сервисы, а исполнитель рассчитывал реализацию через .com-объекты, и т.п.

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

Взаимопонимания Вам!