У Бреслава и Ложечкина очередной выпуск, это запись живой встречи в Лондоне: https://t.me/breslavandlozhechkin/33 Говорили про метрики в ИТ. В какой-то момент захотелось поспорить: кажется, Бреслав сказал, что трекание программистами времени работы над задачей - всегда зло. Расскажу, почему моя команда с моей подачи это делает.

Главный аргумент против обычно звучит так: ой, да люди просто не будут это делать, это слишком сложно, будет сопротивление, саботаж, сплошные "работал 8 часов" и прочие "отстаньте от меня". Мой опыт говорит об обратном: люди в-основном качественно подходит к этой части своей работы, пишут реально потраченные часы, не упираются. Ну, некоторым надо просто напоминать, но они и в других моментах забывчивые. Но людям сначала надо объяснить, какую пользу это даёт им.

Первое. Для более-менее вовлечённого программиста тоже важно, чтобы ему давали интересные и полезные задачи, а идиотские не давали. Программист, как и любой другой нормальный человек, хочет быть частью чего-то красивого, хорошего. Причём здесь часы? - Допустим, бизнес захотел сделать некоторую фичу. Если у него нет представления, к чему она приведёт (но есть много денег), бизнес обычно говорит: "Давайте делать, я так решил". Совсем иная ситуация, когда фича оценена в человеко-часах, и бизнес делает трезвый выбор: ага, это столько-то человеко-часов, миллионов рублей вот столько то, по нашей финмодели окупаемость... через 5 лет. Нет, не пойдёт, не будем делать! Профит: команду не отвлекли на очередную маниловщину.

Второе. Команду не грузят сверх её производственных возможностей. У задач оценки в человеко-часах. Спринт у нас две недели, производственный календарь в Консультанте, график отпусков заполнен. Если нам хотят ещё подбросить сверху "небольшую задачку на 100 часов", то я спокойно говорю: вот чем мы заняты (список из 20-30-40 задач), свободного времени столько-то (обычно это резерв на срочный багфикс), давайте сейчас решим, что мы из текущего спринта выбрасываем. Как правило, в этом месте кавалеристский наскок прекращается. Периметр комфорта команды надёжно сохранён.

Это две основные позиции, которых обычно достаточно, чтобы убедить в пользе трекинга. Бывают ещё всякие другие плюшки: есть материал для анализа трудоспособности, зон роста, проблемных моментов. Например, из-под одного аналитика всегда выходят задачи, сроки по которым превышаются в полтора-два раза (на общем фоне, где 80% задач у нас попадают в оценки). Работают разные программисты. Значит что? - Вопросы к аналитику, качеству проработки требований с его стороны. Ну и так далее, так далее.

ps. Мериться, конечно, только в человеко-часах. Оставьте стори-поинты, майки и пиццы детям.