Я обнаружил, что если вы можете предоставить действительные цифры, менеджеры с большей вероятностью будут действовать. (Если они могут понять логику и затраты / выгоды.)
ИМХО, чтобы убедительно доказать, вам понадобится следующее, чтобы показать, насколько это плохо:
- число инцидентов поддержки, зарегистрированных для проблем
- время, потраченное в часах на поддержку / исправление ошибок в коде / исправление ошибок
- стоимость времени, основанная на почасовой ставке людей, выполняющих техническое обслуживание / вспомогательные средства / поддержку
- какой-то способ продемонстрировать, насколько важны эти вещи для бизнеса
И для обоснования необходимости рефакторинга вам понадобятся:
- оценка времени для рефакторинга и реализации каждой из трех самых плохих вещей
- смета расходов на внедрение (те же почасовые ставки, которые использовались выше)
С их помощью вы сможете сэкономить время, если на рефакторинг уйдет намного меньше времени поддержки для 3 инцидентов для каждого из этих трех лучших элементов. Вы можете утверждать, что этот короткий промежуток времени будет
- быть меньше n инцидентов поддержки
- не будет больше таких инцидентов для этих вещей (ДАЖЕ ЛУЧШЕ!)
Однако самой трудной частью этой продажи будет ответ на следующий вопрос, так как многие люди не планируют время в расписаниях для всей поддержки, которую вы делаете:
Сколько еще мне придется ждать завершения проекта Y, пока вы проводите время, работая над этими проблемами с X ????? (несмотря на текущие временные ссылки поддержки, которые нельзя предсказать и запланировать в диаграммах Ганта)
Это во многом зависит от того, насколько хорошо вы общаетесь с лицами, принимающими решения, и от того, как они понимают ситуацию.
Я определенно думаю, что это стоит делать, поэтому вы получаете практику построения кейса с помощью метрик и экономите время, даже если они этого не делают. К сожалению, не всех легко убедить, несмотря на данные. УДАЧИ!
Все эти цифры в конечном счете основаны на догадках, в вашем случае , сравнивая сумму , которую вы догадаться , что это будет стоить не реорганизовать против того, что вы догадываетесь это будет стоить , чтобы реорганизовать. Лучшее, что вы можете сделать, это показать, что у вас есть какая-то числовая фактическая основа для догадок, и у вас есть довольно хорошая основа.
Плюсы в том, что, вероятно, будет эффективно убедить их позволить вам провести рефакторинг, и это может пойти хорошо и уменьшить количество ошибок.
Недостатки в том, что если количество времени, потраченного на исправление ошибок, не уменьшится, по крайней мере, на столько же, сколько потрачено время на рефакторинг, вам, вероятно, больше не будет разрешено проводить рефакторинг, и вы, вероятно, будете обвинены в «потраченном впустую» времени ,
Может быть слишком сложно измерить экономию времени на отладку, полученную за счет уменьшения сложности всего проекта или упрощения добавления функций, но вы могли бы упомянуть, что они существуют.
источник