Доказательство ROI технологии?

Question

Как доказать ROI технологии своему менеджеру?

Ближе всего я нашел документ о том, как сделать это:

http://www.agilejournal.com/pdf/Finding-ROI-in-Build-Automation.pdf

Есть формулы в этом документе, но я не могу сказать, если они просто много маркетинга или если они являются точными формулами о том, как рассчитать ROI.

Я не пытаюсь рассчитать ROI инструмента построения в приведенной выше статье, я просто пытался вычислить ROI простого инструмента построения, такого как ANT.

Answer 1

Они не решают мясо вопроса: нематериальные выгоды - хотя они хотя бы пытаются пройти через пример. Формулы просто для того, чтобы получить ROI как хороший процент - если бы «использование инструментов сборки» было запасом, сколько бы я мог получить от своих инвестиций?

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

Однако это не помогает при разговоре с парнями, сидящими на деньгах.
Метрики Я woud использовать для анализа влияния инструмента сборки:

• оборотное время от приезда до конечных СМИ
• Число сборок (для тестирования, для выпуска, ..)
• Количество сборки просил (с быстрее строит, вы можете ожидать увеличение спроса)
• Количество ошибок, вносимых при ручной сборке (предполагается, что вы отслеживаете те)
• Количество разработчиков, способных опубликовать выпуск
• Предполагаемые ресурсы (время, лицензии, построить сервер, ..) для реализации и технического обслуживания
• Анализ низкой вероятности, высокие сценарии риска

Часто , инструмент автоматической сборки платит за себя, просто устраняя узкое место: каждый разработчик может публиковать программное обеспечение, а не только John the Builder.

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

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

Answer 2

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

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

Answer 3

Поставить оценку в часах: оценить, сколько времени вы в настоящее время тратить, и сколько времени вы потратили бы

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

Добавить в часы: Определите, сколько времени потребуется, чтобы исправить ошибки, которые были пойманы, и примените их к почасовой оценке.

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

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

Answer 4

Мой совет состоит в том, чтобы дискредитировать то, что сейчас существует, и предложить альтернативу.

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

Вы должны учитывать: сколько времени и достоверности теряется при плохих сборках; сколько ошибок сделано в настоящее время; сколько ручного повторения имеет место и т. д., и попытайтесь поставить метрики или примеры этих вещей.

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

Если вы завоевываете сердца и умы разработчиков и вашего Менеджера, это может означать больше, чем лист бумаги с некоторыми номерами на нем.