Комментарии 30
А можно вкратце отличия этой статьи от PVS-Studio ROI: как не терять миллионы (черновой вариант статьи)?
Отличий почти нет. Но хочется иметь конечный вариант, на который мы будем ссылаться. Старую статью по идеи стоит убрать в черновики, но мне жалко терять обсуждение (комментарии). Поэтому решил оставить, убрав все хабы, кроме нашего.
Может показаться странным, почему мы так много внимания уделяем этой теме. Причина в том, что эта статья действительно важна для нас. Очень часто обсуждения сводятся к просьбе показывать «числа». И понимая условность чисел, нам надо их озвучивать.
Может показаться странным, почему мы так много внимания уделяем этой теме. Причина в том, что эта статья действительно важна для нас. Очень часто обсуждения сводятся к просьбе показывать «числа». И понимая условность чисел, нам надо их озвучивать.
А зачем показывать «условные числа»? Покажите цену — все вопросы пропадут. Цена зависит от чего-то? — раскажите от чего и как.
Практика показывает, что всё наоборот. Первое, что нужно, — это заинтересовать возможностями продукта. Далее нужно объяснить ценность раннего исправления ошибок. И только потом надо говорить о цене. Бессмысленно говорить о цене, пока нет понимания, что и с чем сравнивается.
Частая наблюдаемая первая реакция программиста: «это больше моей месячной зарплаты, даже смотреть не буду». И всё. А зачем человек сравнивает с месячной зарплатой? Во-первых, это лицензия на год, а не на месяц. Во-вторых, лицензия на команду разработчиков, а не на одного человека. В-третьих, надо говорить не о тратах на зарплату, а об упущенной выгоде предприятия (о чем и написано в статье).
В общем, это мы уже всё проходили :). Цена не имеет значения без пояснений. Сколько было критики, когда был CppCat за $250. Ууу… По отзывам было ощущение, что мы должны ещё и доплачивать, чтобы пользовались. При этом, компании приобретают, используют и продлевают лицензии на анализатор. Значит, с ценой всё правильно. Другое дело, что хочется снизить недопонимание. Эта статья — один из шагов в этом направлении.
Частая наблюдаемая первая реакция программиста: «это больше моей месячной зарплаты, даже смотреть не буду». И всё. А зачем человек сравнивает с месячной зарплатой? Во-первых, это лицензия на год, а не на месяц. Во-вторых, лицензия на команду разработчиков, а не на одного человека. В-третьих, надо говорить не о тратах на зарплату, а об упущенной выгоде предприятия (о чем и написано в статье).
В общем, это мы уже всё проходили :). Цена не имеет значения без пояснений. Сколько было критики, когда был CppCat за $250. Ууу… По отзывам было ощущение, что мы должны ещё и доплачивать, чтобы пользовались. При этом, компании приобретают, используют и продлевают лицензии на анализатор. Значит, с ценой всё правильно. Другое дело, что хочется снизить недопонимание. Эта статья — один из шагов в этом направлении.
Для open source и соло программистов с pet проектами планируется с free версиями что либо (аля visual studio community)?
Думаю если человек увидит реальную пользу от продукта, будет пинать начальство на выделение средств.
Думаю если человек увидит реальную пользу от продукта, будет пинать начальство на выделение средств.
Но пояснения без цены также не имеют значения. Это как в рекламе автомобилей стало модно говорить «выгода 100500 денег», но при этом не указывать по сравнению с чем, и сколько таки нужно иметь денег покупателю.
Если с ценой всё правильно — почему нельзя её озвучить, чтобы другие, оценив нужность и посчитав бюджет на год, могли бы принять решение о покупке?
Если с ценой всё правильно — почему нельзя её озвучить, чтобы другие, оценив нужность и посчитав бюджет на год, могли бы принять решение о покупке?
Это как в рекламе автомобилей стало модно говорить «выгода 100500 денег», но при этом не указывать по сравнению с чем, и сколько таки нужно иметь денег покупателю.
Ход мысли рекламодателей я думаю такой. Если я скажу, что «выгода за Мерседес» до 500 тысячи рублей, то люди захотят посмотреть, что же это за машина такая. Возможно кто-то даже на тест-драйв соблазнится… А потом и купит, ужавшись в других тратах… Короче, что если… этот прием для машин и вправду работает? :-).
Если с ценой всё правильно — почему нельзя её озвучить, чтобы другие, оценив нужность и посчитав бюджет на год, могли бы принять решение о покупке?
Вы исходите из того, что цена секретна и никому не сообщается. Это не так. Просто напишите нам и узнаете цену. В этом нет никакого секрета.
У меня при сокрытии важной информации о товаре возникает не мысль о его покупке, а подозрение, что меня хотят обмануть. Возможно, я один такой, и подобные методы работают.
интрига с ценой держится уже который год. как вам удаётся избежать разглашения или утечек?
Эта интрига кажущаяся (мнимая). Она «существует» только в комментах от тех кому на самом деле все-равно не то что до цены, но и до самого продукта.
Любой, кому хоть сколько-то это интересно, просто пишет нам и узнает «главную тайну PVS-Studio» (злодейский смех).
Любой, кому хоть сколько-то это интересно, просто пишет нам и узнает «главную тайну PVS-Studio» (злодейский смех).
вы совершенно правы.
ЗЫ. гугл всемогущий помог отыскать ответ на этот вопрос :), я вшоке впечатлён.
ЗЫ. гугл всемогущий помог отыскать ответ на этот вопрос :), я в
Иногда я получаю странные письма. Люди пишут: «Нашел в Гугле цены на ваш анализатор. Я понимаю, что статья пятилетней давности, но неужели за пять лет ваш продукт ТАК изменился?» Это они потом все-таки запросили актуальные цены (почему не сделать так сразу?) и пытаются упорядочить картинку в голове.
Конечно за пять лет и продукт, и компания изменились. Посмотрите хотя бы release history! Это не может не найти отражения в новых ценах.
К чему это? Не надо ориентироваться на старые статьи на нашем сайте и на упоминания о ценах где-то. Это все не акутально. Почему бы нам не удалить эти старые статьи с ценами? Ну потому что это наша история, как ее удалить…
Конечно за пять лет и продукт, и компания изменились. Посмотрите хотя бы release history! Это не может не найти отражения в новых ценах.
К чему это? Не надо ориентироваться на старые статьи на нашем сайте и на упоминания о ценах где-то. Это все не акутально. Почему бы нам не удалить эти старые статьи с ценами? Ну потому что это наша история, как ее удалить…
А есть ли возможность встраивать ваш продукт в CI? Помнится, показывали анализ опенсорсного OpenXRay, так у него есть сборки в travis и appveyor. Можно ли как-то дополнить сборку ещё и вашим анализом (а если ещё и с уведомлением коммитера о внесенных проблемах, вообще было бы хорошо!)?
Планируется ли плагин для Jenkins сделать и под Linux?
Да. Без него нашему перфекционизму не спокойно в этой таблице :-).
На самом деле, мне кажется, что в вашем расчёте слишком много допущений.
Например, что исправление ошибки это потеря реального рабочего времени. Во-первых, исправление ошибок — это часть рабочего процесса, и оно учитывается при расчёте общих времязатрат. Во-вторых, ваш продукт не может дать строгой гарантии, что его использование это время как-то сократит, а следовательно на него нельзя полагаться при планировании).
Вы верно заметили, что программист не пишет код всё время. Но реальная ситуация такова, что программист может писать код всего два часа в неделю, или даже в месяц, но при этом он всё равно будет приносить компании больше денег, чем компания тратит на его содержание. Много времени может уходить на исследования, совещания, ревью, архитектуру и т.п. Разумеется это зависит и от должности и от обязанностей. Наврено, больше всего времени уходит на чисто кодирование, как раз в тех самых аутсорсинговых компаниях (хотя, это от проекта зависит).
Ещё хотел бы заметить, что многие баги, которые находит анализатор, вызваны использованием «опасных» техник программирования и игнорированием хороших практик программирования. По крайней мере, это моё впечатление, я всегда с удовольствием читаю ваши статьи. То есть, если писать на современном C++, с учётом всех практик и декомпозировать код, то довольно много ошибок можно просто никогда не получить. А если ещё использовать и встроенные в IDE средства анализа, то большую часть проблем можно решить ещё и до формальной компиляции проекта. Не знаю даже, как это учесть в вашем расчёте, и стоит ли.
Оффтопик. Проблемы тут начинаются в основном, когда разработчик считает себя крутым хакером, затейливо самовыражается в коде и/или пытается оптимизировать там, где это не нужно. Вот это, как мне кажется, приносит компаниям существенно больше убытков.
PS
Смысл статьи мне понятен. Принимающие решения люди любят таблицы, формулы, графики и т.п. Т.е. статья действительно может быть полезна технарю, который хочет убедить менеджмент внедрить новую классную штуку в рабочий процесс. На мой взгляд в расчётах просто много допущений.
Например, что исправление ошибки это потеря реального рабочего времени. Во-первых, исправление ошибок — это часть рабочего процесса, и оно учитывается при расчёте общих времязатрат. Во-вторых, ваш продукт не может дать строгой гарантии, что его использование это время как-то сократит, а следовательно на него нельзя полагаться при планировании).
Вы верно заметили, что программист не пишет код всё время. Но реальная ситуация такова, что программист может писать код всего два часа в неделю, или даже в месяц, но при этом он всё равно будет приносить компании больше денег, чем компания тратит на его содержание. Много времени может уходить на исследования, совещания, ревью, архитектуру и т.п. Разумеется это зависит и от должности и от обязанностей. Наврено, больше всего времени уходит на чисто кодирование, как раз в тех самых аутсорсинговых компаниях (хотя, это от проекта зависит).
Ещё хотел бы заметить, что многие баги, которые находит анализатор, вызваны использованием «опасных» техник программирования и игнорированием хороших практик программирования. По крайней мере, это моё впечатление, я всегда с удовольствием читаю ваши статьи. То есть, если писать на современном C++, с учётом всех практик и декомпозировать код, то довольно много ошибок можно просто никогда не получить. А если ещё использовать и встроенные в IDE средства анализа, то большую часть проблем можно решить ещё и до формальной компиляции проекта. Не знаю даже, как это учесть в вашем расчёте, и стоит ли.
Оффтопик. Проблемы тут начинаются в основном, когда разработчик считает себя крутым хакером, затейливо самовыражается в коде и/или пытается оптимизировать там, где это не нужно. Вот это, как мне кажется, приносит компаниям существенно больше убытков.
PS
Смысл статьи мне понятен. Принимающие решения люди любят таблицы, формулы, графики и т.п. Т.е. статья действительно может быть полезна технарю, который хочет убедить менеджмент внедрить новую классную штуку в рабочий процесс. На мой взгляд в расчётах просто много допущений.
Спасибо за хороший большой комментарий. Я могу поспорить по мелким моментам, но поскольку в целом согласен, то не буду.
И самое главное Вы правы с выводом, что такая статья должна быть и что её можно показать как обоснование. Пусть много допущений и т.д. В конце концов, человек может взять рассуждения за основу и посчитать свои числа, учитывающие разные моменты.
И самое главное Вы правы с выводом, что такая статья должна быть и что её можно показать как обоснование. Пусть много допущений и т.д. В конце концов, человек может взять рассуждения за основу и посчитать свои числа, учитывающие разные моменты.
В рассчетах не учитываются затраты времени на анализ отчетов PVS, в которых, по моему опыту, большая часть, это раздражающая фалса. Затраты времени на создание исключений, чтобы давить фалсу. ROI этих затрат неочевиден, т.к., опять же, по моему опыту, критические баги, которые действительно помогает находить PVS, появляются очень редко и, при наличии других средств контроля качества кода, вроде тестов, вполне уловимы без дополнительных инвестиций.
Есть подозрение, что анализатор не настроен или недонастроен. Тогда да, придётся постоянно продираться через ложные срабатывания. Например, есть существует какой-то неудачный макрос, то при каждом его использовании в коде придётся давить предупреждение. Это неправильно и следует разметить макрос. Наша собственная практика показывает, что вполне можно настроить анализатор так, что ложных срабатываний будет около 10%. Никак нельзя сказать, что много ложных срабатываний, когда 9 из 10 предупреждений указывают на ошибку. 10% это реальное значение.
Примечание. Мы можем обсудить с вами вариант расширенной поддержки и помочь настроить анализатор.
Кстати, если хотите, можем здесь порассматривать и пообсуждать ложные срабатывания, которые мешают жить.
Примечание. Мы можем обсудить с вами вариант расширенной поддержки и помочь настроить анализатор.
Кстати, если хотите, можем здесь порассматривать и пообсуждать ложные срабатывания, которые мешают жить.
Для аутсорса на самом деле эффект тоже есть, только он не прямой, а опосредованный. Команда, отлавливающая ошибки до выхода в продакшн, вызовет бОльшее удовлетворение заказчика и с бОльшей вероятностью получит следующий проект. А то, что следующий проект пришел без всех сопутствующих маркетинг-расходов на первую продажу на самом деле от того, что пара критичных ошибок была выловлена анализатором, а не пользователями заказчика, никто не узнает.
А добавьте еще классическую таблицу про стоимость исправления бага в зависимости от времени его выявления :) Станет еще веселее :)
НЛО прилетело и опубликовало эту надпись здесь
Где лицензии для синглов?Такой лицензии нет. Мы пробовали, но не смогли: "Мы закрываем проект CppCat". Сейчас PVS-Studio позиционируется как инструмент для команд разработчиков. Для индивидуального использования возможно Вам подойдёт бесплатная версия: "Бесплатный PVS-Studio для тех, кто развивает открытые проекты".
Где нормально расписанный прайс?Напишите нам, мы вышлем прайс и обсудим варианты лицензирования, удобные для вашей компании.
(del)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PVS-Studio ROI