Швидкий розрахунок вартості розробки сайту

Трохи про те, як я розраховую вартість розробки сайтів, коли на це мало часу.

В силу роботи, мені доводиться розраховувати для замовників вартість розробки сайту. Іноді на це є час, іноді відповідь хочуть побачити через 20 хвилин, а то й зараз. Пару років тому я зробив для себе експертну таблицю в Excel, яка дозволяла дати швидку відповідь про вартість розробки.

Велика частина проектів розраховується виходячи з трудовитрат і процес довший і складніший. Доводиться будувати діаграми Ганта, щоб показати критичні точки і реалістичніше оцінити терміни проекту. Але на практиці, ця проста форма показала свою ефективність.

Швидкий розрахунок вартості розробки сайту

стиль сайту
Складний і незрозумілий процес розробки сайту - варіант головної сторінки. Створюючи його, ми формуємо стиль всього сайту. Задаємо ключові елементи: меню, шрифти, стилістику графіки, макетну сітку. Іноді, щоб затвердити головну сторінку потрібно зробити 1-2 макета, іноді 7-10. Наші (мої) замовники не дуже охоче платять за різні варіанти, але для попередньої оцінки нам і не треба оцінювати реальний проект. Потрібно просто знати, що замовник за це заплатить. В рамках великого сайту ця сума розчинитися, а для маленького буде помітна, що нам власне і треба.

Дизайн макетів
Пункти 2-5 передбачають простий підрахунок елементів майбутнього сайту. Для цього пункту я вважаю потенційна кількість унікальних макетів які мені доведеться спроектувати і для яких доведеться робити дизайн. Вартість роботи усереднена і час на дизайн однієї сторінки взято з досвіду середньої розробки. У кого-то все це може дешевше / дорожче, швидше / повільніше.

ШаблониHTML
Тут нічого рахувати не треба - скільки макетів в дизайні зробимо, стільки і зверстаємо.

форми
Вважаємо кількість унікальних форм. Як правило, форми вимагають додаткових обробок, перевірок, налаштувань, тестування, що робить їх розробку помітною. До того ж, ми в своїй практиці постійно використовуємо кастомізовані форми, що створює додаткову роботу для верстки та тестування.

Прив'язка до CMS
Скільки верстали сторінок стільки їх і прив'яжемо до CMS.

Додаткове програмування (в днях)
За великим рахунком, це поле для внесення поправок до трудомісткості проекту. Нерідко нам потрібно інтегрувати в сайт банківський API, через SOAP зв'язати особистий кабінет з корпоративної ERP або зробити обробку вивантаження з 1С. Ці роботи можуть зайняти кілька зайвих днів, які варто врахувати. Якщо ж програмування багато, то краще його взагалі вважати окремо, а швидкий розрахунок залишити тільки для оцінки фронту сайту.

Контент (наповнення сайту)
Залежно від обсягу наповнення сайту контент може зробити істотний вплив на вартість розробки. Ми враховуємо тільки роботу по наповненню, переносу готового контенту на сайт замовника. Якщо потрібно робити копірайтинг, фото, вигляді, то це завжди розраховується отдельно.Для звичайного сайту я використовую невеликий коефіцієнт, який просто дозволяє відобразити вартість робіт по наповненню в загальній вартості розробки.

мовні версії
Коли на сайті потрібно кілька мов, то приходиться враховувати, що під альтернативні мовні версії доведеться адаптувати дизайн, прив'язувати мовні файли для шаблонів, іноді переробляти шаблони, можливо переробляти обробку форм і деякі скрипти - все це відбитися на термінах і на вартості робіт. Тому мови ми теж враховуємо.

CMS (вартість ліцензії)
Ми використовуємо платні CMS. Тому додаємо їх вартість на суму розробки.

У чому зручність використання для мене? Коли потрібно швидко порахувати приблизно вартість розробки сайту, то можна це зробити за 15-20 хвилин і при цьому не відчувати себе фантазером, який взяв цифри зі стелі. В результаті отримати щось похожеее на бюджет і терміни, що дасть клієнту грунт вирішувати що ж робити далі: співпрацювати з нами або пошукати де дешевше.

Корисна таблиця, скопіював в Докс. Пункт «Прив'язка до CMS» можна асимілювати з якимось іншим, додавши вартості. Все-таки сайти на файлах швидше виняток з правил. Або НЕ?

Вартість робіт по прив'язці і верстці, як і терміни по цих роботах можуть сильно відрізнятися. Але в кінцевому рахунку, для мене важливіше було просто розділити ці роботи. Вони проходять в різний час, їх можуть робити різні люди, у них різні вимоги. Плюс, в прив'язку до CMS, вже вкладено проміжне тестування.

Схожі статті