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

Оценка стоимости собственных услуг – процесс сложный и неоднозначный. Тут как на минном поле – неверный шаг влево или вправо, и либо клиент уплыл к конкуренту, либо твоя компания недозаработала. Поэтому адекватный алгоритм определения стоимости услуг – важнейший инструмент для успешной работы небольшой компании. О том, как scrum-студия Sibirix определяет цену на разработку сайтов, в корпоративном блоге рассказала финансовый директор компании Анна Кожевина.

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

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

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

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

Лирическое отступление. Бывают клиенты, которые нам подходят и которые не подходят. С первыми работать легко и просто, для них хочется делать быстрее, лучше, качественнее. Такому клиенту нужно сделать хорошо! От вторых - аккуратно отойти в сторонку и не трогать. Нужно просто принять, что мы не сможем сделать все-все-все проекты в мире, и искать именно те, которые больше подходят нам по духу. У нас есть чек-лист, который позволяет определить (просто, по сумме баллов), насколько нам интересен проект:

При этом, несмотря на наличие чек-листа, на практике чаще применяется интуитивная оценка. Интуитивная оценка - это когда аккаунт-менеджер думает примерно так: «Ага, это тендер с техническим заданием на 300 страниц, требованиями предоставить бесплатную концепцию и ворох бумажек. Главный критерий выбора - минимальный бюджет. В тендере кроме нас компании из более дешёвого сегмента. Ловить тут нечего. Больше получаса тратить смысла не имеет. Да и полчаса жалко. Смотрим на структуру сайта (как бы ее ещё в ТЗ найти!), умножаем на коэффициент «тендер», даём широкую и не особо точную вилку по цене». 

Если проект точно не в рамках наших компетенций, или по каким-то критериям не подходит - сразу честно пишем про это заказчику.

Вот что мы делаем, когда получаем запрос на разработку:

1. Изучаем заявку. Оцениваем, насколько проект и заказчик нам интересны. Если заявка была сделана по телефону, аккаунт-менеджер делает это уже в ходе брифования.

2. Задаём уточняющие вопросы по проекту. По возможности выясняем бюджет.

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

Поэтому: 

• мы проводим краткое брифование с заказчиком голосом (это быстрее, чем писать письма);
• в разговоре просим референсы (ссылочки на то, что заказчику нравится);
• определяем тип проекта и уточняем наличие фич, которые могут повлиять на цену.

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

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

3. Даём предварительную вилку по стоимости проекта.

В инструкции аккаунт-менеджеров у нас прописаны типовые вилочные оценки разных типов проектов. Например: «Стоимость разработки простого интернет-магазина – от 800 000 рублей до 1 200 000 рублей». 

Мы берём такую типовую оценку и корректируем ее, добавляем-убавляем: 

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

Cуровая правда жизни: точность предварительной оценки напрямую зависит от вероятности, что проект продастся, и от того, насколько он нам интересен.

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

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

Готовим смету. Делаем это исходя из структуры сайта. Опыт показал, что это самый простой в реализации и понятный для всех способ. И потом проще понять, входят ли те или иные фичи в предварительную оценку, или они родились уже в ходе обсуждения проекта. 

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

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

Получается, что проект, в котором вроде бы нет никаких чёрных дыр, всё равно может стоить по-разному. 

Как начать работать при такой степени неопределенности? Всё просто - мы даём фиксированную оценку на первый этап любого проекта -  агрегацию требований. Когда она будет готова, сможем точно оценить разработку прототипов и технического задания. После их утверждения дадим оценку на дизайн... Ну и так далее. 

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

Источник: Sibirix.

Туалетное делегирование: что это такое и как с ним бороться.
Как правильно наказывать сотрудников: без обид и по науке. 
Как навести порядок в процессах.
biz360