С чего начать
Стратегия трансформации собрана как единый рассказ из четырёх частей: почему по-старому нельзя → AI как выход → целевой процесс и роли → честные челленджи. Читай по порядку или переходи сразу в нужный раздел — ниже коротко, что внутри каждого и зачем.
Почему меняемся
Честный диагноз: техдолг, башня знаний, «лишь бы сдать». Почему старый конвейер ведёт в тупик — и это вопрос выживания.
Открыть → Часть 2AI как выход
Не ассистент, а реструктуризация процесса. Три кривые «почему не ассистент», три рычага, экономика ресурсного гэпа.
Открыть → Часть 3 · процессЦелевой процесс
Замкнутая петля SS→2B, KPI (число итераций → Time-to-Market), autonomy ladder A0–A5 — контроль пропорционально риску.
Открыть → Часть 3 · ролиРоли
Что меняется лично у тебя: input/работа/output «было→стало» по 5 ролям + маппинг каждой боли Части 1 на ответственного.
Открыть → Часть 4Челленджи
Честно про риски: под каждый ответ процесса — свой челлендж и как справляемся. Плюс 5 стратегических критик McKinsey.
Открыть → РаскаткаРоадмап
Как внедряем: очаг внутри проекта + разработчики-чемпионы, контракт руководителя, горизонт «задача №1» за 3 месяца.
Открыть → СправкаГлоссарий
Язык трансформации: 24 термина в оригинале + перевод на наш язык и примеры. «Прогресс идёт от языка».
Открыть →Текущее положение дел и почему мы меняемся
Сначала честно: как мы работаем сейчас и почему так дальше нельзя. Мы живём в этом конвейере годами и перестали видеть проблему — предъявим её фактами. Финал раздела — не приговор, а причина, по которой выигрывают все.
Конвейер с передачей работы по этапам
Классический waterfall: работа переходит с этапа на этап. Value «размывается» — каждый обрабатывает вход и выдаёт что-то на выход дальше.
На каждом стыке — перевод в другой артефакт, ожидание, большие батчи, обратная связь в самом конце. Все живут в этом конвейере и не видят, что с ним не так.
Техдолг — и он не про код
Главный симптом — растущая себестоимость каждого изменения. Долг копится во всех слоях, а «видимое кодирование» — не главная статья.
В новых системах доминирует «Реализация». В старых кастомизированных — понимание, координация, регресс и проценты по долгу (выделены), даже когда сама фича маленькая.
Башня знаний, поздние ошибки, растущий регресс
Три проблемы, которые каждый узнает про свой проект.
Bus factor
Знание держится на единицах — «сидят безвылазно». Уходит человек — уходит система. Код становится единственным источником правды.
Всё вскрывается в конце
Ошибку находим на обучении/UAT → откатываемся и переделываем спеку, код, тесты по всей цепочке.
Проверять дороже, чем менять
Маленькая правка → большой объём проверки (ветки, интеграции, конфиги клиентов, история данных) → редкие релизы, страх рефакторить.
Экономика ценового сегмента: «лишь бы сдать» — вынужденно
Это не разгильдяйство. Продукт, сделанный сразу качественно и без техдолга, стоит примерно в 4 раза дороже — в нашем ценовом сегменте это просто не продаётся.
Заложи это в оценки — цена вырастает, и продать нельзя; тогда «бизнес не имеет права на существование». Поэтому режем углы: документация не пишется, регрессы и автотесты — нет. ⌂ данные: откуда X4 (наше упражнение с продуктовым подходом)
Часть долга рождается ещё до разработки — в продажах и контрактах:
У подхода есть срок годности
Косты растут, идёт инфляция ресурсов, всё усложняется. Это порочный цикл, а на исходе лайфтайма системы становятся неподдерживаемыми, любой CR и апгрейд — супердорогой.
Давление сроков
Надо сдать — режем угол.
Архитектура мутнеет
Временное решение остаётся навсегда.
Следующее изменение дольше
Растёт давление сроков → снова режем угол. Цикл.
Итог: компания становится неконкурентоспособной, клиенты переключаются на более гибких, дешёвых и быстрых вендоров. Для 40-летней legacy-компании это вопрос выживания. Что нас пока держит:
«Сделать хорошо» классикой уже пробовали
Кейс из практики
Попытка сделать «хорошо» нашим классическим способом — как обычно предлагают: «давайте аккуратнее, и всё будет хорошо». В итоге получили примерно те же проблемы. Вывод: дело не в старании — сама парадигма ручного конвейера порождает техдолг, сколько ни старайся. ⌂ данные: подтвердить формулировку кейса
Это не «чтобы вас заменить» — по-старому проигрывают все
Людей завалит ручным техдолгом
Дописывать спеки, апдейтить документацию, писать release notes, гонять регрессы — куча ручной, нудной, но необходимой работы. Закрыть это наймом «тучи людей» компания не может → техдолг растёт, нанять некого → дорога к смерти компании.
Выход из тупика, а не замена
Меняемся не чтобы кого-то заменить, а потому что старый путь — тупик для всех, включая самих людей. Новый подход даёт выйти на новый уровень: не оператор конвейера, а AI-assisted «трансформатор» (подробно — в разделе «Роли»).
Ручками это переделать — не вариант. Но появился AI: он позволяет реструктурировать процесс и сломать порочный цикл, автоматизируя ровно то, что порождало техдолг.
AI как выход
Часть 1 упёрлась в порочный цикл: долг растёт, руками не разгрести. Здесь — почему AI ломает этот цикл, и почему это не «купить ассистента», а сменить операционную модель.
Этот долг нельзя закрыть наймом
Чтобы вести execution и поддержку «как надо» по всему портфелю — с тестами, документацией, регрессами, поддержкой всех вариантов — нужен эквивалент огромного дополнительного труда каждый год. Столько не нанять и никто за это не заплатит.
Классический путь закрыть техдолг руками — закрыт: людей столько нет, а нанимать «тучу людей» под нудную ручную работу компания не может (см. часть 1). Значит, нужен другой класс решения. ⌂ данные: подтвердить порядок ~1000–1500 чел-дней/год по портфелю
Реструктурирует процесс, а не ускоряет кодинг
Ценность AI — не в том, что он быстрее печатает код. А в том, что он автоматизирует non-coding работу, которая и была главной статьёй стоимости изменения: понимание, координацию, регресс, доки, спеки.
Зачёркнутое — шаги, которые AI поглощает или схлопывает. Схлопывается именно дорогое (понимание/координация/регресс), а не кодирование.
Три кривые стоимости
Ассистент кодинга уплощает кривую временно. Долг во всех остальных слоях (знание, регресс, доки, координация) продолжает копиться — и догоняет. Наклон меняет только смена самой модели работы.
Три рычага «зелёной кривой» — каждый бьёт по проблеме части 1
Переход — не магия, а инженерия. Механика уплощения кривой раскладывается на три рычага, и каждый прямо адресует боль из части 1.
Знание — в живом контексте
Смысл проекта живёт в спеке, доменной модели, решениях и тестах — не «в голове ключевого эксперта». AI читает живой контекст, а не спрашивает носителя. Bus factor перестаёт быть точкой отказа.
Проверка и рефакторинг непрерывно
Тесты и рефакторинг идут постоянно, проверка детерминированная и независимая от генератора (evidence gates). Ошибку ловим сразу, а не на UAT в конце.
Спека исполняемая и единая
Правка намерения straight-through апдейтит код, тесты и доки, а не расходится с ними. Понимание и координация перестают быть ручной статьёй расходов.
Экономика меняет знак
Свести к финальному контрасту: почему классика обречена расти, а AI-native — уплощается.
Salvation: узкое окно, а не угроза
«Нас заставляют, нас заменят»
AI воспринимается как угроза рабочим местам и привычному укладу. Но по старому пути (часть 1) проигрывают все — и люди, и компания.
Редкое окно вырваться вперёд
Уникальная возможность оперативно трансформировать 40-летнюю компанию: то, что заняло бы десятилетия, реально за месяцы. 40 лет доменного знания + AI-native процесс = труднокопируемое преимущество. Кто адаптируется — вырывается по экономике.
«Выход» — не лозунг, а конкретный процесс: замкнутая петля, роли, автономия под риск. Дальше — как он устроен и что меняется у каждого.
Замкнутая петля и единая метрика
Целевой AI-native процесс: координирует не код, а намерение, спеки, ограничения, тесты и телеметрия. Всё сводится к одной метрике — сокращению числа итераций.
KPI — сокращение числа итераций
Меньше кругов «переделали → вскрылось → откатили» → Time-to-Market ↓ и меньше возвратов.
Было
Изменился RFP или постановка → переделываем спеку → код → тесты → всё «вскрывается» на обучении и UAT → откатываемся. Каждый круг задевает ~10 человек.
Стало
Изменилось намерение → все артефакты в одном репозитории апдейтятся разом (straight-through). Круг короткий, замкнутый, с реальным критерием приёмки.
Прежде чем петля включится — реконструкция контекста
Все три рычага ниже (живой контекст, executable specs, непрерывная проверка) предполагают, что контекст системы уже существует. Но Часть 1 сама признаёт: код — единственный источник правды, консолидированной доменной модели нет, знание — в голове ключевого эксперта. Значит первый и самый дорогой шаг — реверс legacy в доменные модели. Мы ведём его отдельным стримом, а не прячем в петлю.
Отдельный трек с оценкой
Legacy→доменная модель — не побочный результат петли, а стрим №1 раскатки: с эффортом и местом в роадмапе. Рычаги петли включаются только на восстановленном контексте.
Поведение ≠ корректность
AI хорошо мапит, что код делает, но не решает, где поведение правильно, а где — накопленный за годы баг. Где корректно — решает человек-эксперт; AI ассистирует, не заменяет это суждение.
Контекст надо поддерживать
Реконструкция создаёт слой — но у каждого артефакта нужен owner, scope, срок годности и eval-покрытие. Иначе живой контекст протухнет, как это было с нашей Wiki.
Метод стрима — пилот DDD→код→спека (product-vs-project мастер-версии). Честно: даже у лидеров рынка модель PDLC предполагает контекст уже существующим — этот шаг у всех слепое пятно, а не наша локальная недоработка.
Замкнутая петля вместо конвейера с хэндоффами
Строгость не исчезает, а переезжает: вверх (спеки/архитектура), вбок (надзор за агентами), вниз (автопроверка). Клик по узлу — что это.
Autonomy ladder — контроль пропорционально риску
Тесты в новой модели — и что честно остаётся трудным
Тесты — это доказательства приёмки в evidence-гейтах. Целевая архитектура ниже; фронтир помечаем честно, а не выдаём за решённое.
Разные базы и данные
Тесты параметризованы по среде и данным (data-driven), абстрагированы от конкретной БД: один набор — разные базы и наборы данных, а не переписывание под каждую.
Генерация, а не ручная подготовка
AI генерит фикстуры из доменной модели и спеки. Честно: подготовка тест-данных — самое трудное, это фронтир, а не «кнопка».
Хрупкость общего ядра
Правка common-core задевает все проекты → регресс ядра гоняется на каждый зависимый проект непрерывно (evidence-гейты ловят affect). Целостность ядра — отдельная явная работа.
Тесты не «отдельно живущие»
Тесты живут с кодом в едином репо (живой контекст), per-project набор, пирамида e2e ≤1%. «Один набор на всё» уходит — иначе тесты не защищают от регрессий.
⌂ данные: инфра-предпосылки (база из-под СИС, DBA-права у клиента, переносимость на клиентских базах — блокер у клиента) — операционные блокеры перехода, держим в open-questions (G9). Здесь — целевая архитектура тестов, честно с фронтиром.
Что где живёт: проект — слоями в одном Git-репо
Раньше проект размазан по 5 системам (Word · Wiki · Excel · Jira · Email) — статус собирается руками, артефакты теряются. Теперь весь проект — слоями в одном репозитории (живой контекст, трассируемый журнал работ): входы в inputs/ (SoW/RFP) и presale/, дальше — по ролям.
Как ведём проект
plan/ · team/ (команда и аллокация) · deliverables/ (каталог с %) · correspondence/ (переписка) · meetings/ (минутки) · risks/ · status/ · change-management/ · handover/. Всё, что жило в Word/Excel/почте — здесь.
Смысл проекта
spec/ (DDD → executable) · traceability/ («4 кита») · flows-samples/ · impact-analysis/ · integration-spec/ · test-plan/ · onboarding-migration/.
Код и доставка на dev
task-development/ (код + автотесты) · architecture/ (ADR в начале) · code-review/ · deploy/ · bug-diagnosis/ · support/.
Проверка
test-design/ · test-data/ · test-suite/ · test-pyramid/ · acceptance/. Тесты живут с кодом, per-project.
Доставка и инфра
infra-design/ · environments/ (каталог стендов) · access/ (доступы/PKI) · db-migration/ · release-management/ · playbooks/. Credentials — в менеджере паролей, не в Git.
Общее и домен
skills/ — переиспользуемые агенты-скиллы (в общий каталог) · adr/ — арх-решения · glossary/ — язык проекта · design/+Systems/ — наш дизайн по сторонам корридора + границы внешних систем.
⭐ Прямой ответ на PM-боли: «план в бинаре MPP», «нет места под команду», «дублирование минуток», «deliverables нетрекаемы», «переписка не в едином месте» — у каждого теперь конкретная папка. ⌂ данные: структура — прототип <repo>-ai-native (5/5 ролей раскатаны, статус DRAFT); финальная единая иерархия и расхождение с copier-шаблоном — за Василием (open-questions).
Роли: input · работа · output
Общий сдвиг: AI генерирует — человек валидирует (не «AI делает»). Все артефакты — в едином репозитории-cockpit (Git = источник правды), рутины оформлены скиллами. Сначала — какая роль закрывает какую проблему из Части 1, затем выбери роль и переключи «было / стало».
Каждая проблема Части 1 закрывается ролью или функцией
Ничего не повисает в воздухе: под каждую боль — конкретный ответственный в новой модели. Ролей не плодим — те же роли меняют содержание (Function Family под нашу специфику: BA + системный аналитик объединены, Support обязательно в цикле).
⭐ Support в цикле — акцент руководства: иначе неподдерживаемые системы и «внедрили одно — обновить не можем». ⌂ данные: валидация ролей (Function Family) на нашу специфику — за Василием (W8)
Input
Работа
Output
Чего ждём
Чего больше не делает
3D-принтер: разработчик в центре
Поддерживающие роли успешны, когда помогли разработчику автоматически родить код и тесты — дали идеальный вход.
Рисует, что напечатать
Ваншот-постановка = идеальный промт: достаточно определённая спецификация на вход. Не «помойка фактуры», а подготовленный чертёж.
Хозяин 3D-принтера
Из идеального input рождает код + тесты + деплой. Дефинирует и контролирует качество входа: «вы знаете, как лучше для AI».
Операторы качества
Загрузили, проверили, подчистили, отдали. Приёмка — разовая человеческая верификация «сделанное = заказанное».
Артефакт для клиента = фасад, не сырой репозиторий
Внутри — executable spec, DDD и живой контекст в репо. Наружу клиент (часто не-AI) получает человекочитаемый документ. Фасад рождается из внутреннего слоя и синхронизируется с ним, а не ведётся отдельно.
Клиент может быть не-AI
На выходе — не репозиторий, а привычный документ (Word/PDF). Внутренний executable-слой — источник; клиентский артефакт генерится из него, а не пишется руками параллельно.
Наследование правок клиента
Комментарии клиента в Word не теряются при регенерации: привязаны к якорям спеки и переносятся в новую версию, а не затираются свежей генерацией.
«AI-smell» вычищает человек
Сырой AI-текст клиент распознаёт (вода, пурга). Чистовой клиентский текст и политические формулировки проходят человека — см. Ч.4 «Что AI пока НЕ берёт».
Спека не меняется «тихо из кода»
Изменилось поведение → правка спеки для клиента проходит цикл пересогласования (что и почему поменялось), а не появляется молча из регенерации.
Две синхронные версии
Внутренняя (полная, executable) и клиентская (урезанная, причёсанная) связаны: клиентская обновляется управляемо и не разъезжается с реализацией.
⭐ Прямой ответ на pushback «клиент может быть не-AI / наследование Word-комментариев / AI-smell / пересогласование спеки». ⌂ данные: точная механика наследования комментариев и версий клиента — за Василием (open-questions)
Челленджи: под каждый ответ — свой
Это не silver bullet. Каждый ответ из Части 3 несёт собственный риск — показываем честно и сразу рядом: как справляемся. Из McKinsey-дека (риски перехода) + EY (AI может как убрать, так и размножить долг).
Каждый ответ Части 3 → его челлендж → как справляемся
⭐ Психологический барьер + язык — отдельный челлендж (акцент руководства): «прогресс идёт от языка», см. раздел «Глоссарий». Две строки про реконструкцию контекста и незамыкание петли на on-prem — самые честные: они бьют не по механике, а по применимости самой схемы к нашему основному классу проектов (ЦБ за firewall). Держим их явно, а не сглаживаем.
5 возражений к самому подходу — и наши ответы
Более высокий уровень: не «риск механизма», а «стоит ли вообще делать AI-native-first». Клик по карточке — наш ответ.
Что AI пока НЕ берёт
Нарратив не silver-bullet — вот что сегодня остаётся на человеке. Прямой ответ на «процесс чересчур оптимистичен». Границы двигаются по autonomy ladder, но мы признаём их явно.
Заковыристые проводки и нестандартные схемы
Сложную нестандартную логику проектирует человек. AI — на причёсывание и рутину, не на «изобрести проводку».
Первичный бизнес-анализ нестандартных кейсов
Остаётся на человеке — это наш гэп «архитектор / контекст системы». AI приводит к виду, но не решает, «корректно ли» поведение.
Чистовой клиентский текст
AI-черновик бывает «водой»/«пургой», у клиента срабатывает «AI-smell». Вычистка и политические формулировки — на человеке.
Разовые технические активности
Стресс-тесты, switch-over, penetration, рандомные R&D-довески — не алгоритмизируются, остаются ручными.
Корректность ≠ соответствие
Тесты и спека мапят поведение, но «зелёное ≠ правильно». Бизнес-негатив и финальная приёмка «сделанное = заказанное» — на человеке.
Это не «AI не работает», а честная карта: рутину и объём берёт AI, суждение о корректности и нестандартное — человек. По мере зрелости домена границы сдвигаются вверх по ladder.
Добавь своё опасение
Список не закрыт — у каждого свои риски и вопросы. Собираем анонимно и адресуем прямо в этих разделах: опасение уходит в общую панель фидбэка (можно указать раздел и тип).
Две оси одной раскатки
Не ждём новый greenfield-проект: каждая команда берёт кусок функционала из любого текущего этапа и складывает AI-native компоненты в полный процесс. Внедрение — через разработчиков-чемпионов.
Внутри проекта
По организации
Контракт руководителя департамента
- Выбрать боевой эпик (не песочницу)
- Запустить «очаг» и довести цикл до аналитиков и тестировщиков
- Завести/адаптировать скиллы-агенты под домен; полезное — в общий каталог
- Держать дисциплину артефактов в Git (репозиторий-cockpit)
- Отвечать за метрику: cost-to-deliver / cycle time план-факт
- NGPI в департаменте: ключевые + срок на освоение AI-инструментов
Глоссарий терминов
«Прогресс идёт от языка»: термины рождаются на английском и точно что-то значат — сохраняем оригинал и приземляем на «наш язык» с примером. Ищи или кликни термин — определение справа.