Как мы получаем цену на разработку, когда клиент знает что хочет 8 Как мы получаем цену на разработку, когда клиент знает что хочет 9 Как мы получаем цену на разработку, когда клиент знает что хочет 10

Где цены, Зин? Как мы получаем цену на разработку, когда клиент знает, что хочет

#SaaS #Бизнес

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

Когда пришел запрос

Сначала мы читаем запрос и узнаем, какие уже есть вводные материалы, которые описывают идею проекта/продукта. Всё, что уже есть, мы внимательно изучаем прежде, чем двигаться дальше. Также для нас очень важно, кто вы: собственник/топ-менеджер или сотрудник, которому поручено выбрать подрядчиков по формальным критериям или просто “собрать цены”. Это позволяет нам правильно вам ответить.

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

Уточняем, с какой целью разрабатывается данный проект

Если что-то уже есть, то какие сейчас есть нарекания на текущее решение? Мы внимательно (и обычно долго) выслушиваем все проблемы и боли, и там, где мы знаем решение или есть идеи по решению, можем сразу предложить, как это можно решить. Да, иногда оказывается, что всё решается проще и таким образом мы просто сэкономим вам время.

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

Стресс-тест – это короткий список простых вопросов:

  • Кому это нужно?
  • Зачем вам лично этим заниматься?
  • В чем прибыль?
  • Зачем это делать?
  • ...и ряд подобных, которые мы выбираем в зависимости от ваших ответов на предыдущие.

Ответы на эти вопросы помогают нам понять, а стоит ли теперь прорабатывать реализацию этой идеи, а вам - определиться, стоит ли тратить усилия на реализацию этой идеи.

За годы применения такого подхода мы поняли, что не стоит бояться, что клиент обидится и уйдет, обычно наоборот: во-первых, клиент осознает возражения против этого проекта, которые на этапе генерации идеи упускают (особенно это важно в корпоративном секторе, ведь все возражения могут потом озвучить акционеры или генеральный директор на этапе бюджетирования); во-вторых, понимает, что ты не хочешь ему продать что-то по-быстрому, а думаешь о его выгоде в первую очередь (если б ты хотел продать по-быстрому, ты бы просто отправил бриф, собрал бы перечень хотелок, потом выставил бы ему табличку с ценой и забрасывал бы его вопросами: «Получили ли мое недавнее письмо? А когда ответите?»).

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

Заполняем документ с целями и задачами продукта

Это на уровень глубже, чем голая идея и стресс-тест на уровне «зачем это надо». Цель создания продукта – это то, что стоит делать вам или вашему бизнесу, чтобы сгенерировать или повысить прибыль предприятия. Если цель не завязана никак на повышение прибыли или любое другое качественное улучшение бизнеса, бывает очень трудно продвинуться дальше идеи в таком проекте, потому что, если этот проект doesn't make difference, зачем его вообще делать? Процесс определения цели может быть непростым.

Приведем пример: к невропатологу заходит пациент и сходу говорит: «Здравствуйте, доктор! Мне нужна но-шпа, у меня пятка болит!». Что вас смущает в этой ситуации? Клиент приходит с решением, еще не понимая, что же ему на самом деле лечить нужно. Опытный врач не поверит, попросит задержаться и перейдет к выявлению симптомов: «Что болит, где болит? Что делали до этого? Когда появились первые признаки?» и т.д. Наш процесс определения целей – это 1:1 постановка диагноза в подобных ситуациях, только но-шпу заменить, например, на CRM-систему.

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

«Я хочу сделать всё как у них, только с нюансами под мой бизнес»

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

Звучит он так: понимаете ли вы, что вот в этот аналог вложен, скажем, 1 миллион долларов и нужный вам клон, даже местного производства, потребует как минимум 100 000 долларов? (если мы говорим о клоне миллионного продукта, на более простых продуктах пропорция меняется, но принцип тот же).

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

Есть ли команда с вашей стороны, которая будет работать с нами над проектом; если да, то кто за что отвечает?

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

Какой бюджет вы планируете на проект?

Обычно говорят «не скажу», в ответ мы говорим примерно следующее: «Нам нужно знать бюджет, чтобы предложить оптимальное техническое решение по цене и качеству. Не зная бюджет изначально, мы можем потратить много времени на проектирование мерседеса, а вдруг вам нужен Daewoo Lanos?!». Обычно это работает, если вы распоряжаетесь бюджетом. Если вы еще не знаете даже примерных планок, мы спросим вас о вилках цены: «Ваш проект за $10 000 – это много? А за $50 000?». В любом случае нам важно понимать, как ваш запрос коррелирует с нашим пониманием того, сколько это может стоить.

Если на этом этапе вам достаточно получить диапазон «от» и «до», мы его посчитаем по двум параметрам: накопленный опыт (статистика человеко-часов в трекере по старым проектам) + среднерыночные цены на проекты подобного уровня и на таких технологиях. Точность вилки – плюс-минус 25-30%.

Так где же берутся цены?

Итак, вы провели с нами время; мы надеемся, что узнали много интересного для себя, но где же здесь наше коммерческое предложение и цены?

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

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

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

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

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

Что дальше?

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

После этого мы готовы начинать работы, и всё самое интересное только начинается.

20.03.2017
Используемые в статье картинки взяты из открытых источников и используются как иллюстрации.
Хотите обсудить ваш проект или заказать разработку?
Отправить
Цей сайт є українською мовою. Ви можете переключити мову у меню, або зробити це зараз.