Иногда нашим клиентам требуются индивидуальные решения для сайтов: калькулятор, «Личный кабинет», «Корзина» и система оплаты. Порой такие решения стоят дороже и разрабатываются дольше, чем сам сайт. Рассказываем почему.

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

Со стороны клиента не всегда кажется логичным распределение стоимости: функционал одной конкретной страницы может стоить даже больше, чем создание сайта. Ведь результат — одна работающая страница калькулятора или вообще скрытый от глаз пользователей «Личный кабинет». Сайт состоит из множества страниц — почему одна самая дорогая? Есть несколько основных причин, разберемся на примере одного кейса.

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

Полный цикл разработки

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

Отсутствие противоречий в планируемом функционале

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

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

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

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

Полнота исходных данных

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

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

Отсутствие технических ограничений

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

Изменения в процессе

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

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

Выводы

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

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

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

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

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

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

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