Иногда нашим клиентам требуются индивидуальные решения для сайтов: калькулятор, «Личный кабинет», «Корзина» и система оплаты. Порой такие решения стоят дороже и разрабатываются дольше, чем сам сайт. Рассказываем почему.
Стоимость любого сайта складывается из оценки стоимости часов всех специалистов, которые будут работать над ним, дополнительных затрат на покупку готовых решений, а также заложенных рисков. Аналогично оцениваются и доработки — не важно, наполнение контентом или создание принципиально нового функционала.
Со стороны клиента не всегда кажется логичным распределение стоимости: функционал одной конкретной страницы может стоить даже больше, чем создание сайта. Ведь результат — одна работающая страница калькулятора или вообще скрытый от глаз пользователей «Личный кабинет». Сайт состоит из множества страниц — почему одна самая дорогая? Есть несколько основных причин, разберемся на примере одного кейса.
К нам пришел клиент с запросом на разработку инструмента по расчету и сбору заявок. Заказчик уже сформулировал ряд требований к этому инструменту, которые передал нам в таблице. Основные данные таблицы — информация о полях калькулятора и расшифровка их функций. Так как конкретики было много и определенную работу заказчик уже провел на своей стороне, изначально казалось, что трудностей в работе не возникнет.
Полный цикл разработки
Для того чтобы сформировать полную картину практически для любой индивидуальной доработки на сайте, нужно пройти полный цикл — агрегацию требований, прототипирование, составление ТЗ на программирование, дизайн, программирование и верстку, тестирование. Целесообразность наличия каждого этапа определяет менеджер проекта, и каждый этап имеет свою долю в итоговой стоимости. В данном случае работ оказалось больше, и они были сложнее, чем при разработке простого одностраничника или сайта-каталога.
Отсутствие противоречий в планируемом функционале
В процессе прототипирования, встреч и анализа переданной заказчиком таблицы с требованиями к калькулятору выяснилось, что в логике работы присутствует очень много «но». Вот всего пара примеров:
В зависимости от выбранного сценария расчета меняется количество полей, их значения и алгоритм расчета, а также внешний вид и значение других интерактивных элементов.
Часть конфигураций полей может не иметь расчета вовсе. Допустимые значения одного поля должны зависеть от значений другого поля. Это не критично, но с учетом задачи максимально сохранять значения полей нужно было избежать нарушения логики заполнения при постоянном изменении значений полей.
Для решения данной проблемы была составлена подробная матрица с пересечением полей и их значений. Из нее удалось выявить те поля, которые могут сохранять значения всегда, и те, которые могут сохранять значения при определенных условиях. Соответственно, эти условия также удалось зафиксировать при помощи матрицы.
Полнота исходных данных
Очень часто бывает, что даже при самостоятельной подготовке задания к разработке со стороны клиента ряд требований не указывается, так как заказчик их считает чем-то само собой разумеющимся. Так произошло и в этом случае. Необходимость части функций к инструменту выявилась только в процессе. Мы отразили их на интерактивном прототипе. Прототип был реализован и согласован перед тем, как мы перешли к другим этапам.
Периодически мы получали дополнительные условия, так как у клиента также вскрывались определенные нюансы процесса. Такие новые входящие данные всегда приходилось перепроверять, чтобы они не противоречили другим условиям. Здесь нам помогло единое информационное пространство с клиентом — та самая «матрица» и техническое задание. А также наличие проект-менеджера, который за этим всем следил.
Отсутствие технических ограничений
Иногда желания заказчика сталкивались с техническими ограничениями. Одним из таких желаний стало объединение нескольких справочников из разных API в. один — это технически возможно, но далеко за рамками предполагаемых бюджетов. Исходя из задач калькулятора, мы определили, к какой конфигурации полей какой справочник подходит, какую он задачу решает. И подключили справочники параллельно.
Изменения в процессе
Про то, что изменения в ходе разработки влияют на стоимость конечного продукта, мы писали не раз. В этом случае изменение условий привело к сложности обмена данными между CRM и справочником.
Как мы говорили ранее, алгоритм расчета зависел от конфигурации значений полей. Для рационализации процесса было принято решение часть расчетов делать на стороне сайта, а основной расчет производить на стороне CRM клиента. Это привело к тому, что, помимо простой передачи заявок (которая планировалась изначально), необходимо было настроить обмен передачи данных для расчета с одной стороны и получения и вывода результата с другой. Положительная сторона этого изменения в том, что это послужило дополнительной проверкой, все ли мы правильно предусмотрели.
Выводы
Как вы уже поняли, разработка индивидуальных решений состоит в кропотливом сборе данных и внутренней работе, которая хоть и не видна пользователям, но обеспечивает нормальное функционирование разрабатываемых инструментов. Поэтому единственный путь сокращения затрат на разработку со стороны заказчика — предоставление наиболее полных данных с учетом того, что разработчик в начале пути еще ничего не знает о сфере деятельности заказчика.
И это не единственный вывод. Реализация каждого подобного продукта — всегда значимый опыт как для заказчика, так и для разработчиков. Мы пополняем свою копилку полезными нюансами, которые позволят сэкономить время при следующем проекте. На примере разработки калькулятора в эту копилку вошло следующее:
-
Уточняющие вопросы. Предусмотреть все невозможно — и это понятно. Однако с опытом накапливается ряд вопросов, которые стоит задать заказчику при получении заявки. Со временем формируется автоматизм в выяснении нюансов, который позволяет экономить время и избегать ненужных переработок уже почти готового продукта. Однако есть и вторая сторона.
-
Профессиональная деформация есть не только у заказчика, но и у нас, разработчиков. Многократно получая задания с одинаковыми требованиями к одним и тем же элементам, мы можем перестать уточнять ряд нюансов, считая их стандартными. Это тоже необходимо учитывать — и не ослаблять внимание.
-
Время на структуризацию запроса не бывает потрачено зря. На этом проекте мы проверяли каждое новое условие на соответствие всем предыдущим, чтобы не возникло противоречий. Процесс занимал очень много времени, но в конечном счете привел к тому, что мы не создавали неработающих функций в калькуляторе из-за несогласованности действий.
-
Цена определяется только ценностью. Нельзя сказать, что созданный инструмент вышел слишком дорогим или совсем дешевым, только на основании цифры в счете. Есть инструменты, которые определяют суть бизнеса: без них он не может функционировать. Есть инструменты, которые облегчают процесс работы, но не приносят прибыли. Они окупаются за счет сэкономленного времени множества сотрудников, которые пользуются сервисом. А также лояльности клиентов, которым стало удобнее взаимодействовать с компанией.
-
Соблюдение технологии разработки обеспечивает совпадение ожиданий с реальностью. Нельзя переходить к следующему этапу, не завершив предыдущего. Нет хороших и плохих сайтов — есть только соответствие сайта изначальным ожиданиям заказчика. Основная жалоба на веб-студии в том, что процесс разработки растянут, стоимость завышена, а где-то у фрилансера дешевле. Эта разница в цене и сроках обеспечивается наличием множества собранных из опыта этапов, которые позволяют дать заказчику именно то, что он представлял у себя в голове. Экономия на этих этапах выливается в дешевый, но никому не нужный продукт и приводит к новым тратам на правках.
