Не являюсь ни пользователем PVS-Studio, ни их конкурентом. Но поскольку мне самому нужно придумать, как можно зарабатывать на программных продуктах для разработчиков ПО (а не для конечных пользователей), то приходится смотреть по сторонам и обращать внимание на то, как другие это делают. В последнее время продавцы полосатых палок PVS-Studio зафлудили статьями о своем продукте профильные ресурсы, которые я отслеживаю, волей-не-волей обращаешь на них внимание. И ловишь себя на нескольких непонятных вещах...
Стратегия продвижения PVS-Studio через ресурсы, вроде Habr-а, LOR-а и RSDN, по словам главного разработчика PVS-Studio рассчитана на то, что обычные программисты будут узнавать о такой штуке, как статический анализ и будут проникаться его мощью и полезностью. После чего, проникшись, побегут к своим менеджерам с просьбами прикупить PVS-Studio дабы...
И вот тут начинаются вопросы.
Во-первых, "дабы что?" Какую пользу PVS-Studio принесет проекту? Как измерить эту пользу? Как, в последствии, оценить, окупились ли вложения в PVS-Studio или нет? (А ведь оценка окупаемости вложений в случае с PVS-Studio не праздный, т.к. после оплаченного срока действия купленное когда-то ПО тупо превращается в тыкву и нужно платить снова и снова).
Сложность этого вопроса в том, что для менеджера и программиста "польза для проекта" выражается по-разному. Программиста может греть мысль о "повышении качества кода и сокращения количества ошибок", а для менеджера проекта это нечто абстрактное и сложно переводимое в такие осязаемые категории, как сроки, риски и деньги.
Прошу не думать, что я противник статического анализа кода. Речь про другое: вот программист прочитал несколько статей о том, какие баги PVS-Studio выловил в том или ином открытом проекте. Как на основании этой информации сделать вывод о том, что для проекта масштаба N килобаксов с такими-то требованиями к качеству ПО покупка PVS-Studio принесет ощутимый результат?
Непростой вопрос. Вот я сам отчасти и программист, и менеджер. Но читая отчеты о найденных багах у меня нет четкой уверенности в том, что своевременное обнаружение и исправление этих багов как-то существенно повысило бы business-value проанализированных программных продуктов. Ведь одно дело, когда из-за бага программа не выполняет своей основной функциональности. Другое дело, когда ошибка проявляется у единичных пользователей при экзотическом стечении обстоятельств. Да еще и выражается не в крахе программы с потерей данных, а, например, в "поехавшем" расположении контролов в диалоговом окне или в не отображении части информации на экране. Это все, конечно же ошибки, они доставляют неприятности пользователям, но критичными не являются.
Так что первый непонятный момент в бизнес-стратегии продвижения PVS-Studio через разработчиков -- это отсутствие в статьях про PVS-Studio каких-то ориентиров, которые могли бы подсказать, как применение (или не применение) PVS-Studio скажется на разработке: какие затраты, какие выгоды, насколько изменится трудоемкость, насколько изменятся сроки, насколько изменится процесс разработки и т.д.
Второй момент, который так же имеет отношение к вопросу "дабы что?", связан с отсутствием легкодоступной информации о стоимости PVS-Studio. Полагаю, разработчики PVS-Studio смотрят на мир так:
Вот некий разработчик узнал о выгодах статического анализа вообще и PVS-Studio в частности. Радостный побежал к своему менеджеру: "Надо брать!". А менеджер спрашивает: "И во сколько нам обойдется сие счастье?" А разработчик: "Я не знаю, у них цену нужно отдельно уточнять". И менеджер такой: "Нет проблем. Спасибо, что рассказал про PVS-Studio, я с ними сам свяжусь и все выясню".
В наблюдаемой мной реальности картинка несколько другая. У менеджеров голова своими проблемами забита. Ввязываться в переписку непонятно с кем непонятно ради чего... Плюс еще и такой фактор, что подход, когда продавец озвучивает цену только после предварительной оценки состоятельности клиента, воспринимается далеко не однозначно. В общем, если бы ко мне прибежал разработчик с горящими глазами и стал бы агитировать за PVS-Studio, цена которой неизвестна, то меня бы это не обрадовало. А если бы выяснилось, что разработчик этот сам предварительно, без моего ведома связался с продавцами и выяснил цену, то не обрадовался бы еще больше.
В общем, если бы цена была указана сразу на сайте, то продвижение PVS-Studio "снизу-вверх", как об этом мечтают продавцы сего продукта, было бы проще. Например, цены на Visual Studio, CLion, TBB, Qt, gSOAP или на техподдержку для POCO свободно доступны. Что, по-моему, сильно облегчает разговоры о необходимости их покупки.
Есть у меня подозрение, что разработчиков PVS-Studio этот фактор сильно не волнует, т.к. основной поток клиентов у них -- это те, кто не смог себе позволить прикупить Coverity. Когда основная часть работы по убеждению менеджмента в необходимости приобретения статического анализатора уже проделана, проведены переговоры с сейлами Coverity и прошел первый шок от озвученных цен. Вот тогда к офигевшему менеджеру можно подойти и сказать, что еще есть PVS-Studio...
В сухом остатке для себя лично оставляю следующие выводы. Если инструмент рассчитан на разработчиков и делается попытка его продвижения через разработчиков, то в рассказах про инструмент нужно обозначать, среди прочего, и выгоды, понятные менеджменту. Например, сокращение сроков в столько-то раз. Или снижение издержек в столько-то раз. Плюс к тому, информация о стоимости приобретения продукта должна быть легкодоступна. У клиента и так забот хватает, зачем ему лишние хлопоты с уточнением цены и никому не нужные подозрения о том, что цена хитрым образом завязывается на платежеспособность.
Комментариев нет:
Отправить комментарий