Какую концентрацию знаний выдержит команда из двух инженеров?

Команда из двух человек с ИИ-агентами способна выпускать удивительно много программного обеспечения. Но при этом она может попасть в опасную зависимость от одного инженера, хотя во всех репозиториях идет работа, а каждый pull request выглядит проверенным. Чтобы измерить концентрацию знаний, нужно проверить, может ли каждый участник понять, изменить, развернуть и восстановить каждый важный компонент без подсказок второго участника.

Количество коммитов этого не покажет. Не помогут ни число файлов, которых касался каждый инженер, ни количество запущенных сессий с агентом, ни бодрый ответ на вопрос «все ли знают систему?». Нужна ежемесячная оценочная таблица, основанная на владении компонентами, охвате проверками, упражнениях по восстановлению, сервисах без владельцев и актуальности документации. Таблица должна показывать, где отсутствие одного человека остановит выпуск изменений или затянет инцидент.

В этой статье «компонентом» называется операционная единица с четкой границей отказа: API, обработчик заданий, мобильное приложение, конвейер данных, инфраструктурный стек, платежная интеграция или любая другая часть, которая может сломаться и потребовать решения. Иногда репозиторий совпадает с компонентом, но часто он лишь содержит несколько компонентов. Измеряйте ту единицу, которую вы развертываете и восстанавливаете, а не структуру папок, оставшуюся от архитектуры трех поколений назад.

Концентрация знаний сочетает доступ и инженерное суждение

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

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

Разделите знания на четыре способности. Второй инженер должен уметь найти компонент, объяснить его важные ограничения, внести обычное изменение и восстановить приемлемую работу после типичного сбоя. Если для любой из этих способностей нужно живое объяснение основного владельца, знания по-прежнему сконцентрированы.

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

Поэтому обычный вопрос о bus factor, «сколько людей должно исчезнуть, чтобы проект остановился?», слишком груб для команды из двух человек. Ответ почти всегда равен одному и не подсказывает, что исправлять. Показатели на уровне компонентов дают понять, где находится риск: в малозначимом задании для отчетов или в платежном контуре, который приносит компании деньги.

Не пытайтесь сделать обоих инженеров взаимозаменяемыми во всем стеке. Такая цель отнимает время и обычно оставляет обоим лишь поверхностное знакомство. Оценивайте каждый важный компонент, а затем решайте, какой уровень резервной компетенции оправдан его влиянием на бизнес. Для маркетинговой страницы и сервиса аутентификации не нужен одинаковый целевой срок восстановления.

Стройте реестр по границам отказа

Оценочная таблица начинается с реестра компонентов, который достаточно мал для регулярной проверки и достаточно точен для назначения ответственности. Строка «бэкенд» скрывает риск. Список из 400 библиотек превращает ежемесячную проверку в канцелярскую работу. У большинства небольших продуктов получается от восьми до тридцати операционных компонентов.

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

Используйте уровни влияния, чтобы определить строгость показателей:

• Уровень 1 останавливает выручку, блокирует всех пользователей, создает риск для данных или мешает входу.
• Уровень 2 ломает важный процесс, для которого есть обходной путь.
• Уровень 3 причиняет ограниченные неудобства или задерживает внутреннюю работу.
• Уровень 4 может не работать несколько дней без существенного ущерба.

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

Полезная строка реестра выглядит так:

component,tier,primary,backup,deploy_path,data_store,recovery_target_hours
checkout-api,1,Ada,Max,ci/checkout.yml,orders-postgres,2
email-worker,2,Max,Ada,ci/workers.yml,queue-and-postgres,8
marketing-site,4,Ada,Max,ci/web.yml,none,72

Этот артефакт предотвращает три частых сбоя. Он не дает ответственности остаться только в памяти, отделяет знание развертывания от знакомства с кодом и связывает время восстановления с бизнес-целью. Храните его рядом с кодом или операционной документацией, чтобы pull request мог менять реестр вместе с системой.

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

Владение подтверждает недавняя работа

Владение компонентом показывает, кто способен принять безопасное решение сегодня, а не кто написал первую версию. Для каждого компонента зафиксируйте основного и резервного владельца, затем требуйте свежие доказательства реальности обеих ролей. Имя в таблице без действий выражает лишь намерение.

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

Рассчитывайте охват владением так:

ownership coverage =
components with active primary and active backup
/
all in-scope components

Сначала показывайте результат по уровням, а уже потом общий процент. Если у всех компонентов уровня 4 есть два активных владельца, но единственный сервис уровня 1 зависит от одного человека, суммарная оценка выглядит здоровой и скрывает самый большой риск компании.

Я ставлю компоненту уровня 1 зеленую оценку, только если оба инженера выполняли действие владельца за последние 60 дней. Для уровня 2 можно взять 90 дней, для нижних уровней - 180. Это исходные ориентиры, а не законы природы. Компании с сезонными платежами или редкими регулируемыми процессами может потребоваться другое окно. Запишите его, чтобы никто не передвигал границу ради красивого цвета за текущий месяц.

В документации GitHub по CODEOWNERS сказано, что платформа может автоматически запрашивать проверку у владельцев при изменении подходящих файлов, а правила репозитория могут требовать их одобрения. Это полезная маршрутизация, но она не устраняет концентрацию. Если Ada владеет checkout, а GitHub отправляет ей на проверку каждое изменение checkout, файл фиксирует зависимость вместо ее снижения.

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

Охват проверками показывает независимое понимание

Охват проверками отвечает на более узкий вопрос, чем владение: способен ли второй инженер оценить содержательное изменение без подробного рассказа автора о каждом решении? Измеряйте принятые проверки между границами владения компонентами, а не общее количество проверок.

Для каждого компонента изучите содержательные pull request, объединенные за месяц. Исключите механическое форматирование, сгенерированные файлы, обновления зависимостей без изменения поведения и созданную агентом чистку, которая не затрагивает операционные решения. Среди оставшихся изменений посчитайте, сколько получил содержательную проверку от резервного владельца.

Используйте формулу:

reviewer coverage =
meaningful changes reviewed by the backup
/
meaningful changes eligible for backup review

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

Не задавайте 100 процентов как универсальную цель. Она порождает театр одобрений, особенно когда агенты создают много маленьких pull request. Я предпочитаю цель, основанную на риске: каждое изменение поведения компонента уровня 1 проверяет резервный владелец, а для нижних уровней достаточно выборки, которая сохраняет его знакомство с компонентом. Если за месяц содержательных изменений не было, укажите для охвата проверками «нет выборки». Не превращайте отсутствие доказательств в идеальную оценку.

Задержка проверки тоже имеет значение, но трактуйте ее осторожно. Если резервному владельцу нужны два дня и отдельный инструктаж, чтобы проверить небольшое изменение checkout, независимого понимания у него, вероятно, нет. Для компонентов уровней 1 и 2 отслеживайте медианное время от запроса проверки до первого содержательного ответа. Не учитывайте против инженера часы вне его рабочего времени и согласованный отпуск.

Отдельный сложный случай - совместная работа с агентом. Если оба инженера формировали промпт, проверяли план и вместе следили за изменениями, считайте второго инженера проверяющим только тогда, когда pull request фиксирует, что именно он проверил. Разговор помогает работе, но невидимый разговор не поддержит будущую оценку или передачу инцидента.

Время восстановления нельзя сымитировать

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

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

Измеряйте прошедшее время с момента, когда резервный владелец получил сценарий, до прохождения сервисом указанной проверки. Останавливайте таймер только из-за зависимости вне контроля команды и записывайте паузу. Если резервный владелец спрашивает у основного команду, местоположение учетных данных или незаписанное правило безопасности, упражнение нашло концентрацию знаний. Разрешите основному ответить, чтобы не тратить время, но отметьте прохождение как выполненное с помощью.

Разделяйте три значения:

• Целевое время восстановления - бизнес-ограничение из реестра.
• Наблюдаемое время восстановления - фактическое время резервного владельца.
• Уверенность в восстановлении показывает, было ли прохождение независимым, выполненным с помощью или проваленным.

В книге Google Site Reliability Engineering разделены показатель, целевое значение и действие при отклонении результата от цели. Примените такую же дисциплину здесь. Наблюдаемое время восстановления выступает показателем. Цель из реестра задает требуемое значение. Исправлением может стать настройка доступа, улучшение инструкции, упрощение развертывания или повтор под наблюдением.

Не сводите восстановление к отметке «инструкция существует». Я видел, как точные инструкции не работали из-за отсутствия доступа к хранилищу секретов у резервного владельца. Я также видел, как краткие заметки помогали, потому что система была простой, а инженер ее понимал. Измеряйте время до результата.

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

Сервисы без владельцев получают явный штраф

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

Считайте их напрямую:

unowned rate =
in-scope components without two credible owners
/
all in-scope components

Затем взвесьте количество по влиянию. Один сервис уровня 1 без владельца должен причинять оценке больше вреда, чем четыре задания уровня 4. Подойдет простое взвешивание: умножьте уровень 1 на 8, уровень 2 на 4, уровень 3 на 2, а уровень 4 на 1. Числа показывают относительное внимание, а не точный страховой расчет.

Некоторые основатели сопротивляются этому показателю, потому что формально владелец у системы есть: CTO, агентство, поставщик или инженер, который создал ее два года назад. Проверьте утверждение. Может ли этот человек войти в продакшен в пределах целевого срока восстановления? Обязан ли он ответить? Сможет ли второй инженер действовать, если ответа не будет? Контракт с поддержкой поставщика может снизить операционный риск, но не создает внутреннего владельца, если условия и путь эскалации не соответствуют требуемой реакции.

ИИ-агенты создали новую версию той же проблемы. В разговоре компонент могут назвать «принадлежащим агенту», потому что любой инженер может спросить агента о нем. Агенты не дежурят по оповещениям, не владеют доступом к учетным записям, коммерческим контекстом или ответственностью за решение в продакшене. Назначьте людей основным и резервным владельцами. Считайте инструкции для агента, файлы контекста и повторяемые команды частью документации компонента.

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

Актуальность документации требует практической проверки

Документация актуальна, когда резервный владелец успешно применил ее к текущей системе, а не когда кто-то изменил дату вверху страницы. Поле «последнее обновление» поощряет косметические изменения. Практическая проверка поощряет полезность.

Отслеживайте последнюю дату, когда кто-то кроме основного владельца с помощью документации выполнил определенную задачу по компоненту. Это может быть развертывание, локальная настройка, запрос доступа, откат, упражнение по восстановлению или объяснение потока данных. Записывайте задачу и имя проверяющего, а не только дату.

Рассчитывайте актуальность как долю компонентов в области оценки, документация которых проверена внутри окна своего уровня. Я использую 60 дней для уровня 1, 90 для уровня 2 и 180 для остальных. Документация проходит проверку, только если описывает назначение компонента, путь развертывания, зависимости, наблюдаемость, действие для отката или восстановления, местоположение доступа и решения, которые удивят компетентного инженера.

Рекомендации DORA по качеству документации сосредоточены на ясности, удобстве поиска и достоверности, а не на объеме документов. Я согласен с этим подходом, но команде из двух человек нужно еще одно свойство: исполнимость. Резервный владелец должен сделать с помощью документа что-то важное, пока основной молчит.

Не просите агентов создать из кода большие инструкции и не считайте задачу закрытой. Агент может подготовить полезный первый черновик, особенно для команд и карт зависимостей. Он не проверит, работает ли разрешение в консоли, занимает ли миграция больше окна обслуживания или обещал ли основатель клиенту особый порядок восстановления. Резервный владелец проверяет эти детали, выполняя процедуру.

Актуальная документация включает и контекст агента. Если команда зависит от файлов инструкций в репозитории, сохраненных промптов, разрешений инструментов или псевдонимов команд, проверьте их из учетной записи резервного инженера. Идеальный README не поможет, когда фактический процесс зависит от личной функции оболочки или подключения агента, настроенного только у одного человека.

Объединяйте сигналы, не скрывая красный компонент

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

Используйте пять нормированных показателей:

ownership_score      = active dual-owner components / all components
review_score         = covered eligible changes / eligible changes
recovery_score       = independent tests within target / completed tests
documentation_score  = components verified inside freshness window / all components
unowned_score        = 1 - weighted_unowned_points / weighted_total_points

monthly_score =
100 * (
  0.25 * ownership_score +
  0.20 * review_score +
  0.30 * recovery_score +
  0.15 * documentation_score +
  0.10 * unowned_score
)

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

Применяйте два потолка. Если у любого компонента уровня 1 нет надежного резервного владельца, месячный результат не может превысить 49. Если проверка восстановления уровня 1 провалена или потребовала помощи основного владельца, результат не может превысить 69 до успешного повтора. Эти потолки превращают серьезную зависимость в видимое управленческое решение.

Используйте цвета умеренно. Зеленый может означать 85 и выше без потолка, желтый - от 70 до 84, а красный - меньше 70. Пороги полезны, только если запускают действие. Зеленый требует поддерживать ротацию. Желтый резервирует время следующего месяца для крупнейшего пробела. Красный останавливает необязательную архитектурную работу, пока команда не вернет базовый охват открытому компоненту.

Минимальная ежемесячная запись выглядит так:

month: 2026-07
score: 67
cap_reason: "checkout recovery required primary help"
largest_gap: "backup cannot rotate payment credential"
owner: "Max"
due: 2026-08-07
repeat_test: 2026-08-12
evidence:
  inventory_commit: "abc123"
  recovery_record: "ops/recovery/checkout-2026-07.md"

Не превращайте показатель в оценку эффективности одного из инженеров. Люди начинают подгонять под себя любую метрику, связанную с оплатой или обвинением. Этот показатель оценивает устройство работы команды. Основатель или CTO отвечает за условия передачи знаний: время для проверки, общий доступ, меньшие компоненты и практику в обычные рабочие часы.

Проводите ежемесячную проверку за девяносто минут

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

Используйте такую последовательность:

1. Сверьте реестр компонентов с продакшеном и добавьте все пропущенное.
2. Возьмите доказательства владения и проверок из объединенных изменений, развертываний и операционных записей.
3. Обновите результаты восстановления и даты проверки документации.
4. Рассчитайте показатели, примените потолки и изучите строки уровня 1 до общего результата.
5. Назначьте одно исправление с владельцем, сроком и повторной проверкой.

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

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

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

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

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

В oleg.is услуга Team & AI Audit может изучить эту таблицу вместе с потоком поставки и стоимостью разработки, если основателю нужен взгляд со стороны. Таблица работает и без консультационных услуг: ее польза основана на доказательствах и повторных проверках восстановления, а не на личности ведущего встречи.

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

Проходная оценка должна выдержать отсутствие инженера

Самый частый сбой начинается незаметно. Ada создает checkout с агентом, Max проверяет первые pull request, и оба имени появляются в CODEOWNERS. Следующие три месяца Ada занимается каждым изменением платежей, потому что делает это быстрее. Max между другими задачами одобряет небольшие изменения. Таблица показывает двух владельцев и большой объем проверок.

Затем Ada уходит в отпуск на неделю. Учетные данные платежной системы истекают после изменения политики поставщика. Max находит инструкцию по ротации, но в ней указано старое меню консоли. Его учетная запись может прочитать секрет, но не заменить его. Конвейер развертывания также ожидает команду для контрольной суммы, сохраненную в личной конфигурации оболочки Ada. Агент правильно находит место загрузки учетных данных приложением, однако он не может исправить разрешения или восстановить отсутствующую команду выпуска.

Этот сбой показывает четыре разных пробела. Доказательства владения были слишком слабыми, потому что одобрения считались активным владением. Охват проверками измерял нажатия, а не независимое суждение. Актуальность документации определялась датой изменения вместо практического задания. Ни одно упражнение по восстановлению не проверяло доступ из учетной записи Max.

Исправление столь же конкретно. Выдайте и проверьте нужную роль, перенесите команду контрольной суммы в репозиторий, попросите Max заменить тестовые учетные данные, развернуть их и записать прошедшее время. Ada молчит, пока упражнение не достигнет безопасного предела. Успешный повтор меняет доказательства, очередная редакция инструкции - нет.

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

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