Форма поиска

Кто платит за “недопонятые” и “недосказанные” требования к разработке сайта недвижимости? (Кейсы из нашей практики)

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

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

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

Общий принцип формирования стоимости работ по сайту

Алгоритм наших действий по оценке проекта следующий: 

Клиент обращается в нашу компанию, озвучивает свои требования к разработке сайта, рассказывает цели создания/модернизации сайта, отвечает на вопросы менеджера, заполняет бриф.

На основании предоставленной клиентом информации мы готовим для него смету, т.к. наша задача - озвучить оценку описанного им сайта по стоимости и срокам. И вот тут внимание!: работы, которые входят в базовый функционал (являются частью базового пакета "Старт", "Агентство" или "Корпорация" согласно нашему прайсу), оцениваются по фиксированной стоимости (при этом их объем четко прописан в ТЗ), а все доработки "под клиента" и все требования, которые возникают по ходу разработки сайта, остаются как бы "за бортом" сметы и оцениваются почасово, по схеме, описанной в статье "Как сэкономить при почасовой оплате труда программистов не теряя качество продукта?" от 28 января этого года.

  1. Для каждого клиента мы закладываем "порог", в пределах которого мы готовы бесплатно дорабатывать его сайт. Этот порог ограничивается 10% стоимости стандартного (фиксированного по цене) функционала сайта.

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

Пакет "Агентство" - 1200$

Подписка на рассылку по заданным параметрам - 100$

Разработка индивидуального дизайна - 500$

Верстка дизайна - 200$

Подбор доменного имени - 30$

Итого: 2030$

На этом заканчивается фиксированная цена и начинается почасовая оплата. По ходу разработки сайта "всплывают" еще такие доп.работы:

Доработка формы заявки "Хочу купить" - ок. 2 проектных часов 

Индивидуальная донастройка поиска по базе - 1 проектный час. 

Донастройка личного кабинета (дополнительные возможности для агентов) - 4 проектных часа.

По факту оказывается, что на все эти работы мы затратили 6 проектных часов. Поскольку "порог" на данном проекте у нас 10% от 2030$ - т.е. 203$, данные индивидуальные настройки покрываются, и клиент ничего больше не доплачивает. То есть сайт для него в общем будет стоить 2030$.

НО как только переступается указанный порог - оплата всех новых требований и доработок считается в соответствии с затраченным временем (кратность - 15 мин.).

Кто платит за "баги" и "ошибки" на сайте? 

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

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

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

Покажем на примере, что имеется в виду.

Из практики. Клиенту сдан работающий сайт для агентства недвижимости - с поиском, личным кабинетом агентов и функционалом пакета "Агентство" (см. наш Прайс). Уже после сдачи сайта клиент оформил заявку на доработку: добавить на сайт новую операцию с недвижимостью - еженедельную аренду. Таким образом, для каждого объекта нужно добавить цену аренды за неделю, внести соответствующие изменения в поисковую форму и алгоритм поиска, в админку (личные кабинеты). Все это предусмотрено, и озвучена конкретная цена (фиксированная) за выполнение такой доработки.

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

Кто же в такой ситуации должен платить?

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

И все равно, если речь идет не о примитивном сайте-визитке, нет 100% гарантии, что все детали будут учтены сразу. Учитывать всё - дорого и сравнимо по стоимости с самими изменениями.
 
Проводить комплексное тестирование после каждого небольшого изменения тоже неоправданно дорого и может увеличить стоимость работы в несколько раз.
 
Так что выходов у Разработчика два: 1) Заложить работу проект-менеджера и тестировщика + парочку часов программиста в фиксированную цену; 2) Выполнить задачу (доработку), после ее выполнения сделать проверку изменений (тестирование части сайта), а при обнаружении неточностей или ошибок, которые выявились уже в процессе пользования сайтом, устранить их по мере появления.
 
Вывод: И для заказчика, и для разработчика выгодно работать по схеме, предусматривающей оплату за фактически потраченные на разработку сайта проектные часы. По нашему мнению, это справедливая и логичная схема для оплаты работы специалистов в ИТ-сфере. 
 
В самом начале нашего "творческого" пути, когда мы еще были неопытными в работе над созданием сайтов недвижимости новичками, мы фиксировали стоимость доработок еще на этапе переговоров, ориентируясь на прогноз менеджера по проекту. ВСЕГДА появлялись какие-то новые детали и проблемы. Как бы идеально не был сделан сайт, что-нибудь да всплывало: иногда по нашей вине (брифы детальнее заполнять надо было), а иногда просто по объективным причинам - потому что все учесть никогда не получается.

Чтобы научиться на своих ошибках, пришлось сделать несколько сайтов себе же в минус. 

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

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

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

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

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

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

См. также статьи по теме: 

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

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

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