Портфель ИТ-проектов финансируют по полезному потоку: три направления не требуют трёх отдельных команд

Что считать полезным потоком? Задача проходит от готовности к работе до принятой правки. Владелец продукта затем проверяет, что изменилось для бизнеса.

ИТ-стратегия компании связывает выбор проектов с результатами и ограничениями бизнеса.

Atlassian описывает финансирование общей мощности под ожидаемый результат. Для ИИ-агентов применим тот же принцип: заранее записать пользу следующей правки.

Разберём сайт, CRM и кабинет клиента. Это модель распределения между действующими продуктами, не история внедрения у нашего заказчика.

Закрытый тикет ещё не доказывает пользу. Кнопка может пройти тесты, но остаться невостребованной. Выпуск и эффект отмечают раздельно.

Коммиты тоже не заменяют результат. Наш отчёт об агентной разработке показывает работу машины; отдачу продукта проверяет его владелец.

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

Что компания покупает вместе с потоком? На /services это одна задача в работе, следующая ждёт. Поток задаёт предел одновременного исполнения.

В подписке на разработку «Все проекты» стоят 500 000 ₽ в месяц за три потока. Цена проверена 7 октября 2026.

Продукт хранит свою очередь задач. Какой продукт получит освободившийся поток, решает ИТ-директор. Постоянно закреплять поток за продуктом не обязательно.

Большую задачу режут на принимаемые части. Для кабинета это может быть сначала выдача документа, затем уведомление. Шаблон есть в постановке задач ИИ-агенту.

Три потока не обещают втрое больше выпуска. Задачи различаются по сложности, а проверка и общий модуль способны задержать все направления.

Приёмку и момент освобождения потока согласуйте до старта. Надпись «код готов» не должна молча превращать непринятую работу в завершённую.

Как делить мощность между продуктами? Для нашей модели можно начать с потока на сайт, CRM и кабинет. Это исходное распределение, не постоянная доля бюджета.

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

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

Уже начатая заблокированная задача остаётся незавершённой. Перед заменой явно решают, как её остановить и возобновить. Нельзя переименовать ожидание в свободную мощность.

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

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

Можно ли вести продукты общей машиной? Да, если у каждого есть свои правила, очередь и принимающий. Общий модуль при этом остаётся общим риском.

На карте нашей машины видны разные зоны одного сайта. Это собственный опыт организации работ, не доказательство клиентского портфеля.

Несколько репозиториев разобраны в уроке «Больше кодбаз, меньше свалки» курса «Агентная разработка». Отдельная кодбаза помогает отделить правила продукта.

Границы папок не разделяют выпуск и проверку автоматически. Порядок веток и влития разобран в статье про руководителя разработки и агентов.

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

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

Как сравнивать направления? Договоритесь об общей границе «готово». В предлагаемом порядке правка принята владельцем, выпущена и прошла согласованную проверку.

В Kanban Guide, редакция май 2025, считают незавершённую работу, выпуск за период, возраст открытой задачи и время от начала до завершения.

Ожидание проверки входит в незавершённую работу. Добавлять исполнителей, когда принимающий не успевает, означает растить очередь готового кода.

Одинаковое число задач не означает одинаковую отдачу. Исправление потери заявок и замена подписи различаются по эффекту, даже если оба тикета закрыты.

Фактический общий расход распределяют по согласованному основанию. Не делите сумму на число продуктов автоматически: инфраструктуру и работу над общими модулями учитывают отдельно.

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

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

Зафиксируйте исходное ожидание и порядок приёмки до старта. Как считать срок отдельной задачи, разобрано в статье о сроках разработки.

В конце месяца возвращаемся к сайту, CRM и кабинету. Если CRM даёт подтверждённый эффект, а кабинет ждёт решения, продолжение потока согласуют по этим данным.

Общая машина не снимает ответственность компании за выпуск. Проверки, права и откат разобраны в статье об ответственности за ошибки ИИ.

Решение директора должно назвать следующую работу и её принимающего. Бюджет остаётся под контролем, а распределение мощности меняется вместе с результатом.