Сколько стоит сделать сайт
Дать оценку стоимости проекта, когда заказчик не хочет рассказывать о бюджетах и хотелках — задача сложная, но мы её решили вот как.
![](https://s29805.cdn.ngenix.net/upload/_tilda/project417113_1658376315/tild3939-6639-4339-a134-363332383361__-__empty__annafullhd.png)
Анна Кожевина
Финансовый директор
Когда наш аккаунт-менеджер получает лид, ему важно знать, какой бюджет у заказчика. Это помогает сразу выяснить, стоит ли тратить время на звонки-сметы-презентации, или лучше просто поделиться с человеком ссылочкой на fl.ru.
Для заказчиков тоже самое важное — узнать стоимость проекта. Но просто так сказать, сколько готовы потратить, они могут в очень редких случаях. Ибо боятся, что разработчики резко поднимут цены — чтобы бюджет не пропадал (ага-ага).
У нас есть скрипты, которые позволяют выяснить бюджет проекта. Но они не всегда работают. Поэтому у нас есть дополнительные критерии, по которым мы определяем, сколько времени целесообразно тратить на обработку заявки.
Обычно лиды оцениваются в несколько этапов. Это позволяет отсеивать неподходящие заявки и тратить больше времени на продажу интересных нам проектов.
Вот что мы делаем, когда получаем запрос на разработку:
Для заказчиков тоже самое важное — узнать стоимость проекта. Но просто так сказать, сколько готовы потратить, они могут в очень редких случаях. Ибо боятся, что разработчики резко поднимут цены — чтобы бюджет не пропадал (ага-ага).
У нас есть скрипты, которые позволяют выяснить бюджет проекта. Но они не всегда работают. Поэтому у нас есть дополнительные критерии, по которым мы определяем, сколько времени целесообразно тратить на обработку заявки.
Обычно лиды оцениваются в несколько этапов. Это позволяет отсеивать неподходящие заявки и тратить больше времени на продажу интересных нам проектов.
Вот что мы делаем, когда получаем запрос на разработку:
1. Изучаем заявку. Оцениваем, насколько проект и заказчик нам интересны. Если заявка была сделана по телефону, аккаунт-менеджер делает это уже в ходе брифования.
Бывают клиент, которые мне подходят и которые не подходят. С первыми работать легко и просто, для них хочется делать быстрее, лучше, качественнее. ТАКОМУ КЛИЕНТУ НУЖНО СДЕЛАТЬ ХОРОШО! От вторых — аккуратно отойти в сторонку и не трогать. Свои критерии хорошего клиента я изложил тут. Нужно просто принять, что мы не сможем сделать все-все-все проекты в мире, и искать именно те, которые больше подходят нам по духу.
![](https://s29805.cdn.ngenix.net/upload/_tilda/project417113_1658376315/tild3961-3639-4361-a366-663065663730__-__empty__wz1.jpg)
Владимир
Руководитель scrum-студии Сибирикс
У нас есть анкета, которая позволяет определить (просто, по сумме баллов), насколько нам интересен проект. Но на практике чаще применяется интуитивная оценка.
Интуитивная оценка — это когда аккаунт-менеджер думает примерно так: «Ага, это тендер с техническим заданием на 300 страниц, требованиями предоставить бесплатную концепцию и ворох бумажек. Главный критерий выбора — минимальный бюджет. В тендере кроме нас компании из более дешевого сегмента. Ловить тут нечего. Больше получаса тратить смысла не имеет. Да и полчаса жалко. Смотрим на структуру сайта (как бы ее ещё в ТЗ найти!), умножаем на коэффициент „тендер“, даем широкую и не особо точную вилку по цене».
Если проект точно не в рамках наших компетенций, или по каким-то критериям не подходит — сразу честно пишем про это заказчику.
Интуитивная оценка — это когда аккаунт-менеджер думает примерно так: «Ага, это тендер с техническим заданием на 300 страниц, требованиями предоставить бесплатную концепцию и ворох бумажек. Главный критерий выбора — минимальный бюджет. В тендере кроме нас компании из более дешевого сегмента. Ловить тут нечего. Больше получаса тратить смысла не имеет. Да и полчаса жалко. Смотрим на структуру сайта (как бы ее ещё в ТЗ найти!), умножаем на коэффициент „тендер“, даем широкую и не особо точную вилку по цене».
Если проект точно не в рамках наших компетенций, или по каким-то критериям не подходит — сразу честно пишем про это заказчику.
![](https://s29805.cdn.ngenix.net/upload/_tilda/project417113_1658376315/tild3737-3564-4635-a436-666361383237__-__empty__noroot.gif)
2. Задаём уточняющие вопросы по проекту. По возможности выясняем бюджет.
Нам надо максимально точно понять, что хочет заказчик, при этом потратить как можно меньше времени (его и так мало, а то, что есть — жалко). То есть вариант читать от корки до корки ТЗ на несколько сот страниц (если оно есть) отпадает. Отправить заказчику бриф и пусть мучается для заполнения — тоже не вариант. По опыту, с большинством заказчиков общение на этом и заканчивается.
Поэтому:
- мы проводим краткое брифование с заказчиком голосом (это быстрее, чем писать письма);
- в разговоре просим референсы (ссылочки на то, что заказчику нравится);
- определяем тип проекта и уточняем наличие фич, которые могут повлиять на цену. Обычно это интеграции с внешними сервисами, сложные личные кабинеты, калькуляторы-конструкторы, хитрые промо-штуки и т. д. Если на проект есть техзадание — читаем его, пока по диагонали, только чтобы выявить такие моменты.
По итогам брифования аккаунт-менеджер может описать проект в одном абзаце, например: «Интернет-магазин одежды с личным кабинетом пользователя и нетиповой интеграцией с 1С. Фишка проекта — конструктор образов из представленных в магазине товаров и модный блог». И этого вполне достаточно для предварительной оценки.
![](https://s29805.cdn.ngenix.net/upload/_tilda/project417113_1658376315/tild3135-3063-4536-a565-623665343166__-__empty__noroot.gif)
3. Даём предварительную вилку по стоимости проекта.
В инструкции аккаунт-менеджеров у нас прописаны типовые вилочные оценки разных типов проектов. Например: «Стоимость разработки простого интернет-магазина — от ХХХ рублей до YYY рублей». Наглядно можно посмотреть тут.
Мы берём такую типовую оценку и корректируем ее, добавляем-убавляем:
Чем больше на сайте вещей, о которых сам заказчик не знает, как они должны работать, чем толще ТЗ и сложнее клиент — тем шире будет вилка.
Мы берём такую типовую оценку и корректируем ее, добавляем-убавляем:
- возможную стоимость дополнительных элементов, список которых мы
отжаливыяснили у заказчика на предыдущем этапе; - сложность предложенных заказчиком референсов (тут мы будем ориентироваться в первую очередь на дизайн, анимацию и всякие прикольные, но
сцукотрудоемкие мелочи). - степень геморройности заказчика. То, что её мы определяем на глазок, уже написано выше. Но формальный список критериев никто не отменял.
Чем больше на сайте вещей, о которых сам заказчик не знает, как они должны работать, чем толще ТЗ и сложнее клиент — тем шире будет вилка.
Cуровая правда жизни: точность предварительной оценки напрямую зависит от вероятности, что проект продастся, и от того, насколько он нам интересен.
4. Если предварительная оценка подходит заказчику, мы готовим подробную смету, правда, тоже с вилочной ценой.
Мы выясняем, что наши с заказчиком взгляды на стоимость проекта совпадают. Вилочно. Хотя бы количество нулей в бюджете устраивает обе стороны.
Готовим смету. Делаем это исходя из структуры сайта. Опыт показал, что это самый простой в реализации и понятный для всех способ. И потом проще понять, входят ли те или иные фичи в предварительную оценку, или они родились уже в ходе обсуждения проекта.
У нас есть типовые оценки для разных страниц и модулей сайта. Нестандартные модули мы оцениваем отдельной строкой в рамках страниц, где они появляются. Тоже вилочно.
Хотя в голове у заказчика может быть четкая картинка будущего проекта, ее не получится полностью транслировать разработчику, пока не проведена агрегация требований, не разработаны прототипы и техническое задание. А после обсуждения нюансов в ходе аналитики картинка может ещё и измениться (мы посоветуем самые лучшие решения, обещаем).
Готовим смету. Делаем это исходя из структуры сайта. Опыт показал, что это самый простой в реализации и понятный для всех способ. И потом проще понять, входят ли те или иные фичи в предварительную оценку, или они родились уже в ходе обсуждения проекта.
У нас есть типовые оценки для разных страниц и модулей сайта. Нестандартные модули мы оцениваем отдельной строкой в рамках страниц, где они появляются. Тоже вилочно.
Хотя в голове у заказчика может быть четкая картинка будущего проекта, ее не получится полностью транслировать разработчику, пока не проведена агрегация требований, не разработаны прототипы и техническое задание. А после обсуждения нюансов в ходе аналитики картинка может ещё и измениться (мы посоветуем самые лучшие решения, обещаем).
![](https://s29805.cdn.ngenix.net/upload/_tilda/project417113_1658376315/tild3963-3235-4132-b636-303236313339__-__empty__noroot.gif)
Получается, что проект, в котором вроде бы нет никаких черных дыр, все равно может стоить по-разному.
Как начать работать при такой степени неопределенности? Все просто — мы даём фиксированную оценку на первый этап любого проекта — агрегацию требований. Когда она будет готова, сможем точно оценить разработку прототипов и технического задания. После их утверждения дадим оценку на дизайн… Ну и так далее.
Стоимость проекта будет уточняться по мере приближения к релизу, но мы обещаем — она останется в рамках первоначальной вилки, если список функций в проекте не менялся.
Как начать работать при такой степени неопределенности? Все просто — мы даём фиксированную оценку на первый этап любого проекта — агрегацию требований. Когда она будет готова, сможем точно оценить разработку прототипов и технического задания. После их утверждения дадим оценку на дизайн… Ну и так далее.
Стоимость проекта будет уточняться по мере приближения к релизу, но мы обещаем — она останется в рамках первоначальной вилки, если список функций в проекте не менялся.