Перейти к содержанию

П6-бис. Информационный контракт ритуалов

Ритуалы не отменяются — меняется то, что вы с них снимаете. Ниже по каждому: кто источник, что снимаем, как спросить и куда это попадает.

Правило снятия

Любое утверждение фиксируется с тремя полями: кто сказал, когда, каким каналом. Без них это не факт, а воспоминание. Дальше оно попадает в одну из трёх корзин.

Корзина Что это Куда
Обязательство Кто-то обещал что-то сделать Узел зависимости, ступень 2–3
Наблюдение о мире Что-то изменилось в системе или процессе Узел как факт, если источник — владелец объекта
Артефакт Прогон, письмо, MR, дашборд, протокол evidence/ — единственный источник высоких ступеней

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

Ритуалы команды

Ритуал Источник Что снимаем Как спросить Куда заносим
Дейли техлид или PM (вы обычно не присутствуете) События, меняющие подтверждённость: что поехало, что подтвердилось, где стало медленнее «Изменилось ли что-то по нашим зависимостям от других команд?» log/ — если без артефакта; evidence/ — если со ссылкой
Груминг аналитик, техлид Допущения и неизвестные в требованиях: что мы предполагаем, но не проверяли «Что здесь мы считаем верным, но не проверяли?» open_questions узла, задача на выяснение
Планирование спринта техлид Ёмкость, задачи на выяснение, что может уехать вдвое и почему «Чего мы не знаем, из-за чего оценка может уехать вдвое?» bets/: notes и план насыщения
Демо и конец спринта техлид, инженеры Что именно подтверждено и на каком объёме: моки, реальная система, стейдж, прод «Это гоняли на заглушках или против их системы? На каком объёме?» evidence/ со scope; пересчёт cp_current
Ретро команда Где оценки оказались слабее, чем считали; что мешало подтверждать «Что мы считали готовым, а оно таким не оказалось?» decisions/ — материал для калибровки лестницы
Постмортем инцидента техлид, SRE Новая правда о системе: что меняется чаще, чем думали; чего не было ни в одном списке «Что изменилось в системе, о чём мы не знали?» Узел: change_rate вверх; новый узел, если области не было

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

Внешние и управленческие ритуалы

Ритуал Источник Что снимаем Как спросить Куда заносим
Синк со смежниками владелец смежной системы Что отдают, в каком объёме, к какой дате, кто владелец решения «Фиксирую: X к 15.10. Если не успеваете — скажите, поставлю 30.10» Узел зависимости; письмо-резюме → evidence/
1:1 со стейкхолдером заказчик направления Изменения ожиданий и приоритета, новые обязательства, о которых вы не знали «Что изменилось в ваших планах с прошлого раза?» Узел стратегии или бизнес-процесса; при смене приоритета — пересчёт ставок
Квартальное планирование техлиды, стейкхолдеры Условия достижимости цели, владельцы, ёмкость, неизвестные «Что должно быть правдой одновременно, чтобы цель считалась достигнутой?» bets/ — новые обещания с порогом и датой
Mid-quarter review руководство Решения по красным строкам: ресурс, снятие даты, эскалация «Дойдём при текущем темпе? Если нет — какой из двух вариантов?» decisions/ — решение, основание, дата
QBR и закрытие руководство Фактический исход по каждому обещанию и оценка результата «Что из заявленного сработало, а что нет?» Сопоставление cp на момент гейта с фактом; калибровка
Встреча про стратегию топ-менеджмент Что именно изменилось, что остаётся верным, кто владелец решения, когда письменно Пять вопросов из П3-кватер Узел стратегии; письмо-фиксация → evidence/
1:1 с PM и стажёром ваши люди Где застряло, что делегированное требует вашего гейта, чего не хватает «Что из твоего требует моего решения на этой неделе?» bets/ делегированного потока; log/

Что вы ждёте от каждой роли

Роль Что даёт регулярно Чего от неё не ждать
Техлид Техническую правду о подтверждённости и ранний сигнал деградации зависимостей Оценку бизнес-эффекта и приоритетов
Линейный PM Состояние делегированного потока и запрос на гейт перед обещанием наружу Самостоятельных обещаний наружу
Стажёр в роли хранителя Собранные артефакты, дожатые подтверждения, красные строки Решений и оценок
Владелец смежной системы Объём, срок, канал подтверждения Инициативы: он не придёт сам, когда что-то поедет
Аналитик Допущения и неизвестные в требованиях Подтверждения ступени выше 5 — это техническая проверка
Руководитель Решения по красным строкам и критерии оценки квартала Того, что он сам заметит риск

Куда что попадает: поле и файл

Что сняли Поле Файл
Обещание смежника с датой и объёмом facts, open_questions nexus/<зависимость>.md
Письмо, прогон, MR, протокол весь файл артефакта evidence/ГГГГ-ММ-ДД-<что>.md
Кто владелец объекта authority nexus/<узел>.md, один раз
Как часто объект меняется change_rate nexus/<узел>.md, один раз; вверх — после инцидента
Подтверждение на объёме scope и cp_current bets/<обещание>.md
Решение и его основание запись с датой decisions/
Наблюдение без артефакта строка с датой log/ГГГГ-ММ.md

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

Минимальный набор, если сил хватает только на одно

Если из всего контракта удастся удержать только три вещи, пусть это будут они:

  • С дейли или недельного артефакта — что изменилось по зависимостям.
  • С конца спринта — на чём именно проверяли и на каком объёме.
  • Со смежников — письменная фиксация объёма и даты, хотя бы вашим письмом с их подтверждением одним словом.

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