Библиотека · Markdown-файлы
Тринадцать рабочих шаблонов
На странице показаны назначение, обязательные поля и короткий пример каждого шаблона. Полные формы доступны отдельными Markdown-файлами. Кнопка копирования — дополнительное удобство: текст и ссылки работают и без JavaScript.
Паспорт цикла с ИИ
Назначение. Перед первым пилотом и при изменении границ, данных, действий или уровня самостоятельности.
Владелец. Владелец результата процесса.
Обязательные поля и пример
Обязательные поля
- Получатель и принятый результат.
- Сигнал, решение, действие, проверка и обучение.
- Исходные показатели и максимальный ущерб одной ошибки.
- Роли человека, обычной программы и ИИ; исключения.
- Резервный сценарий и дата решения после пилота.
Короткий пример
Владелец поддержки отвечает за принятый ответ клиенту. Сигнал — новое типовое обращение; ИИ на A1 готовит черновик, оператор сверяет источник и отправляет. Претензии и запросы на возврат всегда передаются старшему специалисту. Исходный уровень: 14 минут на принятый ответ; резерв — прежняя ручная очередь.
Карточка сценария применения
Назначение. При выборе, сравнении и пересмотре инвестиций в сценарии с ИИ.
Владелец. Предложивший сценарий вместе с владельцем результата.
Обязательные поля и пример
Обязательные поля
- Получатель, проблема, принятый результат, частота и объём.
- Исходный показатель и более простой механизм.
- Роль ИИ, данные, ожидаемая польза и полная стоимость.
- Цена ошибки, обратимость, гипотезы и условие остановки.
Короткий пример
Сценарий: классификация входящих заявок для оператора. Правила проверяют обязательные поля, а ИИ предлагает тему и маршрут. Ожидаемая польза — сократить время первичной сортировки с пяти до трёх минут; остановка — критическая ошибка маршрута в контрольной выборке.
Карта полномочий человека и ИИ
Назначение. До доступа к рабочей системе, при смене прав и при повышении уровня A0–A3.
Владелец. Владелец результата; владелец системы подтверждает фактические технические права.
Обязательные поля и пример
Обязательные поля
- Точное действие и его инициатор.
- Владелец результата, исполнитель, согласующий и проверяющий.
- Уровень A0–A3 и техническое право.
- Условие остановки, цена ошибки и резервный сценарий.
Короткий пример
ИИ на A2 создаёт запрос на слияние только в ветке задачи. Инициатор — разработчик, владелец результата — владелец компонента, проверяющий — автор изменения. Слияние запрещено технически; после трёх сбоев проверок система переходит на A1, а запрос создаёт разработчик вручную.
Реестр источников контекста
Назначение. До передачи внутренних данных в процесс, при подключении нового источника и при смене его условий.
Владелец. Владелец данных отвечает за смысл и доступность; владелец процесса подтверждает пригодность.
Обязательные поля и пример
Обязательные поля
- Название, происхождение и владелец источника.
- Разрешённое использование, чувствительность, свежесть и версия.
- Права доступа, способ отзыва и проверка конфликта или устаревания.
- Резервный источник или действие при недоступности.
Короткий пример
Каталог продукта принадлежит коммерческому директору и обновляется ежедневно. Его разрешено читать служебной роли только для подготовки предложения; при возрасте данных больше суток система не формирует цену и передаёт задачу оператору. Отзыв выполняется удалением роли доступа.
Навык агента
Назначение. Когда повторяемая процедура должна давать воспроизводимый результат у нескольких участников или запусков.
Владелец. Владелец навыка.
Обязательные поля и пример
Обязательные поля
- Назначение, условия применения и отказа.
- Вход, выход, ограничения и предел полномочий.
- Разрешённые инструменты и порядок действий.
- Обычный и пограничный примеры.
- Проверки результата, хода действий, расхода и регрессий.
- Версия, совместимость, отключение и журнал изменений.
Короткий пример
Навык «Описание изменения» принимает задачу, список изменённых файлов и фактические результаты проверок; выпускает черновик описания запроса на слияние. Он не утверждает риск и не выдумывает проверки. Разрешены только чтение журнала версии и результатов тестов; при отсутствии журнала навык останавливается и сообщает автору.
План проверок качества
Назначение. До пилота, выпуска, изменения существенной части системы и повышения полномочий.
Владелец. Владелец качества вместе с владельцем результата; независимый рецензент подтверждает существенный риск.
Обязательные поля и пример
Обязательные поля
- Решение, которое меняет проверка, и состав проверяемой системы.
- Обычные, пограничные, редкие и вредоносные случаи по сегментам.
- Отдельные проверки результата и хода действий.
- Детерминированные правила, человеческая выборка и калибровка второй модели при её использовании.
- Показатели, пороги предупреждения и остановки, резерв и решение по прогону.
Короткий пример
Проверка решает, можно ли оставить подготовку типовых ответов на A1. В контрольной выборке ни один критический факт не должен быть ошибочным, а каждая фактическая фраза должна ссылаться на допустимый источник. Отдельно журнал проверяется на отсутствие чтения чужих клиентских данных; при нарушении система переходит в ручную очередь.
Реестр рисков
Назначение. С первого производственного использования, при существенном изменении и после серьёзного инцидента.
Владелец. Владелец результата; владельцы мер подтверждают выполнение предотвращения, обнаружения и реакции.
Обязательные поля и пример
Обязательные поля
- Риск, причина, последствие и затронутые лица.
- Вероятность или неопределённость, тяжесть и остаточный риск.
- Предотвращение, обнаружение, реакция, владелец и дата пересмотра.
- Цена ошибки и резервный сценарий для существенного риска.
Короткий пример
Устаревшая цена может привести к неверному предложению клиенту. Предотвращение — не использовать источник старше суток; обнаружение — сверка цены перед отправкой; реакция — заблокировать отправку и вернуть заявку оператору. Владелец меры — коммерческий директор.
Договор о самостоятельности
Назначение. Перед разрешением A2 или A3, а также после инцидента, смены модели или ухудшения показателя.
Владелец. Владелец результата; владельцы безопасности и системы подтверждают ограничения и технические права.
Обязательные поля и пример
Обязательные поля
- Уровень A0–A3 и точные разрешённые действия в разрешённых системах.
- Владелец, служебная учётная запись, максимальный ущерб и обратимость.
- Права, лимиты времени, расходов, числа действий и объёма данных.
- Обязательные проверки, согласования, журнал и доказательства стабильной работы.
- Условия остановки или понижения, резерв и дата пересмотра.
Короткий пример
На A2 системе разрешено создать один запрос на слияние в ветке задачи за 20 минут; слияние и изменение защищённой ветки запрещены. Любая попытка такого изменения понижает действие до A1, отключает служебную роль и передаёт работу разработчику. Откат — закрыть запрос и восстановить ветку из сохранённой точки.
Описание изменения с ИИ
Назначение. Для изменения, подготовленного или существенно изменённого ИИ, перед независимой рецензией и выпуском.
Владелец. Автор изменения; владелец компонента отвечает за решение о выпуске.
Обязательные поля и пример
Обязательные поля
- Цель, спецификация, объём изменения и то, что намеренно не изменено.
- Результат для пользователя, затронутые данные и права, новые зависимости.
- Доказательства проверок и проверка отрисованного результата при наличии интерфейса.
- Риск, возможные точки поломки, откат и наблюдение после выпуска.
- Что подготовил ИИ и что независимо проверил человек.
Короткий пример
Изменение добавляет проверку свежести каталога перед подготовкой предложения. Автор приложил результат теста устаревшего источника и проверил экран с сообщением оператору. Риск — ошибочная блокировка типовой заявки; откат — отключить правило через конфигурацию; после выпуска наблюдается доля заблокированных заявок.
Инцидент → улучшение проверки
Назначение. После серьёзного или повторяющегося сбоя, а также после обнаружения обхода прав или ограничений.
Владелец. Владелец инцидента; изменение постоянной проверки, прав, контекста или процесса принимает владелец соответствующего актива.
Обязательные поля и пример
Обязательные поля
- Наблюдаемый ущерб, время обнаружения и ограничения.
- Версии системы, воспроизведение и последовательность внешних событий.
- Причина, содействующие условия и причина пропуска проверкой.
- Исправление, новая постоянная проверка, изменение актива, владелец и срок.
- Подтверждение после исправления и резервный сценарий на время работ.
Короткий пример
Система использовала каталог, не отмеченный как устаревший, и подготовила неверную цену. Воспроизведение использует сохранённый срез источника. Добавлены правило свежести, сигнал и контрольный случай; до выпуска исправления предложения готовит оператор. Владелец источника подтвердил ежедневное обновление.
Полная стоимость результата
Назначение. До пилота, при решении о продолжении, при смене объёма, поставщика или архитектуры процесса.
Владелец. Финансовый партнёр и владелец результата.
Обязательные поля и пример
Обязательные поля
- Принятый результат, количество и исходный процесс для сравнения.
- Модели, инфраструктура, инструменты, разработка, данные и сопровождение.
- Повторы, человеческая проверка, исправления, наблюдение, безопасность и резерв.
- Ожидаемая стоимость ошибки, допущения, неопределённость и решение.
Короткий пример
Условный пример: За месяц принято 700 ответов. Модели и сервисы стоили 40 000 рублей, инфраструктура и сопровождение — 60 000, проверка человеком — 180 000, повторы и исправления — 70 000. При общем расходе 350 000 рублей стоимость одного принятого ответа — 500 рублей; возможный ущерб от редкой критической ошибки считается отдельно.
План стартапа на 30 и 90 дней
Назначение. После выбора первого цикла, чтобы зафиксировать его пилот, ограниченную эксплуатацию и решение о втором сценарии.
Владелец. Основатель отвечает за инвестицию и остановку; владелец процесса ведёт действия и принятый результат.
Обязательные поля и пример
Обязательные поля
- Цель, исходный профиль и границы первого цикла.
- Действия на 30 и 90 дней с владельцем, артефактом и критерием завершения.
- Исходные показатели, уровень A0 или A1, проверки, права и резерв.
- Условия остановки, решение дня 30 и решение дня 90.
Короткий пример
К дню 10 владелец поддержки измеряет время и возвраты по ответам, к дню 20 эксперт собирает обычные и редкие случаи, к дню 30 основатель решает продолжить A1 или остановить пилот. К дню 60 команда испытывает ручную очередь как резерв, а к дню 90 выбирает второй сценарий только при подтверждённой повторяющейся потребности.
План зрелой компании на 30, 90 и 180 дней
Назначение. Когда нужно превратить разрозненные пилоты и существующие механизмы в один управляемый сквозной поток.
Владелец. Исполнительный куратор задаёт полномочия; владелец потока отвечает за результат; руководящий комитет принимает портфельные решения.
Обязательные поля и пример
Обязательные поля
- Цель, границы потока, исходный профиль и владелец.
- Действия на 30, 90 и 180 дней с владельцем, артефактом и критерием завершения.
- Инвентаризация сценариев, данных, прав, расходов и применимых требований.
- Проверки, служебные права, договор самостоятельности, резерв и портфельное решение.
- Условия остановки и события внепланового пересмотра.
Короткий пример
К дню 30 руководитель программы выявляет личные производственные права и назначает владельца одного клиентского потока. К дню 90 поток проходит ограниченный выпуск с отдельной учётной записью и испытанным резервом. К дню 180 второй поток повторно принимает библиотеку проверок, а комитет решает, нужен ли общий сервис.
Шаблон нужен, когда он помогает принять решение и сохранить доказательство. Заполненная форма без владельца и последующего действия создаёт архив, а не управление.
Ниже приведён минимальный комплект. Его можно расширять под отрасль, но обязательные поля лучше не удалять без записанного основания.
1. Паспорт цикла с ИИ #
Когда нужен: перед первым пилотом и при изменении границ.
Кто отвечает: владелец результата.
Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.
Короткий пример: система готовит ответ на A1; оператор проверяет источник и отправляет; редкие претензии всегда уходят старшему специалисту; резерв — прежняя очередь.
Критерий готовности: каждый шаг цикла имеет исполнителя, проверку и границу.
2. Карточка сценария применения #
Когда нужна: при выборе и сравнении инвестиций.
Кто отвечает: предложивший сценарий вместе с владельцем результата.
Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.
Короткий пример: частая классификация входящих заявок; обычные правила покрывают заполненность, ИИ предлагает тему; запись маршрута остаётся за оператором до проверки.
Критерий готовности: сценарий можно сравнить с другим по одинаковым полям, а гипотезы не выданы за факты.
3. Карта полномочий человека и ИИ #
Когда нужна: до доступа к рабочей системе и при повышении A.
Кто отвечает: владелец результата; владелец системы подтверждает фактические права.
Сокращённый пример формы. Полная форма с ценой ошибки, условием остановки и резервом — в Markdown.
Короткий пример: создать запрос на слияние | разработчик | владелец компонента | ИИ-система | A2 | не требуется | разработчик | только ветка задачи | три сбоя проверки.
Критерий готовности: организационная ответственность и техническое исполнение различимы; уровень назначен действию.
4. Реестр источников контекста #
Когда нужен: до передачи внутренних данных и при смене источника.
Кто отвечает: владелец данных; владелец процесса подтверждает пригодность.
Сокращённый пример формы. Полная форма с резервным сценарием на случай недоступности источника — в Markdown.
Короткий пример: каталог продукта; владелец — коммерческий директор; обновление ежедневно; только подготовка предложения; чтение служебной ролью; отключение через группу доступа.
Критерий готовности: для каждого значимого вывода можно найти источник, версию и право использования.
5. Навык агента #
Когда нужен: когда одна процедура повторилась и должна работать у нескольких участников.
Кто отвечает: владелец навыка.
Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.
Короткий пример: навык готовит описание изменения, но не утверждает риск; использует только журнал версии и результаты тестов; выдуманная проверка считается критической ошибкой.
Критерий готовности: маршрутизация, результат, ход, расход и регрессии проверены на закреплённой версии среды.
6. План проверок качества #
Когда нужен: до пилота, выпуска и повышения полномочий.
Кто отвечает: владелец качества вместе с владельцем результата.
Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.
Короткий пример: разрешить A1 для типовых обращений, если ни один критический факт не ошибочен в контрольной выборке и каждая фактическая фраза имеет допустимый источник.
Критерий готовности: набор воспроизводим, пороги заданы заранее, решение следует из результата.
7. Реестр рисков #
Когда нужен: с первого производственного использования и при существенном изменении.
Кто отвечает: владелец результата; владельцы мер подтверждают выполнение.
Сокращённый пример формы. Полная форма с ценой ошибки, реакцией и резервом — в Markdown.
Короткий пример: устаревшая цена приводит к неверному предложению; предотвращение — источник не старше суток; обнаружение — сверка расчёта; реакция — блокировка отправки.
Критерий готовности: каждый существенный риск имеет предотвращение, обнаружение, реакцию и владельца.
8. Договор о самостоятельности #
Когда нужен: перед A2 и A3, а также после инцидента или смены модели.
Кто отвечает: владелец результата; владельцы безопасности и системы подтверждают ограничения.
Сокращённый пример формы. Полная форма с областью данных, техническими правами, лимитами и резервным режимом — в Markdown.
Короткий пример: A2 разрешает создать запрос на слияние только в ветке задачи; запрещает слияние; предел — один запрос и 20 минут; остановка — любая попытка изменить защищённую ветку.
Критерий готовности: технические права соответствуют тексту, а остановка и откат испытаны.
9. Описание изменения с ИИ #
Когда нужно: для изменения, подготовленного или существенно изменённого ИИ.
Кто отвечает: автор изменения.
Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.
Короткий пример: ИИ подготовил сводку и код; автор сверил список файлов, результаты тестов и риск; выпуск ограничен десятью процентами внутреннего трафика.
Критерий готовности: каждое заявленное доказательство существует, риск и откат понятны независимому рецензенту.
10. Инцидент → улучшение проверки #
Когда нужен: после серьёзного или повторяющегося сбоя.
Кто отвечает: владелец инцидента; постоянное улучшение принимает владелец соответствующего актива.
Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.
Короткий пример: устаревший источник не был отмечен; добавлены правило свежести, сигнал и контрольный случай; владелец источника подтвердил обновление.
Критерий готовности: сбой воспроизводится до исправления и не воспроизводится после; выбранный механизм закрывает причину.
11. Полная стоимость результата #
Когда нужна: до пилота, при решении о продолжении и при существенном изменении объёма или поставщика.
Кто отвечает: финансовый партнёр и владелец результата.
Сокращённый пример формы. Полная форма со всеми обязательными полями — в Markdown.
Короткий пример: 350 000 рублей расходов и 700 принятых результатов дают 500 рублей на результат; это условный пример из главы 9, а не отраслевой ориентир.
Критерий готовности: показатель пересчитывается из указанных данных, допущения видны, сравнение использует ту же единицу.
12. План стартапа на 30 и 90 дней #
Когда нужен: после выбора первого цикла, чтобы зафиксировать пилот, ограниченную эксплуатацию и решение о втором сценарии.
Кто отвечает: основатель отвечает за инвестицию и остановку; владелец процесса — за действия команды и принятый результат.
Сокращённый пример формы. Полная форма с этапами, резервом и решениями дня 30 и дня 90 — в Markdown.
Короткий пример: к дню 30 команда измеряет и ограничивает первый цикл; к дню 90 решает, переносить ли подтверждённый механизм во второй сценарий.
Критерий готовности: каждый срок заканчивается проверяемым артефактом и решением; цикл либо работает с известными стоимостью и риском, либо закрыт с сохранёнными знаниями.
13. План зрелой компании на 30, 90 и 180 дней #
Когда нужен: когда разрозненные пилоты и действующие механизмы нужно собрать в один управляемый сквозной поток.
Кто отвечает: исполнительный куратор задаёт полномочия; владелец потока отвечает за результат; руководящий комитет принимает портфельные решения.
Сокращённый пример формы. Полная форма с этапами, повторной приёмкой, резервом и тремя решениями — в Markdown.
Короткий пример: к дню 30 компания выбирает поток и ограничивает права; к дню 90 проводит ограниченный выпуск; к дню 180 проверяет общий компонент во втором потоке и решает, масштабировать ли его.
Критерий готовности: каждый горизонт завершается наблюдаемым решением; переносимый компонент отдельно принят вторым потребителем.
Короткий глоссарий #
- AI-native компания
- авторский термин для организации, где ИИ встроен в управляемый цикл операционной модели.
- Агент
- модель вместе со средой, состоянием, инструментами, обратной связью и ограничениями.
- Принятый результат
- выход процесса, который прошёл согласованный критерий и принят получателем.
- Постоянный контекст
- общие правила, архитектура, стандарты и ограничения.
- Оперативный контекст
- данные и история текущей задачи.
- Навык агента
- версионируемый набор инструкций, примеров и материалов для повторяемой задачи.
- Среда исполнения
- состав моделей, инструкций, навыков, инструментов, порядка выполнения и изоляции.
- Контур управления
- учётные записи, права, согласования, политики, секреты и журнал действий.
- Проверка хода действий
- проверка использованных источников, инструментов, прав, шагов и согласований.
- Полная стоимость результата
- все расходы и ожидаемый ущерб, разделённые на число принятых результатов.
- Резервный сценарий
- заранее испытанный способ продолжить или безопасно остановить процесс при отказе.
Следующий шаг #
Не заполняйте весь комплект сразу.
- Назовите один процесс.
- Заполните карточку сценария и паспорт цикла.
- Измерьте исходный уровень.
- Проведите карту зрелости.
- Закройте один блокирующий разрыв.
- Составьте план проверок.
- Запустите ограниченную серию на A0 или A1.
- Через заранее заданный срок примите решение.
Если вы не можете назвать владельца, принятый результат или условие остановки, не переходите к выбору модели.
Рабочая карточка главы #
Решение
Выбрать минимальный набор форм для ближайшего решения и отказаться от документов без владельца.
Минимальный механизм
Карточка сценария, паспорт цикла, карта зрелости, план проверок и календарный план. Остальные формы добавляются по правам, риску и масштабу.
Ответственный
Владелец процесса ведёт комплект. Каждый профильный владелец подтверждает свой раздел.
Артефакт
Связанный набор версионируемых форм с единым названием процесса и ссылками друг на друга.
Критерий готовности
По комплекту можно восстановить решение, исполнителя, доказательство, риск и следующий момент проверки.
Различия маршрутов
Стартап хранит короткие формы рядом с рабочим процессом. Зрелая компания связывает их с системами управления документами и контролем доступа. Одинаковая структура облегчает сравнение, но объём доказательств соответствует риску.
Показатели результата
- время от идеи до решения;
- доля форм, использованных в реальном обзоре;
- доля решений со ссылкой на доказательство;
- время обновления после события;
- повторное использование без потери смысла.
Показатели риска
- формы без владельца;
- противоречащие версии;
- пустые обязательные поля;
- секреты и лишние персональные данные;
- планы без критериев завершения;
- права без договора.
Типичные ошибки
- заполнять все формы ради полноты;
- копировать пример как факт;
- хранить доказательство только в переписке;
- допускать разные названия одного процесса;
- не обновлять связанные артефакты после смены границы;
- считать подпись доказательством работающего механизма.
Чек-лист · сохраняется в браузере