Задача и границы
Для темы «передача работы между командами» используется артефакт «контракт передачи работы между командами». Он отвечает на вопрос: как согласовать ожидаемый результат, владельца, критерии приёмки и оставшиеся риски при переходе работы через границу команды. Модель «контракт передачи работы между командами» разделяет факт и гипотезу. Для «контракт передачи работы между командами» явно указывают владельца и дату пересмотра. Причинность артефакт не доказывает.
Редакционная методика «контракт передачи работы между командами» проверяется на завершённом рабочем эпизоде. В границах «контракт передачи работы между командами» правовые, трудовые, клинические и договорные вопросы остаются в профильных процедурах.
Проверенные основания
GOV.UK соединяет delivery с прозрачностью. основание В артефакте «контракт передачи работы между командами» это основание проверяет компонент «передаваемый результат».
AWS сохраняет решения в ADR. основание В артефакте «контракт передачи работы между командами» это основание проверяет компонент «границы ответственности».
GitLab опирает асинхронность на документацию. основание В артефакте «контракт передачи работы между командами» это основание проверяет компонент «критерии приёмки».
AWS проверяет операционную готовность вопросами. основание В артефакте «контракт передачи работы между командами» это основание проверяет компонент «неразрешённые риски».
Внешние источники задают ориентиры. Конкретная схема «контракт передачи работы между командами» остаётся редакционной методикой и требует проверки на данных команды.
Рабочая модель
Передаваемый результат. В «контракт передачи работы между командами» фиксируют вход, решение и ожидаемый выход. Связь «передаваемый результат → критерии приёмки» проверяют критерием «принимающая команда участвовала до передачи»; ошибка «передавать работу после завершения разработки» служит отрицательным тестом.
Границы ответственности. В «контракт передачи работы между командами» фиксируют вход, решение и ожидаемый выход. Связь «границы ответственности → неразрешённые риски» проверяют критерием «критерии приёмки наблюдаемы»; ошибка «считать документ достаточной передачей» служит отрицательным тестом.
Критерии приёмки. В «контракт передачи работы между командами» фиксируют вход, решение и ожидаемый выход. Связь «критерии приёмки → операционная поддержка» проверяют критерием «доступы проверены реальным действием»; ошибка «не включать принимающую команду в проверку» служит отрицательным тестом.
Неразрешённые риски. В «контракт передачи работы между командами» фиксируют вход, решение и ожидаемый выход. Связь «неразрешённые риски → точка окончательной передачи» проверяют критерием «риски названы явно»; ошибка «скрывать временные обходные решения» служит отрицательным тестом.
Операционная поддержка. В «контракт передачи работы между командами» фиксируют вход, решение и ожидаемый выход. Связь «операционная поддержка → передаваемый результат» проверяют критерием «период поддержки ограничен»; ошибка «оставлять двойное владение без срока» служит отрицательным тестом.
Точка окончательной передачи. В «контракт передачи работы между командами» фиксируют вход, решение и ожидаемый выход. Связь «точка окончательной передачи → границы ответственности» проверяют критерием «после передачи существует один владелец»; ошибка «передавать работу после завершения разработки» служит отрицательным тестом.
Минимальная версия «контракт передачи работы между командами» включает компоненты «передаваемый результат», «критерии приёмки» и «операционная поддержка». Остальное добавляют только при влиянии на решение по теме «передача работы между командами».
Порядок внедрения
Шаг 1: Определить принимающую сторону заранее. В «контракт передачи работы между командами» обновляют компонент «передаваемый результат». Результат подтверждает критерий «принимающая команда участвовала до передачи»; ограничение «аварийная передача требует последующего восстановления контекста» записывают рядом.
Шаг 2: Согласовать форму результата. В «контракт передачи работы между командами» обновляют компонент «границы ответственности». Результат подтверждает критерий «критерии приёмки наблюдаемы»; ограничение «регуляторная ответственность может оставаться у исходной стороны» записывают рядом.
Шаг 3: Провести совместную проверку. В «контракт передачи работы между командами» обновляют компонент «критерии приёмки». Результат подтверждает критерий «доступы проверены реальным действием»; ограничение «аутсорсинг задаёт договорные процедуры» записывают рядом.
Шаг 4: Передать знания и доступы. В «контракт передачи работы между командами» обновляют компонент «неразрешённые риски». Результат подтверждает критерий «риски названы явно»; ограничение «платформенная команда может владеть только частью контура» записывают рядом.
Шаг 5: Зафиксировать остаточные риски. В «контракт передачи работы между командами» обновляют компонент «операционная поддержка». Результат подтверждает критерий «период поддержки ограничен»; ограничение «большая миграция требует нескольких точек передачи» записывают рядом.
Шаг 6: Закрыть временную поддержку по критерию. В «контракт передачи работы между командами» обновляют компонент «точка окончательной передачи». Результат подтверждает критерий «после передачи существует один владелец»; ограничение «аварийная передача требует последующего восстановления контекста» записывают рядом.
После внедрения «контракт передачи работы между командами» проверяют на другом случае. Если решение неясно, «контракт передачи работы между командами» упрощают и проверяют повторно.
Практический пример
Продуктовая команда передала новый сервис платформенной эксплуатации вместе с архитектурной схемой, но без квот и сценария деградации. Контракт передачи добавил нагрузочную проверку, runbook, срок совместного дежурства и критерий завершения поддержки.
В примере «контракт передачи работы между командами» связывает «передаваемый результат» с действием «определить принимающую сторону заранее». Затем компонент «неразрешённые риски» проверяют шагом «передать знания и доступы» и критерием «риски названы явно».
Контрольный разбор темы «передача работы между командами» рассматривает ошибку «передавать работу после завершения разработки» и ограничение «аварийная передача требует последующего восстановления контекста». Если другой участник не может повторить проверку, артефакт «контракт передачи работы между командами» остаётся экспериментальным.
Типовые ошибки
-
Передавать работу после завершения разработки. В «контракт передачи работы между командами» страдает компонент «границы ответственности». Исправление начинают действием «провести совместную проверку» и проверяют на следующем рабочем случае.
-
Считать документ достаточной передачей. В «контракт передачи работы между командами» страдает компонент «критерии приёмки». Исправление начинают действием «передать знания и доступы» и проверяют на следующем рабочем случае.
-
Не включать принимающую команду в проверку. В «контракт передачи работы между командами» страдает компонент «неразрешённые риски». Исправление начинают действием «зафиксировать остаточные риски» и проверяют на следующем рабочем случае.
-
Скрывать временные обходные решения. В «контракт передачи работы между командами» страдает компонент «операционная поддержка». Исправление начинают действием «закрыть временную поддержку по критерию» и проверяют на следующем рабочем случае.
-
Оставлять двойное владение без срока. В «контракт передачи работы между командами» страдает компонент «точка окончательной передачи». Исправление начинают действием «определить принимающую сторону заранее» и проверяют на следующем рабочем случае.
В «контракт передачи работы между командами» одновременно исправляют две ошибки максимум. Затем «контракт передачи работы между командами» сравнивают с новым результатом.
Критерии качества
-
Принимающая команда участвовала до передачи. В «контракт передачи работы между командами» критерий проверяют после шага «определить принимающую сторону заранее» на компоненте «неразрешённые риски». Подтверждением служит наблюдаемый результат или журнал решения.
-
Критерии приёмки наблюдаемы. В «контракт передачи работы между командами» критерий проверяют после шага «согласовать форму результата» на компоненте «операционная поддержка». Подтверждением служит наблюдаемый результат или журнал решения.
-
Доступы проверены реальным действием. В «контракт передачи работы между командами» критерий проверяют после шага «провести совместную проверку» на компоненте «точка окончательной передачи». Подтверждением служит наблюдаемый результат или журнал решения.
-
Риски названы явно. В «контракт передачи работы между командами» критерий проверяют после шага «передать знания и доступы» на компоненте «передаваемый результат». Подтверждением служит наблюдаемый результат или журнал решения.
-
Период поддержки ограничен. В «контракт передачи работы между командами» критерий проверяют после шага «зафиксировать остаточные риски» на компоненте «границы ответственности». Подтверждением служит наблюдаемый результат или журнал решения.
-
После передачи существует один владелец. В «контракт передачи работы между командами» критерий проверяют после шага «закрыть временную поддержку по критерию» на компоненте «критерии приёмки». Подтверждением служит наблюдаемый результат или журнал решения.
Итоговая оценка «контракт передачи работы между командами» называет остаточный риск и событие будущего пересмотра. Ограничение «аутсорсинг задаёт договорные процедуры» остаётся видимым даже при выполнении критериев.
Ограничения применимости
-
Аварийная передача требует последующего восстановления контекста. Для компонента «передаваемый результат» в «контракт передачи работы между командами» требуется отдельная проверка. Перенос чужого вывода остаётся гипотезой.
-
Регуляторная ответственность может оставаться у исходной стороны. Для компонента «границы ответственности» в «контракт передачи работы между командами» требуется отдельная проверка. Перенос чужого вывода остаётся гипотезой.
-
Аутсорсинг задаёт договорные процедуры. Для компонента «критерии приёмки» в «контракт передачи работы между командами» требуется отдельная проверка. Перенос чужого вывода остаётся гипотезой.
-
Платформенная команда может владеть только частью контура. Для компонента «неразрешённые риски» в «контракт передачи работы между командами» требуется отдельная проверка. Перенос чужого вывода остаётся гипотезой.
-
Большая миграция требует нескольких точек передачи. Для компонента «операционная поддержка» в «контракт передачи работы между командами» необходима самостоятельная проверка. Перенос чужого вывода остаётся гипотезой.
Три ограничения требуют пересборки «контракт передачи работы между командами». Для темы «передача работы между командами» новый вопрос заменяет список исключений.
Практика пересмотра.
Команда сохраняет исходную версию «контракт передачи работы между командами», результат шага «согласовать форму результата» и решение по критерию «период поддержки ограничен». На следующем цикле «контракт передачи работы между командами» сравнивают с изменениями, отдельно отмечая ограничение «платформенная команда может владеть только частью контура».
Полезность «контракт передачи работы между командами» подтверждает новый участник. Он повторяет проверку «контракт передачи работы между командами» без устного контекста; для темы «передача работы между командами» это важнее объёма.
Вывод
Практику «передача работы между командами» начинают с «контракт передачи работы между командами» и действия «определить принимающую сторону заранее». Первый результат проверяют критерием «принимающая команда участвовала до передачи» и сопоставляют с ограничением «аварийная передача требует последующего восстановления контекста». Так решение, остаточный риск и пересмотр остаются прозрачными.
