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

Прочтёте за 5 мин.

Анна Кожевина – о том, как scrum-студия Sibirix определяет стоимость своих услуг по разработке сайтов

IT-инструменты, которые использует Анна Кожевина

  • 1С:Бухгалтерия
  • 1С-Битрикс
  • Facebook
  • Skype

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

Досье

Анна Кожевина, финансовый директор scrum-студии  Sibirix. Образование: Алтайский государственный технический университет, специальность – «менеджер-экономист». Студия Sibirix специализируется на разработке интернет-магазинов, корпоративных сайтов, мобильных приложений и т.д. Компания входит в топ-10 рейтинга лучших веб-студий по версии Tagline. Среди клиентов студии такие бренды, как Ralf Ringer, Ormatek, Slava Zaitsev, «СоюзЛото», «Ярославский бройлер» и др.

Анна Кожевина

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

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

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

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

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

Хороший клиент

1000

Проект имеет шанс выжить (стать прибыльным, №1 или №2 в своей отрасли)

990

Сходу есть ощущение, что мы - значительно компетентнее клиента и можем и хотим ему помочь

950

В разговоре чувствуется взаимное уважение

900

У него интересный, технологичный проект

900

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

850

Готов вносить предоплату

840

Согласен на копирайт или +20% стоимости за NDA

800

Проект для мобилок или какой-то интересный стартап

780

Есть деньги на аналитику (прототип)

760

Быстро принимает решение о старте работ

750

Согласен с нашим рейтом, сроками и ценовой политикой

700

Готов выделить время 30-60 минут 2-3 раза в неделю на работу над проектом

650

Прямой контакт с ЛПР

600

Не компостирует мозг с многочисленными редакциями договора

600

Имеет чёткий дедлайн и намерен его придерживаться

550

Намерен согласовывать проект единолично

500

Есть деньги на раскрутку проекта

500

Быстро принимает решения по ходу переговоров

450

Клиент управляемо-готов к креативным решениям, но не требует «подумать за него»

300

В течении рабочего дня отвечает на письма

300

В рабочее время доступен по skype или по телефону

150

У клиента есть готовый контент

80

Клиент готов на scrum

Карма

-200

Хочет всё «под ключ», не вникая в ход работы. Готов проявлять вовлечённость только на этапах приёмки, но не на промежуточных этапах.

-250

Придирается к работам

-300

Имеет юротдел, который хочет выслужится

-300

Хочет мелкую техподдержку, и ничего кроме

-300

Заказывает внешний аудит

-300

Критикует какие-либо из работ в портфолио, при этом выражает одобрение другим

-300

Не даёт точной информации при брифовании, но торопит заключить договор

-400

Имеет штатного или удалённого админа или другого техспеца, который планирует вмешиваться в ход программирования и код проекта или «дописывать» модули

-420

Внезапно пропадает или едет в отпуск или у него постоянно горят заводы (человек форс-мажор)

-500

Внезапно меняет ответственное лицо

-540

Очень медленно принимает любые решения. Меняет мнения.

-550

Долго не отвечает на письма (более 1 суток или даже более того)

-600

Имеет 1 посредника

-750

Не согласен с нашим рейтом, сроками и ценовой политикой

-800

Долго согласовывает договор (три итерации).

-830

Не готов работать с предоплатой

-900

Сроки — вчера, но ничего еще неизвестно

-900

Фантазёр. Хочет какую-то фигню

-900

Имеет более одного посредника

-900

Не согласен на размещение копирайтов и публикацию в портфолио

-900

УпалНамоченный. Принимает любые решения только коллегиально.

-900

Передаст. Назначен менеджером, но ничего не делает, кроме копипастов сообщений.

-900

Чайка. Прилетел-наорал-нагадил-улетел.

-950

Пробивальщик цены или тендер

-950

Хулитель. Обсирает предыдущую студию

-970

Нарциссизм. Проект - повод почесать ЧСВ клиента об ваше и сделать из вас никчёмность

-1000

Гопник. Мат. Ненормативная лексика. Грубые выражения. Криминальный или военный сленг

-1000

Неуважительные высказывания. Непартнёрские (барские) повадки.

-20000

Намекает на откат.

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

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

I

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

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

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

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

Поэтому: 

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

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

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

II

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

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

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

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

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

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

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

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

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

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

III

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

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

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

Источник: Sibirix.

Money

Читайте также:

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

05 мая 2017

Комментарии

1
  • Михаил Левочко 27.10.2018 10:29

    Так в итоге как работают коэффициенты из этой таблицы?

  • Задайте вопрос
    по автоматизации бизнеса

    Наши эксперты ответят на вопросы по автоматизации бизнеса


    Задать вопрос
    Ваш вопрос отправлен

    Ваш вопрос

    Введите Имя
    Введите E-mail
    Отправить Очистить
Возможно, вас заинтересуют другие наши материалы
Загрузить ещё
Идёт загрузка материалов