Разработка vs. техдолг: как не угробить команду
В разработке всегда хочется найти золотую середину между внедрением новых фич, поддержкой старых и борьбой с техдолгом. Типа, 50% времени на новые фичи, 30% на поддержку, 20% на техдолг — и вот тебе идеальный баланс. На деле это так не работает.
Почему это не работает?
Распределение ресурсов по задачам кажется логичным, но на практике…
- Команды не резиновые. Разработчики не могут переключаться между разными типами задач без потерь. Контекстное переключение — это время, которое уходит в никуда.
- Фокус размазывается. Когда команда пытается делать сразу несколько вещей, она в итоге не делает ничего по-настоящему хорошо. Прогресса нет, хотя работа вроде идёт.
- Скорость падает. Постоянная смена фокуса замедляет работу, а задачи начинают тянуться на месяцы. В итоге сроки срываются, клиенты не довольны, а команда выгорает.
- 80% времени уходит на поддержку. Поддержка старого кода и багфиксы становятся основной частью работы, а не развитие нового функционала.
Зачем всё усложнять?
Проблема в том, что при распределении ресурсов не учитывается, что простое разбрасывание задач по всему процессу не приводит к прогрессу. Работа сама по себе — это не всегда результат.
1 Контекстное переключение. Разработчик не может на 30% заниматься рефакторингом, а на 70% пилить новый функционал — это просто разные режимы работы. Постоянные переключения замедляют команду.
2 Размытые приоритеты. Когда пытаешься делать всё сразу, не получается сделать ничего качественно.
3 Ограниченные ресурсы. Если команда уже на пределе, перераспределение не даст результата. Иногда проще просто сократить задачи, чтобы сосредоточиться на важном.
4 Неучёт зависимостей. Раздача задач без понимания взаимосвязей между ними приводит к задержкам.
Как сделать лучше?
- Сосредоточиться на приоритетах. Лучше сделать одну ключевую задачу до конца, чем начинать десять мелких, которые не двигают дела вперёд.
- Целевые команды. Для решения техдолга или конкретных задач проще выделить отдельную команду, чем заставлять всех заниматься всем сразу. Когда люди сосредоточены на одной цели, результат лучше.
- Zero Bug Policy и Kill Your Darlings. Прежде чем разрабатывать новые фичи, важно закрывать баги. Но так же важно «убивать любимые фичи», если они не приносят реальной пользы.
- Гибкое перераспределение людей. Иногда лучше сделать паузу в одном направлении и переключиться на другое, чем пытаться тянуть всё одновременно. "По чуть-чуть" редко работает эффективно.
- Прозрачность. Когда команда понимает, почему именно эти задачи в приоритете, её вовлечённость растёт. Прозрачность позволяет эффективно управлять ожиданиями.
- Долгосрочное видение. Инвестиции в основу, даже если это замедлит темп на некоторое время, могут дать значительный рост в будущем.
Пример: проект как старый «рыдван»
Представьте, что у вас есть старая машина, которая постоянно ломается. Подвеска скрипит, двигатель чихает, коробка передач заедает. Но вместо того, чтобы починить эти проблемы, вы решаете поставить новый мафон, чтобы музыка играла. Мастер спрашивает: "Может, сначала тормоза починим?" Но… сидюк важнее. Через неделю машина намертво встала на обочине — двигатель накрылся, тормоза отказали. Зато музыка радует слух.
Вот так часто происходит в dev-командах: стараются улучшить продукт, но важные проблемы остаются нерешёнными. Распределив ресурсы по всем направлениям, команда не двигается вперёд, и в результате страдает всё: пользователи, бизнес и сама команда.
Как вы находите баланс между новыми фичами, поддержкой и техдолгом в своей команде?
Больше на канале Из Кода В Руководы