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