Доказывает окупаемость технологии?

Question

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

Самое близкое, что я нашел к документу о том, как это сделать:

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

Добавить в часы: Выясните, сколько времени потребуется, чтобы исправить обнаруженные ошибки, и добавьте это в почасовую оценку.

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

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

Answer 4

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

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