Почему мой сайт так много стоит или Сколько стоит разработка сайта?

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

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

Для начала примем ряд аксиом, это необходимо нам для полной картины.

1. «Цели — Задачи» — ставит заказчик основываясь на том или ином опыте.
2. «Время — деньги» определяем мы — исполнители, это наши временные затраты определяющие конечную стоимость выпускаемого нами продукта. Для упрощения расчетов будем считать что все расходы (а оно почти всегда так и есть) включены в конечную стоимость часа работы программиста.
3. «Законченность проекта» — определяется заказчиком на основании удовлетворенности клиента. Т.е. проект можно считать законченным в том случае, когда заказчик удовлетворен тем что у него есть в настоящий момент времени (согласно технического задания).

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

Т1-Ф1 или «а что тут делать»

Сначала официально. Т1-Ф1 это базовый функционал друпала + простая темизация либо настройка базовой или бесплатной темы стоимость такого продукта в принципе равна времени затраченного на разворачивание сайта из коробки и настройку темы.

Подробно: БТД (базовая тема друпала) + СФ(стандартный функционал из коробки): условно бесплатно.

Цена: «дешево до безобразия» обычно от «бесплатно» и до «кто за сколько продаст».

К примеру студия берет за 1 час работы программиста 20$, значит, если идти по накатанной схеме установки и базовой настройке друпала (разворачивание сборки, или просто движок + модули) примерно 1 час, то можно выдвигать слоган 20$ за сайт и вперед (в дальнейшем все денежные эквиваленты будут браться из расчета 20$ час), но …
Вы должны как исполнитель сразу объявить заказчику что он получает в конечном итоге за эти деньги и время, в противном случае мы станем свидетелями следующей ситуации:

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

В качестве примера: Многие из нас очень часто встречались с задачей «регистрация пользователей на сайте» — казалось бы куда проще = стандартный функционал друпала, что тут обсуждать или пережевывать, но смотрите как одна фраза в ТЗ или просто банальная хотелка — «как там» превращает вполне тривиальную задачу в «головняк» для разработчика:
«По нажатию на клавишу «восстановить пароль» пользователю должно приходить письмо в котором указан его текущий логин в системе и пароль указанный при регистрации, никаких одноразовых ссылок».
Получается что вполне стандартное с точки зрения заказчика требование (пусть оно и противоречит требованиям безопасности о хранении паролей в явном виде, сейчас мы не об этом) перерастает для нас в дополнительную работу. Написать модуль, который будет перехватывать задаваемый пользователем или генерируемый системой при регистрации пароль, записывать его в отдельную таблицу БД из которой мы по запросу сможем отправлять нашим пользователям забытые пароли.

Вывод: мелочь из примера увеличивает стоимость разработки минимум на 2-3 часа и либо вы это делаете бесплатно угоду клиенту т.е. из 20$ в 80$ и дарите клиенту 60$, либо пытаетесь объяснить что стандартно это не было предусмотрено движком (клиента чаще всего не интересует, что там предусмотрел Дрис и его коллеги а что нет).
В конечном итоге в 90% случаев клиент с недовольной миной отзывается о вас «вот пообещал все сделать за час а в итоге ничего не сделал, функционал не готов, сайт не работает».

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

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

Т2-Ф2 или «а что тут делать — 2»

Сначала официально. Т2-Ф2 это + дизайн с последующим созданием темы + небольшие отдельные хотелки и финтифлюшки реализуемые на этапе темизации, либо написанием мелких кастомных модулей.

Подробно:

• дизайн (400$ 20часов) может быть заменен дизайном заказчика, тогда бесплатно;
• создание темы (до 40 часов 800$, возьмем половину)
• стоимость отдельного функционала (хотелки) в зависимости от задач и почасового рейта компании.

Итого: итого в среднем по стране без хотелок мы из 1 часа превращаемся в 1 недельную работу (40 часов) и стоимостью в среднем в 800$ без учета хотелок.

В качестве примера: «а что тут делать -2» — во избежании очередных недопониманий о том «что тут делать» :)
Банальное слайдшоу ;) из 2-100 картинок на главной странице между меню и основным контентом такое «каждый школьнег умеет делать», но посмотрим на ожидания заказчика:

• он в 100% подразумевает, что картинки можно было удалять и добавлять из админки.
• он в 95% подразумевает, что можно добавить текст если захочешь и он выведется не ломая верстку
• он в 90% подразумевает, что можно из админки регулировать скорость смены слайдов стили смены слайдов или включать — отключать автоматическую прокрутку
• он в 85% подразумевает, что всем этим умеет управлять блондинка-секретарша а не программист.

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

Итак 4 хочу, которые заказчик ожидает увидеть но нигде об этом явно не говорится превращают 30-40 минутную задачу в работу на целый день. Ведь если мы банально зальем картинки по фтп или в какой-то статик пейдж и на шаблоне добавим свои js и css результат внешне не будет отличаться от сложного функционала реализованного за 8 часов, но если человек захочет что-то поменять в слайдшоу и не сможет то в 99% задача будет считаться не выполненной, функционал с точки зрения заказчика не сделан.

Т3-Ф3 или «ну а тут то что сложного»

Сначала официально. Т3-Ф3 это два предыдущих этапа + реализация не видимого простому глазу функционала требующего написания одного или нескольких модулей реализующих достаточно сложный функционал к примеру расчет стоимости доставки в зависимости от веса, габаритов товара, региона, способа доставки, учета общей стоимости заказа и т.д. начисления процентов менеджеру через которого сделан заказ или по чьей ссылке человек пришел на сайт в общем любую сложную задачу которую вы можете себе представить :)

Здесь не будет подразделов «подробно», «цена» и т.д. поскольку в таких частных случаях конечная стоимость формируется только по оценочной стоимости задач специфичных только для этого проекта. Если кастомный функционал оценен разработчиками в 100 часов то и стоимость проекта будет к примеру 2820$ если присутствуют все этапы, может быть вариант и без дизайна и мелких «свистелок», тогда стоимость составит 2020$

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

Увидит:
— галочку на форме редактирования товара;
— результат вашей работы при включении свойства товара.

Не увидит:
— таблицу в БД которая появится при создании поля типа select (checkbox);
— изменение вьюхи (добавить поле нового товара), вьюх или дисплеев отображения может быть несколько
— перекрытие шаблона вьюхи (добавить дивку с классом для row);
— вырезать или сохранить картинку из PSD (хуже если нарисовать)
— поправить css файлик темы чтоб выводилась картинка;
— проверить корректность отображения в поддерживаемых браузерах.

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

Итак задача в ТЗ повесить ленточку (примерная оценка):
— добавить филд — 10 минут;
— добавить филд на вьюху — 10 минут на каждую если их больше одной или больше одного дисплея;
— перекрытие шаблона вьюхи — в зависимости от архитектуры — от 15 минут;
— картинка — от 10 мин;
— сss — 10 мин;
— тест — 15 мин;
ИТОГО: в идеальных условиях 1час 10мин т.е. ~23$ за какую-то ленточку
А если что-то не так сделал (все люди) и надо исправить проблему?

Эпилог :)

Какие-же выводы можно сделать из всего этого набора букв и одной картинки :)

1. Внешняя картинка (морда) в 90% случаях не отражает весь функционал сайта.
2. Одна и та же задача в глазами заказчика и разработчика совершенно разные картины и чем точнее ее решит разработчик, тем довольнее будет заказчик и будет им обоим много счастья.
3. Совершенный (идеальный) проект сделать можно только в теории, на практике нет, потому и график — асимптота т.к. этот идеал возможно где-то есть в перспективе, время и прогресс важные факторы.
4. Техническое задание — неотъемлемая часть любого проекта включая сайт-визитку. Чем точнее задание будет описывать функционал будущего сайта, тем меньше головных болей будет у вас и меньше будет недовольных конечным результатом заказчиков. И самое главное тем точнее предварительная оценочная стоимость будущего проекта.

P.S.
Так сколько же должен стоить сайт на самом деле? Ответ на этот вопрос мы можем дать только в конце создания продукта, так же как и нет ответа на вопрос «сколько стоит дом нарисованный на схеме»? Мы можем говорить о конечной стоимости только по завершению какого либо этапа работ. Спасибо :)