Для многих разработчиков программного обеспечения, выбор и изменение модели trial-режима является одной из самых трепетных и обсуждаемых задач. Для одних программ придумать модель проще, для других сложно. А некоторых людей не покидает вопрос: «Мы всё правильно сделали?». Актуальна задача выбора trial-модели и для нас, разработчиков PVS-Studio. Мы решили поделиться некоторыми сопутствующими мыслями и рассказать о том, какой новый вариант мы придумали. Надеемся, что наши рассуждения и некоторые мысли окажутся полезными и другим разработчикам.
Введение
Модель try-before-buy (или по-другому shareware) давно стала классической в современном бизнесе продажи программного обеспечения. Я искренне завидую тем, кто разрабатывает бесплатное и/или открытое программное обеспечение. Они в каком-то смысле избавлены от необходимости показать программу со всех сторон потенциальному пользователю и одновременно мотивировать его купить софт. Нет, конечно же, они должны продвигать свои программы и обилие рекламы Google Chrome и Mozilla Firefox тому подтверждение. Тем не менее там ситуация иная и я ее не рассматриваю.
Итак, что у нас есть? Статический анализатор кода – инструмент, который находит ошибки в программах подобно диагностическим сообщениям компилятора. Нужно продать этот инструмент пользователю.
Стандартный подход к продаже статических анализаторов кода
На сайтах лидеров индустрии (Coverity, Klocwork, Parasoft) вы всегда легко найдете кнопку «Free Trial» за которой, однако, кроется анкета: кто вы, откуда и зачем. Это делается для того, чтобы как можно раньше sales manager в костюме начал охоту, то есть работу. При этом саму программу пользователю иногда дают, а иногда и не дают. Почему? Ну потому что в идеале в крутых компаниях к достойному клиенту сразу же вылетает спецназ на вертолете в составе: менеджер по продажам, техническая команда для развертывания сложного окружения анализатора кода и запуска его на проекте клиента, а также человек с подвешенным языком для проведения презентации о найденных в коде потенциального клиента ошибках. После этого клиент говорит либо: «Да, мы берем этот продукт за много десятков-сотен тысяч долларов в год», либо: «Спасибо, не впечатлило».
Зачем выезд к клиенту, развертывание у него инфраструктуры и презентация по найденным ошибкам? Это делается потому, что ЛЮБОЙ статический анализатор кода дает ложные срабатывания. И если пользователь первые десять просмотренных сообщений увидит ложные срабатывания, то на 11 сообщение (даже если это реальная ошибка) он может сказать: «Это не ошибка». Просто потому что не внимателен. Конечно, читатель возразит: «Я – не такой!». Увы, но люди устроены именно так и ничего с этим не поделаешь. Поэтому лучше, когда намного более опытные люди просмотрят код потенциального клиента, найдут ошибки и сделают презентацию. Тогда, скорее всего, потенциальный клиент станет реальным. И это не только мои мысли. Об этом говорится в статье A Few Billion Lines of Code Later — Using Static Analysis to Find Bugs in the Real World, которую очень рекомендую прочитать тем, кто интересуется статическим анализом.
Как у нас в PVS-Studio было реализовано раньше
Мы – разработчики PVS-Studio – маленький стартап, и нам спецназ из предыдущего раздела пока недоступен. Но свои недостатки мы пытаемся превратить в преимущества. Поэтому у нас на сайте можно скачать trial-версию без всякой регистрации и ожидания, пока sales manager одобрит заявку на скачивание. Это ОЧЕНЬ нравится нашим потенциальным пользователям. Собственно «триальность» работы заключалась в том, что анализатор находил все ошибки в коде, но для некоторых не указывал, в каком они месте находятся. С таким trial-режимом мы жили довольно долго. И к нему накопились претензии:Нередко получалось так, что интересные ошибки оказывались скрыты, а неинтересные (проще говоря, ложные срабатывания) наоборот показывались пользователю. Создавалось впечатление, что инструмент плохой.
Пользователи не всегда понимают, что выгода от статического анализа проявляется при регулярном использовании. Недостаточно один раз «прогнать» инструмент, исправить те ошибки, которые были показаны в trial-режиме, и успокоиться на этом. Важно регулярно его запускать, чтобы как можно быстрее находить ошибки, только что внесенные в код.
Наконец при таком trial-режиме очень трудно показать преимущества нашей очень крутой возможности Incremental Analysis. Это режим работы, когда статический анализатор автоматически запускается после компиляции и проверяет только те файлы, которые были изменены. Тем самым показывается не куча диагностических сообщений про весь проект, а только те сообщения, которые относятся к текущим изменениям пользователя. В случае если после правки двух-трех файлов и их перекомпиляции анализатор говорит про две ошибки, но одну из них не показывает – как-то не убедительно, что это крутая возможность.
Кроме того, мы так и не знали, кто потенциальные пользователи нашего продукта, так как нигде на сайте у нас нет регистрации и прочих подобных форм.
Исходя из этих недостатков, было принято решения изменить trial-модель, сохранив достоинство существующей версии в виде простоты скачивания.
Идеальный trial моей мечты
Здесь я немного отвлекусь от статических анализаторов и расскажу про две trial-модели, от которых я в восторге.
CAD-системы
Прежде всего, я завидую разработчикам CAD-систем, у которых часто trial выглядит так. Пользователю доступны все возможности программы постоянно и без ограничения времени. Единственное ограничения функциональности заключается в том, что… разработанную модель нельзя сохранить. Без этого функционала реальное использование инструмента невозможно, однако потенциальный пользователь может оценить все возможности программы. Супер, просто мечта.
К сожалению, для статического анализа не подходит, так как отчет о найденных ошибках хоть и можно сохранить, но это не такая уж необходимая вещь как в CAD-системах.
Игры типа World of Warcraft
Сразу скажу, что я ни разу не играл в World of Warcraft и им подобные игры, но, насколько мне известно, там trial работает так. Пользователь может бесплатно начать играть, прокачать своего персонажа до какого-то уровня и только потом ему надо платить за продолжение. Это еще одна идеальная схема, так как никто, дойдя до 15-уровня, не сможет отказаться от продолжения.
Хотя с выходом шутливого плагина Visual Studio Achievements Extension для прокачки разработчиков под Visual Studio прокачка стала актуальна и для программистов, все-таки нам это никак не приспособить.
Что в итоге сделали мы в PVS-Studio
Мы придумали использовать концепцию «кликов» – это переход к исходному коду с ошибкой при помощи клика в списке сообщений. Скачав PVS-Studio без всяких регистраций, потенциальный пользователь получает полнофункциональную версию анализатора кода. Он может проверять ей какие угодно проекты сколько угодно раз. Он получает полный список сообщений. Но у него есть только какое-то ограниченное количество кликов (переходов к коду). Например, 100. Но число не принципиально и возможно мы его будем менять. Таким образом, пользователь может посмотреть и перейти к 100 диагностикам. Повторюсь, без каких либо ограничений.
Если пользователь израсходовал эти клики, то он должен принять одно из следующих решений:либо купить лицензию;
либо отказаться от использования инструмента, если он ему не понравился;
либо попросить у нас продлить trial-режим, предоставив информацию о себе, чтобы мы могли уже как-то с ним поработать в почте.
При покупке лицензии пользователь получает обычный ключ на год и полноценно использует инструмент (ни про какие клики ему думать не надо). При отказе от использования тоже все понятно.
А вот продление режима у нас в версии PVS-Studio 4.54 реализовано так. После окончания кликов пользователь отсылает нам e-mail со следующей информацией: имя, компания, причина продления trial-режима. И мы ему даем ключик еще на одну неделю. То есть имеется некоторое количество ручной работы с нашей стороны.
В следующей версии после 4.54 мы это переделаем. Будет в программе автоматическая форма для указания этой информации, и после ее отправки пользователь будет получать еще, к примеру, 500 кликов. Продлеваться trial-режим будет один раз.
Если пользователь не хочет продлевать trial, то у него будут следующие ограничения:При проверке новых проектов не будут выдаваться имена файлов с ошибками. Вместо них будет фраза «TRIAL RESTRICTION».
Если пользователь открывает заранее сохраненный лог с найденными ошибками, то у него не будет работать переход к коду по клику.
Конечно же, пользователь, даже имея 0 кликов, может открыть заранее сохраненный отчет и вручную выполнять навигацию – открывать файл, переходить к соответствующей строке в нем. Это сделать можно. Но надо понимать, что статический анализ – это инструмент, который, прежде всего, позволяет экономить время (за счет раннего обнаружения ошибок в программах до релиза, а не после). Если же время потенциального пользователя дешевое или бесплатное настолько, что он готов делать навигацию вручную, то статический анализ не для него и он не наш клиент в любом случае.
Выводы
Мы надеемся, что новая trial-модель в конечном итоге позволит нам увеличить продажи. Ну а что вы сейчас должны сделать, так это скачать PVS-Studio и попробовать нашу идею с кликами на себе.
