Чат-спецификация вместо ТЗ: готовый шаблон сообщения с контекстом, ролями, сущностями, событиями и блоком «не делаем», плюс пример для сервиса заявок.
Обычное ТЗ легко разрастается до 20 страниц: много текста, общие формулировки и вечное «потом уточним». В итоге каждый читает его по-своему: заказчик думает про удобство, разработчик - про данные и ограничения, менеджер - про сроки.
Боль в другом: ТЗ часто не отвечает на вопросы, без которых прототип не собрать. Кто именно будет пользоваться системой? Какие данные храним? Что считается «готово»? Что происходит при ошибке, дубликате, пустом поле, отмене? Пока это не зафиксировано, работа буксует не из-за кода, а из-за угадывания.
Чат-спецификация помогает тем, что фиксирует минимальный набор опорных деталей, которые сразу превращаются в экраны и логику. Сообщение должно быть «исполняемым»: после него понятно, что делаем в первой версии, а что сознательно откладываем.
Обычно хватает пяти блоков: контекст и границы, роли и права, сущности и поля, события и правила, а также «не делаем».
Чат-спецификация - это одно заранее собранное сообщение, которое описывает задачу так, чтобы по нему можно было сразу собрать прототип. По сути, это мини-документ, но написанный человеческим языком и адаптированный под работу в чате, где система может задать 2-3 уточняющих вопроса и начать делать.
В отличие от «переписки без структуры», здесь сразу заданы рамки и порядок: контекст, роли, сущности, правила. Поэтому команда не тратит время на догадки и не размазывает решение по сотне сообщений.
На выходе вы ожидаете не абстрактное «поняли», а понятные артефакты: наброски экранов, роли и доступы, сущности и поля, ключевые события и правила, плюс главный пользовательский маршрут.
Формат хуже подходит, если есть жесткие регуляторные требования, много юридических нюансов, сложные интеграции с десятком систем или согласование между несколькими отделами. В таких случаях чат-спецификация все равно полезна как старт, но рядом нужен отдельный документ с деталями, рисками и критериями приемки.
Чтобы сообщение действительно превращалось в прототип, нужна простая дисциплина.
Первое: одна цель - одно сообщение. Если вы одновременно описываете сервис заявок, личный кабинет и CRM, получится каша. Лучше два отдельных сообщения и два прототипа.
Второе: пишите простыми словами и показывайте смысл на примере. Вместо «обеспечить эффективное управление обращениями» - «менеджер видит новые заявки, берет в работу, ставит статус и пишет комментарий». Один короткий сценарий сильно помогает: «клиент отправил заявку, менеджер уточнил, клиент получил ответ».
Третье: фиксируйте допущения и прямо просите вопросы. Это экономит итерации: вы заранее обозначаете, где не уверены, и приглашаете уточнить.
Удобная «шапка» для начала сообщения:
И еще один обязательный пункт: договоритесь о терминах. Один раз решите, как вы называете «заявку», «пользователя», «оператора», какие статусы бывают. Если сегодня это «обращение», завтра «тикет», а статус «новая» иногда означает «на рассмотрении», прототип будет постоянно расходиться с ожиданиями.
Начните с контекста. Один абзац про то, что вы делаете и зачем, снимает половину вопросов: какую проблему решаем, какой результат считаем успешным, где заканчивается первая версия.
Пользователей описывайте не абстрактно, а в ситуации: кто они, когда открывают сервис, что хотят сделать за 1-2 минуты. Так проще выбрать правильный минимум функций.
Дальше зафиксируйте платформы: нужна только веб-версия, мобильный интерфейс, отдельная админка? Лучше написать прямо, чем получить прототип, который не подходит по формату.
И сразу обозначьте ограничения: сроки, запрет на интеграции, уровень простоты, все, что «точно нельзя трогать». Это не «плохие новости», а защита от расползания.
Короткий шаблон:
Пример: «Нужен простой веб-сервис заявок для офиса, чтобы сотрудники оставляли запрос (ремонт, доступ, закупка), а ответственный быстро брал в работу. Пользователи: сотрудники с телефона или ПК в течение рабочего дня, цель - отправить заявку за минуту. Делаем: веб + простая страница админа. v1 за 1 неделю, без интеграций с почтой/1С, без аналитики и автоматических уведомлений».
Роли лучше описывать не «как в компании принято», а как ответы на четыре вопроса: кто заходит, что видит, что может сделать, что ему нельзя.
Для простого сервиса часто хватает трех ролей: Заявитель, Оператор, Администратор. Если ролей больше, добавляйте только тех, у кого реально отличаются действия или доступ к данным.
Права удобно фиксировать в формате «может/не может»:
Отдельно пропишите видимость данных. Например: заявитель видит только свои заявки и только публичные комментарии; оператор видит все заявки или только своего отдела; администратор видит все, включая историю изменений.
И обязательно задайте дефолт: если роль не указана или пользователь не авторизован, какие права у него будут.
Опишите, из каких объектов состоит система. Думайте не про экраны, а про данные: что мы храним и как это связано.
Обычно достаточно 3-5 сущностей. Для сервиса заявок базовый набор:
Дальше перечислите поля и отметьте обязательные. Пример: у Заявки обязательные id, title, created_at, author_id, status; необязательные description, assignee_id, due_date. У Комментария обязательные id, ticket_id, author_id, text, created_at.
Связи лучше писать простыми фразами: один Пользователь создает много Заявок; у одной Заявки много Комментариев; Вложение относится либо к заявке, либо к комментарию (укажите правило).
Зафиксируйте значения и смысл, чтобы прототип не спорил сам с собой:
Этот блок превращает «набор экранов» в работающую логику: какие действия меняют состояние, что происходит со статусами, кому что разрешено, как ведем себя при ошибках.
События удобнее описывать короткими карточками: триггер, условия, изменение данных, результат. Для сервиса заявок обычно достаточно: создание заявки, назначение исполнителя, закрытие, комментарий/уточнение, изменение приоритета.
Сразу задайте переходы статусов и запреты. Пример: Новая -> В работе -> Решена -> Закрыта, а переход Новая -> Закрыта запрещен.
Если нужны уведомления, пишите конкретно: кому и когда. И отдельно опишите реакции на ошибки:
Здесь важна конкретика: какие страницы нужны в первой версии, что человек видит на каждой, какие действия доступны. Дизайн и пиксели не нужны.
Хороший формат на экран: цель, что показываем, какие кнопки.
Пример для сервиса заявок:
На старте оставьте минимум по поиску и фильтрам: поиск по теме или номеру и 1-2 фильтра по статусу.
Этот блок защищает от разрастания задачи. Прототип не обязан закрывать все реальные случаи. Он должен проверить идею и логику.
Сформулируйте «не делаем» как явные запреты. Для первой версии часто подходит такой набор:
И добавьте критерии готовности прототипа, чтобы не спорить:
Почти всегда срабатывает одна и та же последовательность.
Пример фразы, которая задает тон: «Делаем простой сервис заявок: сотрудник создает заявку, оператор назначает исполнителя, исполнитель меняет статус и оставляет комментарий. В первой версии без уведомлений и интеграций».
Ниже пример сообщения, которое можно отправить в платформу, чтобы получить первый прототип.
Сделай прототип внутреннего сервиса заявок для компании (веб). Цель: сотрудник быстро пишет проблему, оператор обрабатывает, админ управляет справочниками.
1) Контекст и границы
- Это внутренний сервис поддержки для сотрудников.
- Один офис/организация, без внешних клиентов.
- В первой версии важнее простота, чем красота.
2) Роли и права
- Сотрудник: создает заявки, видит только свои, добавляет комментарии, закрывать не может.
- Оператор: видит все заявки, берет в работу, меняет статус, запрашивает уточнение, закрывает.
- Администратор: все права оператора + управляет категориями и пользователями.
3) Сущности и поля
- Пользователь: id, ФИО, email/логин, роль, активен.
- Категория: id, название, активна.
- Заявка: id, тема, описание, категория_id, автор_id, исполнитель_id (опц.), статус (Новая/В работе/Нужно уточнение/Закрыта), приоритет (Низкий/Обычный/Высокий), created_at, updated_at.
- Комментарий: id, заявка_id, автор_id, текст, created_at.
4) События и правила
- Создать заявку: статус=Новая.
- Взять в работу: только оператор/админ, назначается исполнитель, статус=В работе.
- Запросить уточнение: статус=Нужно уточнение, сотрудник получает уведомление внутри приложения.
- Закрыть: только оператор/админ, статус=Закрыта.
5) Не делаем (первая версия)
- Нет SLA, автоэскалаций и интеграций (почта/мессенджеры/1С).
- Нет сложных отчетов и дашбордов.
- Нет поддержки внешних клиентов и публичной формы.
Собери 3-4 экрана: список заявок (по роли), создание заявки, карточка заявки с комментариями, админка категорий/пользователей.
После первого прототипа добавьте 2-3 уточнения (например, фильтры по статусу и поиск) и пересоберите версию.
Проверьте три вещи.
Термины: у каждого важного слова одно значение. Если написано «заявка», должно быть ясно, что это именно.
Роли и права: описаны действиями и запретами, а не словами «имеет доступ». Должно быть понятно, кто что видит и что не может сделать.
Логика: есть статусы, переходы и правила. Если есть запреты, они явные. И есть «не делаем» для v1.
Если в тексте одновременно «и заявки, и склад, и личный кабинет партнера», система начнет угадывать приоритеты.
Исправление: оставьте один продукт и один сценарий v1. Остальное вынесите в отдельные сообщения как следующий этап.
Список страниц не говорит, что происходит с объектом. В итоге получаются формы без логики.
Исправление: добавьте статусы, переходы и условия. Например: «Новая -> В работе (когда назначен исполнитель) -> Закрыта (когда заполнен результат)», плюс запрет «нельзя закрыть без комментария».
Если границы не заданы, в прототип автоматически попадают уведомления, отчеты, интеграции и сложные роли.
Исправление: явно перечислите, что не входит в первую версию: без интеграций и импорта, без платежей, без сложных отчетов, без многоуровневых ролей.
Фразы вроде «удобно», «современно», «как везде» не переводятся в решения.
Исправление: замените оценку на проверяемое правило. Было: «удобный поиск». Стало: «поиск по номеру заявки и по телефону заявителя, результаты за последние 90 дней».
Без примера трудно понять, что хранить: «контакт» - это ФИО? телефон? email?
Исправление: добавьте 2-3 строки примеров прямо в сообщении. Например: «Заявка: № A-1042, тема: "Не работает домофон", адрес: "Казань, Ленина 10-15", телефон: "+7 999 123-45-67", желаемое время: "после 18:00"».
После того как сообщение собрано, не пытайтесь сразу дописать «все детали». Отправьте основу и дождитесь коротких уточняющих вопросов. Хороший признак - вопросов мало, и они про спорные места: права, статусы, исключения.
Дальше помогает простой цикл:
Если вы делаете прототипирование через чат, полезно выбирать инструмент, где можно фиксировать версии. Например, в TakProsto (takprosto.ai) удобно начинать с режима планирования, а перед крупными изменениями сохранять снимки, чтобы при необходимости быстро откатиться. Когда структура стабилизируется, можно экспортировать исходники и продолжить развитие в привычном процессе.
Чат-спецификация — это одно структурированное сообщение, по которому можно сразу собрать рабочий прототип: экраны, данные и базовую логику. Она заменяет длинные описания тем, что фиксирует минимум деталей, без которых команда обычно начинает «угадывать».
Ориентируйтесь на один главный сценарий v1 и держите объем таким, чтобы сообщение можно было перечитать за пару минут. Если получается слишком длинно, почти всегда это признак, что вы смешали две задачи и их лучше разделить на два сообщения.
Самый практичный минимум — контекст и границы, роли и права, сущности и поля, события и правила, а также явный блок «не делаем». Если эти части есть, прототиперу не нужно додумывать, кто пользователь, какие данные сохраняем и что считается правильным поведением.
Пишите роли через действия и запреты: что человек видит, что может сделать и что ему нельзя. Дополнительно сразу зафиксируйте видимость данных, потому что именно на этом чаще всего ломаются ожидания, например «сотрудник видит только свои заявки».
Сначала опишите объекты, которые вы храните, а уже потом думайте про экраны. Дайте каждому объекту 5–10 ключевых полей, отметьте обязательные, и проговорите связи простыми фразами, например что у одной заявки много комментариев и кто может быть автором.
Заранее задайте статусы и разрешенные переходы, иначе прототип будет «жить своей жизнью». Полезно прямо написать, какие переходы запрещены и при каких условиях статус меняется, чтобы не получилось, что заявку можно закрыть из любого состояния.
Опишите поведение на простых проблемных случаях: пустые обязательные поля, нет прав, попытка действия в неподходящем статусе, дубликаты, отмена и конфликт изменений. Это экономит время на переделках, потому что пользовательские ожидания обычно формируются именно на «краевых» ситуациях.
Блок «не делаем» нужен, чтобы прототип не разросся до продукта «на все случаи» и чтобы команда не спорила о том, что «подразумевалось». Формулируйте запреты прямо и проверяемо, например что в v1 нет интеграций, уведомлений, сложной аналитики и многоуровневых ролей.
Сначала дайте системе задать 2–3 уточняющих вопроса, затем обновите исходное сообщение единым блоком, чтобы не потерять контекст. После сборки прототипа пройдите руками 1–2 ключевых сценария и добавляйте изменения следующей версией, а не бесконечной перепиской.
Если вы делаете прототип в TakProsto, удобно начинать с режима планирования, чтобы сначала согласовать структуру и правила, а потом уже собирать экраны и данные. Перед крупными изменениями сохраняйте снимки, чтобы быстро откатиться, а когда структура стабилизируется, экспортируйте исходники и продолжайте развитие в своем процессе.