Время от времени нам задают вопрос, какую пользу в денежном эквиваленте получит компания от использования анализатора PVS-Studio. Мы решили оформить ответ в виде статьи и привести таблицы, которые покажут, насколько анализатор может быть полезен. Мы не можем в статье доказать абсолютную достоверность всех расчётов, но думаем, читатель согласится с нашими размышлениями, и это поможет принять решение в вопросе приобретения лицензии.
Сначала мы хотели реализовать на сайте ROI-калькулятор и разместить подробное описание принципов его работы. Однако, подготовив описание, стало понятно, что калькулятор является лишним. Достаточно тех таблиц, которые были приведены в пояснении. Поэтому мы просто оформили это объяснение в виде статьи, которую вы сейчас читаете. Надеемся, она поможет убедиться в рациональности регулярного использования статического анализатора кода PVS-Studio.
PVS-Studio — это инструмент для выявления ошибок и потенциальных уязвимостей в исходном коде программ, написанных на языках С, C++, C# и Java. Работает в среде Windows, Linux и macOS.
Давайте рассчитаем возврат инвестиций от использования в процессе разработки статического анализатора кода PVS-Studio в режиме «скептика», а потом — в более реалистичном варианте.
Ценность часа работы программиста
Чтобы определить, сколько денег вернёт PVS-Studio, для начала надо рассчитать, какова настоящая стоимость (ценность) часа работы программиста.
Дело в том, что недостаточно просто взять ежемесячную зарплату программиста и разделить её на 160 (среднее количество часов в месяце при 40 часовой рабочей неделе).
Во-первых, программисты, как и сотрудники любой другой сферы, приносят больше денег, чем получают зарплатой, иначе бизнес будет работать себе в минус. Программистов нужно обеспечить рабочим местом, платить аренду за помещения, покупать им печенье, снабжать интернетом и так далее. Ах да, ещё бывают премии, корпоративы, различные бонусы.
При этом использование программиста должно быть выгодным, то есть он прямым или косвенным образом должен приносить чистую прибыль компании. На практике это означает, что работа программиста в зависимости от ситуации приносит в 2-10 раз больше денег, чем тратится на его зарплату. Ещё раз подчеркнём, что программисты здесь ничем не отличаются от любых других наёмных сотрудников. Некоторые особенности есть у аутсорсинга, но это отдельная история.
Для скептически настроенных читателей мы возьмем коэффициент 2. То есть программист приносит в 2 раза больше денег, чем тратится на его зарплату. На самом деле, компания с такими коэффициентами балансирует на грани безубыточности. Более честно брать коэффициент, равный, по крайней мере, 3.
Что всё это означает? Если программист выпал из процесса разработки на 1 час, то компания недополучила не сумму, равную часу его работы, а в 2 или 3 раза больше.
Есть и второй коэффициент, влияющий на цену настоящего рабочего часа. Дело в том, что сотрудник вовсе не программирует 8 часов в день. Невозможно представить, что человек как пришел с утра и как сел, так 8 часов, не отрываясь, занимается кодом. Программист работает с Trello, участвует в совещаниях, отвечает на письма в почте, участвует в code-review. В конце концов, ему ещё надо ходить в туалет и пить чай :). В лучшем случае непосредственно с кодом он будет работать 6 часов. А если вы читаете этот текст не в режиме скептика, то понимаете, что на самом деле 4 часа — куда более правдоподобное время.
Вот и получается, что стоимость часа нужно дополнительно умножить на 8/6=1.33 (режим скептика) или на 8/4=2 (вариант, более близкий к реальности).
Теперь перемножим два рассмотренных коэффициента и получим итоговый коэффициент, на который нужно умножать стоимость часа работы программиста:
- коэффициент для скептиков: 2 * 1.33 = 2.66
- коэффициент, более близкий к реальности: 3 * 2 = 6
На практике коэффициенты будут чуть больше, так как мы не учитываем в расчётах отпуск.
Давайте теперь посмотрим, что означает для компании выпадение программиста с зарплатой 100 000 рублей из рабочего процесса на 1 час.
Примечание. Для понимания отметим, что на самом деле компания тратит на выплату зарплаты больше, чем 100 000 рублей. Следует учесть, что компания делает отчисления в различные фонды («зарплатные налоги»). А на руки после удержания 13% налога человек получает 87 000 рублей. Для упрощения расчётов не будем учитывать отчисления и примем, что компания тратит только 100 000. Мы решили это отметить, чтобы показать, что делаем округления не в пользу PVS-Studio.
При зарплате 100 000 рублей ставка 1 часа работы составит 625 рублей. Получается, что если программист на 1 час отвлёкся на правку ошибки, то компания не сможет из-за этого заработать:
- для скептика: 625 рублей/час * 2.66 = 1660 рублей/час
- в реальности более чем: 625 рублей/час * 6 = 3750 рублей/час
Это и есть настоящая стоимость (ценность) одного часа программиста, когда он занят полезным делом.
Сколько часов экономит PVS-Studio
Очень сложно назвать, сколько часов в год сэкономит PVS-Studio, находя ошибки на ранних этапах. Ошибки бывают очень разные. Некоторые из них программист сразу замечает сам и моментально исправляет. А иногда баг может отвлечь программиста от полезной деятельности на несколько дней.
Из эмпирических соображений для скептика мы скажем, что анализатор сэкономит как минимум 2 часа работы программиста в неделю, избавив его от необходимости искать баги, найденные юнит-тестами или отделом тестирования. Да, само исправление бага обычно занимает минуты, но вот попытки воспроизвести проблему, переписки в багтрекере, прогоны тестов, мержи и так далее запросто съедят эти 2 часа.
Указанные выше два часа — это скептический вариант, на самом деле может быть больше. Учитывая, что иногда анализатор может предотвратить появление трудно воспроизводимых гейзенбагов, то средним значением вполне можно указать 3 часа.
В году приблизительно 52 недели. В год анализатор экономит следующее количество часов настоящей работы программиста:
- скептическое отношение к статическому анализу: 2 часа * 52 = 104 сэкономленных часа
- позитивное отношение: 3 часа * 52 = 156 сэкономленных часов
Пришло время считать ROI
Тогда использование PVS-Studio одним программистом с зарплатой в 100 000 рублей будет возвращать бизнесу в год:
- Если вы скептик: 1660 рублей/час * 104 часа = 172 640 рублей
- Реально: 3750 рублей/час * 156 часов = 585 000 рублей
Возьмём теперь типовую команду разработчиков из 10 человек. Внедрив PVS-Studio, можно ожидать, что благодаря сэкономленному времени команда сможет выполнить полезную работу стоимостью:
- Скептик: 1 726 400 рублей
- Реальность: 5 850 000 рублей
Окончательная формула
Итак, давайте теперь объединим всё в единую формулу.
Обозначим ежемесячную зарплату программиста как S.
Количество программистов в команде обозначим как N.
- Формула для скептика: N * (S / 160) * 2.66 * 104
- Реальная формула: N * (S / 160) * 6 * 156
Теперь приведём в виде таблиц расчёты для команд других размеров. В таблице указано прогнозируемое количество денег, которые может заработать команда разработчиков для компании, если в течение года вместо правки багов будет занята созданием чего-то нового. Именно эти числа следует сравнивать со стоимостью лицензии.
Описание таблицы. Верхняя строка: зарплата разработчика в месяц. Левый столбец: количество программистов в команде. Ячейка таблицы: сколько денег команда дополнительно заработает для компании в течение года, если вместо правки багов, которые найдёт PVS-Studio, будет заниматься полезным программированием.
Таблица для скептиков:
Таблица N1. Скептик. Красный: использование PVS-Studio может быть неоправданным. Зеленый: использование статического анализатора оправдано и полезно. Голубой: использование однозначно выгодно.
Реальная таблица:
Таблица N2. Реальность. Красный: использование PVS-Studio может быть неоправданным. Зеленый: использование статического анализатора оправдано и полезно. Голубой: использование однозначно выгодно.
Вторая таблица, на наш взгляд, достоверна, и именно ей разумно руководствоваться при оценке экономической целесообразности приобретения лицензии.
Примечание
Конечно, приведённые расчёты уместны не всегда и не везде. Например, если цена ошибок и уязвимостей для проекта крайне высока, то нет смысла связывать ценность от использования PVS-Studio с зарплатами программиста. В таких проектах следует оценивать возможные денежные и репутационные потери и уже их связывать с понижением риска при использовании анализатора кода. Это отдельная история, и мы пока не знаем, как к ней подойти с точки зрения расчётов.
Также расчёты могут не работать для аутсорсинговых компаний. Это может прозвучать не очень красиво, но такие компании заинтересованы продать как можно больше часов на разработку, тестирование и сопровождение. В каком-то смысле, использование анализатора может только сократить их выручку. Это косвенно подтверждается тем, что среди клиентов PVS-Studio нет аутсорсинговых компаний. Плюс, в таких компаниях иногда могут происходить на первый взгляд странные процессы. Компания в момент низкой загруженности может взять себе какой-то проект даже в убыток. Это лучше, чем распускать некоторых разработчиков в отпуск. Пусть лучше они будут при деле и чем-то заняты.
Кстати, приведённые расчёты и таблицы отличаются от тех, что приводятся в англоязычном варианте статьи. Приходится учитывать другой уровень зарплат, при котором получается, что PVS-Studio полезен практически любой команде. Что же, наверное, так оно и есть. Косвенно это подтверждается тем, что США и Европа дают нам гораздо больше заказов, чем Россия, хотя в России про нас больше знают.
Заключение
Итак, хотя расчеты могут подходить не для всех компаний, надеемся, что нам удалось продемонстрировать, как подойти к оценке эффективности использования PVS-Studio с точки зрения бизнеса в целом.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. PVS-Studio ROI.
Комментарии (23)
eagleivg
29.01.2019 18:01А есть ли возможность встраивать ваш продукт в CI? Помнится, показывали анализ опенсорсного OpenXRay, так у него есть сборки в travis и appveyor. Можно ли как-то дополнить сборку ещё и вашим анализом (а если ещё и с уведомлением коммитера о внесенных проблемах, вообще было бы хорошо!)?
Andrey2008 Автор
29.01.2019 19:23NDA81
30.01.2019 08:48Планируется ли плагин для Jenkins сделать и под Linux?
EvgeniyRyzhkov
30.01.2019 08:51+2Да. Без него нашему перфекционизму не спокойно в этой таблице :-).
NDA81
30.01.2019 10:29Вот и наш перфекционизм волнуется немного, когда смотрит на сервере статистику… отчет с предупреждениями компилятора — есть, отчет cppchek — есть, PVS-Studio — пока нет :)
EvgeniyRyzhkov
30.01.2019 10:32+1Есть супер простой способ удовлетворить их двоих. Становитесь нашим клиентом и приоритет у этой задачи вырастет до небес!
vt4a2h
30.01.2019 12:50На самом деле, мне кажется, что в вашем расчёте слишком много допущений.
Например, что исправление ошибки это потеря реального рабочего времени. Во-первых, исправление ошибок — это часть рабочего процесса, и оно учитывается при расчёте общих времязатрат. Во-вторых, ваш продукт не может дать строгой гарантии, что его использование это время как-то сократит, а следовательно на него нельзя полагаться при планировании).
Вы верно заметили, что программист не пишет код всё время. Но реальная ситуация такова, что программист может писать код всего два часа в неделю, или даже в месяц, но при этом он всё равно будет приносить компании больше денег, чем компания тратит на его содержание. Много времени может уходить на исследования, совещания, ревью, архитектуру и т.п. Разумеется это зависит и от должности и от обязанностей. Наврено, больше всего времени уходит на чисто кодирование, как раз в тех самых аутсорсинговых компаниях (хотя, это от проекта зависит).
Ещё хотел бы заметить, что многие баги, которые находит анализатор, вызваны использованием «опасных» техник программирования и игнорированием хороших практик программирования. По крайней мере, это моё впечатление, я всегда с удовольствием читаю ваши статьи. То есть, если писать на современном C++, с учётом всех практик и декомпозировать код, то довольно много ошибок можно просто никогда не получить. А если ещё использовать и встроенные в IDE средства анализа, то большую часть проблем можно решить ещё и до формальной компиляции проекта. Не знаю даже, как это учесть в вашем расчёте, и стоит ли.
Оффтопик. Проблемы тут начинаются в основном, когда разработчик считает себя крутым хакером, затейливо самовыражается в коде и/или пытается оптимизировать там, где это не нужно. Вот это, как мне кажется, приносит компаниям существенно больше убытков.
PS
Смысл статьи мне понятен. Принимающие решения люди любят таблицы, формулы, графики и т.п. Т.е. статья действительно может быть полезна технарю, который хочет убедить менеджмент внедрить новую классную штуку в рабочий процесс. На мой взгляд в расчётах просто много допущений.Andrey2008 Автор
30.01.2019 14:24Спасибо за хороший большой комментарий. Я могу поспорить по мелким моментам, но поскольку в целом согласен, то не буду.
И самое главное Вы правы с выводом, что такая статья должна быть и что её можно показать как обоснование. Пусть много допущений и т.д. В конце концов, человек может взять рассуждения за основу и посчитать свои числа, учитывающие разные моменты.
arabesc
30.01.2019 16:51В рассчетах не учитываются затраты времени на анализ отчетов PVS, в которых, по моему опыту, большая часть, это раздражающая фалса. Затраты времени на создание исключений, чтобы давить фалсу. ROI этих затрат неочевиден, т.к., опять же, по моему опыту, критические баги, которые действительно помогает находить PVS, появляются очень редко и, при наличии других средств контроля качества кода, вроде тестов, вполне уловимы без дополнительных инвестиций.
Andrey2008 Автор
30.01.2019 19:32Есть подозрение, что анализатор не настроен или недонастроен. Тогда да, придётся постоянно продираться через ложные срабатывания. Например, есть существует какой-то неудачный макрос, то при каждом его использовании в коде придётся давить предупреждение. Это неправильно и следует разметить макрос. Наша собственная практика показывает, что вполне можно настроить анализатор так, что ложных срабатываний будет около 10%. Никак нельзя сказать, что много ложных срабатываний, когда 9 из 10 предупреждений указывают на ошибку. 10% это реальное значение.
Примечание. Мы можем обсудить с вами вариант расширенной поддержки и помочь настроить анализатор.
Кстати, если хотите, можем здесь порассматривать и пообсуждать ложные срабатывания, которые мешают жить.
Igor_Shumilov
А можно вкратце отличия этой статьи от PVS-Studio ROI: как не терять миллионы (черновой вариант статьи)?
Andrey2008 Автор
Отличий почти нет. Но хочется иметь конечный вариант, на который мы будем ссылаться. Старую статью по идеи стоит убрать в черновики, но мне жалко терять обсуждение (комментарии). Поэтому решил оставить, убрав все хабы, кроме нашего.
Может показаться странным, почему мы так много внимания уделяем этой теме. Причина в том, что эта статья действительно важна для нас. Очень часто обсуждения сводятся к просьбе показывать «числа». И понимая условность чисел, нам надо их озвучивать.
alexxisr
А зачем показывать «условные числа»? Покажите цену — все вопросы пропадут. Цена зависит от чего-то? — раскажите от чего и как.
Andrey2008 Автор
Практика показывает, что всё наоборот. Первое, что нужно, — это заинтересовать возможностями продукта. Далее нужно объяснить ценность раннего исправления ошибок. И только потом надо говорить о цене. Бессмысленно говорить о цене, пока нет понимания, что и с чем сравнивается.
Частая наблюдаемая первая реакция программиста: «это больше моей месячной зарплаты, даже смотреть не буду». И всё. А зачем человек сравнивает с месячной зарплатой? Во-первых, это лицензия на год, а не на месяц. Во-вторых, лицензия на команду разработчиков, а не на одного человека. В-третьих, надо говорить не о тратах на зарплату, а об упущенной выгоде предприятия (о чем и написано в статье).
В общем, это мы уже всё проходили :). Цена не имеет значения без пояснений. Сколько было критики, когда был CppCat за $250. Ууу… По отзывам было ощущение, что мы должны ещё и доплачивать, чтобы пользовались. При этом, компании приобретают, используют и продлевают лицензии на анализатор. Значит, с ценой всё правильно. Другое дело, что хочется снизить недопонимание. Эта статья — один из шагов в этом направлении.
MyOnAsSalat
Для open source и соло программистов с pet проектами планируется с free версиями что либо (аля visual studio community)?
Думаю если человек увидит реальную пользу от продукта, будет пинать начальство на выделение средств.
Andrey2008 Автор
?Бесплатный PVS-Studio для тех, кто развивает открытые проекты.
alexxisr
Но пояснения без цены также не имеют значения. Это как в рекламе автомобилей стало модно говорить «выгода 100500 денег», но при этом не указывать по сравнению с чем, и сколько таки нужно иметь денег покупателю.
Если с ценой всё правильно — почему нельзя её озвучить, чтобы другие, оценив нужность и посчитав бюджет на год, могли бы принять решение о покупке?
EvgeniyRyzhkov
Ход мысли рекламодателей я думаю такой. Если я скажу, что «выгода за Мерседес» до 500 тысячи рублей, то люди захотят посмотреть, что же это за машина такая. Возможно кто-то даже на тест-драйв соблазнится… А потом и купит, ужавшись в других тратах… Короче, что если… этот прием для машин и вправду работает? :-).
Вы исходите из того, что цена секретна и никому не сообщается. Это не так. Просто напишите нам и узнаете цену. В этом нет никакого секрета.
alexxisr
У меня при сокрытии важной информации о товаре возникает не мысль о его покупке, а подозрение, что меня хотят обмануть. Возможно, я один такой, и подобные методы работают.
eshirshov
интрига с ценой держится уже который год. как вам удаётся избежать разглашения или утечек?
EvgeniyRyzhkov
Эта интрига кажущаяся (мнимая). Она «существует» только в комментах от тех кому на самом деле все-равно не то что до цены, но и до самого продукта.
Любой, кому хоть сколько-то это интересно, просто пишет нам и узнает «главную тайну PVS-Studio» (злодейский смех).
eshirshov
вы совершенно правы.
ЗЫ. гугл всемогущий помог отыскать ответ на этот вопрос :), я в
шокевпечатлён.EvgeniyRyzhkov
Иногда я получаю странные письма. Люди пишут: «Нашел в Гугле цены на ваш анализатор. Я понимаю, что статья пятилетней давности, но неужели за пять лет ваш продукт ТАК изменился?» Это они потом все-таки запросили актуальные цены (почему не сделать так сразу?) и пытаются упорядочить картинку в голове.
Конечно за пять лет и продукт, и компания изменились. Посмотрите хотя бы release history! Это не может не найти отражения в новых ценах.
К чему это? Не надо ориентироваться на старые статьи на нашем сайте и на упоминания о ценах где-то. Это все не акутально. Почему бы нам не удалить эти старые статьи с ценами? Ну потому что это наша история, как ее удалить…