Очень часто разработчики программных продуктов страдают перфекционизмом. При разработке программы они стремятся к тому, чтобы их детище решило все возможные и невозможные проблемы клиента сразу, одним махом. При этом они закладывают в функционал программы "преимущества", на деле являющиеся явно избыточными. Продукт получается близким к универсальному, с тысячей кнопок, иконок и кратким руководством по использованию на 800 листов. При этом часто вспомогательные функции остаются не доведенными до ума, неудобными в использовании, а иногда просто работающими некорректно. На претензии клиентов продавцы ПО отвечают: основной функционал работает отлично, а эти сервисы - дополнительные, скажите спасибо, что они вообще есть, ведь как-то они работают, а у других нет и такого…
При разработке программы специалисты стремятся к тому, чтобы их детище решило все возможные и невозможные проблемы клиента сразу, одним махом
Претензии клиентов, связанные с плохой работой дополнительных сервисов (а зачастую именно из-за них был сделан выбор в пользу этого конкретного продукта), часто распространяются на весь продукт (в общем неплохой). Кроме того, софт получается неудобным в использовании. Но самое главное - цена такого продукта становится непомерно высокой. Понятно, что это оказывает негативное влияние на принятие решения о приобретении. Согласитесь, не каждый клиент готов выложить кровно заработанное за софт, половиной функций которого он будет пользоваться чисто теоретически. Следовательно, разработчики недополучают ожидаемой прибыли. А на высококонкурентных рынках такое увеличение цены может оказаться и вовсе фатальным.
Трудности позиционирования
Другая проблема, которая возникает перед разработчиками, - позиционирование продукта. Повышая стоимость программы за счет ее универсальности, разработчик невольно сужает свой рынок сбыта, делая продукт недоступным для небольших клиентов и рассчитывая только на крупную корпоративную "рыбу".
На деле решение этой проблемы лежит на поверхности. Достаточно поделить программу на модули и сформировать нескольких версий с ограниченной и полной функциональностью.
При разработке ПО вендор должен разделить весь функционал на три независимые части: необходимый - решающий основные проблемы, достаточный - решающий все задачи, а также набор сервисов, создающих дополнительные возможности и комфорт при работе с программой.
Из необходимого функционала формируется так называемая "light" версия. Эта версия должна решать все насущные проблемы клиента, но при этом вызывать непреодолимое желание расширить возможности приложения. Говоря простым языком, в облегченной версии чего-то должно не хватать, она должна быть немного неудобной. Причем возможности полной, "профессиональной" версии ни в коем случае нельзя скрывать. Клиент должен видеть недоступные (пока) ему возможности. Это могут быть неработающие в light-версии кнопки, иконки и т.д.
Задача разработчика на этом этапе - сделать так, чтобы пользователь четко понимал, что полная версия сделает его работу более эффективной и позволит ему сэкономить массу времени. В этом случае клиент и продавец как бы меняются местами. И уже не разработчик ПО убеждает клиента перейти на полную версию, а покупатель фактически готов заплатить деньги, чтобы иметь дополнительные возможности.
При таком разделении на версии разработчик резко расширяет целевую аудиторию, выходя на более мелких клиентов, и в результате получает преимущества для выигрыша в конкурентной борьбе. У него появляется возможность поэтапного выпуска облегченной и профессиональной версий. Это позволяет разработчикам быстрее завоевывать рынок и снижать начальные инвестиции в разработку продукта.
А зачем нам кузнец?
Сервисы, которые делают работу с программным продуктом комфортнее, всегда следует выносить за рамки основной версии и продавать отдельно по мере необходимости. Это простой рыночный принцип: "за удобство нужно платить".
Вопрос, которому действительно стоит уделить пристальное внимание - разделение собственно защиты и лицензирования. Установка лицензионных разграничений должна быть компетенцией не программиста, а менеджера. А вот задачи по построению защиты должны оставаться на совести разработчика. Таким образом, при постановке задачи на разработку ПО менеджеры определяют, какие функции войдут в light-версию, какие - в полную, и какие сервисы будут предоставлены дополнительно. Далее разработчики встраивают защиту и выпускают полный дистрибутив, содержащий всю функциональность. В случае использования для защиты аппаратных ключей, ограничения записываются в память ключа. При использовании софтверной защиты, менее надёжной, но имеющей право на существование, определяемое низкой стоимостью самого программного продукта, это реализуется в коде.
В первом случае клиенту поставляется полный дистрибутив вместе c аппаратным ключом. Однако покупателю будут доступны только те функции, за которые он заплатил, и разрешения на которые присутствуют в памяти ключа. При необходимости расширения функционала клиент отправляет запрос на обновление. После поступления оплаты менеджер продавца генерирует обновление памяти для ключа клиента и отправляет его по e-mail. После установки обновления у покупателя появляется расширенный функционал.
В случае использования софтверной защиты, разработчик обрекает себя на риск, отдавая полный дистрибутив в руки пользователя. Взломать программную защиту и пользоваться полноценным продуктом, заплатив при этом лишь за ограниченную light-версию, соблазн, согласитесь, большой. Именно поэтому сторонники защиты на основе специальных утилит плодят множество различных версий своего ПО с функционалом light, расширенным, супер-расширенным и т.п., увеличивая тем самым стоимость производства и логистики, а также усложняя саму схему продаж и жизнь дистрибутора, которому предстоит разобраться в хитрых замыслах вендора.
Как продать и не пострадать
Из-за кажущейся сложности многие нестандартные способы организации продаж остаются вне поля зрения разработчиков программных продуктов, а зря.
Рассмотрим простой пример. Клиенту для реализации проекта необходимо приобрести дорогостоящий продукт. Если выделить единовременно средства на его приобретение не представляется возможным, часто клиент попросту отказывается от проекта, а разработчик продукта теряет потенциальную прибыль.
А между тем такая проблема легко решается организацией аренды или лизинга продукта. Для этого необходимо реализовать ограничение по времени использования продукта. С этим методом многие встречались на примере антивирусов. Как известно, антивирусные базы необходимо обновлять, соответственно антивирусные вендоры встраивают ограничение на использование продукта на какой-либо срок, в течение которого ваш антивирус исправно обновляется. По истечении этого срока вы обязаны либо пролонгировать действие лицензии, либо отказаться от использования продукта, либо продолжать использование, но уже на свой страх и риск. Понятно, что и в этом случае вопрос безопасности и денежных рисков стоит во главе угла.