Как договориться заказчику с программистом

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

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

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

Как может кинуть программист:

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

Как может кинуть заказчик:

Как правило, программиста дотапливают почти до конца и доработка будет стоить явно не 50‑70% от бюджета, если она вообще будет заказываться…

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

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

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

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

Очевидно, что желания работать с таким клиентом у программиста не появится. На самом деле, возможно, изначальная цена бы и не изменилась, если бы заказчик озаботился тем, чтобы указать все принципиальные для него моменты в рамках ТЗ. А в приведённом примере, ситуация выглядит так, что заказчик не хочет вникать в проект ни на старте, ни во время приёмки, а потом считает, что можно передоговориться задним числом.

Чтобы максимально избежать таких ситуаций и, как минимум, помочь программистам задать наводящие вопросы, мне и пришла идея канала с типовыми заготовками, на основе которых можно уже дописывать индивидуальное ТЗ. 50‑70% в схожих проектах идентично и всё внимание как раз концентрируется на принципиальных нюансах — шанс недосказанности уменьшается.

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

Доверие

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

Позиция заказчика, в даном случае, в вопросе рисков — программист не разбирается в его сфере, пока ещё слабо вник в его идею и довериться человеку тяжело.

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

Недавно мы проиграли тендер на приложение интернет-магазина. Заказчик выбрал подрядчика, который предложил чек в 1,5 раза больше. Даже не получив заказ я почувствовал уважение к этому выбору — у нас магазинов в портфолио не густо, у победителей — это основная специализация. Заказчик предпочёл переплатить 50%, но получить снижение риска завала проекта.

Коммуникации

Ещё один пример недопонимания. Для программиста коммуникации — это разговоры на тему как всё будет классно и прочие микро отвлечения, которые сильно выбивают из колеи. Для заказчика коммуникация — это отчётность.

Адекватно будет договориться об отчёте каждые 2 дня в формате что было сделано за 16 часов и как это проверить. Если отчёта нет или он написан в формате «сделано огого, но проверить можно будет только в конце» — это повод волноваться.

Вместе с тем, заказчику стоит избавить программиста от дерготни в стиле «как дела» в несогласованное время. Разработка — дело творческое и выдернув программиста в неправильный момент, можно на несколько часов увеличить срок реализации. Отвлекли 10 раз — вот вам и недельная задержка.

Оценки и доработки

Заказчика, как человека из бизнеса, постоянно посещают идеи по развитию проекта. Само собой, он хочет понимать сколько это стоит, причём, не факт, что он будет это заказывать.

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

Крайне важно идти недельными спринтами, в рамках которых задание не меняется и программист не отвлекается от текущего объёма. При правильной коммуникации — это даёт ускорение в 20‑30% и адекватного программиста в финале, который будет только рад продолжить работу с таким заказчиком.

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

Постоянная дерготня в произвольно время — это как раз один из красных флажков для программиста.

Заказчик тоже работает

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

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

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

Финалом такого подхода является осознание, что в какой-то момент программиста настолько задёргали, что ему становится «не надо» запускать проект заказчика и появляется обида — почему я делал версии, присылал, мне согласовывали продолжение работ, а в итоге сказали, что всё не так.

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

Резюме по всем иллюстрациям можно свести к нескольким тезисам: