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

Суть проблемы

Продажа – самое начало проекта и ошибки на этом этапе – самые страшные. Не проработаете ожидания клиента или промахнетесь с оценками и вас ждет «путь камикадзе». Перезаложите бюджет – потеряете клиента или у него сложится ощущение обманутости.

Чтобы хорошо продавать ПО необходимо обладать солидным опытом как в разработке (технологиях, менеджменте и процессах), так и в продажах. Эти компетенции крайне сложно совместить в одном человеке, а когда они совмещаются, такой человек называется «основатель компании» или «исполнительный директор». Я знаю примеры компаний, в которых директор проводит первичную обработку всех заказов на разработку. Обычно потолок роста такой компании 25-30 человек, а директор – перегружен.

Альтернативный вариант – делегировать оценку техническому директору (CTO). Обычно, это второй по перегруженности человек в компании. Кроме того, у технического директора вагон и маленькая тележка других задач. Таскать его на каждый pre sales – не вариант. Я искренне убежден, что любой нетривиальный проект можно разрабатывать только итеративно и только с прототипами. Такой подход до сих пор сложно принять многим клиентам на территории СНГ. Все хотят на берегу зафиксировать сроки и бюджет. К сожалению, это желание не сопровождается техническим заданием, на основании которого можно было бы работать.

Данная статья – не совсем скрипт для продажи в привычном понимании слова. Скорее попытка построить мостик между «техническим» и «бизнес» — мышлением и помочь тем, кто испытывает сложности с презентацией и отстаиванием итеративного подхода к разработке.

Первая встреча/входящий запрос

На кликабельной для увеличения картинке ниже жизненный цикл проекта, каким его вижу я. Зелеными флажками обозначены этапы, за которые клиент вносит предоплату. Исключением является этап «подписываем акт». В этот момент клиент принимает работу и оплачивает оставшуюся часть.

В статье я буду использовать термин «проект», а не «продукт», даже если речь идет о стартапе или разработке коробочного, тиражируемого продукта, потому что «продуктовая» разработка подразумевает работу с внутренним, а не внешним заказчиком.

Задачи:

1. отсеять неадекватных клиентов
2. подготовить адекватных к тому что с высокой вероятностью работа предстоит долгая и потребует хотя-бы частичного погружения в проект
3. провести подготовительную работу, узнать текущий статус проекта запросить существующие материалы
4. дать клиенту грубую оценку по срокам, стоимости и технологиям (обязательно уточнив, что такая оценка показывает лишь порядок сроков и цен, не является финальной и может измениться в любую сторону)
5. презентовать клиенту итеративный подход и предложить работать именно так

Отсеять неадекватных клиентов

1. Хамит
2. Не слушает и перебивает
3. Ставит под сомнение любые мои аргументы или пытается уличить во лжи
4. Апеллирует тезисами, вроде «у меня у друга сын-студент написал программу…»

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

Подготовить адекватных

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

Львиная доля всех проектов в IT не укладывается в сроки и бюджеты. Иные даже в релиз не выходят. Причины я описывал в статье «рентабельный код». Несмотря на это, все еще хватает в нашей сфере индусов не опытных подрядчиков, пренебрегающих рисками. Эти горе-программисты не способны правильно оценить объем работы, зато способны пообещать золотые горы. Не квалифицированному клиенту сложно выбрать правильного подрядчика. Клиент оперирует терминами «стоимость» и «срок».

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

Однажды мне нужно было купить утюг. Я зашел в один крупный магазин бытовой техники. На меня смотрела целая полка утюгов. Самый дешевый стоил 800 рублей, самый дорого – больше 20.000 рублей. Я находился в растерянности, потому что на вид все чайники казались мне одинаковыми. Я попросил продавца-консультанта объяснить мне разницу. Девушка что-то начала рассказывать про дополнительные функции, режимы… Дивный голос продавщицы показался мне песней… на китайском языке. Я попросил ее посоветовать мне то, что она купила бы себе, взял эту модель и пошел домой, думая, как трудно моим клиентам. Ведь им нужно не просто выбрать из существующих «утюгов», а спроектировать и собрать свой собственный «утюг» с блэк-джеком и всем остальным.

Я могу разделить сложных клиентов на два типа:

1. я расскажу вам, как делать вашу работу
2. ну что вы ко мне пристали, вы программисты – вы и делайте

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

Со вторым типом клиентов все проще и сложнее одновременно. С одной стороны, вам не мешают, с другой – вас лишают обратной связи и велик риск того, что на этапе сдачи проекта вам скажут «мы ожидали совершенно иного». Чего они ожидали они на самом деле не знают, что не является поводом включать дурочку стиле «клиент сам дурак, бе-бе-бе».

Дать клиенту грубую оценку по срокам, стоимости и технологиям

К этому моменту у нас на руках есть вся существующая документация по проекту и какая-то информация, преданная устно, в ходе встречи или звонка. К сожалению, это все еще очень ранний pre-sales. Желательно уклониться от оценки и продать прототипирование, потому что на данном этапе все еще правильно говорить «угадывать», а не «оценивать». Однако, если дать какую-то вилку все-же нужно, я использую «ресурсный метод» подсчета:

1. Программист, обладающий необходимый для моих задач квалификацией, стоит в регионах России (не Белокаменной)
   60.000 – 120.000 рублей
2. QA – 30.000 – 80.000
3. Менеджер 40.000 – 80.000

Типичные небольшие команды могут быть такими:

Вариант 1

1. Team Lead (Старший разработчик + Менеджер)
2. Разработчик
3. QA

Вариант 2

1. Разработчик
2. Разработчик
3. Менеджер (заодно и тестирует)

Вариант 3 (расширенный)

1. Team Lead
2. Разработчик
3. Разработчик
4. Разработчик
5. QA
6. UX
7. Аккаунт-Менеджер

Вариаций может быть много, это базовые составы. Стоимость аренды подобной команды в месяц у российских аутсорсеров варьируется в диапазоне 500.000 рублей +- 100.000. Типичные проекты длятся от 3 до 12 месяцев.

Умножаем полмиллиона на от 3 до 12 и получаем от 1.5 до 4 миллионов рублей.

Именно на этом этапе у нас появляется пространство для переговоров

С одной стороны, клиент должен был к этому моменту составить представление за что он платит и какие опасности поджидают при обращении к студенту-племяннику или подрядчику из Калькутты. С другой, разброс цен слишком велик.
В этот момент на сцене появляется волшебный термин «прототипирование». Под прототипами я понимаю mockup’ы, собранные а Axure или подобном софте, желательно, интерактивные.

Прототипирование можно посчитать по fixed-price схеме: клиент платит за концепцию (3-10 экранов). После утверждения концепции оплачивается разработка остальных экранов прототипов. Я считаю, что проектирование должен делать один UX/BA-специалист, консультируясь с «технарем», чтобы не нарисовать что-то слишком сложно реализуемое (этим грешат обычно в digital’е) или не подходящие для выбранной платформы разработки. Если такого специалиста нет, то надо завести в штат или на договоре подряда.

С прототипами на руках уже можно рассчитать проект по столь любимой клиентом fixed-price схеме. А может, уже и не придется этого делать и T&M подойдет. Когда вы продаете прототипирование вы говорите клиенту: «давай снизим наши общие риски, прежде чем с головой бросаться в омут разработки, еще раз хорошенько все обдумаем и нарисуем, чтобы ты смог потрогать».

Аргументы за прототипирование

1. На основании можно более точно рассчитать стоимость. На основе прототипов клиент получит смету, с указанием технологического стека, платформы, которую действительно считали, а не взяли с потолка
2. Прототипы можно прокликать и еще до разработки понять, удобно ли пользоваться системой и не упущены ли какие-то ключевые требования. Удобство использования – не пустой звук. Плохой интерфейс может стать узким местом бизнес-процесса, следовательно, причиной снижения дохода. Если интерфейс позволяет допустить оператору ошибку, это может привести к прямым убыткам
3. Исправить ошибки на этапе прототипирования гораздо быстрее и дешевле, чем на этапе разработки
4. Прототип – может использоваться как средство верификации работы подрядчика, он гораздо нагляднее и понятнее текста, отмазка в стиле «я так понял ТЗ» не пройдет

После утверждения прототипов можно одновременно рисовать финальный визуальный дизайн и начинать разработку. Я предпочитаю Scrum для команды разработки и Kanban для поддержки. Организация работы команды по Agile и утверждение визуального дизайна выходят за рамки этой статьи. Остановлюсь лишь на том, что я рекомендую согласовать с клиентом несколько промежуточных демонстраций и процесс обработки change request’ов. На этих встречах необходимо рассказывать о проделанной работе и предлагать клиенту самому проверить выполнение целей спринтов. Таким образом, этап внедрения и интеграции начнется раньше сдачи проекта, что поможет не затягивать с подписанием финальных актов и оперативно реагировать на изменение внешней ситуации. Как говорится, аппетит приходит во время еды и уже после первой или второй демонстрации клиент может захотеть расширить функциональность и бюджет.

Автор: marshinov

Источник