Способы продажи программного обеспечения

Как продавать свою программу

Если воспользоваться поиском, то окажется, что статей с таким заголовком много. Многие из них посвящены заработку в интернет, что естественно. Но писали их, во многих случаях, люди далекие от разработки ПО. Поэтому, там не раскрыты некоторые интересные детали процесса «Идея → Разработка → Продажа».

Начнём с самого начала…

По-умолчанию, вы — программист, работаете в какой-то компании, у вас есть желание и возможность сделать что-то своё и получать за это деньги, независимо от основной работы. Также, будем считать, что разрабатываете вы десктопные программы и под Windows — ориентируемся на бóльшую аудиторию.

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

И так, вы сели делать свою чудо программу и желание у вас есть, но нет идеи что делать. Если так, то вот некоторые варианты решения этой «проблемы»:

• Взять какую-нибудь популярную программу/утилиту и сделать лучше добавив свои уникальные функции (например, сделать mp3 плеер с трансляцией названия песни в социальные сети);
• Присмотреться к своим ежедневным операциям за компьютером, возможно вы бы хотели автоматизировать какой-нибудь процесс (например, сделать программу которая сортирует фотки по папкам, взяв информацию о дате из EXIF и сохраняет на dropbox.com);
• Посмотреть тематические форумы и сайты где пользователи выкладывают свои программы, возможно какая-нибудь программа натолкнёт вас на мысль (например, на forum.searchengines.ru есть ветка с программами для SEO оптимизаторов);

Как только вы определились с идеей и решили что такой гениальной и нужной программы ещё не было, обязательно поищите в интернете конкурентов! На 99,99% уверен, что-то подобное уже кто-нибудь пытался сделать или сделал. Это не повод расстраиваться, изучите своих конкурентов, найди их недостатки и сделайте лучше. Также, посмотрите на цены конкурентов, подумайте, есть ли вообще смысл делать похожую программу, если у конкурентов уже всё готово, цены не ломят или вообще распространяют бесплатно?

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

Например: Google это для , которая , применяя .

Разработка

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

Вот основные моменты:

• Придумать и сделать защиту от взлома (если быстро взломают, то ваши продажи будут равны нулю);
• Сделать демо версию программы;
• Написать справку;
• Неплохо было и видеоролики, если программа не простая;
• Сделать сайт с анонсом программы, с которого потом будете продавать ПО и получать жалобы от пользователей (а они будут);
• Написать тексты с описанием программы, сделать скриншоты главных окон;
• Завести аккаунты в социальных сетях, для раскрутки и общения с пользователями;
• Определиться как будете принимать оплату за программу;
• Протестировать на различных версиях Windows (дать программу знакомым, чтобы они понажимали «не туда»);
• Собрать дистрибутив и проверить на вирусы;

Уделите внимание и интерфейсу. Он должен быть не только понятным, красивым, но и удобным! Пусть ваша программа будет выполнять какие-то уникальные операции, но если ей невозможно будет пользоваться никто её и не купит. Ну и встречают по одёжке… 🙂

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

В общем, перед началом продаж всё 10 раз проверьте. И делайте лучше сразу «хорошо», потому что:

Нет ничего более постоянного, чем временное

Продажа

Настал час Х, точнее час П — продаж. Программа готова и протестирована, сайт работает. Пора заявить о себе:

• Для начала, нужно добавить свою программу во все популярные и не очень каталоги программ. Автоматизировать этот процесс поможет программа RoboSoft. Тут нам понадобятся заготовленные описания программы и скриншоты;
• На тематических форумах разместить информацию о вашей новой программе, с описанием, ссылкой на демо и т.п. Видеоролик будет большим плюсом;
• Вплотную заняться раскруткой сайта, чтобы вашу программу и сайт находили через поисковые системы. Это тема отдельной статьи. Стоит упомянуть про набор программ от PromoSoft, тут и рассылка объявлений и регистрация в каталогах и оптимизация сайта. Также можно воспользоваться сервисами по автоматическому продвижению сайта, например Rookee или Seopult;
• Если есть возможность, использовать контекстную рекламу Яндект.Директ и/или Google Adwords;
• Разместите информацию о программе в социальных сетях;

Продажи кое-какие пошли, появились первые пользователи…

Теперь надо сосредоточиться на отзывах пользователей, быстро исправлять неисправности. Чем больше довольных первых пользователей, тем лучше. Заработает «сарафанное радио». На форумах можно и акцию какую-нибудь устроить, скидки, лицензию за обзор вашей программы в блоге, например. Пробуйте, вы же бизнесмен, продвигайте свой товар 🙂

Всё это постоянный процесс. Но процесс интересный и порой прибыльный. Имея 2-3 продающихся программы можно неплохо зарабатывать. Тем более интернет не ограничен русским языком и Россией — сделайте в вашей программе многоязыковую поддержку и продавайте где угодно.

That’s all, folks! Надеюсь статья была полезна новичкам в shareware.

Источник

Как продать ПО? Советы разработчику

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

При разработке программы специалисты стремятся к тому, чтобы их детище решило все возможные и невозможные проблемы клиента сразу, одним махом

Претензии клиентов, связанные с плохой работой дополнительных сервисов (а зачастую именно из-за них был сделан выбор в пользу этого конкретного продукта), часто распространяются на весь продукт (в общем неплохой). Кроме того, софт получается неудобным в использовании. Но самое главное ­– цена такого продукта становится непомерно высокой. Понятно, что это оказывает негативное влияние на принятие решения о приобретении. Согласитесь, не каждый клиент готов выложить кровно заработанное за софт, половиной функций которого он будет пользоваться чисто теоретически. Следовательно, разработчики недополучают ожидаемой прибыли. А на высококонкурентных рынках такое увеличение цены может оказаться и вовсе фатальным.

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

На деле решение этой проблемы лежит на поверхности. Достаточно поделить программу на модули и сформировать нескольких версий с ограниченной и полной функциональностью.

При разработке ПО вендор должен разделить весь функционал на три независимые части: необходимый – решающий основные проблемы, достаточный — решающий все задачи, а также набор сервисов, создающих дополнительные возможности и комфорт при работе с программой.

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

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

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

А зачем нам кузнец?

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

Вопрос, которому действительно стоит уделить пристальное внимание — разделение собственно защиты и лицензирования. Установка лицензионных разграничений должна быть компетенцией не программиста, а менеджера. А вот задачи по построению защиты должны оставаться на совести разработчика. Таким образом, при постановке задачи на разработку ПО менеджеры определяют, какие функции войдут в light-версию, какие – в полную, и какие сервисы будут предоставлены дополнительно. Далее разработчики встраивают защиту и выпускают полный дистрибутив, содержащий всю функциональность. В случае использования для защиты аппаратных ключей, ограничения записываются в память ключа. При использовании софтверной защиты, менее надёжной, но имеющей право на существование, определяемое низкой стоимостью самого программного продукта, это реализуется в коде.

В первом случае клиенту поставляется полный дистрибутив вместе c аппаратным ключом. Однако покупателю будут доступны только те функции, за которые он заплатил, и разрешения на которые присутствуют в памяти ключа. При необходимости расширения функционала клиент отправляет запрос на обновление. После поступления оплаты менеджер продавца генерирует обновление памяти для ключа клиента и отправляет его по e-mail. После установки обновления у покупателя появляется расширенный функционал.

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

Как продать и не пострадать

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

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

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

Источник

Как перестать беспокоиться и начать лучше продавать разработку ПО

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

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

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

Чтобы хорошо продавать ПО необходимо обладать солидным опытом как в разработке (технологиях, менеджменте и процессах), так и в продажах. Эти компетенции крайне сложно совместить в одном человеке, а когда они совмещаются, такой человек называется «основатель компании» или «исполнительный директор». Я знаю примеры компаний, в которых директор проводит первичную обработку всех заказов на разработку. Обычно потолок роста такой компании 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 до 6 миллионов рублей.

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

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

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

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

Источник