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

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

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

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

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

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

Владимир
Руководитель scrum-студии Сибирикс

Бывают клиенты, которые мне подходят и которые не подходят. С первыми работать легко и просто, для них хочется делать быстрее, лучше, качественнее. ТАКОМУ КЛИЕНТУ НУЖНО СДЕЛАТЬ ХОРОШО! От вторых — аккуратно отойти в сторонку и не трогать. Свои критерии хорошего клиента я изложил тут. Нужно просто принять, что мы не сможем сделать все-все-все проекты в мире, и искать именно те, которые больше подходят нам по духу.

У нас есть анкета, которая позволяет определить (просто, по сумме баллов), насколько нам интересен проект. Но на практике чаще применяется интуитивная оценка.

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

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

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

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

Поэтому:

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

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

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

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

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

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

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

• возможную стоимость дополнительных элементов, список которых мы отжали выяснили у заказчика на предыдущем этапе;

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

• степень геморройности заказчика. То, что её мы определяем на глазок, уже написано выше. Но формальный список критериев никто не отменял.

Чем больше на сайте вещей, о которых сам заказчик не знает, как они должны работать, чем толще ТЗ и сложнее клиент — тем шире будет вилка.

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

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

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

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

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

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

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

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

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