Разбор · Опубликовали 08.10.2026
ИТ-стратегия задаёт целевую схему систем и порядок инвестиций: агенты исполняют переход по частям
Как CTO согласовать с собственником устройство систем, расставить зависимости и передать агентам исполнение перехода. Архитектурное решение остаётся у клиента.
Машина агентов под надзором инженера vibecoding.ru · факты проверены 8 октября 2026
ИТ-стратегия определяет, как системы компании должны работать вместе и в каком порядке в них вкладывать деньги. Быстрый код ИИ-агентов эту работу не отменяет.
CTO утверждает схему, инженер ведёт машину агентов и выполняет переход по частям. Клиентской ИТ-стратегии у нас пока нет; свой опыт разбираем на vibecoding.ru.
Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.
1. ИТ-стратегия переводит цель бизнеса в изменения систем.
Разработка ИТ-стратегии начинается с нужного результата для бизнеса. В методике Info-Strategy целевое состояние ИТ предшествует плану проектов; список новых приложений сам по себе цель не задаёт.
Возьмём учебный пример: заявку принимают на сайте, заказ ведут в CRM, оплату учитывают отдельно. Цель собственника: видеть оплаченный заказ без ручной сверки.
«Купить новый кабинет» ещё не описывает переход. CTO нужно определить, откуда кабинет получит заказ и оплату, а какой прежний способ работы компания уберёт.
От проблемы к изменению системы
Учебная модель статьи, 8 октября 2026. Порядок и результаты не взяты из клиентского проекта.
2. Целевая схема закрепляет за каждой системой свои данные.
В целевой схеме важно показать, кто отвечает за каждый факт. В нашем примере CRM ведёт заказ, учётная система подтверждает оплату, кабинет показывает оба статуса.
Для каждой связи CTO фиксирует состав данных и поведение при сбое. Если подтверждение оплаты задержалось, кабинет показывает ожидание проверки, а не выдумывает статус.
Часть систем можно оставить. Когда границы уже подходят бизнесу, достаточно связать их, а разобрать старый код можно отдельными задачами.
3. Зависимости систем определяют порядок вложений.
Следующее вложение должно опираться на работающий результат предыдущего. Кабинету нужны связанные заказ и оплата; вложение в экран до этой связи не решает ручную сверку.
Сначала свяжем заявку с заказом. Затем научимся получать подтверждение оплаты. Кабинет включим, когда данные для него уже есть.
Порядок согласуют по зависимостям, эффекту и риску остановки работы. В нашем примере собственник финансирует связь заказа с оплатой раньше кабинета, потому что она уже убирает ручной поиск платежа.
Очередь перехода по зависимостям
Учебный порядок, не оценка срока. Мартин Фаулер в Strangler Fig, 22 августа 2024, описывает отделимые части перехода и временную архитектуру. Работа агентами является нашим применением этого принципа.
Промежуточную схему тоже нужно описать. Пока кабинет ещё не готов, сотрудники продолжают вести заказы в CRM. Такой временный порядок CTO тоже включает в бюджет перехода.
У временной связи должно быть условие снятия. Иначе после запуска кабинета останутся прежняя таблица, новый экспорт и обязанность сотрудников сверять оба.
На разборе этапа CTO сверяет результат с целью. Если ручная сверка сохранилась, следующий этап возвращают на уточнение, даже если код уже выпущен.
Что согласовать перед следующим вложением
Авторское лекало инвестиционного решения, 8 октября 2026. Суммы заполняет компания; окупаемость этого примера не измерялась.
4. Агенту передают изменение внутри утверждённой схемы.
Агенту можно поручить связать оплату с заказом по описанному правилу. Решение, какая система подтверждает оплату, к этому моменту уже принято CTO.
В задаче для агента нужны граница изменения и способ проверки. Например, повторное подтверждение не создаёт новый заказ.
Если связь не работает в этих границах, инженер возвращает вопрос CTO. Агент не получает право создать ещё одну систему учёта только потому, что так проще написать код.
Одна связь становится задачей с приёмкой
Шаблон для учебного примера. Постановка и проверка задачи подробно разобраны в соседней статье серии.
5. В нашей машине решение хранится рядом с кодом.
На карте нашей машины рядом с кодом видны описания проекта и журнал решений. По снимку 8 октября 2026 там 387 тысяч строк спеков и 391 тысяча строк кода.
Описания дают агенту решение до правки, журнал объясняет его причину. Сопоставимый объём документов и кода показывает масштаб этой работы; пользу клиентской стратегии по нему не измерить.
Наш опыт относится к этому сайту. Перенос принципа на компанию потребует её схемы систем и проверки результата; бюджета клиентского перехода мы не измеряли.
Что и как мы проверяли
| Факт | Что известно | Проверено |
|---|---|---|
| Метод стратегии | Открыли первоисточники Джет, Info-Strategy и КОРУС. Они связывают бизнес-цели, состояние ИТ и план изменений. Лекала этой статьи предложены редакцией. | 2026-10-08 |
| Переход по частям | Статья Мартина Фаулера Strangler Fig, редакция 22 августа 2024: постепенная модернизация и уточнение целей. Применение к исполнению агентами является нашим выводом. | 2026-10-08 |
| Объём нашей машины | 387 тысяч строк спеков и 391 тысяча строк кода на живой /open. Это показанные страницей объёмы на 8 октября, без замера прироста за период. Окно накопления на странице не названо. | 2026-10-08 |
| Истории поломок | Записи нашей машины от 31 июля и 17 сентября 2026 перечитаны по первичке. Правила подтверждены действующей проверкой передачи полей и каноном зависимостей постоянного процесса. | 2026-10-08 |
| Граница подписки | На живой /services сверены один и три потока, цены 250 000 и 500 000 ₽ в месяц, определение потока и исключение архитектурных решений. | 2026-10-08 |
| Граница опыта | Клиентской ИТ-стратегии и замера её бюджета у машины нет. Пример заявки, заказа и оплаты учебный, без обещания срока или экономии. | 2026-10-08 |
Связь проверяют на обоих концах. В учебном процессе факт оплаты должен совпасть с заказом, который увидел клиент; успешная запись в учёте ещё не подтверждает передачу статуса.
Зависимости постоянной службы должны пережить временную задачу. Если новый процесс работает только в окружении исполнителя, переход ещё не завершён.
В курсе агентной разработки есть уроки «Руль, окно и сторож» и «Больше кодбаз». Первый связывает описания, наблюдение и проверки; второй разбирает разделение кодбаз. Целевую схему компании эти уроки не заменяют.
Поломка становится правилом связи между частями машины.
31.07
Описание обложки новости терялось на части путей публикации. Правило: все пути используют общий перевод полей; проверка не пропускает ручной обход.
17.09
Постоянный сборщик зависел от временной папки задачи; после её удаления замер не снялся. Правило: постоянному процессу нужны собственные зависимости и проверка их наличия перед запуском.
Наши записи июля–сентября 2026, сверены 8 октября. Это не кейсы перехода клиента.
6. CTO утверждает схему, подписка исполняет переход задачами.
Архитектурное решение остаётся у клиента. CTO отвечает за целевую схему, собственник согласует вложения, инженер ведёт исполнение машиной агентов.
Кто принимает код и разрешает выпуск, нужно определить отдельно. В статье о руководителе разработки разобраны эти роли и проверки.
Разработка по подписке подходит для последовательного исполнения утверждённого перехода. На странице услуги архитектурные решения исключены из работ.
Как объём работы соотносится с потоком
Условия /services проверены 8 октября 2026. Поток содержит одну задачу в работе. Цена месяца не является оценкой бюджета всей ИТ-стратегии.
Три потока не отменяют зависимость. Кабинет ждёт данные об оплате; параллельно можно делать отдельную связь, если она не меняет общий источник данных.
Если неясно, что уже можно передать исполнителю, начните с теста для руководителя. Затем обсудите исполнение по схеме своего CTO.
После принятого этапа обновите схему и сравните работу сотрудников с исходной целью. Этот результат становится основанием следующего вложения или изменения порядка.
7. Частые вопросы
Чем ИТ-стратегия отличается от списка проектов?+
Она объясняет, как системы должны работать вместе ради целей бизнеса. Список проектов показывает действия; стратегия задаёт целевое устройство, зависимости перехода и основания для вложений.
Нужно ли менять все системы компании?+
Сначала нужно решить, какую роль каждая система играет в целевой схеме. Часть останется, часть получит новые связи, часть можно будет вывести из работы после принятого перехода.
Можно ли поручить агенту разработку ИТ-стратегии?+
Агент может собрать описания, сравнить их и подготовить черновик. Целевое устройство, допустимые компромиссы и порядок вложений утверждают CTO и собственник компании.
Как оценить бюджет перехода?+
По этапам: изменения кода, перенос данных, обучение сотрудников и расходы на работу новой схемы. Цена месяца исполнителя входит в этот расчёт, но не заменяет его. До уточнения зависимостей сумму всего перехода обещать нельзя.
Как понять, что этап закончился?+
Проверить заранее согласованный результат в работе компании и обновить схему. В учебном примере запуск кабинета завершает переход только после того, как клиент видит верные статусы, а сотрудники прекращают прежнюю ручную сверку.
Когда нужно пересматривать ИТ-стратегию?+
Когда меняется цель бизнеса, выясняется новая зависимость или результат этапа расходится с ожидаемым. CTO сверяет факт с целевой схемой и согласует изменение порядка с собственником.
Источники
- Инфосистемы Джет: разработка ИТ-стратегии для предприятия — официальный сайт
- Info-Strategy: этапы разработки стратегии — авторская методика
- КОРУС Консалтинг: ИТ-консалтинг — официальный сайт
- Мартин Фаулер: Strangler Fig (22 августа 2024) — авторский блог
- Открытые цифры машины vibecoding.ru, карта описаний и кода — наш снимок
- Агентная разработка по подписке: условия и границы работ — наша услуга
- Агентная разработка: программа курса — наш обучающий опыт
- Индекс: публичный ряд замеров после восстановления сборщика — публичный результат работы машины
Запомнить
- Начните с результата бизнеса. Запишите, какую ручную работу или потерю компания должна убрать.
- Утвердите ответственность систем. Для каждого факта назовите источник и способ передачи.
- Оплачивайте переход по зависимостям. До этапа согласуйте результат и условие следующего вложения.
- Передавайте агентам изменения внутри схемы. После приёмки возвращайте результат CTO и обновляйте порядок.