Плохой клиент? Тупой исполнитель?

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

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

Тупой же исполнитель часто характеризуется: низким качеством предоставленных услуг, непрофессионализмом, срывом сроков, а иногда и тем, что не может реализовать запросы из ТЗ подобного формата: «Результат работ должен быть удобен в использовании заказчиком»

Попасть и на одних и на других порой не составляет труда. От "плохого” клиента, подрядчики как правило бегут или уже даже судятся. "Тупой" исполнитель в свою очередь, постарается максимально быстро забрать ваш проект (лишь бы — лишь бы). Какой же забавный фейерверк эмоций получается, когда эти двое находят друг друга.

Короткие истории о том, как в таких ситуациях оказывались мы:

Кейс № 1

Прилетает к нам заказчик с заявлением: — "Ребят, нам нужен сайт, но большим запасом временем на разработку мы не располагаем, поможете? ”. Клиент показался отзывчивым и понимающим. "Грех не помочь” подумали мы, заключили договор, провели бриф, составили ТЗ.

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

Этап разработки. Всё идёт своим чередом, проект на 75% готов, и тут директор компании выходит из отпуска, и оказывается что ему не нравится. Подключается юрист и с угрозой судебного иска требует сделать проект строго по ТЗ (от которого 3.000 раз разумеется уже отошли), разумеется без дополнительных оплат, ведь считает что виноваты мы. И виноваты! Но лишь в том, что не подписывали допники, это действительно — полностью наша вина.

Кейс № 2

Другой заказчик пришёл к нам по понятной причине, банально дешевле. Клиент был подготовлен, его техническое задание казалось было максимально подробным, ведь состояло более чем из 150 страниц, но как показала практика — это совсем не показатель. Справедливости ради стоит отметить, что проект был действительно тяжёлый, и специфичный. Поэтому в случае если бы ТЗ было меньше по объёму, это вызвало бы куда гораздо большие трудности, нежели те которые возникали.

“Каждая итерация правок подписывается дополнительным соглашением.” — Пункт из договора, который мы упустили.

Разработка дизайна очевидно была затянутой по сравнению с обычным периодом, но вот, подходит время отправлять его на правки… Ответ был словно пуля в сердце — ещё один файл, ещё на 150 страниц. [Теперь уже дизайнер делает правки, отправляет готовый вариант, и ему опять приходит файл на +- 150 страниц]. Что бы искусственно не затягивать рассказ было принято решение использовать “[ ]” — фигурные скобки, действия происходящие внутри них повторялись ещё 6 раз.

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

Плохой клиент или всё же тупой исполнитель? Перейдём к выводам.

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

Составляйте четкое и понятное, техническое задание, составляйте его вместе, ибо самое главное тут то, что бы две стороны понимали его одинаково. Не надо писать дурости по типу:

«Результат работ должен быть удобен в использовании заказчиком»

«Сделать красивый дизайн»

«Настроить базу данных»

Всё это создаёт неопределенности и вызывает множество вопросов, которые часто завершаются дикой убыточностью работ для подрядчика и пустой тратой денег для заказчика. Для успешной и взаимовыгодной работы, требования должны быть конкретными, измеримыми, чётко определёнными и подкрепленными договором!

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

Роль качественной документации:

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

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

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