Прототип, описание процесса и текст технического задания часто живут в разных местах. Ожидание заказчика вроде «в форме документа должно быть поле статуса и кнопка согласования» легко теряется между перепиской, версиями макета и задачами. Модуль «Требования» в MAKER-STUDIO закрывает этот разрыв. Он фиксирует ожидания и обязательства по проекту как отдельные карточки со статусами и связями - не как абзац в документе, а как управляемый реестр.
MAKER-STUDIO - онлайн-студия для прототипирования интерфейсов, моделирования бизнес-процессов, подготовки ТЗ, работы с канбан-доской, цифрового согласования и опросов заказчиков. Всё работает в браузере, без установки платформы 1С. «Требования» связывают то, что нужно сделать, с тем, где это показано и кто это делает.
Что такое «Требования»
Требование в студии - карточка учёта. В ней: краткая формулировка ожидания или обязательства, подробное описание, заявитель, статусы и связи с другими объектами проекта. Это не замена технического задания и не дублирование канбан-задачи. Это отдельный учёт: что должно быть сделано, кто это заявил, согласовано ли, исполнено ли, к какой форме и задаче привязано. В студии уже есть опросы, согласование, формы и прототипы, канбан. Без общего учёта ожиданий каждый инструмент работает сам по себе: опрос собрал ответы, макет показал экран, задача назначила исполнителя, согласование утвердило версию. Требование связывает это в одну цепочку: ожидание → утверждение → экран в прототипе → задача на реализацию.
Типичный сценарий: после опроса или совещания аналитик фиксирует пункт «в карточке контрагента нужна проверка ИНН перед записью». Дальше требование можно согласовать с заказчиком, связать с прототипом формы и поставить в работу через задачу на доске. Реестр остаётся актуальным на всём проекте. Он не «застывает» в PDF после первой выгрузки. То есть техническое задание фиксирует срез для передачи, а реестр требований помогает контролировать работу по ходу проектирования и реализации.
Для проектов внедрения и доработки 1С это особенно полезно. Заказчик мыслит бизнес-правилами и экранами. Команда - формами, процессами и задачами. Общий реестр снижает риск, что согласованное на демо ожидание растворится между версиями макета и бэклогом.
Устройство карточки требования
Создание требования - отдельная форма. Набор полей сразу задаёт структуру учёта.
Номер - автоидентификатор карточки (например, 00001). Выдаётся при открытии создания. По нему удобно ссылаться в обсуждениях и связях: проще сказать «по требованию 00001», чем цитировать длинную формулировку.
Название - краткое имя требования. Его видно в списках и при выборе связей. Оно должно быть понятным без чтения полного текста.
Описание - развёрнутая формулировка: что именно ожидается, при каких условиях, с какими ограничениями. Сюда уходит деталь, которую нельзя уместить в название.
Заявитель - кто инициировал требование. Можно указать вручную. Для типового случая есть кнопка «РП» - быстрая подстановка роли руководителя проекта.
Статус согласования - на каком этапе утверждение. По умолчанию стоит «Черновик»: карточка заведена, но ещё не согласована.
Статус исполнения - насколько продвинулась реализация. По умолчанию «Не начат».
Статусы согласования и исполнения независимы. Требование может быть уже согласовано, но ещё не начато. Или, наоборот, уже в работе, хотя согласование ещё не завершено - если так принято в команде. Разделение не смешивает «утвердили ли» и «сделали ли».
Связи → Формы - привязка к макету или форме проекта. Требование указывает на конкретный экран прототипа.
Связи → Задачи - привязка к задаче канбана. Становится видно, кто делает работу и в каком статусе задача.
Внизу формы - Отмена и Создать. Отмена закрывает создание без сохранения. «Создать» фиксирует карточку в реестре.
После создания требование живёт в реестре. Его можно уточнять, менять статусы и использовать как точку отсчёта при согласовании и постановке работ. Связи можно задать сразу или позже - когда появятся макет и задача.
Практический совет по формулировкам: название - «что / где», описание - «как должно работать и зачем». Так реестр читается и заказчиком, и исполнителем.
Связи с другими инструментами студии
Опросы. Ожидания заказчика собираются структурированно. Ответы и приоритеты удобно переносить в требования: из «хотелок» в формулировки с номером, заявителем и статусами. Подробнее о том, как генерировать опросы, писали здесь - //infostart.ru/pm/2732805/
Согласование. Цифровое утверждение в студии дополняет статус согласования требования. Реестр показывает, какие пункты уже на утверждении, а какие ещё черновики.
Формы и прототипы. Связь с формой привязывает ожидание к конкретному экрану. На демо проще показать: вот экран, вот требование к нему. Расхождения между «нарисовали» и «договорились» становятся заметнее раньше.
Канбан. Через требование создается задача на доске. Аналитик и РП видят не только текст ожидания, но и кто его исполняет. Программист получает понятный набор: требование + форма + задача.
Кроме того, требования доступны в API, т.е. могут быть получены через MCP-сервер, и все связанные с ним объекты. Про интеграцию MAKER-STUDIO с MCP-сервером мы подробно писали здесь - //infostart.ru/1c/articles/2739096/
Кому это полезно
Аналитик и внедренец фиксируют ожидания без потери контекста, ведут статусы, связывают пункты с макетами и задачами. Реестр становится рабочим инструментом сопровождения проекта, а не приложением к ТЗ «на потом».
Заказчик видит согласованные пункты рядом с прототипом: что утверждено, что ещё обсуждается. Проще сверять демо с договорённостями и возвращаться к конкретным номерам требований.
Руководитель проекта контролирует картину целиком: что заявлено, что утверждено, что в работе, что ещё не начато. Два независимых статуса помогают отдельно смотреть на согласование и на прогресс исполнения.
Программист получает задание в одном месте: формулировка требования, связанная форма и задача на доске. Меньше двусмысленности «сделайте как на скрине» без критериев. Меньше потери деталей между чатом и бэклогом.
Короткий вывод
«Требования» в MAKER-STUDIO - модуль учёта ожиданий и обязательств: карточки с номером, описанием, заявителем, двумя независимыми статусами и связями с формами и задачами. В отличие от сгенерированного ТЗ, это живой реестр на всём цикле проекта. Вместе с опросами, согласованием, прототипами и канбаном он собирает разрозненные договорённости в управляемую цепочку - от ожидания заказчика до реализации.