Двести позиций в бэклоге, самая старая — полтора года назад. Никто уже не помнит, кто её завёл и существует ли вообще ещё проблема, которой она касается. Каждую неделю появляется больше заявок, чем команда закрывает, а каждый разговор о приоритетах заканчивается одинаково: всё важно, значит, ничего не важно. Если вы руководите компанией или отвечаете за продукт, такой список – это не техническая проблема. Это проблема принятия решений. И её можно решить без найма трёх дополнительных программистов.
Прежде чем что-либо ускорять, делегировать или вырезать, бэклог нужно отсортировать. Не по дате заявки и не по тому, кто громче требует своего.
Шаг 1: разделите заявки на четыре корзины
Первую сортировку делают по бизнес-последствиям, а не по технической сложности:
- Критичные для выручки: заявки, которые блокируют продажи, обслуживание клиентов или выставление счетов. Каждый день задержки имеет исчислимую стоимость.
- Комплаенс с жёстким сроком: KSeF, GDPR, EU AI Act. Предельная дата не обсуждается, а штраф порой выше стоимости всего изменения.
- Quality-of-life: ничего не блокируют напрямую, но ежедневно съедают время людей. Ручное переписывание данных, отчёт, склеенный в таблице, обходные пути, к которым все привыкли.
- Nice-to-have: идеи, которые год назад казались хорошими, и с тех пор о них никто не спрашивал.
Из наших проектов следует простое наблюдение: последняя корзина – это часто 30–50% всего списка. Смело удаляйте её. Если какая-то идея действительно нужна, она вернётся сама, причём с лучшим обоснованием, чем в первый раз.
Шаг 2: добавьте вторую ось – кто должен это делать
Для заявок, переживших первую отсечку, задайте второй вопрос: требует ли реализация глубокого знания вашей предметной области, или это стандартная инженерная работа? Добавление поля в форму, интеграция через API, новый отчёт, миграция данных, регрессионные тесты – всё это выглядит одинаково и в транспортной компании, и на фармацевтическом складе. Логика ценообразования, алгоритм планирования маршрутов, правила скоринга клиента – этого хорошо не сделает никто, кто не знает вашего бизнеса.
Из этих двух осей получается матрица, упорядочивающая решения:
- Срочное и стандартное: лучший кандидат на делегирование внешнему партнёру. Чётко определённые вход и выход, мало «племенного» контекста.
- Срочное и предметное: собственная команда, немедленно. Здесь нет пути напрямик.
- Несрочное и стандартное: делегировать пакетами, когда наберётся разумный объём.
- Несрочное и предметное: осознанно отложено, с конкретной датой пересмотра вместо вечного «когда-нибудь».
Частая ошибка: делегирование наоборот
И здесь одно мнение, сложившееся на проектах модернизации: многие компании делят работу ровно наоборот. Сложные, предметные задачи отдают вовне, потому что «у нас нет для этого людей», а простые изменения держат у себя, потому что они кажутся дешёвыми. Эффект вдвойне плохой. Внешний партнёр годами изучает предметную область, которую компания должна контролировать сама, потому что это её конкурентное преимущество. А собственный senior тратит недели на добавление полей в формы – работу, которую выполнил бы любой добросовестный подрядчик. Предметное ядро держите in-house даже тогда, когда это идёт медленнее. Стандартную работу отдавайте без сантиментов.
Как понять, что бэклог оздоравливается
Количество позиций в списке говорит немного. Две метрики говорят почти всё:
- Возраст самой старой активной заявки. Если он падает с 18 месяцев до 3, очередь реально движется. Если растёт – сортировка была косметической.
- Lead time, то есть медианное время от заявки до работающего изменения в продакшене. Это единственная мера, которую ощущает бизнес.
К этому – один контрольный тест: баланс поступления и выполнения за месяц. Пока прибывает больше, чем убывает, никакая приоритизация не поможет – нужно либо увеличить пропускную способность, либо резать смелее. Одна оговорка: эти метрики легко подделать. Удаление старых заявок только ради того, чтобы улучшить график, наводит порядок в отчёте, а не в компании.
Где в этой схеме ESKOM AI
В таком разделении труда мы занимаем правую колонку матрицы: берём на себя стандартные изменения, интеграции между системами и автоматизацию регрессионных тестов, а ваша команда остаётся владельцем предметного ядра. Процесс, основанный на команде специализированных AI-агентов, с полным набором автоматических тестов (модульных, интеграционных, E2E, интерфейсных, тестов безопасности и производительности), позволяет закрывать типичную заявку из корзины «стандартная работа» за дни или недели; о том, откуда берётся эта скорость, мы писали в тексте как AI сокращает время реализации изменений. Честно: первые недели сотрудничества медленнее, потому что нам нужно изучить вашу систему и окружение. Эти издержки входа окупаются на последующих заявках, поэтому для одной мелкой правки такая модель не имеет смысла. Для потока изменений смысл большой.
С чего начать уже в эту пятницу
Заблокируйте час в календаре и пройдите список с таблицей рядом: четыре корзины, потом вторая ось. После этого часа вы будете знать три вещи: что удалить, что сделать своими силами и что можно отдать вовне прямо сейчас. А если хотите пройти это разделение с тем, кто делал это неоднократно, запишитесь на бесплатную консультацию через форму на eskom.ai/pl/kontakt. Приходите с выгрузкой бэклога. Уйдёте с отсортированным списком и реальными временными вилками для заявок, которые подходят для немедленного делегирования.