Как продать продукт людям, принимающим решения




Если вы уже попробовали PVS-Studio, и продукт произвел хорошее впечатление, то следующий серьезный шаг для внедрения статического анализа кода в вашей организации - это убедить людей, принимающих решения о покупке программного обеспечения (ПО) в том, что статический анализ кода с помощью PVS-Studio - это отличная инвестиция.

Примечание: если вы лицо, принимающее решение, прочтение этой статьи может также быть полезным, так как тут приведен ряд интересных фактов о PVS-Studio и статическом анализе в целом.

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

  • Если речь идет об отдельном проекте, или единственном в своем роде для организации, то таким лицом может быть старший разработчик или менеджер проекта
  • Если в компании есть достаточно большая группа людей, занимающихся разработкой ПО, такие решения обычно принимаются высшим руководителем всей группы разработки программного обеспечения.
  • В больших организациях, основной задачей которых является разработка программного обеспечения, обычно существуют подразделения, которые занимаются отбором, покупкой, поддержкой и индивидуальной настройкой инструментов разработки. В таком случае руководитель этого подразделения часто и является лицом, принимающим решения

Следующий важный шаг - это понять, какие еще подразделения, отделы и люди являются заинтересованными лицами. Заинтересованные лица (и группы) будут прямо или косвенно затронуты внедрением статического анализа в процесс разработки. Обычно внедрение такого инструментария воспринимается только как источник дополнительных затрат, которые понадобятся на его поддержку. Именно поэтому очень важно провести подготовительную работу, описав преимущества, которые получит каждая из подобных групп:

  • Отдел обеспечения качества (Quality Assurance). будет получать для тестирования сборки продукта с меньшим количеством дефектов, соответственно, общее качество продукта повысится. Также есть высокая вероятность что с помощью статического анализа можно будет выявить какие-то из "неуловимых" дефектов, на которые жалуются пользователи, но которые не удается воспроизвести в лабораторных условиях.
  • Инженеры по сборкам (Build engineers). Несмотря на то, что интеграция инструментов статического анализа в процесс разработки ПО потребует усилий от инженеров по сборке, в долгосрочной перспективе они получат очевидные преимущества за счет меньшего количества экстренных пересборок, полуночных выпусков из-за проскочившей все этапы тестирования проблемы и т.д.
  • Разработчики. Очень часто у разработчиков возникает ощущение, что статический анализ кода добавляется в процесс для того, чтобы подчеркивать, кто именно допустил конкретную ошибку. Конечно, все очень сильно зависит от организационной культуры, но при общении с разработчиками необходимо подчеркивать, что статический анализ - это способ ранней диагностики проблем (чтобы проблемный код даже не покинул компьютер разработчика), а не инструмент поиска виновных.
  • Высшее руководство часто воспринимает статический анализ как дополнительную строчку в бюджете, однако на самом деле внедрение статического анализа приводит к уменьшению стоимости реализации каждого отдельного функционального блока и всей системы в целом, а также к повышению качества продукта. На данный момент достаточно сложно точно посчитать коэффициент возврата инвестиций (ROI) от внедрения инструментов статического анализа, однако многие исследования показывают положительный экономический эффект.

После того, как все заинтересованные лица и группы лиц определены, стоит пообщаться со всеми ними неформально и понять, как они относятся к внедрению статического анализа, понять, кто будет поддерживать, а кто будет сопротивляться этому процессу. Очень важно понять, какие именно возражения возникают у противников внедрения, и заранее подготовиться отвечать на них во время презентации проекта.

Следующий серьезный шаг - это подготовка презентации. Вы можете использовать наш шаблон как основу, однако его необходимо расширить детальными результатами проведенного пробного использования. Также в рамках презентации можно описать ответы на самые частые возражения, которые звучали по поводу внедрения статического анализа.

Пожалуйста, учтите, что наш шаблон презентации не концентрируется на конкретных ошибках, которые способен находить продукт - он подчеркивает преимущества, которые получает проект, внедрив статический анализ в процесс разработки.

Затем приходит время большой презентации. Убедитесь, что все лица, принимающие решения, могут присутствовать, а также что все заинтересованные лица и представители заинтересованных групп приглашены как необязательные участники.

Совет: пообщайтесь с людьми, поддерживающими проект, и убедитесь, что они смогут присутствовать во время презентации и обсуждения.

На этом этапе серьезных проблем не должно быть - к моменту проведения презентации вам уже известны основные возражения по поводу внедрения PVS-Studio или статического анализа в целом.

Самый важный результат обсуждения - это либо финальное решение о внедрении, либо список открытых вопросов, ответы на которые необходимо получить до момента принятия такого решения.

Обращайтесь к нам, если понадобится помощь в поиске ответов на подобные вопросы.



Найдите ошибки в своем C, C++, C# и Java коде

Предлагаем попробовать проверить код вашего проекта с помощью анализатора кода PVS-Studio. Одна найденная в нём ошибка скажет вам о пользе методологии статического анализа кода больше, чем десяток статей.

goto PVS-Studio;


Найденные ошибки

Проверено проектов
344
Собрано ошибок
12 970

А ты совершаешь ошибки в коде?

Проверь с помощью
PVS-Studio

Статический анализ
кода для C, C++, C#
и Java

goto PVS-Studio;