Привет всем тут!
Моя основная работа – это разработка программного обеспечения для бизнеса. Скажу по правде, бывают дни, когда мне хочется взять автомат в руки и просто пристрелить весь отдел продаж. Но потом вспоминаю, что именно эти сотрудники обеспечивают в компанию денежный поток. А мы, прогеры, только приносим затраты. Потом меня осеняет, мышление программиста и продавца существенно отличается, да и навыки тоже. Плюс и учили нас всех по-разному совершенно. Им каждый день приходится, беднягам, выслушивать возражения, капризы, и что-то вроде «а у нас есть знакомый подрядчик, так он пообещал разработать нам точно вот такую же систему, только в два раза дешевле и в три раза оперативнее».
Проблема по существу
Продажа – это ж только начальная стадия проекта. То есть, если допустить ошибки на этом этапе, то они окажутся самыми страшными. Если облажаетесь с оценкой или проработаете ожидания клиента, то можно сразу сливаться. Потерять клиента можно и в случае, если вы перезаложите бюджет. Так ему может показаться, что его обманули и «надули».
Чтоб отлично и продуктивно заниматься продажей ПО, нужно обладать очень внушительным опытом не только в разработках, но и в сфере продаж. При этом необходимо уметь разрабатывать не только технологии, но и процессы, в том числе менеджмент. Крайне сложно найти человека, который бы совмещал в себе все эти компетенции. Даже если найти такую личность, то она обычно занимает кресло директора или основателя фирмы. Лично знаю примеры компаний, где директор самолично производит первичную обработку каждого заказа на разработку. В итоге управляющий перегружен, а рост фирмы может ограничиться в лучшем случае 25-30 людьми.
Альтернатива? Как вариант, можно делегировать оценку СТО, то есть техническому директору. Как правило, это второй по перегруженности человек на фирме. И у него всегда найдется вагон других проблем. Вызывать его на каждый «пре сейл» – вообще не вариант.
Мое твердое убеждение – любой нетривиальный проект возможно разработать только при наличии прототипов, а также исключительно итеративно. Данный подход по сей день сложно принимается клиентами, тем более отечественными. Все что хотят? Сидеть на берегу, фиксируя и бюджет, и сроки. Увы, но такое желание не сопровождается техзаданием, а ведь только на его основании можно начать работу. Но да, клиент всегда думает, что он поставил задачу предельно ясно и четко.
Если вы надеетесь, что я дальше буду описывать вам скрипт для продажи, в том понимании этого слова, в каком все привыкли это видеть – то ошибаетесь. Я всего лишь попробую выстроить мостик между понятиями «бизнес» и «техничность», то есть помочь тем, у кого вызывают сложности презентации, а также тем, кто отстает с итеративным подходом к разработке.
Дальше я буду применять понятие «проект», даже если речь будет идти о тиражируемом продукте. «Продуктовые» разработки – это же ведь работа с внутренним заказчиком, а не заказчиком из «вне».
Итак, какие главные задачи?
1. Определить неадекватных клиентов и сразу же их отсеять.
2. Оставшихся (то есть компетентных) морально подготовить к долгой работе. Также убедить их, что процесс требует от них хотя бы минимального погружения в проект.
3. Подготовительная работа: запрос существующих материалов и поиск информации о текущем статусе проекта.
4. Предоставление грубой оценки для клиента по стоимости, срокам и технологиям. Тут важно уточнить, что подобная оценка олицетворяет только лишь порядок стоимости и сроков, но никак не считается финальным значением. То есть, может меняться в любую сторону.
5. Презентация клиенту итеративного подхода. Нужно предложить именно такое выполнение работы.
Если же клиент неадекватный, то, как вести себя? Многие сейчас мне возразят, мол, половина неадекватная, так что теперь, отказываться от них? Да, отказываться. Причем я определяю неадекватность следующим набором признаков:
- хамство;
- нежелание выслушать вас и постоянное перебивание;
- сомнения в любых ваших аргументах, попытки уличить во лжи;
- апелляция тезисами «да у меня у двоюродного брата есть друг, так его сын написал программу…».
Любой из вышеперечисленных пунктов свидетельствует о том, что построить нормальное общение и взаимодействие не получится. Это значит, что в будущем проект будет провальным. Нужно отказываться от подобных клиентов. Не переживайте, запросов на разработку программного обеспечения всегда хватает.
Теперь идем дальше. Подготовительный этап, точнее подготовка вашего адекватного клиента. Тут нужно сразу же дать ему понять, что работа предстоит сложная, трудная. Но не переусердствуйте. Не стоит запугивать клиента. Оставайтесь все-таки оптимистично настроенными.
Большая часть всех существующих проектов зачастую не укладывается в определенные изначально бюджеты и сроки. Бывают и такие, которые даже не могут войти в релиз. Но, несмотря на это, до сих пор встречаются в этой сфере неопытные подрядчики, которые пренебрегают рисками. Такие горе-прогеры не могут даже адекватно оценить объем предстоящей работы, но все остальное им – как море по колено. Неквалифицированный клиент всегда будет испытывать сложность в плане выбора «правильного» подрядчика, ведь для него главными остаются «сроки» и «цена».
Чтоб вы лучше понимали чувства и мысли вашего клиента, нужно встать на его место. Так у вас получится в необходимый момент подобрать нужные слова и донести до него свои мысли.
Как-то раз мне нужно было приобрести утюг. С этой целью я забрел в крупный супермакет бытовой техники. Там на меня глядела целая полка этих самых утюгов. Ценовой диапазон – от тысячи до 20 тысяч. Я прям растерялся, так как на вид все они были для меня абсолютно одинаковыми. Девушка-консультанат попробовала мне объяснить разницу между ними всеми, начала рассказывать про какие-то опции, режимы и т.д. В итоге я попросил ее посоветовать модель, которую бы она сама для себя выбрала. По дороге домой я впервые задумался, насколько сложно нашим клиентам. Перед ними же не просто полка с утюгами, а необходимость проектирования и сборки уникального «утюга», в котором встраивается целое казино.
Вообще, все «нелегкие» клиенты делятся на два типа:
- «Сейчас я вам расскажу, как вам нужно делать свою работу».
- «Не приставайте ко мне, вы прогеры – вам виднее, поэтому делайте все сами».
Первая категория будет постоянно закидывать вас кучей бесполезной информации, какими-то непонятными документами и прочим. При этом будет просто-таки настаивать, чтоб вы применяли определенные процессы или технологии. Постоянные требования каких-то специальных и особых отчетов, ведь же им кто-то сказал, что «так должно быть». В таком случае я лично придерживаюсь четкой позиции: «в курсе, как можно сделать лучше – милости прошу, идите и сами делайте!». Тут нужно показывать жесткость, иначе всю команду просто начнут говнокодить. Это не только снижает всю систему мотивации в целом, но и ведет проект к провалу. А вот когда это случится и проект сорвется, то обвинят в этом как раз команду разработки. Ну да, это ведь подрядчик некомпетентный был и принял неправильные с технической точки зрения решения.
Второй тип клиентов может показаться намного проще. Но я б не спешил с выводами. Да, пусть вам не мешают, это плюс. Но с другой стороны вы абсолютно лишены обратной связи. Поэтому существует риск, что при сдаче проекта вам просто выпалят в лоб «а мы ожидали другого». Что там кто ожидал – так никто и не узнает.
Поехали дальше – следующий пункт: грубое определение стоимости, сроков и технологий. Обычно к этому моменту на руках у вас уже будет вся существующая документация по проекту, а также устная информация от клиента. Но это еще очень ранний пре сейл. Желательно стараться уклончиво отвечать по поводу оценки и продавать прототипирование. Согласитесь, но на данном этапе стоит вместо «оценивать» применять «угадывать».
Понятно, что какие-то данные вам все-таки придется предоставить клиенту, поэтому лично я рекомендую использовать следующие приблизительные подсчеты (применил «ресурсный метод»):
- Услуги программиста, который обладает нужной квалификацией: 65-115 тысяч рублей.
- QА: 35-75 тысяч рублей.
- Услуги управляющего: 45-85 тысяч рублей.
Типичная команда может выглядеть следующим образом:
Вариант 1
- разработчик;
- Tеаm Lеаd (управляющий + старший разработчик);
- QА.
Вариант 2
- разработчик;
- управляющий (который также тестирует);
- разработчик.
Вариант 3 (более расширенный)
- разработчик;
- разработчик;
- разработчик;
- Tеаm Lеаd;
- UХ;
- QА;
- Аккаунт-управляющий.
Конечно, вариативность может быть очень разной. Я тут просто привел базовые варианты. Месячная аренда такой команды у отечественных аутсорсеров может варьироваться в диапазоне от 400 до 600 тысяч рублей. Срок типичного проекта: от трех месяцев до года. Если умножить в среднем на полмиллиона, то получаем в итоге: полтора – шесть миллионов рублей. Это так сказать, очень приблизительная конечная цифра.
Давайте подойдем к рассмотрению ситуации с разных сторон. К этому моменту клиент уже должен был бы понять для себя, за что он платит деньги и какие риски его ожидают, если он обратится к сыну друга своего брата или к подрядчику из Индии. Но с другой стороны ценовой диапазон очень большой. И тут на помощь приходит «прототипирование», то есть собранные Аxurе mоckup’ы (может использоваться и другой софт, главное, чтоб он был интерактивным).
Прототипирование можно считать по фиксированной схеме: клиент дает деньги за концепт (от 3-х до 10-ти экранов). После того, как концепция утверждается, проходит оплата разработки остальных экранов прототипов. Мое твердое убеждение – проектированием должен заниматься один UХ/BА-специалист. При этом обязательно проводить консультации с «техником», чтоб не нарисовать что-то нереальное, крайне сложное или неподходящее для выбранной платформы. В случае если такой профессионал не найдется, то стоит искать его из «вне», заключая с ним договор подряда.
Когда у вас на руках будут прототипы, будет намного проще проводить расчеты по проекту. Если же к этому моменту придет время T&M, то можно будет предложить клиенту еще раз все обдумать и нарисовать, чтоб снизить риски перед разработкой.
Какие аргументы можно выдвинуть в пользу прототипирования:
- На его основании производится более точный расчет стоимости. В таком случае клиент может получить смету, указав технологический стек, платформу (которую не выдумали, а в реальности рассчитывали).
- Прототипы позволяют понять еще до разработки, насколько ними комфортно пользоваться. Также можно понять, не было ли что-то упущены ключевые требования системой. Если использовать плохой интерфейс, то это может стать реально проблемой в бизнес-процессе, а значит, повлиять на снижение доходной части. Если оператор ошибется через интерфейс, то это спровоцирует прямые убытки.
- Намного рациональнее исправить ошибки, пока это прототипирование, чем в процессе разработки.
- Прототип можно применять в качестве средства для верификации работы подрядчика. Так наглядно можно увидеть текст.
После того, как прототипы были утверждены, можно начинать разработку и параллельно изображать финальный дизайн. Лично мои предпочтения – это Sсrum (для команды разработки) и для поддержки – Kаnbаn.
Еще один совет или даже лучше сказать настоятельная рекомендация: согласуйте с клиентом пару промежуточных демонстраций, а также процесс разработки чейндж реквестов.
На таких встречах важно рассказать клиенту обо всем объеме проделанных работ. При этом лучше будет, если он сможет самостоятельно проверить выполнение всех целей спринтов. То есть, внедрение и интеграция начинается гораздо раньше, чем стартует проект. Это предотвращает «затягивание» при подписании финальных актов. К тому же, как по мне, это обеспечивает оперативную реакцию на изменение внешней ситуации. Знаете же поговорку «аппетит приходит во время еды». Вот так и тут. После пары первых демонстраций клиент может проявить желание расширить функционал, а вместе с ним и бюджет.
Как перестать беспокоиться и начать лучше продавать разработку ПО
