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

Знакомство заказчика с системой

Редко какая система документооборота бывает простой в плане изучения. Но тот, кому это нужно, конечно, разбирается, изучает, зачастую с нашей помощью. В ход идет все — ICQ, Skype, форум, телефонные беседы.

У нас на сайте имеется бесплатная версия на 5 пользователей, можно изучать неограниченно. Также есть триальная лицензия на полгода на 50 (или более) пользователей. Заказчик изучает, сразу строит свои бизнес-процессы, проектирует типы документов, заводит пользователей и подразделения. Все это время он спокойно живет и пользуется, без заключения договора и без затрат со своей стороны. Не понравится — бросит и уйдет. Триальную лицензию по согласованию с нами он может продлить на сколько угодно, пока мы не признаем в нем «читера».

Мы будем брать вашу систему, но…

Наконец наш заказчик принял решение «Да, мы будем брать и внедрять вашу систему!». Это звучит отлично, но пока это только начало. Определяемся с количеством модулей, сколько нужно клиентских мест — стоимость вычисляется легко, на сайте есть калькулятор. Что следует далее? Давай же, подпиши договор, получи лицензию и пользуйся!

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

Разработка технического задания

Если ваши клиенты умеют писать технические задания — вам невероятно повезло. Еще больше повезло, если вам оплачивается время, потраченное на составление ТЗ. Но, классический заказчик — это не директор фирмы, а скорее его технические специалисты плюс их руководство. Например, один-два сотрудника IT-департамента и их руководитель. Люди технари, но писать и объяснять они не всегда умеют.

В результате от них вы сможете получить разве что «общее описание» того, что они хотят, а вот задавать им вопросы и уточнять детали — это ваша забота. Человек говорит: «Хочу, чтобы ваша система была интегрирована с 1С!». Для него это вроде бы очевидно и нечего обсуждать, но вы, как разработчик, знаете, что это только вершина айсберга. Пункты в ТЗ добавляются по мере поступления желаний. Здесь нет предела совершенству и нужно вовремя сказать «Стойте, давайте все же, подпишем ТЗ». Подписанное ТЗ дает вам фиксацию требований и хоть как-то защищает от безмерной разработки.

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

Договор, который хорош для заказчика

Технические вопросы — это интересно, но мы забыли главное, ради чего работаем. А работаем мы ради денег. Подписанный и оплаченный договор приносит деньги фирме, а вам, как разработчику (или внедренцу), возможно, премию. И вот тут начинается самый неприятный участок.

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

Правильный подход

Правильный выход при продаже сложных программных систем — разделить мух и котлеты. Вот лицензия, вот вы заплатили за «готовую систему», ту цену, что указана на сайте. Это один договор. А вот второй договор, который зовется «Договор на внедрение и доработку». Там описаны все пожелания, все технические пункты и он оценивается и оплачивается отдельно.

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

Исполнение технического задания — сложная вещь, там свой календарный план, но вы уже продали продукт и первую часть дохода получили. Исполнив ТЗ и закрыв второй договор вы получите свои деньги за «доработки».

Неправильный подход

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

Итог

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

Автор: darthandrew

Источник