Оглавление главы

Приложение B: Организационная трансформация

Это приложение — про то, как встроить агентную практику в организацию так, чтобы она не зависела от энтузиастов, не превращалась в «магическую кнопку» и выдерживала ревью.

Ключевой принцип книги: мы не продаём цифры — мы строим проверяемые контуры. Поэтому вместо “в X раз быстрее” здесь будут:

  • гипотезы эффекта,
  • риски и митигации,
  • способ проверки,
  • критерии go/no-go,
  • артефакты, которые живут в Git.

См. также:

  • Глава 9 — governance и принудительное применение.
  • Глава 10 — эталонный полный цикл и артефакты.
  • Приложение A — бизнес‑обоснование “без ложной точности”.
  • Приложение C — карта процесса и каталог артефактов.

1) Управление изменениями: как внедрять без сопротивления#

1.1 Типовые паттерны сопротивления#

Паттерн: “Агенты заменят меня”#

Корень: страх потери статуса/экспертизы.
Риск: люди будут саботировать практику, а не спорить с ней вслух.

Неправильно:

“Не бойтесь, агенты вас не заменят.”

Правильно:

“Агенты сдвигают вашу роль: меньше ручной рутины — больше дизайна решений, проверок и процессов.
Мы не «автоматизируем инженеров», мы автоматизируем повторяемые операции под контролем инженеров.”

Как проверяем (без обещаний):

  • берём <WINDOW> истории задач
  • выбираем повторяемые классы работ
  • фиксируем “что было руками” → “что стало делегироваться” по артефактам (PR, планы проверки, SOP)

Критерий go/no-go:

  • go: видно устойчивое смещение рутины в делегирование при сохранении/улучшении качества
  • no-go: рост ошибок/регрессий или снижение доверия команды (по фактам, не по ощущениям)

Паттерн: “У нас особый контекст, не сработает”#

Корень: защитный механизм “если не сработает, меняться не надо”.
Решение: не спорить — сделать проверку на реальной задаче.

Проверка (пилот‑эксперимент):

  • выбираем задачу, которая действительно “наша”
  • фиксируем ограничения и STOP заранее
  • сравниваем результат через артефакты и проверку (а не через “кажется быстрее”)

Паттерн: “Нет времени учиться, я завален”#

Корень: парадокс занятости.
Решение: не просить “выделить время”, а встроить обучение в задачу.

Практика: “учимся на боевом кейсе, но безопасно”

  • наставник помогает сформулировать задачу и критерии
  • агент делает черновик
  • инженер делает проверку и принимает/отклоняет по критериям

Критерий go/no-go:

  • go: следующий похожий кейс уже проходит быстрее и предсказуемее
  • no-go: “каждый раз заново”, без накопления артефактов и повторяемого процесса

1.2 Коммуникационная стратегия (без “продажи”)#

Для инженеров#

Сообщение: “роль растёт вместе с ответственностью за качество”.

  • агент пишет черновики и выполняет рутину
  • инженер отвечает за дизайн проверок, крайние случаи, безопасность, оркестрацию

Для руководителей разработки#

Сообщение: “масштабирование = воспроизводимость”.

  • знания из голов → в SOP/шаблоны/runbooks
  • качество контролируется контрольными точками (план проверки, условия остановки, ревью)
  • риск‑контур встроен в процесс

Для CTO/руководства#

Сообщение: “это дисциплина и governance, а не покупка инструмента”.

  • успех измеряется не “скоростью генерации кода”, а предсказуемостью изменений
  • безопасность по умолчанию консервативна (read_only, approvals, allowlist)
  • качество защищается eval/golden tests (глава 8)

2) Эволюция ролей: что меняется на практике#

Это про сдвиг ответственности, а не про “проценты времени”.

2.1 Senior#

Сдвиг:

  • от “писать руками” → к “проектировать и проверять”
  • от “спросить в чате” → к “зафиксировать как артефакт”

Артефакты, по которым видно сдвиг:

  • спецификация (ФТ/НФТ/AC)
  • план проверки
  • пакет решения — decision packet — для рискованных решений

2.2 Staff#

Сдвиг:

  • от “делать архитектуру самому” → к “делать архитектуру воспроизводимой”

Артефакты:

  • ADR (контекст → решение → последствия)
  • SOP и шаблоны, которые реально применяются
  • базовый уровень/контрольные точки качества для команд

2.3 Principal#

Сдвиг:

  • от “влияю через людей” → к “влияю через систему”

Артефакты:

  • governance (что обязательно, кто утверждает, когда STOP)
  • контур качества (eval/golden tests) как часть CI
  • библиотека шаблонов и правил применения

3) Захват знаний: из “эксперта‑узкого места” в воспроизводимые артефакты#

Проблема обычно не в том, что “нет документации”. Проблема в том, что документация не является местом правды и не живёт вместе с кодом и изменениями.

3.1 Принцип “место правды”#

  • Git — место правды для SOP, промптов, чеклистов, runbooks, ADR (версионирование, ревью, история).
  • Таск‑трекер — управление работой: статус/обсуждение + ссылки на конкретные версии артефактов в Git + доказательства.

Мини‑шаблон карточки:

  • ссылка на PR
  • ссылка на артефакт в Git (SOP/чеклист) на конкретный commit/tag
  • ссылка на результаты проверки (CI, тесты, отчёты)

3.2 Метод “парная сессия для захвата знаний”#

Гипотеза: если эксперт делает типовую задачу “вслух”, агент может превратить её в SOP с контрольными точками и условиями остановки; дальше команда выполняет задачу по SOP, а эксперт становится ревьюером артефакта, а не “единственным исполнителем”.

Риски:

  • SOP превращается в “простыню” без проверок
  • агент придумывает детали вместо эксперта
  • команда начинает обходить процесс “потому что быстрее руками”

Митигации:

  • правило “не придумывать”: пробелы = TBD
  • у SOP есть входы/выходы/STOP/проверки/rollback
  • SOP живёт только если проходит ревью и используется (иначе удаляем/архивируем)

Как проверяем:

  • выбираем один повторяемый класс работ
  • делаем один цикл “эксперт + агент → SOP → другой инженер выполняет по SOP”
  • фиксируем gaps и улучшаем SOP итеративно

Критерий go/no-go:

  • go: повторяемость растёт (видно по артефактам и качеству)
  • no-go: без эксперта всё снова “останавливается”, SOP не помогает

Мини‑скелет SOP:

## SOP: <NAME>

### Цель
<WHAT_WE_DO_AND_WHY>

### Входы (обязательные)
- <INPUT_1>
- <INPUT_2>

### Ограничения / политика
- default_mode = `read_only` (если применимо)
- запрет на действия вне разрешённого списка
- что требует подтверждения человека

### Шаги
1) <STEP>
   - Проверка до: <CHECK>
   - STOP: <STOP_CONDITION>
2) <STEP>
   - Проверка после: <CHECK>

### Definition of Done
- <DOD_ITEM_1>
- <DOD_ITEM_2>

### Rollback
- <ROLLBACK_STEPS>

4) Координация: от встреч к контрольным точкам и артефактам#

4.1 Гипотеза#

Если решения и прогресс фиксируются как артефакты (план/ADR/план проверки), то координация смещается:

  • от синхронизаций “расскажи что сделал”
  • к контрольным точкам “покажи артефакты и доказательства”

4.2 Мини‑шаблон контрольной точки#

Контрольная точка: <NAME>

Агент показывает:
- что собирается менять (diff/список файлов)
- риски и митигации
- план проверки (какие проверки и почему достаточны)

Человек решает:
- approve / request changes / stop

4.3 Критерий go/no-go#

  • go: меньше “обсуждений по памяти”, больше ревью по доказательствам
  • no-go: решения принимаются без артефактов, контрольные точки формальные

5) Структура команд: от “экспертов по системе” к “командам по результату”#

Цель не в том, чтобы “сократить людей”. Цель — сделать результат устойчивым:

  • меньше зависимости от единичных экспертов
  • больше воспроизводимых процессов
  • ясные границы ответственности и эскалации

Шаблон изменения структуры:

  • определить поток результатов (например, “изменения безопасно в прод”)
  • закрепить владельца артефактов (базовый уровень, контрольные точки качества, шаблоны)
  • сделать применение “по умолчанию” (через CI/ревью/политику)

6) Метрики трансформации (без обещаний и “×”)#

Метрики нужны, чтобы отличать “кажется стало лучше” от реального эффекта.

6.1 Качество#

  • частота регрессий/инцидентов после изменений
  • доля изменений, которые отклонены контрольной точкой (и почему)
  • соблюдение политики (нарушения STOP/read_only/approvals)

6.2 Скорость (аккуратно)#

  • lead time на выбранном классе работ (с методикой измерения из Приложения A)
  • доля повторяемых задач, которые проходят по SOP

6.3 Воспроизводимость#

  • bus factor (базовый уровень → target) как наблюдаемая зависимость от конкретных людей
  • доля “типовых” изменений, которые могут выполнить разные инженеры по артефактам

Правило: пороги фиксируются заранее как <TARGET> и валидируются на окне <WINDOW>.

7) Мини‑карта: как выглядит полный цикл (в 2026)#

Если вы внедряете практику, держите в голове простую проверку: в каждом шаге должен оставаться артефакт, который можно ревьюить.

См. Глава 10 (эталонный цикл). Мини‑набор артефактов:

  • уточнение требований (вопросы + TBD)
  • спецификация (ФТ/НФТ/AC)
  • план + риск‑регистр
  • ADR по ключевым решениям
  • SOP (контрольные точки)
  • runbook(s) для операций/инцидентов (если применимо)
  • модель угроз + rollout/rollback
  • eval/golden tests в CI

8) Заключение: от сопротивления к трансформации#

Организационная трансформация в этой книге — это не “вдохновляющая речь”. Это серия малых проверяемых изменений, которые:

  • фиксируются в артефактах,
  • проходят ревью,
  • защищены стоп‑условиями,
  • и становятся нормой управления практикой.

Связанные документы: