если вы используете хороший трекер билетов (например, Jira из Atlasian) и вы потратили время на ввод всех категорий, пользовательских историй, уровней срочности правильно и с согласия ваших товарищей по команде, то фактически рассчитываете эти метрики (и даже больше) удивительно легко
В предыдущем проекте мы использовали Jira для управления списками ошибок / задач / задач, и в итоге это фактически показало нам, что основной причиной задержек и проблем оказались неэффективные методы управления.
Как ни странно, когда эта информация появилась, мы вдруг сказали, что больше не будем использовать Jira и что для ее замены будет предложен новый продукт.
В то же время все запросы на передачу данных через Jira нужно было отправлять руководству, и у нас был удален прямой доступ.
Что не было замечено, так это то, что в рамках расчета статистики команда разработчиков Jira отправляла данные в веб-хук, и этот веб-хук использовался для передачи данных в конечную точку на некоторых внутренних серверах, где у нас был код, который создавал эти отчеты автоматически.
Мы начали мониторинг веб-хука и обнаружили, что, хотя нам было сказано, что Jira больше не используется, он оставался очень живым в течение значительного периода времени дольше (6+ месяцев, если быть точным), и массовое злоупотребление со стороны высшего руководства было просто буйный с неправильным использованием.
Конечно, это не должно быть так сложно, как Джира.
Если вам нужно решение с низкой доходностью, вы можете использовать электронную таблицу google-docs и API уведомлений GDocs для отслеживания задач / заявок / ошибок / запросов функций и т. Д.
Сам GDocs теперь может выпускать веб-хуки и все виды вещей.
Соедините это с Git и / или Github и некоторыми хуками, которые срабатывают, когда код фиксируется в вашем хранилище, и у вас есть достаточно эффективная система домашнего пивоварения, которая может записывать удивительное количество данных.
В целом, однако, из 100% естественного срока службы продуктов, разделение между разработчиками новых приложений и техническим обслуживанием составляет, как правило, 20/80, большая часть затрат в цикле ALM (Application Lifetime Management) берется на расходы на обслуживание и поддержку.
Нет такой вещи, как тратить слишком много времени на исправление ошибок, потому что просто невозможно писать код без ошибок.
Хорошее тестирование и политика непрерывной интеграции уменьшат дефицит, но вы никогда не будете полностью его ликвидировать.
Любой, кто верит в обратное (ИМХО), не обладает достаточными знаниями, чтобы сделать острое суждение, или слеп (в более обычном случае), насколько сложно на самом деле писать программное обеспечение.
Если ваш менеджер готов к этому, и некоторые из них готовы, вы можете предложить, чтобы он следил за вами в течение дня, чтобы он мог точно видеть, что вы делаете и как вы это делаете.
Iv'e работал в нескольких компаниях, где такая работа активно поощрялась: сотрудники высшего уровня следили за сотрудниками более низкого уровня, и наоборот, это может быть действительно очень хорошим опытом обучения для обеих вовлеченных сторон.