# От брифа до передачи проекта Шесть этапов цифрового проекта: исходные материалы, задачи помощника, решения заказчика, документы и примеры заполнения. Раздел для заказчиков, участников проекта и ИИ-помощников. Этапы и комплект согласуются под задачу; это не обязательный пакет. - Начните с нужного этапа. Если задача ещё не оформлена, достаточно первого. Не требуется собирать весь комплект до обращения. - Для каждого важного сведения укажите источник и дату. Разделяйте подтверждённое, предположение и открытый вопрос. Неизвестные бюджет, сроки, аудиторию и показатели не заполняйте догадками. - В документе указывайте статус: черновик, на согласовании или согласовано; автора, проверяющего, версию и дату. Наличие текста не означает согласования. - Помощник может собрать материалы и подготовить варианты. Выбор концепции, объём, стоимость, сроки, публикацию, доступы и юридические условия подтверждают уполномоченные люди. - Ссылку на документ передавайте вместо секретов. Не включайте пароли, токены, чужие персональные данные и закрытые материалы в публичный пример. Заказчик определяет допустимые сведения и способ передачи. [Паспорт для заполнения](template.md) · [Заполнить на странице](https://keiss.ru/resources/project-workflow/#worksheet) ## Материалы и бриф Какую задачу бизнеса предстоит решить? ### На входе Разговор, письмо, голосовые заметки, описание продукта, предыдущие кампании, материалы бренда. Укажите, чего пока нет и кто может это предоставить. ### Работа помощника Соберите факты в короткий бриф. Сопоставьте пожелания участников, выделите противоречия и запишите вопросы. Сохраните ссылки на исходные материалы, а не выдавайте пересказ за подтверждённый факт. ### Решение людей Заказчик подтверждает цель, ограничения и круг согласующих. Ответственный за проект уточняет границы первого этапа и то, какие сведения нужны до выбора решения. ### Когда идти дальше Есть понятная задача, желаемое действие аудитории, известные ограничения и список неизвестного. Если сведений не хватает, следующий результат — вопросы или исследование, а не придуманная концепция. ### Результат Бриф, перечень материалов, реестр открытых вопросов и ближайшее решение. ### Документы - [Бриф: заполнить на странице](https://keiss.ru/resources/brief/#worksheet) - [Пустой бриф (.md)](https://keiss.ru/resources/brief/template.md) - [Учебный пример](examples/brief.md) ### Пример заполнения **Статус:** Учебный черновик. Вымышленный проект, не заказ и не согласованный план. **Задача:** Познакомить совершеннолетнюю аудиторию с линейкой «Заряд» через цифровой проект. **Продукт по условию:** Три цитрусовых вкуса: апельсин, лайм, грейпфрут. Банка с графикой батарейки. Эти сведения заданы для примера, не подтверждают существование товара. **Действие аудитории:** Рассмотреть вкусы и попробовать короткую игру. Это предложенная цель; пригодность формата нужно проверить. **Материалы:** Учебные изображения упаковки и палитра трёх вкусов. Исследование аудитории, медиаплан и требования площадок отсутствуют. **Открытые вопросы:** Срок запуска, бюджет, каналы, измерение результата, согласующие и ограничения бренда. Ни один из этих пунктов не считается согласованным. **Первое решение:** Уточнить цель и ограничения с заказчиком; после этого сравнить варианты участия. ## Идея и концепция Почему выбранная идея подходит задаче и бренду? ### На входе Бриф, подтверждённые сведения об аудитории, правила бренда, материалы прошлых кампаний, доступные каналы и ограничения. ### Работа помощника Подготовьте несколько различающихся решений, а не только разные оформления. Для каждого объясните связь с задачей, участие человека, необходимые материалы, ограничения и способ проверки. Соберите референсы с источниками и пометками о правах. ### Решение людей Заказчик выбирает вариант и утверждает ключевое сообщение и характер визуального решения. Команда проверяет реализуемость и допустимость применения материалов. Несогласие участников фиксируется явно. ### Когда идти дальше Записано, какой вариант выбран, кем и когда. Понятно, что будет проверено прототипом и какие вопросы ещё могут изменить решение. Визуальные наброски не выдаются за готовые макеты. ### Результат Концепция, объяснение выбора, референсы, палитра, эскизы и задание на прототип. ### Документы - [Концепция: заполнить на странице](https://keiss.ru/resources/concept/#worksheet) - [Пустая концепция (.md)](https://keiss.ru/resources/concept/template.md) - [Учебный пример](examples/concept.md) ### Пример заполнения **Статус:** Учебный вариант для обсуждения; выбора заказчика нет. **Предложенная идея:** «Собери свой заряд»: выбрать цитрусовый вкус, сыграть короткую партию «три в ряд», увидеть итог и карточку напитка. **Визуальное решение:** Белая питьевая банка; плюс, минус и сегменты заряда как графика батарейки. Апельсин — оранжевый, лайм — зелёный, грейпфрут — коралловый. Форма и подпись плода дополняют цвет. **Сообщение:** «Свежий вкус. Твой заряд.» — рабочая рекламная формулировка, не заявление о физиологическом действии. **Вариант для сравнения:** Неигровой выбор вкуса с короткой интерактивной историей. Он может оказаться уместнее, если аудитория не готова играть. **Что проверить:** Понимает ли человек механику и связь с продуктом; не мешает ли игра знакомству со вкусами; узнаваемы ли три вкуса без объяснения автора. **Ограничения:** Нет обещания роста продаж, физических наград или полезного действия напитка. Правила кампании и допустимые сообщения ещё требуют проверки. ## Сценарий и прототип Что человек делает и что происходит после каждого действия? ### На входе Выбранная концепция, сведения об устройствах и каналах, предполагаемое целевое действие, ограничения доступности и данных. ### Работа помощника Опишите пользователя, его цель и последовательность экранов. Для каждого шага задайте действие, ответ интерфейса, ошибку и восстановление. Составьте пользовательские истории и проверяемые критерии. Для схемы переходов используйте те же идентификаторы экранов, что и в требованиях. ### Решение людей Заказчик подтверждает путь и результат участия. Дизайнер и разработчик проверяют управление, состояния, реалистичность прототипа и технические ограничения. Сам прототип должен быть просмотрен, а не только описан. ### Когда идти дальше Можно пройти основной путь и восстановиться после ошибки; есть начало, понятные правила, результат и следующее действие. Неописанные состояния вынесены в вопросы, а не пропущены. ### Результат Сценарий, схема переходов, пользовательские истории, перечень экранов, прототип и критерии проверки. ### Документы - [Требования и критерии: заполнить](https://keiss.ru/resources/requirements/#worksheet) - [Пустая заготовка](templates/scenario.md) - [Учебный пример](examples/scenario.md) ### Пример заполнения **Статус:** Учебный сценарий. Иллюстрации не являются работающей игрой. **Пользователь и цель:** Совершеннолетний посетитель хочет быстро понять варианты вкуса и попробовать механику. Это гипотеза примера, не результат исследования. **Экраны:** S01: продукт и три вкуса → S02: правила → S03: игровое поле → S04: итог и карточка вкуса. Из S04 доступны повтор партии и возврат к вкусам. **Ход:** Обменять два соседних элемента. Комбинация из трёх одинаковых цитрусовых исчезает, шкала увеличивается. Правила неуспешного обмена и пересчёт ходов нужно согласовать отдельно. **История и критерий:** Посетитель хочет понять результат хода. Проверяем: после допустимой комбинации видны изменившееся поле, значение счёта и оставшиеся ходы. Цвет сопровождается формой и числом. **Неудачные состояния:** Нет допустимого хода: подсказка или пересборка по согласованному правилу. Перезагрузка: заранее решить, сохраняется ли партия. Недоступен сервис: понятное сообщение без потери выбранного вкуса, если это предусмотрено требованиями. **Прототип:** Ссылки на работающий прототип нет. Следующий шаг — сделать и проверить его, а не пометить этап готовым. ## План и требования Что делаем, кто отвечает и от чего зависит запуск? ### На входе Согласованная концепция и сценарий, оценки исполнителей, календарь кампании, требования к данным и интеграциям. ### Работа помощника Сведите объём, исключения, этапы, владельцев решений и зависимости. Для интеграций опишите данные, направление обмена, ошибки и владельца системы; неизвестные API не придумывайте. Изменения оформляйте отдельной записью с влиянием на сроки и стоимость. ### Решение людей Уполномоченные участники подтверждают объём, оценку, даты и критерии приёмки. Владельцы систем согласуют интерфейсы и доступы. Договор, права и обработку данных проверяют соответствующие специалисты. ### Когда идти дальше Каждая работа имеет результат, ответственного и проверку; внешние зависимости названы. Дата рекламы не подменяет подтверждённую готовность проекта. Неподтверждённые оценки помечены как предварительные. ### Результат Требования, календарь с зависимостями, ответственность, критерии приёмки и порядок изменения объёма. ### Документы - [Требования: шаблон](https://keiss.ru/resources/requirements/template.md) - [Изменение объёма: заполнить](https://keiss.ru/resources/change/#worksheet) - [Пустая заготовка](templates/plan.md) - [Учебный пример](examples/plan.md) ### Пример заполнения **Статус:** Учебный план без согласованных сроков и стоимости. **Объём:** Посадочная страница, выбор одного из трёх вкусов, игровая механика и итог. Физические призы, личный кабинет и продажи не включены по условию примера. **Зависимости:** Упаковка и тексты → прототип → макеты и правила → разработка → проверка → решение о запуске. Календарные даты не назначены. **Кампания:** Рекламный трафик направляется только на принятую рабочую версию. Даты размещений и выпуска продукта пока неизвестны. **Интеграция:** Внешняя CRM не подтверждена. Идентификатор участника и контакты не собираем по условию примера. Если интеграция понадобится, её состав и оценка согласуются отдельно. **Приёмка:** Выбор вкуса работает, допустимый ход обрабатывается по правилам, итог доступен, путь проверен на согласованных устройствах. Полный список критериев готовится вместе с требованиями. **Изменение:** Появление регистрации или конкурса — отдельное изменение с оценкой, ответственными и проверкой правил; не добавляется молча. ## Разработка и проверка Что действительно проверено и что ещё мешает запуску? ### На входе Версия для проверки, согласованные требования, перечень устройств, доступная тестовая среда и критерии приёмки. ### Работа помощника Подготовьте проверки, сопоставленные требованиям. Запишите действия, ожидаемый и фактический результат, устройство, версию и доказательство. Если проверку выполнить нельзя, укажите это; не заменяйте фактический результат ожидаемым. ### Решение людей Исполнитель проверяет исправления, ответственный за качество оценивает результаты, заказчик принимает результат по согласованным условиям. Помощник не объявляет безопасность, доступность и готовность подтверждёнными без соответствующих проверок. ### Когда идти дальше У критических требований есть результаты проверки. Известные дефекты и непроверенные области перечислены; решение о допустимости остаточных проблем принято явно. ### Результат Протокол проверок, список дефектов и ограничений, повторная проверка исправлений, решение о готовности. ### Документы - [Изменение и замечания: шаблон](https://keiss.ru/resources/change/template.md) - [Пустая заготовка](templates/qa.md) - [Учебный пример](examples/qa.md) ### Пример заполнения **Статус:** Учебная заготовка протокола. Никакие проверки игры ещё не выполнены. **Версия и среда:** Адрес работающей игры отсутствует. Устройства и проверяющий не назначены. **T01: выбор вкуса:** Ожидание: выбранный вкус и карточка продукта согласованы на всех экранах. Фактический результат: не проверено. **T02: комбинация:** Ожидание: допустимый ход изменяет поле, счёт и шкалу согласно правилам. Фактический результат: не проверено. **T03: завершение:** Ожидание: после окончания ходов доступен итог, повтор и возврат к продукту. Фактический результат: не проверено. **T04: управление:** Ожидание: подсказки, фокус, клавиатура и различение вкусов не зависят только от цвета. Фактический результат: не проверено. **Решение:** До появления работающей версии и протокола запуск не считается подтверждённым. ## Запуск и передача Сможет ли заказчик управлять проектом после передачи? ### На входе Принятая версия, перечень исходников, владельцы домена и размещения, зависимости и согласованные условия поддержки. ### Работа помощника Соберите опись файлов, инструкцию сборки и размещения, карту ресурсов и владельцев, список лицензий и ограничений. Секреты передаются отдельно в согласованном защищённом порядке. Подготовьте проверку передачи с получающей стороной. ### Решение людей Заказчик и исполнитель подтверждают комплект и фактический доступ. Юридические условия использования и передачи прав утверждаются отдельно; опись файлов не заменяет договор и не доказывает наличие исключительных прав. ### Когда идти дальше Получающая команда может найти материалы, собрать и разместить проект по инструкции. Владелец каждого ресурса известен; поддержка, обращения, резервирование и завершение обслуживания согласованы. ### Результат Комплект передачи, инструкция, реестр ресурсов и лицензий, подтверждение получения и условия дальнейшей поддержки. ### Документы - [Передача: заполнить](https://keiss.ru/resources/handover/#worksheet) - [Передача: пустой шаблон](https://keiss.ru/resources/handover/template.md) - [Хостинг и поддержка: заполнить](https://keiss.ru/resources/hosting/#worksheet) - [Учебный пример](examples/handover.md) ### Пример заполнения **Статус:** Учебная опись будущей передачи, не акт выполненных работ. **Материалы:** Исходники игры и страницы, макеты, тексты, изображения трёх вкусов и правила. Для каждого файла — версия и место хранения; сейчас не предоставлены. **Размещение:** Домен, аккаунт размещения, оплата, владельцы и процедура восстановления ещё не определены. **Права:** Проверить основания использования шрифтов, графики, музыки, кода и упаковки. Объём передаваемых прав определяется соглашением, а не этой описью. **Проверка получения:** Получатель должен подтвердить открытие материалов и воспроизвести сборку по инструкции; проверка ещё не проводилась. **Поддержка:** Контакты ответственных, срок, часы обслуживания, перечень работ и условия окончания поддержки согласуются до запуска. **Секреты:** Пароли и ключи в учебный документ не входят. Передача — отдельно уполномоченному получателю. ## Источники и адаптация Материал Keiss Media: рабочий маршрут и учебные примеры. Повторно используются существующие бриф, концепция, требования, изменение объёма, передача и размещение из библиотеки. Их источники и условия использования указаны на соответствующих страницах. Новые заготовки сценария, плана и проверки связывают эти материалы; это не официальный стандарт и не договор. Пользовательские истории и критерии сверены с GOV.UK Service Manual; разделение цели и гипотезы — с 18F Methods. Тексты примеров написаны для вымышленного «Заряда». - [GOV.UK: пользовательские истории и критерии](https://www.gov.uk/service-manual/agile-delivery/writing-user-stories) - [18F: гипотеза проектного решения](https://raw.githubusercontent.com/18F/methods/main/_methods/design-hypothesis.md) Версия 1.0 · 24 октября 2026.