Самый опасный разработчик тот, у которого закончились задачи

Есть одна довольно интересная особенность управления в IT. Мы научились очень внимательно следить за тем, сколько времени человек тратит на работу, но до сих пор не очень понимаем, что делать, если он справляется с ней слишком быстро.

У нас есть трекеры времени, сторипоинты, «велосити», «капасити», «утилизация», «бёрндаун», «трупут», «лид тайм», «сайкл тайм», план-факт и ещё десяток способов убедиться, что разработчик действительно работал свои восемь часов. Причём иногда на обсуждение всех этих метрик уходит больше времени, чем на саму разработку. Зато менеджменту есть что показать на следующем созвоне 🤗 Посчитали, сравнили, нашли отклонение, сделали выводы. Управляем.

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

Представим вполне обычную продуктовую команду из десяти человек. Ребята несколько лет разрабатывали сервис, переписывали неудачные решения, исправляли ошибки, выстраивали архитектуру, автоматизировали процессы. Продукт наконец работает стабильно, критичных багов почти нет, основные фичи реализованы, инфраструктура не падает каждую пятницу. Даже пользователи почему-то довольны.

Эм 🫤 После чего у разработчиков стало меньше работы.

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

🍄 Но попробуйте показать такую команду человеку, который привык оценивать эффективность по занятости. Десять разработчиков, а задач на пятерых. Всё, математика сошлась.

Начинается любимое корпоративное развлечение. Посмотреть загрузку, что-то пересчитать, оптимизировать фонд оплаты труда. Зачем платить десятерым, если текущий бэклог спокойно закрывают пятеро? Особенно забавно, что ещё вчера этих же людей просили ускоряться, автоматизировать рутину, внедрять ИИ, сокращать время разработки и повышать производительность.

🏁 Они ускорились. Теперь их слишком много.

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

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

Можно ведь просто растянуть работу на весь спринт. Аккуратно списать часы, заполнить Jira, прийти на дейлик и рассказать, что всё идёт по плану. Никто не задаёт лишних вопросов, все заняты, метрики красивые.

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

Например, сколько денег компания потеряла из-за бессмысленных согласований❓ Сколько времени разработчики потратили на отчётность вместо продукта❓ Сколько хороших инженерных решений не было принято, потому что в ближайшем спринте они не давали красивых цифр❓

И кто вообще решил, что отсутствие задач обязательно означает избыток людей, а не отсутствие новых идей, исследований и нормального продуктового планирования?

Разумеется, иногда команда действительно становится избыточной. Продукты меняются, бюджеты заканчиваются, потребность в разработке может снижаться. Но делать такой вывод исключительно по количеству свободных часов примерно так же разумно, как увольнять пожарных за то, что в городе давно ничего не горело 🧯

Ставь лукас, поддержи пост комментом, если близко ✊🏻

Самый опасный разработчик тот, у которого закончились задачи | Сетка — социальная сеть от hh.ru