Як продати ПЗ? Поради розробнику

Дуже часто розробники програмних продуктів страждають на перфекціонізм. При розробці програми вони прагнуть до того, щоб їх дітище вирішило всі можливі і неможливі проблеми клієнта одразу, одним махом. При цьому вони закладають у функціонал програми "переваги", на ділі є явно надмірними. Продукт виходить близьким до універсального, з тисячею кнопок, іконок і коротким керівництвом по використанню на 800 аркушів. При цьому часто допоміжні функції залишаються не доведеними до розуму, незручними у використанні, а іноді просто працюють некоректно. На претензії клієнтів продавці ПО відповідають: основний функціонал працює відмінно, а ці сервіси – додаткові, скажіть спасибі, що вони взагалі є, адже як-то вони працюють, а в інших немає і такого …


При розробці програми фахівці прагнуть до того, щоб їх дітище вирішило всі можливі і неможливі проблеми клієнта одразу, одним махом


Претензії клієнтів, пов'язані з поганою роботою додаткових сервісів (а найчастіше саме через них було зроблено вибір на користь цього конкретного продукту), часто поширюються на весь продукт (у загальному непоганий). Крім того, софт виходить незручним у використанні. Але найголовніше – ціна такого продукту стає непомірно високою. Зрозуміло, що це робить негативний вплив на прийняття рішення про придбання. Погодьтеся, не кожен клієнт готовий викласти кровно зароблене за софт, половиною функцій якого він буде користуватися чисто теоретично. Отже, розробники недоотримують очікуваної прибутку. А на висококонкурентних ринках таке збільшення ціни може бути й зовсім фатальним.


Труднощі позиціонування


Інша проблема, яка виникає перед розробниками, – позиціонування продукту. Підвищуючи вартість програми за рахунок її універсальності, розробник мимоволі звужує свій ринок збуту, роблячи продукт недоступним для невеликих клієнтів і розраховуючи тільки на велику корпоративну "рибу".


На ділі вирішення цієї проблеми лежить на поверхні. Досить поділити програму на модулі та сформувати декількох версій з обмеженою і повною функціональністю.


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


З необхідного функціонала формується так звана "light" версія. Ця версія повинна вирішувати всі нагальні проблеми клієнта, але при цьому викликати непереборне бажання розширити можливості програми. Говорячи простою мовою, в полегшеної версії чогось має не вистачати, вона повинна бути трохи незручною. Причому можливості повної, "професійною" версії ні в якому разі не можна приховувати. Клієнт повинен бачити недоступні (поки що) йому можливості. Це можуть бути непрацюючі в light-версії кнопки, іконки і т.д.


Завдання розробника на цьому етапі – зробити так, щоб користувач чітко розумів, що повна версія зробить його роботу ефективнішою і дозволить йому заощадити масу часу. У цьому випадку клієнт і продавець як би міняються місцями. І вже не розробник ПЗ переконує клієнта перейти на повну версію, а покупець фактично готовий заплатити гроші, щоб мати додаткові можливості.


При такому поділі на версії розробник різко розширює цільову аудиторію, виходячи на більш дрібних клієнтів, і в результаті отримує переваги для виграшу в конкурентній боротьбі. У нього з'являється можливість поетапного випуску полегшеною і професійної версій. Це дозволяє розробникам швидше завойовувати ринок і знижувати початкові інвестиції в розробку продукту.


А навіщо нам коваль?


Послуги, які роблять роботу з програмним продуктом комфортніше, завжди слід виносити за рамки основної версії і продавати окремо в міру необхідності. Це простий ринковий принцип: "за зручність потрібно платити ".


Питання, якому дійсно варто приділити пильну увагу – поділ власне захисту та ліцензування. Установка ліцензійних розмежувань повинна бути компетенцією не програміст, а менеджера. А ось завдання з побудови захисту повинні залишатися на совісті розробника. Таким чином, при постановці завдання на розробку ПО менеджери визначають, які функції увійдуть до light-версію, які – на повну, і які сервіси будуть надані додатково. Далі розробники вбудовують захист і випускають повний дистрибутив, який містить всю функціональність. У разі використання для захисту апаратних ключів, обмеження записуються в пам'ять ключа. При використанні софтверної захисту, менш надійною, але має право на існування, яке визначається низькою вартістю самого програмного продукту, це реалізується в коді.


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


У разі використання софтверної захисту, розробник прирікає себе на ризик, віддаючи повний дистрибутив у руки користувача. Зламати програмну захист і користуватися повноцінним продуктом, заплативши при цьому лише за обмежену light-версію, спокуса, погодьтеся, великий. Саме тому прихильники захисту на основі спеціальних утиліт плодять безліч різних версій свого ПО з функціоналом light, розширеним, супер-розширеним і т.п., збільшуючи тим самим вартість виробництва і логістики, а також ускладнюючи саму схему продажів і життя дистрибутора, якому належить розібратися в хитрих задумах вендора.


Як продати і не постраждати


Через уявну складності багато нестандартні способи організації продажу залишаються поза полем зору розробників програмних продуктів, а даремно.


Розглянемо простий приклад. Клієнту для реалізації проекту необхідно придбати дорогий продукт. Якщо виділити одноразово кошти на його придбання не представляється можливим, часто клієнт просто відмовляється від проекту, а розробник продукту втрачає потенційний прибуток.


А тим часом така проблема легко вирішується організацією оренди або лізингу продукту. Для цього необхідно реалізувати обмеження за часом використання продукту. З цим методом багато зустрічалися на прикладі антивірусів. Як відомо, антивірусні бази необхідно оновлювати, відповідно антивірусні вендори вбудовують обмеження на використання продукту на будь-який строк, протягом якого ваш антивірус справно оновлюється. Після закінчення цього терміну ви зобов'язані або пролонгувати дію ліцензії, або відмовитися від використання продукту, або продовжувати використання, але вже на свій страх і ризик. Зрозуміло, що і в цьому випадку питання безпеки і грошових ризиків стоїть на чолі кута.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*