Форма поиска

Разумный компромисс между Заказчиком и Исполнителем: как справедливо оценить разработку сайта для недвижимости?

Очень важным и для Заказчика, и для Разработчика является вопрос - по какой модели правильнее разрабатывать сайт: с фиксированной стоимостью работ (т.е. фиксированная оплата за фиксированный объем работ) или с оплатой по факту (т.е. за количество фактически затраченного специалистами времени).

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

Конфликт при оплате дополнительных работ по сайту

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

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

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

Конечно, в этой ситуации самым важным является вопрос доверия. Статью можно закончить просто на этом абзаце отметив:

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

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

Почему Заказчики стремятся к фиксированной оплате (Fixed Price)?

  • При Fixed Price легко управлять бюджетом, т.к. точно знаешь, сколько и когда тебе нужно заплатить. Это особенно важно, если для реализации проекта привлекаются спонсоры, инвесторы. Тогда Заказчик стремиться получить точную оценку даже для очень большого проекта еще на этапе переговоров.

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

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

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

Поэтому разработчику, работающему по фиксированной оплате труда,  остается два варианта: 

  • Либо зафиксировать первоначально озвученную стоимость и рискнуть сработать себе же в убыток (а практика показывает, что в большинстве случаев так и получается).
  • Либо заложить страховочную сумму на все “детали”, которые могут возникнуть (это сумма от 50 до 100% стоимости проекта), даже не сообщив об этом Заказчику, т.к. вряд ли тот согласится заплатить в 2 раза больше, если его предупредить о рисках. 

Развенчание стереотипов 

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

Однако же, у фиксированной оплаты есть очень существенные минусы, которые перечеркнут те преимущества, которые отпечатались в сознании заказчика: 

Минусы работы по фиксированной оплате

  1. Получив деньги за какой-то объем работ и взяв на себя обязательства эти работы выполнить, разработчики будут стремиться как можно скорее сдать эту работу Заказчику, чтобы перейти к исполнению следующей и, кроме того, оставить еще сэкономленное время на исправление каких-то багов и отладку работы системы (если учесть, что работа программиста - это и есть исправление ошибок, такое время оставлять по-любому нужно). То есть страдает качество и “правильность” выполнения работы.
  2. По оговоренным выше причинам возрастает стоимость технической поддержки, т.к. при разработке с фиксированными временем и стоимостью у программиста очень низкая мотивация. Например, программист обещал проект-менеджеру закрыть задачу за три часа, т.к. именно это время оплатил заказчик. Зачем же ему рисковать и предлагать какое-то новое, нетрадиционное решение или доработку, если стоимость данного модуля уже все равно зафиксирована? А вдруг это существенно повлияет на время завершения задачи? Ну нет уж. Лучше выполнить то, за что уже заплатили, и решать проблемы по ходу поступления. Зачем стараться себе же в ущерб? Вот поломается что-то - потом будем разбираться.
  3. Команда будет меньше вдаваться в детали и стремиться сделать продукт наиболее привычным и стандартным способом. Нестандартные способы решения задачи влекут за собой ненужные и незапланированные дополнительные временные затраты, а кому это нужно? Клиент-то все равно не доплатит, т.к. мы с ним оговорили фиксированную стоимость разработки. Еще, не дай Бог, что-то сломается - придется вместо часа потратить день. Нет уже, пусть все остается, как есть.
  4. По той же причине в интересах разработчика умолчать о потенциальных проблемах, т.к. эти проблемы пока не возникли и неизвестно возникнут ли. А ответственность за них Заказчик вполне логично переложит на плечи разработчика уже сегодня. И решай их потом когда хочешь - изыскивай время. Само собой разумеется, что за решение этих проблем никто платить не намерен.
  5. В случае возникновения спорных ситуаций поднимается вся переписка, документация, тратится куча времени, чтобы понять. что где и когда было прописано и т.п., потом ведутся переговоры, переливание из пустого в порожнее и в итоге компромиссное решение, чтобы как-то загладить конфликтную ситуацию, в результате которого обе стороны остаются недовольными. Таким образом, на неэффективное выяснение отношений тратится время, которое намного более правильно было бы потратить на улучшение качества продукта, на реализацию новых идей и т.п. Часто на обсуждение работы в 40 долларов тратится час работы менеджера проекта и программиста (к которому первый обращается с вопросами и уточнениями). То есть работу еще не начали, а запланированные деньги, получается, уже потратили.
  6. Как только в результате срыва сроков (а значит, и увеличения стоимости проекта) команда выходит на “ноль”  - резко снижается мотивация работать. Это очень логично. Команда начинает “замазывать дыры” и “ставить заплаты”, чтобы хоть как-то сдать проект и получить за него хот какие-то деньги, чтобы не выйти в слишком большой минус. И тогда о качестве и правильности работы вообще речи не идет.

Плюсы работы по почасовой оплате

  1. Во-первых, у исполнителя появляется мотивация работать хорошо, т.к. он не находится в постоянном стрессе, что он что-то не успевает, что ему не оплатят его работу и т.п. Наоборот у него есть время на разработку качественного продукта. А это цель для любого специалиста, т.к. основной инструмент продаж - портфолио, в котором хочется разместить как можно больше качественных примеров.
  2. С другой стороны - разработчик не будет растягивать время выполнения задач, т.к. это снижает продуктивность его труда. Во-первых, как только это обнаружится - ему перестанут платить деньги. Во-вторых - чисто психологический (или даже экономический) мотив - программисты не любят “топтаться” долго на месте и переделывать одно и то же. Это люди по своей натуре творческие, так что им намного интереснее сделать хорошо задачу, закрыть ее, начать делать новую, не возвращаясь потом к предыдущей. То есть они сами - если дать им такую возможность - изначально все протестируют, исправят, сделают что называется по уму. И все останутся довольны. Потому что все равно потом придется доплачивать за заранее незапланированные работы
  3. Все получают то, к чему стремятся. Заказчик хочет получить как можно более качественный продукт, недвижимости это касается в первую очередь - тут какую сферу не возьми - везде бешеная конкуренция. Разработчику же со своей стороны нужно аргументировать, грубо говоря,  каждую минуту оплаченного заказчиком времени и тогда он получит то, что нужно ему - своевременную оплату его работы, а также качественный продукт, который можно разместить в портфолио.

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

- Кто платит за "недопонятые” и “недосказанные” требования к разработке сайта? (Кейсы из нашей практики) - 23 января 2012 года.

- Как сэкономить при почасовой оплате труда программистов не теряя качество продукта? - 28 января 2013 года.

Понравилось?: 
Голосов еще нет
О consult