Сколько стоит создать сайт? Сроки и бюджет веб-проекта

Сроки и бюджет проекта напрямую зависят от объема работ. Практически всегда точный объем работ на начальном этапе не может быть определен по следующим причинам: 

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

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

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

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

Более детальное ТЗ мы пишем на 1 этапе и только после этого делается уточненная оценка. Это уже более конкретный ориентир для заказчика. 

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

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

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

Появилось ТЗ - еще сильнее сужается. 

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

P.S. Рекомендуем вам посмотреть нашу статью о снижении стоиомсти затрат на сайт

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

Чем меньше будет первая версия, тем точнее и проще ее описать, тем быстрее вы ее внедрите в работу, тем ниже риски для заказчика застрять на полпути, тем ниже риски исполнителя “работать в стол”. Уменьшайте максимально объем первой версии. 

Как мы определяем бюджет проекта

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

Сроки обычно определяются по историческим данным - если мы успели сделать похожий объем за 1 месяц, при прочих равных в этом проекте это также будет 1 месяц. 

На что необходимо обратить внимание при оценке: 

1. Учитывайте доп работы такие как менеджмент, тестирование. Менеджмент включает в себя работу с клиентом, приемку, формулирование задач, разъяснение бизнес-логики программистам. Тестирование - это проверка задач, а также проведение сессий тестирования по чек-листу этапа.
2.  Ревизия кода - если вы проводите ревизию кода, то имеет смысл выделить отдельным пунктом эти работы. Это особенно актуально на более поздних этапах, когда изменения в коде идут поверх начального кода. 
3. Отладка, решение багов - этот пункт подразумевает, что вы в явной форме выделяете время на решение подобных проблем. Обычно в нашей практике это около 5-10%, но для проектов с кучей этапов в кастом разработке это число может доходить до 20-25% от этапа.  Здесь многое зависит от качества кода, квалификации программистов, точной постановки задач. 
4. Создание ТЗ на следующий этап. Можно в явном виде выделить работы по созданию будущего задания, проработке пользовательских историй в беклоге. 

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

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

Есть различные методики оценки проекта. Я считаю, что делать оценку должен 1 опытный разработчик. Есть вариант, когда проводится совещание всей командой и делается голосование по каждой задаче (каждый дает свою оценку). На мой взгляд, это придумал человек, который платит программистам не из своего кармана. 

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

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

Ключевое по оценке проекта 

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

P.S. Реокмендуем вам посмотреть нашу статью о снижении затрат на разработку сайта.