Составить ТЗ: подробный опросник

Этот опросник — быстрый способ зафиксировать задачу так, чтобы результат был предсказуемым. Он помогает превратить исходный запрос в понятную структуру: цели, процессы, роли, данные, ограничения и критерии приёмки.

Важно: вам не нужно писать код или “делать работу разработчиков”. Достаточно описать реальность бизнеса: как всё работает сейчас и как должно работать после. Если термин непонятен — откройте подсказку (она раскрывается по клику) или пишите своими словами.

Заполнение опросника не гарантирует совместной работы: решение принимается после ознакомления с ответами и уточнений. Но в конце, после успешной отправки, вы сможете скачать файл с вопросами и вашими ответами — это удобно и помогает перейти к следующему шагу.

Финальная кнопка отправки находится в самом низу страницы. Самый быстрый путь: в выпадающем меню разделов выберите пункт 15, дождитесь прокрутки и пролистайте чуть ниже — там будет кнопка отправки.

Рекомендация: для полного понимания задачи постарайтесь дать ответы на максимум вопросов, на которые вы знаете ответ — даже коротко.

Точная оценка: сроки/бюджет становятся понятнее, видно от чего зависит цена и что можно упростить.
Меньше переделок: заранее фиксируются требования, развилки, статусы, исключения и проверки данных.
Понятный MVP и приоритеты: выделяем “самое важное для запуска” и что можно отложить.
Критерии приёмки: чтобы было ясно “что считается готово” и как это проверяется.
Риски заранее: интеграции, миграция данных, права, безопасность, отчёты и нюансы процессов вскрываются до разработки.
Единый документ: удобно согласовать внутри команды/с руководителем и сравнить предложения разных исполнителей на одинаковых вводных.
Удобно заполнять: можно проходить частями — автосохранение включено и работает в этом браузере.

Подсказка: что означает шапка опросника

← — вернуться на главную страницу.
0/0 · 0% — прогресс заполнения (сколько ответов заполнено из общего количества).
Автосохранение — статус сохранения (работает в этом браузере).
0 сл · 0 зн — сколько слов и символов введено по всему опроснику.
Обяз. 0/7 — сколько обязательных пунктов заполнено; клик по “Обяз.” или по меткам рядом ведёт к нужному пункту.
Список разделов — быстрый переход (пункт “Начало” возвращает наверх).
↓ / ↑ — перейти к следующему / предыдущему разделу.
Полоска под шапкой — общий прогресс заполнения.

Как отвечать, чтобы оценка была точнее:

Добавляйте цифры: сколько заявок/заказов, сколько людей, сроки, частота операций.
Пишите примеры реальных кейсов: 3–10 типовых ситуаций и 3–10 нештатных.
Если есть документы/таблицы/скриншоты — просто вставьте ссылки в соответствующие поля.
Если что-то “не знаете” — так и пишите (это нормально), но укажите, кто может уточнить и когда.
Где есть варианты ответов — выбирайте ближе всего к правде, а детали дописывайте в поле рядом.

Подсказка: что считается “достаточно подробно”

Хороший ответ — это маленькая “инструкция”, по которой другой человек смог бы повторить процесс без уточняющих вопросов. Самый удобный формат: роль → триггер/условия → входные данные → шаги → результат → критерий “готово” → исключения.

Кто делает: роль/должность (и сколько людей таких), кто проверяет и кто утверждает.
Где происходит: в какой системе/канале (CRM, сайт, Telegram, Excel, почта), на каком экране/разделе.
Когда и при каких условиях: “после заявки”, “когда оплата подтверждена”, “если просрочка > 2 часа”, “если клиент новый”.
Что нужно на вход: какие поля обязательны (телефон, адрес, категория, сумма), откуда берём данные, какие проверки/валидации.
Что делаем (шаги): по пунктам, включая развилки (“если нет товара →…”, “если клиент отменил →…”).
Что получается на выходе: какой объект создан/изменён (заявка/заказ/счёт), какой статус, какие уведомления/документы появились.
Как понять, что всё ок: критерий “готово” и измеримый результат (например: “статус ‘Закрыта’, акт прикреплён, клиенту ушло SMS”).
Исключения и ошибки: что делаем при возврате, ошибке данных, переносе срока, отмене, повторном выполнении.

Мини‑шаблон + пример (одним блоком)

Роль: …
Пример: Менеджер.

Триггер/условия: …
Пример: новая заявка с сайта или из Telegram.

Входные данные (обязательные поля): …
Пример: имя/телефон, адрес, категория работ, желаемая дата, комментарий.

Шаги: 1) … 2) … 3) …
Пример: 1) создать “Заявку” → 2) назначить ответственного → 3) поставить статус “В работе” → 4) согласовать время → 5) создать “Выезд/задачу”.

Результат/выход: …
Пример: заявка в статусе “Назначено”, ответственный указан, клиенту отправлено сообщение с подтверждением времени.

Критерий “готово”: …
Пример: есть назначение + подтверждение от клиента + нет пустых обязательных полей.

Исключения/что если: …
Пример: если клиент не отвечает 2 часа → напоминание; если отмена → статус “Отменено” + причина.

Если встретили непонятный термин (SLA, AS-IS, сущность, webhook и т.п.) — откройте словарь ниже. Если термин всё равно непонятен — пишите своими словами: “хотим, чтобы было так-то”.

Словарь терминов (простыми словами)

AS-IS: Как процесс работает сейчас. Пример: “заявка в Telegram → менеджер копирует в Excel → контроль вручную”.
TO-BE: Как процесс должен работать после внедрения. Пример: “заявка создаётся в системе → статусы → уведомления → отчёты”.
Сущность (entity): Тип карточки/таблицы в системе. Примеры: “Заявка”, “Клиент”, “Заказ”, “Платёж”, “Документ”.
Статус / этап: Стадия жизни объекта. Пример: “Новая → В работе → Проверка → Завершена/Отменена”.
MVP: Первая версия для запуска: минимум функций, чтобы начать работать и получить пользу.
Роль: Группа пользователей с одинаковыми правами. Пример: админ, менеджер, исполнитель, клиент.
Матрица прав: “Кто что может”: роль → сущность → действия (просмотр/создание/редактирование/удаление/экспорт/смена статуса).
SLA: Норматив времени: за сколько нужно отреагировать/сделать. Пример: “реакция 2 часа, выполнение 24 часа”.
Приоритет (P1/P2/P3): Насколько срочно. Пример: P1 — критично (простои/штрафы), P3 — планово.
Audit log / аудит: История действий: кто и когда сменил статус, отредактировал поля, удалил, экспортировал.
API: Способ системам обмениваться данными по запросу. Пример: система запрашивает “получить оплату по заказу”.
Webhook: “Отправка по событию”: когда что-то случилось, система сама отправляет данные на ваш URL.
BI / DWH: BI — инструменты аналитики (Power BI и т.п.). DWH — хранилище данных для аналитики.
SSO: Единый вход через корпоративную учётку (Azure AD/Okta/Google Workspace).
2FA: Два фактора входа: пароль + код/приложение/ключ.
OTP: Одноразовый код (по SMS/в приложении) для входа или подтверждения действия.
CI/CD: Автоматическая сборка, тесты и выкладка обновлений.
UAT: Проверка пользователями перед запуском (User Acceptance Testing).
Soft-delete: “Мягкое удаление”: объект скрывается, но его можно восстановить (обычно с аудитом).
Row-level security: Ограничение видимости на уровне записей: видишь только “свои/своей команды/своего филиала”.

Если вы не знаете, как ответить на вопрос

Если вопрос не подходит — напишите “не применимо” (например, нет оплат — значит раздел про оплаты не актуален).
Если нет цифр — дайте оценку: минимум/обычно/пик (пример: 10/30/120 заявок в день).
Если нет схем — опишите словами 5–10 шагов процесса, этого достаточно для старта.

Пример заполнения (короткий кейс, чтобы было понятнее)

Кейс: сервис выездного ремонта

Проблема: заявки теряются в чатах, нет контроля сроков, сложно понять загрузку мастеров.
AS-IS: заявка приходит по телефону → менеджер пишет в чат → мастер берёт “кто первый” → отчёт в виде фото в чат.
TO-BE: заявка создаётся в системе → назначается мастер → чек-лист работ → фото до/после → закрытие → отчёт по просрочкам.
Роли: админ (настройки), менеджер (назначает), мастер (выполняет), руководитель (контроль/отчёты), клиент (видит статус).
Сущности: Заявка, Клиент, Выезд, Мастер, Фото, Документ/акт, Оплата (если нужна).
SLA: “перезвонить клиенту за 30 минут”, “назначить мастера за 2 часа”, “закрыть заявку за 24 часа”.
Интеграции: телефония (звонки), SMS/мессенджер (уведомления), 1С (счета/оплаты) — если нужно.

0. Контакт и идентификация проекта

Цель раздела 0: понять, кто принимает решения, как быстро можно уточнять вопросы, и какие исходные материалы уже есть. Если какой-то вопрос не относится к вам — напишите “не применимо” или пропустите. Непонятные термины — в словаре.

Пример: как может выглядеть заполнение раздела 0 (0.1–0.4)

В разделе 0 вопросы разбиты на подпункты. Например, про MVP вопрос находится ниже в 0.2 — “Что входит в первую версию (MVP)?”.

Контакт: Иван — операционный директор — Telegram/Email — удобное время 10:00–14:00.
Роль в проекте: Лицо, принимающее решения (утверждает требования и изменения).
Что реализуем: автоматизацию процессов + личный кабинет клиента.
MVP (если уже понимаете): заявки → статусы → назначение ответственного → уведомления о просрочке → простой отчёт. Перейти к вопросу про MVP: здесь.
Материалы: ссылка на текущую таблицу/CRM + 2–3 скриншота текущего процесса.

0.1 Контакты Имя и фамилия (контактное лицо)

Компания / проект

Email

Телефон

Telegram (предпочтительно):
Укажите номер, на котором есть Telegram (доступен поиск по номеру), или ник.

Город / страна:

Удобное время связи:

Должность / роль в компании:
Например: владелец, CEO, операционный директор, руководитель отдела продаж.

Роль в проекте (как вы участвуете):
Помогает понять, кто принимает решения, кто согласовывает, кто просто консультирует.

Предпочитаемый язык общения/документов:

Формат коммуникации:
Выберите то, как вам удобнее работать в процессе анализа/разработки.

Каналы связи (можно несколько) Telegram
WhatsApp
Viber
Signal
Email
Звонок
Zoom / Google Meet
Slack

Ссылка на календарь/слоты для созвона (если есть):
Например: Calendly/Google Calendar appointment schedule.

Другие участники со стороны заказчика (имя — роль — контакт):
Кого подключать: ключевые пользователи, финансы, безопасность, юристы, интеграторы.

NDA (соглашение о конфиденциальности):

0.2 Тип и исходные условия проекта Что вы хотите реализовать?
Выберите вариант, который наиболее точно отражает задачу.

Коротко сформулируйте идею проекта (1–3 предложения):
Опишите суть задачи без технических деталей.

Какую ключевую проблему должна решить система?
Что сейчас мешает работать эффективно.

Что должно принципиально измениться после внедрения системы?
Скорость, контроль, прозрачность, масштабирование и т.п.

На каком этапе находится проект сейчас?

Опишите текущую ситуацию подробнее:
Какие ограничения, ожидания или проблемы есть сейчас.

Какой формат разработки вы рассматриваете?

Есть ли жёсткие ограничения? (сроки, регуляции, безопасность, интеграции):
Это “рамки”, которые нельзя нарушать. Если есть хотя бы 1 — лучше написать сразу, чтобы не проектировать “в вакууме”. Примеры: фиксированный дедлайн (“к 01.03 обязательно запуск”), хранение данных в определённой стране, обязательная 2FA, запрет на сторонние сервисы, интеграция только через API (без доступа к базе), обязательные журналы действий, требования комплаенса. Если ограничений нет — напишите “нет”.

Ссылки на материалы (если есть):
Сюда можно вставить любые ссылки, которые помогут понять проект быстрее: ваш сайт/лендинг, страницы конкурентов/аналогов, документы/таблицы, схемы процессов, макеты интерфейса/экраны, видео/скринкасты, демо-версию. Пишите “ссылка — что это”, каждая с новой строки. Если ничего нет — напишите “нет”.

Какой результат вы ожидаете на выходе (артефакты/продукты):
Например: веб-система + админка + API + отчёты + интеграции.

Выберите, что нужно (можно несколько) Веб-приложение (кабинет пользователей)
Админ-панель
API для интеграций
Мобильное приложение
Отчёты/аналитика
Интеграции с внешними системами
Миграция данных
Другое

Если нужно, уточните результат словами:
Например: “публичный API для партнёров”, “админка только для супер-админа”, “2 интерфейса: оператор и клиент”.
Какие процессы/направления важнее всего автоматизировать в первую очередь?
Перечень 3–10 самых ценных процессов (по приоритету).

Что входит в первую версию (MVP)?
MVP = первая версия, которая уже приносит пользу и может использоваться “в бою”. Это не “самое простое”, а “самое необходимое”: минимум функций, чтобы процесс работал от начала до конца. Удобный формат ответа: процесс → роли → карточки/данные → статусы → уведомления → отчёт → критерии приёмки.

Подсказка: что обычно входит в MVP (если применимо)

Один основной объект (Заявка/Заказ/Объект) + карточка клиента/контрагента
Статусы (4–8 штук) + понятные правила переходов (что можно/нельзя)
Ответственный и сроки: назначение исполнителя, дедлайн, просрочка, эскалация
Роли и доступы: минимум “админ”, “оператор/менеджер”, “исполнитель”, “руководитель” (и клиент, если нужен кабинет)
Файлы/комментарии — если без них процесс не закрывается (фото, акт, причина отмены)
Уведомления по ключевым событиям (создано/назначено/просрочено/закрыто/возврат)
Мини‑отчёт: “просроченные”, “в работе”, “нагрузка по людям/филиалам” (хотя бы 1 экран)

Если пункт не нужен — прямо так и пишите: “в MVP не нужно, потому что …”.

Пример MVP (система заявок на услуги)

Процесс: заявка пришла → уточнение → назначение мастера → выполнение → проверка → закрытие
Роли: менеджер, мастер, руководитель, админ
Карточки: заявка (контакт, адрес, тип, приоритет), клиент, файлы (фото), комментарии
Статусы: Новая → Уточнение → В работе → Проверка → Закрыто/Отменено
Уведомления: назначили мастера, просрочка, запрос уточнения, закрыто
Отчёт: список просроченных + фильтр “мои/филиал/период”
Приёмка: 10 сценариев: создать/назначить/вернуть/закрыть/отменить + проверка прав доступа

Что можно отложить на 2–3 этап (Nice-to-have)?
Это помогает не раздувать MVP и быстрее запустить.

Что точно НЕ нужно / что является “не-целью” проекта:
Важный вопрос: помогает избежать лишней работы и разночтений.

Примеры реальных кейсов (3–15 штук) — как это должно выглядеть “в жизни”:
Опишите в формате: входные данные → шаги → результат → кто участвует → сроки.

Уровень чувствительности данных:
Нужно для выбора мер безопасности и хранения.

Дизайн и брендирование:
Есть ли готовый брендбук/макеты или нужно делать с нуля.

0.3 Стейкхолдеры и принятие решений Кто участвует со стороны заказчика (список ролей/людей):
Например: владелец, операционный директор, руководитель продаж, бухгалтер, безопасность.

Кто финально принимает решения по требованиям и изменениям?

Кто будет принимать работу (acceptance) и по каким критериям?
Опишите процесс приемки: демо, чек-лист, UAT, кто подписывает “готово”.

Как быстро вы обычно отвечаете/согласовываете (SLA по коммуникации):
Например: “в течение 1 рабочего дня” или “раз в неделю”.

Инструменты для согласований (можно несколько) Telegram
Slack
Email
Google Docs
Notion
Jira
Trello

0.4 Материалы, доступы, исходные данные

Что уже есть (можно несколько) Брендбук/гайдлайн
Логотип/айдентика
UI‑макеты/экраны (если есть)
Прототип/кликабельный прототип
Схемы процессов (BPMN/блок-схемы)
Таблицы/Excel с текущими данными
Существующая система/CRM
Документация API/интеграций
Ничего из перечисленного

Есть ли существующие данные для импорта/миграции?
Например: клиенты, заявки, история статусов, документы.

Какие доступы сможете предоставить для анализа (если есть):
Например: тестовый доступ к текущей CRM, доступ к API, к базе, к логам.

0.5 Быстрая сводка (обязательно) Коротко: что нужно сделать (1–3 предложения)
Чтобы мы сразу поняли суть задачи, даже если дальше вы заполняете постепенно.

Критерии успеха (2–5 пунктов)
Как поймём, что система “заработала”: скорость, контроль, прозрачность, показатели.

Желаемый дедлайн / когда нужно запустить

Бюджет (ориентир)

1. Контекст бизнеса и цели

Цель раздела 1: чтобы система решала реальную бизнес-задачу и была удобна конкретным людям. Здесь лучше писать простыми словами и примерами, чем “красиво”. Непонятные термины — в словаре.

Пример: ответы для раздела 1 (упрощённо)

Ниша: сервисные выезды (ремонт/монтаж) в 3 городах.
Пользователи: менеджеры (офис), мастера (поле), руководитель, клиент (видит статус).
Боль: нет контроля сроков, заявки теряются, трудно понять загрузку.
Цель: сократить время обработки и убрать хаос: “видно где застряло” + “кто отвечает”.
Критерии успеха: 90% заявок закрываются без ручных “напоминаний в чат”, просрочки видны сразу.

1.1 Бизнес и аудитория Сфера / ниша бизнеса:
Основная область деятельности компании.

Бизнес-модель:
Как вы зарабатываете.

Категории пользователей системы:
Кто будет работать в системе и в каком качестве.

Краткое описание ключевых ролей пользователей:
Чем занимаются, какие задачи решают.

Ожидаемое количество пользователей:
Сейчас и в перспективе.

География работы:
Страны, регионы, города, филиалы.

Масштаб бизнеса:

Основные продукты / услуги:
Что именно производится или продаётся.

Насколько сложен продукт / услуга:

Частота операций / заказов:
Нагрузка на систему.

1.2 Проблема и ценность Какая главная проблема сейчас (1–3 пункта):
Пишите конкретно и “из жизни”: где ломается процесс и что это стоит бизнесу (деньги/время/нервы/репутация). Примеры: “заявки теряются в чатах”, “нет контроля сроков и просрочки не видны”, “данные дублируются и отчёты неверные”.

Почему существующие решения не подходят (шаблонные CRM и т.п.):
Укажите, что пробовали (если пробовали) и чего не хватает: гибких статусов/переходов, матрицы прав, кастомных полей, сложных интеграций, автоматизаций, отчётов, оффлайн-режима, скорости.

Какая цель проекта (что должно измениться):
Формулируйте измеримо: “сократить время обработки с X до Y”, “уменьшить просрочки на N%”, “дать прозрачность по статусам”. Можно указать срок, в который хотите увидеть эффект.

Критерии успеха (как поймём, что получилось):
Подумайте как “чек-лист приемки”: какие отчёты/экраны/сценарии должны работать и какие цифры считаем успехом. Пример: “95% заявок проходят без ручных правок”, “поиск < 2 сек”, “руководитель видит просрочки в 1 клике”.

1.3 Целевая аудитория и сценарии использования

Цель: описать, кто и как реально будет пользоваться системой, чтобы интерфейсы и логика были “по делу”.

Сегменты аудитории / типы клиентов (если есть):
Например: малый бизнес / корпоративные клиенты / частные лица; новые/повторные; партнёры.

Ключевые задачи пользователей (Jobs-to-be-done):
Что пользователи хотят “сделать” в системе: быстро оформить, контролировать статус, получить документ и т.п.

Путь пользователя (user journey) от начала до результата:
Шаги: как появляется заявка/заказ, что видит клиент, что делают менеджеры, где возникают ожидания.

Каналы поступления заявок/обращений (можно несколько) Сайт/форма
Звонки
Мессенджеры
Email
Соцсети
Партнёры/рефералы
Офлайн/точки продаж
Другое

Какая информация должна быть доступна клиенту/партнёру в личном кабинете (если он будет):
Например: статусы, история, документы, оплаты, комментарии, файлы, чат.

1.4 Конкуренты, аналоги, референсы

Цель: понять, что вам нравится/не нравится в существующих решениях и какие паттерны интерфейса удобны.

Конкуренты/аналоги/сервисы, на которые вы ориентируетесь (ссылки):
Достаточно 3–10 ссылок. Если это внутренний продукт — опишите названием/скриншотами.

Что в них нравится (функции, интерфейс, скорость, логика):
Отдельно можно отметить: навигация, фильтры, карточка объекта, отчёты, автоматизации, уведомления.

Что не нравится / что точно не хотим повторять:
Примеры: “слишком много кликов”, “непонятные статусы”, “нет гибких прав”, “сложный интерфейс”.

Ваши отличия / уникальность (почему клиент выбирает вас):
Это полезно для приоритизации функций и фокуса на ценности.

1.5 Метрики, экономика, сезонность (если применимо) Основные метрики бизнеса, которые важно улучшить:
Например: скорость обработки, конверсия, просрочки, повторные продажи, возвраты, качество.

Сезонность/пики нагрузки:
Когда много обращений и почему (месяцы, дни недели, кампании).

Средний чек / средняя стоимость заказа (если есть):

Как формируется цена/стоимость (тарифы, доп.услуги, скидки):
Если есть прайс/таблица — можно просто дать ссылку и кратко описать правила (скидки, надбавки, минималки).

2. Текущие процессы (AS-IS)

AS-IS = “как сейчас”. Представьте, что вы объясняете новому сотруднику: что происходит шаг за шагом, кто за что отвечает, где хранится информация и где чаще всего ломается процесс.

Мини-шаблон AS-IS (можно просто скопировать и заполнить)

Вход: откуда приходит заявка (сайт/телефон/чат/почта).
Шаги: 5–15 шагов “кто делает → что делает → где фиксирует”.
Данные: какие поля/документы нужны, где они сейчас лежат.
Проблемы: где теряется время/данные, почему, как часто.
Пример кейса: 1 типовой и 1 “нештатный” (отмена/возврат/ошибка/срочно).

2.1 Как работает сейчас

Здесь важно описать реальную картину “как есть”, даже если она хаотичная. Чем честнее AS-IS, тем точнее получится TO-BE. Хороший формат: вход → шаги → кто делает → где фиксируется → какие данные нужны → что считаем результатом.

Опишите текущий процесс “от заявки до результата” :
Подсказка: перечислите этапы и людей. Пример: “заявка приходит → менеджер уточняет → создаёт заказ → назначает исполнителя → контроль → закрытие”.

Какие инструменты используете сейчас (Excel, Telegram, CRM, 1C и т.п.):
Укажите, для чего каждый инструмент: где хранят данные, где общаются, где согласуют, где считают деньги/склад.

Какие документы/файлы используются (акты, накладные, договора, фото и т.д.):
Важно: кто создаёт/подписывает документ, где хранится, нужен ли шаблон, бывают ли версии/правки.

Какие источники данных (сайты, почта, звонки, интеграции):
Опишите, откуда именно приходят данные и как попадают в учёт: вручную/автоматически/через менеджера.

2.2 Проблемные места Где чаще всего возникают ошибки/потери данных:
Примеры: “не заполнили поле”, “потеряли файл”, “не тот статус”, “не туда назначили”, “пропустили согласование”.

Где теряется время (ожидания, согласования, поиски информации):
Полезно указать: сколько времени теряем, кто ждёт кого, и можно ли это автоматизировать/убрать.

Какие “узкие места” по людям (кто перегружен, кто bottleneck):
Пример: один человек “держит в голове” процесс или только у него доступ/компетенция → всё стопорится.

2.3 Объёмы, метрики, временные параметры (как сейчас)

Если точных цифр нет — оцените “примерно”. Эти ответы сильно влияют на архитектуру и приоритеты.

Сколько “единиц работы” проходит через процесс?
Например: заявок/заказов/объектов в день, неделю, месяц; сколько одновременно “в работе”.

Среднее и максимальное время прохождения процесса “от входа до результата”:
Например: в среднем 3 дня, максимум 14 дней.

Где обычно возникают задержки и почему (ожидания людей/материалов/согласований):
Совет: перечислите 3–10 причин задержек и укажите, какая из них самая частая/дорогая.

Пиковые нагрузки и сезонность (когда “штормит”):
Укажите пример: “в понедельник 30% всех заявок”, “в сезон +200%”. Это влияет на производительность и UX.

2.4 Коммуникации и согласования (как сейчас)

Где обсуждают задачи и “передают” информацию (можно несколько) Telegram/чаты
WhatsApp/Viber
Email
Звонки
Совещания
Комментарии в текущей системе/CRM
Бумага/распечатки
Другое

Как сейчас устроены согласования (кто, что и когда должен подтвердить):
Пример: “после расчёта суммы руководитель утверждает скидку > 10%”, “бухгалтерия подтверждает оплату”.

Где чаще всего теряется контекст/информация при “передаче” между людьми/отделами:
Примеры: “в чате нет единого места”, “часть деталей в звонке”, “файл лежит у одного человека”, “нет истории решений”.

2.5 Данные и качество данных (как сейчас) Где хранятся данные сейчас (таблицы, CRM, 1С, почта) и что является “источником правды”:
“Источник правды” — место, где данные считаются корректными, даже если копии есть в других местах.

Проблемы качества данных (дубликаты, неполные поля, разные форматы):
Совет: перечислите 5–15 типовых проблем и их последствия: “ошибка в счёте”, “не дозвонились”, “не нашли объект”.

Часто ли бывают дубликаты клиентов/заявок?
Если дубли бывают — уточните: как их сейчас находите и что делаете (объединяете/связываете/игнорируете).

Какие поля/данные чаще всего забывают заполнить (и почему):
Пример: телефон, адрес, сумма, дата, прикреплённый документ, комментарий причины отказа.

2.6 Типовые кейсы (AS-IS) — примеры “как сейчас”

Опишите 5–15 примеров: типовой, сложный, срочный, с возвратом, с ошибкой, с отменой, с интеграцией.

Примеры кейсов (каждый в 3–7 строк):

3. Будущие процессы (TO-BE)

TO-BE = “как хотим после внедрения системы”. Здесь важно описать не только “красивую картинку”, но и правила работы — чтобы мы могли реализовать процесс без дополнительных уточнений.

Удобный формат: основной сценарий (идеальный поток) + исключения (возвраты/отмена/ошибки данных) + правила (кто что может, какие поля обязательны, что запрещено) + сроки (SLA/дедлайны/эскалации) + автоматизации (уведомления/напоминания/автозаполнение) + критерии “готово” (как поймём, что всё работает).

Пример TO-BE: статусы + правила (коротко)

Статусы: Новая → Уточнение → В работе → Проверка → Закрыто → Архив.
Возврат: из “Проверка” в “В работе”, если не хватает фото/документа.
Согласование: скидка > 10% требует подтверждения руководителя.
SLA: “перезвонить за 30 минут”, “выполнить за 24 часа”, при просрочке — эскалация.
Исключения: клиент отменил → статус “Отменена” + причина + уведомление.

Пример TO-BE (подробнее): “заявка → выполнение → проверка → закрытие”

Ниже — пример, как можно описать будущий процесс “человеческим языком”, но достаточно точно для разработки.

Триггер: заявка приходит с сайта/из Telegram/по телефону (менеджер заводит вручную).
Входные данные: контакт клиента, адрес/объект, тип работ, желаемое время, фото/файлы (если есть).
Статусы: Новая → Уточнение → Запланирована → В работе → Проверка → Закрыта / Отменена.
Роли: менеджер (принимает/уточняет/назначает), исполнитель (делает), руководитель (контроль/эскалации), админ (настройки).
Правила: без адреса/контакта нельзя перевести в “Запланирована”; закрытие возможно только с результатом и фото/комментарием (если требуется).
Возврат: “Проверка” → “В работе”, если не хватает фото/подписанного акта/данных.
Сроки (SLA): “перезвонить/уточнить за 30 минут”; “назначить исполнителя за 2 часа”; при просрочке — уведомление руководителю.
Автоматизации: напоминания о просрочке, уведомление исполнителю о назначении, уведомление клиенту о статусе, история изменений.
Критерий “готово”: можно пройти сценарий “создать → назначить → выполнить → вернуть на доработку → закрыть” и всё фиксируется в истории/отчёте.

Шаблон TO-BE (можно копировать и заполнять)

Если не знаете, как “правильно описать” — просто заполните пункты ниже. Этого обычно хватает, чтобы мы спроектировали логику и оценили работу.

Цель процесса: … (какой результат должен появиться)
Триггер (как начинается): … (откуда приходит заявка/задача)
Статусы/этапы: … (цепочка “как в интерфейсе”)
Роли: … (кто участвует и что делает)
Обязательные данные: … (какие поля нельзя забыть)
Правила: … (что запрещено/что только с подтверждением/условия переходов)
Возвраты и исключения: … (“если X — что делаем”)
Сроки (SLA): … (где нельзя задерживать и что считать просрочкой)
Автоматизации: … (напоминания/уведомления/автоназначение)
Как принимаем (критерии “готово”): … (2–5 сценариев проверки)

3.1 Основной сценарий (TO-BE) Опишите, как процесс должен работать в идеале :
Опишите “идеальный поток” так, чтобы по нему можно было собрать систему: кто делает шаг, какие данные нужны, что меняется в статусах. Можно сравнить с AS-IS: что убираем/автоматизируем/делаем прозрачным.

Какие этапы есть/должны быть (перечень):
Совет: делайте названия статусов “как в интерфейсе”. Пример: “Новая → В работе → Проверка → Закрыто → Архив”.

Есть ли возвраты/доработки? Опишите:
Пример: “если клиент не подтвердил — вернуть на ‘Уточнение’”, “если проверка не прошла — вернуть исполнителю”.

Есть ли параллельные этапы? Опишите:
Если можно делать одновременно (например, “согласование” и “закупка”) — это важно для модели процессов.

Есть ли контрольные точки/согласования? Опишите:
Пример: “скидка > 10% согласует руководитель”, “закрытие задачи подтверждает контролёр/клиент”.

Нужна ли история изменений (кто/что/когда):
Если “да” — уточните, что важно хранить: смены статусов, изменения полей, файлы, комментарии, кто смотрел данные.

3.2 Исключения и “нештатные ситуации” Какие исключения бывают (пример: клиент отменил, нет материала, сотрудник заболел):
Это самый “дорогой” по логике пункт: именно исключения делают систему умной (и экономят деньги/нервы в работе). Перечислите максимум реальных ситуаций формата “если случилось X — что делаем?”.

Удобно писать так: ситуация → как узнаём → кто принимает решение → что меняется (статус/срок/ответственный) → что фиксируем (причина/комментарий/файл) → кого уведомляем.

Примеры исключений (идеи, чтобы было проще вспомнить)

Клиент отменил / перенёс дату / не выходит на связь.
Нет материала / поставщик задержал / брак материала.
Исполнитель заболел / перегружен / не успевает в срок.
Адрес/контакт неверный / клиент ввёл “мусор” в поле.
Нужно согласование скидки/сметы/изменения объёма работ.
Оплата не прошла / частичная оплата / возврат денег.
Работу сделали, но клиент не принял (нужна доработка/повторный выезд).
Интеграция не отвечает (1С/платежи/телефония) — что делать “вручную” и как потом синхронизировать.

Какие правила приоритетов (что важнее, что срочнее):
Пример: P1 — остановка производства; P2 — клиент ждёт; P3 — плановые задачи. Укажите сроки реакции и эскалации.

Какие правила сроков (SLA, дедлайны, штрафы):
Если SLA зависит от типа заявки/клиента/региона — обязательно укажите условия.

3.3 Детализация этапов/статусов (TO-BE)

Если хотите максимально точную реализацию — опишите этапы как “мини-спецификацию”. Чем точнее здесь — тем меньше “а мы думали иначе” на разработке и приёмке.

Шаблон описания этапа (пример)

Этап: “Согласование”
Вход: заявка заполнена, приложены документы X
Кто отвечает: менеджер + руководитель
Действия: запросить правки, согласовать, отклонить
Выход: статус “Согласовано” или “На доработке”
SLA: 1 рабочий день, при просрочке — уведомить руководителя

Опишите каждый этап/статус по шаблону (можно списком):

Правила переходов между статусами (какие переходы разрешены/запрещены):
Например: из “В работе” нельзя сразу в “Закрыта”, только через “Проверка”. Можно писать списком: из → в + кто может + условия/обязательные поля + что фиксируем (причина/комментарий).

Какие поля/данные обязательны на каждом этапе:
Пример: “перед переходом в ‘Счёт выставлен’ должен быть заполнен ‘Сумма’ и ‘Реквизиты’”. Это помогает избежать ситуации “статус поставили, а данных нет”.

3.4 Валидации, качество, чек-листы Нужны ли чек-листы на этапах? Какие пункты:

Правила по вложениям/фото/документам (что обязательно и где):
Примеры: “в ‘Проверка’ обязательно 2 фото до/после”, “в ‘Оплачено’ должен быть чек/квитанция”, “в ‘Закрыта’ — акт”. Укажите также ограничения: формат, размер, сколько файлов, нужны ли подписи к файлам.

Политика дублей (что делать, если пришла повторная заявка/клиент уже есть):

Какие проверки и ограничения должны не давать делать ошибки (валидации):
Это про автоматические правила, которые не дают сохранить “кривые” данные или сделать неправильный шаг. Простой формат: если … → система делает … (показывает ошибку / не даёт перейти дальше / просит заполнить поле / просит подтверждение).
Важно: если вы уже описали “обязательные поля по этапам” и “правила переходов” выше — здесь можно дописать именно проверки ввода: формат, диапазоны, уникальность, права, лимиты, обязательные комментарии/вложения.

Подсказка: как понять, какие валидации нужны

Вспомните реальные ошибки “сейчас”: что забывают заполнить, где путают статусы, какие поля вводят как попало.
Опишите риск: “если это пропустить — будет …” (срыв срока, лишний выезд, спор по оплате, потеря заявки).
Укажите реакцию системы: блокировать сохранение / просить подтверждение / автозаполнять / показывать предупреждение.
Сфокусируйтесь на критичном: обычно достаточно 5–20 правил для MVP, остальное добавляется по мере эксплуатации.

Если пока не знаете — напишите “не знаю” и перечислите 3–5 самых частых косяков, которые хотелось бы убрать.

3.5 SLA, эскалации, контроль сроков Сроки по этапам/типам задач (SLA): сколько времени допустимо на шаг/этап:
SLA — это “норматив времени”: за сколько нужно отработать этап или сколько задача может находиться в статусе, прежде чем это станет просрочкой. Эти сроки нужны, чтобы система автоматически подсвечивала задержки, напоминала и эскалировала (см. следующие вопросы).

Укажите 5–15 ключевых этапов. Если сроки разные по типу заявки, клиенту, региону или приоритету — напишите условия. Если SLA у вас нет — можно написать “нет/на усмотрение” и указать 2–3 самых критичных места, где “нельзя задерживать”.

Подсказка: как проще всего придумать SLA, если его не фиксировали

Возьмите 3–5 реальных кейсов и посмотрите, где чаще всего “застревает”. Именно туда SLA важнее всего.
Разделите “реакцию” и “выполнение”: реакция = первый шаг (взяли/назначили/связались), выполнение = довели этап до результата.
Уточните рабочие часы: SLA обычно считают “в рабочее время” (например, Пн–Пт 09:00–18:00) — иначе будут ложные просрочки ночью.
Определите “что считается выполнением”: это конкретный факт/статус (например, “назначен исполнитель”, “прикреплён акт”).
Если сомневаетесь — достаточно приблизительных значений: “обычно/максимум” или “критично/обычно/планово”.

Что делать при просрочке (автоматические действия/эскалации):
Кого уведомлять, как часто, какие статусы/метки ставить, нужно ли блокировать переходы.

Цепочка эскалации (кто следующий, если исполнитель не реагирует):

Приоритеты задач (P1/P2/P3) и правила для них:
Это про срочность: чтобы система понимала, что делать в первую очередь и какие сроки/эскалации применять. Опишите для каждого уровня: когда ставим → пример ситуации → SLA реакции → SLA выполнения → кто может назначить → что делает система (уведомления/эскалации/ограничения).

Подсказка: пример простой логики P1/P2/P3

P1 (критично): работа “стоит” или есть прямые потери/штрафы. Примеры: не проходит оплата, система не открывается, нельзя оформить заказ, сорвётся выезд/доставка сегодня.
P2 (высокий): не останавливает бизнес целиком, но влияет на клиента/срок сегодня‑завтра. Примеры: нужно срочно согласовать документы, исправить важную ошибку в отчёте, подготовить данные к дедлайну.
P3 (обычный): плановые задачи без “горящей” срочности. Примеры: улучшения интерфейса, новые поля, расширение отчёта, оптимизация.

Если не хотите букв P1/P2/P3 — можно назвать “Критичный / Срочный / Плановый”. Главное, чтобы были понятные критерии и сроки. Если пока не знаете — напишите 3–5 типовых ситуаций “что для вас срочно”, и мы сами предложим шкалу.

3.6 Варианты процессов (если их несколько)

Если есть разные типы заявок/заказов, которые идут по разным маршрутам — опишите правила “маршрутизации”.

Пример: варианты процессов и маршрутизация (очень наглядно)

Типы: гарантийный ремонт / платный ремонт / монтаж / консультация.
Правило выбора: если “тип=гарантия” → маршрут “Гарантия” (нужен документ покупки), иначе “Платный”.
По клиенту: VIP‑клиенты → SLA быстрее + отдельная очередь.
По региону: Киев → команда A, область → команда B; при отсутствии слотов — предложить другую дату.
По сложности: если “работа > 4 часов” → нужна предварительная смета и согласование руководителя.

Какие типы процессов/заявок бывают (перечень):

Как выбирается вариант процесса (правила/условия):

Нужна ли кастомизация под разных клиентов/филиалы (разные статусы/поля/правила):

4. Роли, пользователи, доступы

Раздел 4 отвечает на вопрос “кто что видит и что может делать”. Это важно для безопасности и удобства: чтобы сотрудники не видели лишнего, а руководители имели контроль. Ещё это влияет на стоимость: чем сложнее права/филиалы/уровни доступа — тем больше логики и тестирования.
Если сомневаетесь — опишите “как в жизни”: кто работает, что делает, какие данные видит, что нельзя, по каким правилам ограничиваем доступ (свои/команда/филиал) — мы переведём это в матрицу прав и сценарии приёмки.

Пример: матрица прав простыми словами

Ниже — пример формулировок. Вам достаточно написать похожими фразами: “видит …”, “может …”, “не может …”. Если у вас есть филиалы/команды — добавьте, что именно считается “своё/команда/филиал”.

Клиент: видит только свои заявки и их статусы, может прикрепить документы.
Исполнитель: видит только назначенные ему заявки, может менять статусы “в работе/сделано”, добавлять фото.
Менеджер: видит заявки своего филиала, назначает исполнителей, общается с клиентом, закрывает.
Руководитель: видит всё по филиалу/компании, смотрит отчёты, может эскалировать и переназначать.
Админ: управляет ролями/настройками/справочниками, но не обязан “работать по заявкам”.

Пример (чуть подробнее): ограничения и “опасные действия”

Запрет на редактирование после статуса: “после ‘Оплачено’ цену может менять только руководитель”.
Обязательный комментарий: “при отмене/отклонении — причина + комментарий”.
Экспорт: “экспорт клиентов в Excel доступен только руководителю/админу”.
Скрытие полей: “исполнителю скрываем финансы, клиенту скрываем внутренние комментарии”.

4.1 Список ролей Перечислите роли (например: админ, менеджер, мастер, контролёр, клиент):
Совет: перечислите роли “как в жизни” и добавьте 1–2 строки: что делает, какие данные видит, какие ограничения. Полезно указать примерное количество людей в роли (сейчас/через год).
Примеры ролей, которые часто нужны: админ, менеджер/оператор, исполнитель/мастер, контролёр/QA, руководитель, бухгалтерия (если есть финансы), клиент/партнёр (если есть кабинет).

Опишите права доступа (кто что видит/может делать):
Удобный формат: по сущностям (заявки, клиенты, документы, отчёты, настройки) и по действиям (просмотр/создание/редактирование/удаление/экспорт/смена статуса).
Если есть спорные места — напишите их явно: кто может менять цену/скидку, кто может удалять, кто может смотреть финансы, кто может видеть данные других филиалов, можно ли “переоткрывать” закрытые заявки.
Если удобнее — можно заполнить более формально ниже в “Матрица прав”, а здесь оставить коротко.

Нужны ли разные уровни доступа внутри роли (например: старший менеджер):
Это когда у роли есть “ступени” с разным объёмом прав, но с похожими задачами. Пример: “Менеджер” (только свои) → “Старший менеджер” (отдел) → “Супервайзер” (филиал).
Если выберете “Да” — опишите уровни в следующем поле “ограничивать доступ по филиалам/командам”: кто какой уровень и что это даёт.

Нужно ли ограничивать доступ по филиалам/объектам/командам:
Опишите правила видимости: “свои”, “команда”, “филиал”, “регион”, “все”. Уточните, что считается “своё”: назначенный ответственный, создатель, менеджер по клиенту, исполнитель на этапе.
Примеры: “менеджер видит заявки своего филиала”, “руководитель видит все филиалы”, “исполнитель видит только назначенные”. Также укажите, кто может переключать филиал/команду в фильтрах и кто может “выдать доступ” к чужому объекту.

4.2 Авторизация и безопасность Способ входа:
Выберите, как пользователи будут входить. Если есть корпоративные требования (SSO/AD/Okta) — лучше выбрать сразу: это влияет на архитектуру.
Примеры “по ситуации”: внутренняя система для сотрудников → Email+пароль или SSO; личный кабинет для клиентов → телефон+код (OTP) или Email+пароль; B2B/корпорации → чаще SSO.

Двухфакторная авторизация (2FA):
2FA = второй фактор при входе (например, приложение‑аутентификатор/код). Рекомендация: включать минимум для админов и ролей с доступом к финансам, экспорту, настройкам.
“Опционально” — пользователь может включить сам. “Обязательно” — без 2FA вход невозможен (обычно для критичных ролей).

Требования к безопасности/политикам (пароли, аудит, доступы):
Опишите, если есть “обязательные” требования (или напишите “стандартно”). Примеры: политика паролей, блокировка после N попыток, логирование действий (аудит), ограничения по IP/странам, хранение персональных данных, требования по шифрованию, запрет экспорта, отдельные роли для финансов.
Если есть внутренний ИТ/безопасность — можно указать контакт/документ, который регламентирует требования.

4.3 Управление пользователями (создание, приглашения, увольнения) Как пользователи будут попадать в систему?
Как появляются аккаунты. Для внутренней системы чаще: “админ приглашает” или “SSO”. Для кабинета клиентов/партнёров чаще: “саморегистрация” (и/или приглашения менеджером). Если пользователей много и они уже есть в таблице/CRM — удобен импорт списком.

Нужны ли команды/отделы/филиалы в структуре пользователей?
Если “да” — это поможет ограничивать доступ (по филиалу/команде) и строить отчёты (нагрузка по отделам). Примеры: “Отдел продаж”, “Сервис”, “Филиал Львов”, “Смена 1/Смена 2”, “Команда монтажников”.

Процесс увольнения/отключения пользователя (что происходит с его объектами/задачами):
Важно, чтобы ничего “не повисло”. Опишите, что делать с заявками/задачами/ответственностью, если человек уволился или ушёл в отпуск. Примеры: “переназначить на руководителя/дежурного”, “поставить в очередь”, “оставить историю, но отключить вход”.

Нужна ли делегирование/замещение (отпуска), “ответственный на период”?
Пример: менеджер ушёл в отпуск → все новые заявки автоматически уходят заместителю, а текущие можно массово переназначить. Уточните, нужно ли “делегировать только уведомления” или прямо права/ответственность на период.

4.4 Безопасность подробнее (политики, сессии, ограничения) Политика паролей (если вход по паролю):
Если выбираете Email+пароль — задаём требования к сложности. Если вход через SSO/OTP — можно выбрать “Пароли не используем”. “Корпоративная” обычно означает ротацию, запрет повторов, требования ИБ.

Таймаут сессии / автолог-аут:
Баланс удобства и безопасности: чем меньше таймаут — тем безопаснее, но тем чаще придётся входить заново. Для внутренних систем часто достаточно 8–24 часа, для финансовых/чувствительных — меньше.

Ограничения по IP/странам/устройствам (если нужно):
Если доступ должен быть “только из офиса/страны/корп‑сети” — напишите здесь. Примеры: IP‑allowlist офиса, запрет входа с анонимайзеров/VPN, разрешить доступ только по Украине, ограничить вход только с корпоративных устройств.

Нужно ли маскирование/скрытие чувствительных данных для части ролей?
Это когда часть полей показывается не всем (или показывается частично). Примеры: скрывать телефон/email у исполнителей, скрывать суммы у менеджеров, показывать только последние 4 цифры, скрывать персональные данные, скрывать внутренние комментарии от клиента.

Нужно ли периодическое ревью доступов (audit access review):
Ревью доступов = периодически проверять “у кого какие права” (особенно после увольнений/переводов). Пример: раз в квартал руководитель подтверждает список пользователей и их ролей.

4.5 Разграничение доступа (матрица прав)

Если вам удобнее структурировано — заполните матрицу прав. Это то же самое, что “права доступа” выше, только в более формальном виде. Достаточно основных сущностей: заявки, клиенты, документы, отчёты, настройки + ключевые действия (просмотр/создание/редактирование/удаление/экспорт/смена статусов).

Матрица прав (в текстовом виде или таблицей ссылкой):
Можно просто вставить ссылку на Google Sheet/Notion и кратко пояснить. Если заполняете текстом — пишите “роль → сущность → действия → видимость (свои/филиал/все)”.

Нужны ли права на уровне строк (row-level security):
Это ограничение “не по роли вообще”, а по конкретным записям: кто видит какие именно заявки/заказы. Примеры: видеть только свои, только своей команды, только своего филиала, только клиентов, закреплённых за менеджером.

Какие действия должны требовать особых прав (опасные/финансовые/удаление):
Это список действий, которые нельзя делать “просто так”. Примеры: удаление, экспорт базы/клиентов, изменение цены/скидок, изменение прав/ролей, массовые операции, просмотр финансов, закрытие без документов. Можно указать: кто может, и нужно ли подтверждение/комментарий.

4.6 Приватность и соответствие (если актуально) Есть ли требования по GDPR/152-ФЗ/другим регуляциям?

Сроки хранения и правила удаления/анонимизации мы фиксируем ниже в разделе 5.6: “Сроки хранения данных и правила удаления/анонимизации”. Здесь достаточно указать только регуляции/ограничения, если они есть.

5. Данные и сущности

Раздел 5 — про “какие карточки/таблицы будут в системе” и какие данные в них храним. Если проще: перечислите объекты, с которыми вы работаете каждый день (заявка, клиент, заказ, документ, оплата и т.п.).

Пример: сущности для сервиса/CRM (упрощённо)

Клиент: ФИО/компания, контакты, реквизиты.
Заявка: источник, тип, адрес, приоритет, статус, ответственный, сроки.
Работа/Выезд: дата/время, мастер, чек-лист, фото до/после.
Документ: договор/акт/счёт (шаблон + номер + PDF).
Оплата: сумма, статус оплаты, дата, способ оплаты (если актуально).

5.1 Основные сущности системы Перечислите ключевые сущности (например: Заявка, Клиент, Заказ, Объект, Сотрудник):
Сущность = “объект” в системе (карточка/таблица). Советы: выпишите всё, что нужно учитывать и связывать между собой. Примеры: “Заявка”, “Контрагент”, “Договор”, “Счёт”, “Платёж”, “Филиал”, “Товар/услуга”, “Задача”, “Комментарий”.

Для каждой сущности — основные поля (если знаете):
Полезно описывать: обязательные поля, вычисляемые поля, справочники/статусы, уникальные поля (например, номер договора), а также кто заполняет и на каком этапе.

Связи между сущностями (кто с чем связан):
Пример связей: “клиент 1 → много заявок”, “заявка 1 → много файлов”, “заказ 1 → много оплат”, “филиал 1 → много сотрудников”. Если есть “многие-ко-многим” (несколько исполнителей на задачу) — отметьте.

Нужны ли статусы? Опишите статусы и переходы:
Совет: статусы лучше делать “говорящими” и конечными. Пример: “Новая → В работе → Ожидаем клиента → Завершена/Отменена”. Укажите запрещённые переходы и что является “закрытием”.

Нужно ли хранение истории статусов/изменений:
Если “да” — уточните, что именно важно: кто поменял статус, кто редактировал поля, кто удалил/экспортировал данные.

5.2 Файлы и вложения Нужны ли вложения (фото, документы, PDF)? Опишите:
Укажите: какие типы файлов, на каких этапах нужны, кто загружает, кому доступны и нужно ли хранить версии.

Лимиты и форматы (пример: до 20MB, jpg/pdf):
Совет: укажите максимальный размер одного файла, общий лимит на объект и разрешённые форматы.

Нужна ли галерея/привязка файлов к этапам/комментариям:
Пример: “фото привязано к этапу ‘Выезд’”, “договор — к этапу ‘Подписание’”, “файл — в комментарии”.

5.3 Справочники, теги, классификаторы Какие справочники нужны (перечни значений):
Например: типы заявок, категории, причины отмены, источники, статусы оплаты, приоритеты.

Нужны ли теги/метки (tagging) и для чего:
Например: быстрые метки для фильтрации, “VIP”, “проблемный клиент”, “срочно”.

Нужны ли пользовательские поля (custom fields), которые админ сможет добавлять сам?

5.4 Импорт и миграция данных

Если миграция нужна — важно заранее понять источники, формат и качество данных.

Откуда мигрируем данные (системы/таблицы/файлы):
Пример: “Excel в Google Drive”, “старая CRM”, “1С”, “почта”, “формы на сайте”, “AmoCRM”.

Какие сущности нужно перенести (клиенты, заявки, история статусов, файлы):
Совет: перечислите по сущностям и приблизительные объёмы (кол-во записей/файлов).

Требуется ли перенос истории (комментарии, статусы, события) или достаточно текущего состояния?
Чем больше истории переносим — тем сложнее миграция, но тем легче работать без “разрыва контекста”.

Кто отвечает за подготовку/очистку данных (удаление дублей, выравнивание форматов):
Важно заранее назначить ответственных: бизнес обычно лучше понимает “что правда”, а разработка — формат и требования.

Сценарий запуска: одноразовая миграция или нужно “синхронизировать” параллельно какое-то время:

5.5 Нумерация, идентификаторы, документы Нужна ли нумерация объектов (заявка №, заказ №) и по каким правилам:
Пример: ORD-2026-000123, с префиксом филиала, по году/месяцу.

Нужны ли QR/штрихкоды для объектов/документов:

Есть ли внешние идентификаторы (ID из 1С/сайта/партнёров), которые нужно хранить и по ним синхронизировать:
Пример: ID заказа на сайте, ID клиента в 1С, номер заявки у партнёра. Важно для интеграций и дедупликации.

5.6 Архивирование, удаление, жизненный цикл данных Правила архивирования/закрытия (когда объект считается завершённым, что делать с доступом):
Пример: “после закрытия заявка доступна для чтения всем, редактировать можно только 7 дней”, “через 90 дней — в архив”.

Сроки хранения данных и правила удаления/анонимизации (если есть):
Если есть требования закона/комплаенса — укажите. Если нет — можно предложить разумные сроки.

Нужно ли “мягкое удаление” (soft-delete) с восстановлением:
Soft-delete обычно безопаснее: можно восстановить ошибочно удалённые данные и сохранить аудит.

6. Функциональные требования

Раздел 6 — “что система должна уметь делать”. Лучше описывать сценариями: кто нажимает, что вводит, что получает на выходе. Если вы не уверены в формулировках — напишите пример реальной ситуации.

Пример: сценарий в 5 строк (как писать)

Роль: менеджер → Создаёт заявку → Заполняет поля → Назначает мастера → Клиенту уходит уведомление → Руководитель видит заявку в отчёте “в работе”.

6.1 Модули Какие модули нужны (список):
Модуль — это отдельный раздел системы (обычно: список → карточка → действия), который отвечает за один кусок работы или данных. Например, “Заявки” или “Клиенты” — это модули, потому что там есть список, фильтры, карточка, история и действия.
Напишите 5–25 модулей. Для каждого достаточно 1–2 строк: что хранит/делает + кто пользуется + ключевые действия. Если пока не уверены — откройте подсказку ниже: там варианты модулей и готовые наборы.

Подсказка: какие модули бывают (примеры по категориям)

Не обязательно иметь всё. Выберите то, что реально нужно “в бою”. Остальное можно отложить на этап 2–3.

Основной процесс: Заявки/Обращения, Заказы/Сделки, Этапы/Статусы, Задачи/Подзадачи, Календарь/планирование, Выезды/маршруты, Проверки/QA.
Клиенты и справочники: Клиенты/Контакты, Компании/контрагенты, Объекты/адреса, Услуги/номенклатура, Прайс/тарифы, Причины отказа/возврата, Типы заявок.
Документы и файлы: Документы/вложения, Акты/сметы/КП, Шаблоны документов, Печать/PDF, Версии документов, Подпись/согласование.
Финансы (если нужно): Счета, Платежи, Возвраты, Начисления/стоимость работ, Долги/лимиты, Комиссии/скидки.
Склад/материалы (если нужно): Остатки, Поступления/списания, Закупки, Поставщики, Резервирование под заказ, Серии/партии.
Коммуникации: Комментарии/обсуждения, Уведомления, Шаблоны сообщений, История контактов (звонки/почта/Telegram), Подписчики объекта.
Аналитика: Отчёты, Дашборды, KPI, Просрочки, Нагрузка по людям/филиалам, Экспорт в Excel, История изменений (audit log).
Администрирование: Пользователи, Роли/права, Настройки процессов (статусы/поля), Справочники, Интеграции/API, Webhooks, Импорт/экспорт, Архив.
Для клиентов/партнёров (опционально): Кабинет клиента, Публичная форма заявки, Статус заказа, Оплата онлайн, Портал партнёра.
Поддержка/обучение (опционально): Тикеты/поддержка, База знаний/инструкции, FAQ.

Примеры готовых наборов модулей (если не знаете с чего начать)

Сервисная компания (заявки/выезды): Заявки → Клиенты → Выезды/расписание → Исполнители → Материалы → Документы (фото/акт) → Отчёты → Настройки/роли.

CRM продаж: Лиды → Контакты/компании → Сделки → Задачи/календарь → Коммерческие предложения/счета → Оплаты → Отчёты/воронка → Настройки/права.

Производство/склад: Заказы → Техкарты/операции → Партии/серии → Склад/остатки → Закупки/поставщики → Контроль качества → Документы → Отчёты.

Мини‑шаблон: как описать модуль в 1–2 строках

Модуль: …
Зачем нужен: … (какую проблему решает)
Кто пользуется: … (роли)
Действия: создать / редактировать / менять статус / прикреплять файлы / экспорт …
Ключевые поля: … (3–10 самых важных)

Какие действия выполняют пользователи (сценарии):
Опишите сценарии по ролям: “менеджер создаёт заявку”, “исполнитель закрывает этап”, “клиент подтверждает работу”. Чем больше реальных сценариев — тем точнее оценка и реализация.

Нужны ли шаблоны/техкарты/чек-листы? Опишите:
Пример: “шаблон заявки по типу услуги”, “чек-лист выезда”, “техкарта ремонта”, “скрипт звонка”.

Нужны ли комментарии/обсуждения внутри объектов?
Если “да” — уточните: комментарии приватные/публичные, с файлами, с упоминаниями, с историей редактирования.

Нужны ли упоминания (@user) и уведомления из комментариев?
Пример: @Иван — уведомить в Telegram, отметить в ленте, добавить в подписчики объекта.

6.2 Поиск, фильтры, представления Нужен ли глобальный поиск? По каким полям?
Примеры полей: номер заявки, телефон, email, название компании, адрес, VIN/серийный номер, комментарии.

Какие фильтры нужны (статус, дата, ответственный и т.п.):
Совет: перечислите фильтры “по умолчанию” и продвинутые (сохранённые фильтры, быстрые пресеты).

Какие представления нужны (таблица, канбан, календарь, карта, список):
Подсказка: укажите для каких ролей какие представления удобны и какие колонки/карточки важны. Пример: менеджер — таблица + фильтры, руководитель — канбан по статусам, выезды — календарь/карта.

Экспорт/импорт (Excel/CSV/PDF):
Уточните: что экспортируем, кто может, какие шаблоны/форматы, и нужен ли импорт обратно (обновление данных).

6.3 Операции с объектами и массовые действия

Какие массовые операции нужны (можно несколько) Массовая смена статуса
Массовое назначение ответственного
Массовые теги/метки
Массовый экспорт
Массовое удаление/архивирование
Массовое изменение полей
Массовая печать/генерация документов
Другое

Правила для массовых операций (кто может, ограничения, подтверждения):

Нужны ли действия “копировать объект”, “создать по шаблону”, “создать на основе предыдущего”:
Пример: “создать повторный заказ на основе прошлого”, “скопировать заявку вместе с чек-листом”.

6.4 Задачи, календарь, планирование Нужен ли встроенный список задач (to-do) и привязка задач к объектам?
Если “да” — уточните: статусы задач, напоминания, повторяющиеся задачи, зависимости, контроль выполнения.

Нужны ли календарные представления/планирование ресурсов:
Например: календарь выездов, загрузка мастеров, бронирование времени.

Напоминания по задачам/срокам (внутри системы/внешние каналы):
Пример: “за 24 часа до срока”, “каждый день пока просрочено”, “эскалация руководителю через 2 дня”.

6.5 Документы, шаблоны, печатные формы Какие документы нужно генерировать из системы (договор, акт, счет, накладная):
Уточните: когда генерируется, кто видит, нужен ли номер/серия, подпись, печать, хранение версий.

Нужны ли шаблоны документов и переменные поля (подстановка данных):
Пример переменных: {номер_заявки}, {клиент}, {сумма}, {адрес}, {дата}. Можно указать ссылку на текущие шаблоны.

Нужна ли электронная подпись/подтверждение (OTP, ЭЦП, подпись пальцем на мобильном):
Уточните юридическую значимость: достаточно “подтвердить кодом” или нужна квалифицированная ЭЦП.

6.6 Финансы/оплаты (если применимо) Нужно ли выставление счетов/оплат/статусы оплаты внутри системы:
Если “да” — уточните: валюта, частичные оплаты, связь с документами, интеграции с банком/эквайрингом.

Если оплаты нужны — опишите сценарии (предоплата, частичная оплата, возвраты, скидки):
Пример: “50% предоплата → выезд → доплата”, “возврат при отмене”, “скидка по промокоду”.

6.7 Личный кабинет клиента / партнёра (если нужен) Нужен ли вход для клиентов/партнёров (личный кабинет):
Это отдельный доступ для внешних пользователей: они видят только свои заявки/заказы, могут загружать документы и получать уведомления. Если кабинет не нужен — пропустите.

Что клиент/партнёр должен видеть и уметь делать в кабинете:

Нужны ли публичные формы (без входа) для создания заявки/обращения:
Пример: форма на сайте / ссылка из Telegram / QR‑код — создаёт новую заявку со статусом “Новая”.

Нужна ли “проверка статуса” без входа (по номеру/телефону):
Пример: клиент вводит номер заявки и видит текущий статус + следующий шаг (без лишних данных).

6.8 Настройки и админ‑панель (чтобы менять без разработчика) Нужно ли, чтобы администратор мог настраивать систему без программиста:
Примеры настроек: добавить новый статус, изменить обязательность поля, создать новый тип заявки, изменить шаблон документа/сообщения, включить/выключить правила, управлять справочниками.

Что именно должно настраиваться через интерфейс (списком):
Если уже описали в TO‑BE/ролях — можно просто перечислить кратко, чтобы зафиксировать важность.

Нужен ли аудит админских изменений (кто поменял настройки и когда):
Полезно, если процесс и правила часто меняются — видно, кто и почему внёс правку.

6.9 Дополнительные функции (выберите, что интересно)

Это “каталог возможностей”. Отметьте, что хочется видеть в системе — даже если пока не уверены. Детали мы уточним в соответствующих разделах (интеграции — в 8, интерфейсы — в 9, отчёты — в 10).

Удобство и скорость работы

Сохранённые фильтры/пресеты (“Мои”, “Просроченные”, “На сегодня”)
Теги/метки + быстрые подборки
Лента активности по объекту (что изменилось и кем)
Подписчики/наблюдатели (получать уведомления по объекту)
Быстрые действия в карточке (1‑клик: назначить/закрыть/вернуть)
Умное обнаружение дублей (похожие клиенты/заявки)

Контроль, качество, согласования

Согласования (скидки/сметы/изменения/закрытие) с историей решений
Чек‑листы по этапам (обязательные пункты перед переходом)
Обязательная причина/комментарий при отмене/возврате/изменении цены
Роль “контролёр качества” / отдельный этап проверки

Документы и файлы

Версии файлов/документов (кто заменил и когда)
Фото‑галерея в карточке (до/после, подписи)
Поиск по тексту документов (OCR) — если много PDF/сканов

Выезды, география, ресурсы

Карта объектов/клиентов + маршруты
Запись на время/слоты (календарь доступности)
Гео‑отметка “прибыл/уехал” (если актуально)
QR/штрихкод сканирование (объекты/материалы/документы)

Коммуникации с клиентом

Чат/переписка с клиентом внутри заявки (с историей)
Шаблоны сообщений (SMS/Email/Telegram) + переменные
История звонков/контактов (если есть телефония)

Интеграции и внешние доступы

Публичный API для партнёров (ограниченный доступ)
Webhooks “по событиям” (создано/изменено/оплачено)
Импорт из Excel “с сопоставлением полей” (не просто CSV)

Финансы (если актуально)

Расчёт стоимости по правилам (прайс/работы/материалы/скидки)
Онлайн‑оплата (эквайринг) + статусы оплаты
Мультивалюта / разные прайсы по филиалам
Если отметили что-то выше — какие детали/пожелания важны:

7. Автоматизация, события, уведомления

Раздел 7 — как убрать ручную рутину: напоминания, автоназначение, эскалации, “если произошло X — сделай Y”. Если не знаете, что автоматизировать — просто перечислите “что сейчас люди делают вручную каждый день”.

Пример правила if/then (очень понятно)

Если статус “Новая” и прошло 30 минут то уведомить менеджера и руководителя.
Если заявка просрочена на 2 часа то повысить приоритет до P1 и эскалировать.
Если клиент отменил то попросить причину и закрыть с меткой “Отмена”.

7.1 Уведомления Куда и кому уведомлять?
Заполните “роль → канал”. Так вы можете задать разные каналы для разных людей. Пример: Клиент — SMS/email, Менеджер — Telegram/внутри системы, Руководитель — email. Если одной роли нужны 2 канала — добавьте эту роль второй строкой.

Роль (кому):
Канал связи:

Можно добавить до 12 строк. Если точный канал неизвестен — пишите “уточним” и опишите логику ниже.

Какие события уведомлять (пример: новый объект, смена статуса, просрочка):
Опишите по ролям: кого уведомляем и зачем. Советы: избегайте спама, делайте “важно/неважно”.

Нужны ли напоминания по расписанию (каждый день/час)? Опишите:
Пример: “каждое утро список просрочек руководителю”, “каждый час напоминать исполнителю пока не взял в работу”.

7.2 Автоматические действия (правила) Какие правила автоматизации нужны (if/then):
Формат if/then: “Если (событие/условие) → то (действие)”. Пример: “если статус = ‘Просрочено’ → уведомить руководителя и поставить приоритет P1”.

Нужны ли фоновые задачи (то, что система делает сама “в фоне”, без кнопки пользователя):
Это задачи, которые запускаются по расписанию или автоматически: синхронизация с внешними системами, пересчёты показателей, проверка просрочек, генерация отчётов/файлов, отправка напоминаний, “чистка” и порядок в данных. Если сейчас кто‑то делает это вручную “раз в час/день/неделю” — скорее всего, это как раз фоновая задача. Если ничего такого не нужно — напишите “не нужно”.

Примеры простыми словами (что сюда писать)

Синхронизация: “каждые 15 минут подтягивать оплаты из банка/1С; если ошибка — сообщить бухгалтерии”.
Пересчёт: “ночью пересчитать остатки/балансы/стоимость/метрики; утром отправить сводку руководителю”.
Напоминания: “каждый час проверять просроченные задачи и напоминать исполнителю; через 2 часа — эскалация руководителю”.
Документы: “после статуса ‘Готово’ автоматически сформировать PDF счёт/акт и прикрепить в карточку”.
Импорт/экспорт: “раз в сутки выгружать реестр в Excel и отправлять на email/в папку”.
Порядок в данных: “чистить дубликаты, архивировать старые записи, удалять временные файлы/черновики”.

7.3 Шаблоны уведомлений и тон коммуникации Нужны ли шаблоны сообщений (email/SMS/push) с подстановкой переменных?
Например: “Здравствуйте, {name}. Статус заявки #{id} изменился на {status}”.

Тон сообщений (официально/дружелюбно/коротко) и обязательные элементы:
Опишите, как именно должны звучать уведомления: на “вы” или на “ты”, строго/нейтрально/дружелюбно, максимально коротко или с пояснениями. Укажите, можно ли смайлы/эмодзи, допустим ли “продающий” тон, и где нужно быть максимально сухими (например, про оплату/документы). Также перечислите, что обязательно должно быть в каждом сообщении: кто пишет (компания/бренд), о чём (номер/объект), что делать (следующий шаг), ссылка (на кабинет/карточку), контакты и важные ограничения (не раскрывать персональные данные и т.п.).

Примеры “как может выглядеть”

SMS (коротко): “Сервис: заявка #124 назначена на 12:00. Детали: ссылка. Вопросы: +380…”.
Email (подробнее): “Здравствуйте, Иван. Статус заявки #124: ‘В работе’. Следующий шаг: уточнить адрес. Перейти: ссылка. Контакты/график: …”.
Telegram / внутри системы: “Новая просрочка: заявка #124, дедлайн 14:00. Открыть карточку: ссылка. Действие: взять в работу/перенести срок (с причиной)”.

7.4 Настройки уведомлений пользователями Могут ли пользователи настраивать уведомления (вкл/выкл события/каналы)?
Пример: менеджер выключает “каждый комментарий”, но оставляет “просрок/назначение”.

Нужны ли “тихие часы” (не присылать ночью) и по каким правилам:
Совет: для критичных событий (P1) можно исключить “тихие часы”, а для остального — переносить на утро.

Нужно ли отслеживание доставки (доставлено/прочитано) для критичных уведомлений:
Если “да” — уточните, что делать если не доставлено/не прочитано: повтор, эскалация, смена канала.

7.5 Автоматизация — детализация правил

Чем точнее описаны триггеры/условия/действия — тем меньше “сюрпризов” при внедрении.

Триггеры автоматизаций (что запускает правило):
Пример: создание объекта, смена статуса, наступление срока, изменение поля, входящий webhook.

Кто может создавать/редактировать правила (админ, руководитель, бизнес-пользователь):
Совет: ограничьте создание правил, чтобы избежать хаоса, но оставьте “настройки” для руководителей.

Что делать при конфликте правил (если два правила срабатывают одновременно):
Пример: приоритеты правил, порядок выполнения, “последнее победило”, блокировка статуса, запись в лог.

Нужна ли возможность “ручного переопределения” автоматизации (override):
Пример: админ может вручную сменить статус, даже если правило запрещает, но это фиксируется в аудите.

8. Интеграции

Интеграция = обмен данными между системами (1С, сайт, телефония, SMS, BI и т.п.). Если сомневаетесь, нужна ли интеграция — ответьте на простой вопрос: “какие данные мы не хотим переносить руками?”

Пример “карточки интеграции” (как описывать)

Система: 1С
Зачем: подтягивать оплаты и выставлять счета
Данные: заказ → сумма/статус оплаты; клиент → реквизиты
Способ: API или выгрузка файлами (если API нет)
Частота: каждые 10 минут, допустимая задержка 30 минут

8.1 Внешние системы С чем нужно интегрироваться (список):
Примеры: 1С/ERP, CRM, телефония, почта, SMS, платежи, карты, склад, BI, сервис-деск, маркетинг.

Какие данные туда/сюда (что отправляем, что получаем):
Совет: укажите направления и поля: “отправляем статусы/суммы”, “получаем клиентов/оплаты”, “создаём лиды”.

Формат интеграций:
Если есть ограничения (нельзя открывать API наружу, только через VPN/прокси) — напишите.

Частота синхронизации / требования к реальному времени:
Примеры: “в реальном времени”, “каждые 5 минут”, “раз в сутки ночью”. Укажите допустимую задержку.

8.2 Детализация интеграций (по каждой системе)

Для каждой интеграции укажите: цель, направление данных, способ авторизации, критичность, и что считается ошибкой.

Перечень интеграций с деталями (можно в виде списка):

Доступ и безопасность интеграций (как подключаться, кто выдаёт доступ):
Простыми словами: чтобы система могла “разговаривать” с 1С/CRM/платёжкой, ей нужен ключ доступа. Это может быть API‑ключ/токен, OAuth, логин‑пароль “служебного пользователя”, сертификат, VPN и т.п. Здесь важно понять: кто выдаёт доступ, какие ограничения и что делать при ошибке. Секреты/пароли сюда не вставляйте — достаточно описания и контакта ответственного.

Примеры (как это выглядит в реальности)

API‑ключ (токен): “в 1С включён API, ключ выдаёт админ 1С; ключ бессрочный, но меняем раз в 3 месяца; доступ только на чтение оплат”.
OAuth (вход через аккаунт): “подключаемся к Google/amoCRM через OAuth; кто авторизует: руководитель отдела; доступ ограничить правами роли”.
VPN / доступ по IP: “API доступно только из VPN, нужно добавить наш сервер в белый список IP; ответственность: системный администратор”.
Файлы вместо API: “раз в день выгружаем CSV в папку/почту; кто даёт доступ: бухгалтерия; формат файла фиксированный”.

Маппинг данных (соответствие полей) и правила конфликтов:
Например: если имя изменилось в двух системах — что “побеждает”.

8.3 Webhooks/события Какие события система должна отдавать наружу (webhooks):
Например: создана заявка, изменился статус, просрочка, создан документ.

Какие события система должна принимать извне (inbound webhooks):
Пример: “поступила оплата”, “обновился статус в 1С”, “создан лид на сайте”.

Безопасность вебхуков (как убедиться, что запрос “настоящий”, а не от посторонних):
Вебхук — это входящий запрос в вашу систему “по событию”. Важно защититься от ситуации, когда кто‑то посторонний отправит такой же запрос и подделает событие (например, “оплата прошла”). Самые частые меры: секрет + подпись (проверка “как пароль”), белый список IP (принимать только с IP сервиса), VPN, а также защита от повторов (чтобы один и тот же запрос не обработался 10 раз). Секретные ключи сюда не вставляйте — достаточно описать требования и кто это настраивает.

Примеры (что выбрать, если вы не технарь)

Секрет + подпись: “сервис присылает подпись, мы проверяем её по секрету; без подписи запрос игнорируем”.
IP allowlist: “принимаем вебхуки только с IP платёжки/CRM (их список даёт поставщик)”.
Защита от повторов: “у каждого события есть ID; если такой ID уже был — повтор не обрабатываем”.
Безопасный транспорт: “только HTTPS; без шифрования не принимаем”.

8.4 Импорт/экспорт файлами Какие файлы нужно импортировать/экспортировать (CSV/Excel/PDF) и по каким шаблонам:

Как часто и кем это делается (автоматически/вручную):
Уточните ответственных и контроль ошибок: кто замечает, что импорт не прошёл, и что делаем дальше.

8.5 Надёжность интеграций

Раздел 8.5 — про “что будет, если что-то пошло не так”. Интеграции иногда падают: внешний сервис недоступен, интернет “моргнул”, лимит API закончился, или пришли данные с ошибкой. Чтобы бизнес не стоял, заранее решаем: повторяем ли попытки, куда складываем ошибки, кто видит проблему и как быстро нужно реагировать.

Повторы и “очередь ошибок” (что делаем, если синхронизация не прошла с первого раза):
Простыми словами: если не удалось отправить/получить данные — система может попробовать ещё раз. Если всё равно не получилось — сохранить попытку в список ошибок (очередь) и дать возможность повторить вручную. Это защищает от ситуаций “оплата есть, а в системе не обновилось” или “заказ не ушёл в 1С”.

Примеры (можно выбрать как “по умолчанию”)

Безопасный стандарт: 3 повтора (через 1/5/15 минут) → потом в “очередь ошибок” → уведомление ответственному.
Для критичных событий (оплата/доставка): больше повторов + эскалация руководителю, если не прошло за 30–60 минут.
Статусы на карточке: “в синхронизации” / “ошибка” / “успешно” + кнопка “повторить”.
Защита от дублей: если одно и то же событие пришло повторно — не создавать второй раз (по ID заказа/платежа).

Мониторинг и алерты (как быстро узнаём, что интеграция сломалась):
Алерт = автоматическое уведомление ответственному, что “что-то пошло не так”. Укажите: когда бить тревогу (порог), кому и куда (Telegram/email), и что делать в первом шаге. Если алерты не нужны — так и напишите, но тогда важно указать, кто и как проверяет ошибки вручную.

Примеры алертов (понятно)

Задержка: “не было синхронизации 30 минут” → Telegram ответственному.
Много ошибок: “ошибок > 5 за 10 минут” → Telegram + запись в журнал.
Лимит API: “осталось < 10% лимита запросов” → уведомить заранее.
Критичная ошибка: “оплата пришла, но не применена” → эскалация руководителю.

9. Интерфейсы и UX

Раздел 9 — про удобство: какие экраны нужны, какая навигация, что должно заполняться быстро, где важны подсказки. Если сложно — перечислите “какие страницы вы бы хотели видеть в меню”.

Пример: ключевые экраны для системы заявок

Список заявок (фильтры + быстрые действия)
Карточка заявки (данные + история статусов + комментарии + файлы)
Календарь/планирование (если есть выезды/расписание)
Отчёты (просроки, нагрузка, KPI)
Настройки (роли, справочники, интеграции)

Шаблон: как описать экран (простая структура)

Если вы опишете экран по этому шаблону — оценка и проектирование UI становятся намного точнее.

Для кого: роль (кто будет пользоваться этим экраном).
Зачем: цель экрана (“быстро найти просрочки”, “создать заявку за 30 секунд”, “увидеть историю общения”).
Что видно сразу: ключевые блоки/колонки (что должно быть “на первом экране”).
Что можно сделать: действия (кнопки) + быстрые действия из списка.
Поиск/фильтры: как находят нужное (по номеру/телефону/статусу/дате/ответственному).
Ошибки/подсказки: что показываем, если данных нет/ошибка/не хватает прав.
Особенности: мобильные сценарии, оффлайн, печать, обязательные поля по статусам.

Пример описания (как выглядит “хороший ответ”): экран “Список заявок”

Цель: за 10–20 секунд понять: что срочно, кто перегружен, где просрочки.
Колонки: №, статус, дедлайн, клиент, адрес/город, ответственный, сумма (если важно), последний комментарий.
Фильтры: “мои”, “сегодня”, “просрочено”, “по статусу”, “по городу”, “по источнику (сайт/телеграм)”.
Быстрые действия: назначить ответственного, сменить статус, поставить дедлайн, написать клиенту, добавить комментарий.
Пустое состояние: “Заявок нет — создайте первую” + кнопка “Создать”.
Ошибки: если не хватает прав — “Обратитесь к администратору (контакт)”.

9.1 Платформы

Где будет работать система? (можно выбрать несколько)

Пример: “в офисе — веб, на выезде — телефон”. Если есть ограничения по устройствам/браузерам/корп.среде (VPN/прокси) — лучше указать сразу.

Веб (браузер)
Мобильный веб (в браузере на телефоне)
Мобильное приложение (iOS/Android)
Десктоп (Windows/macOS)
Смешанное / несколько платформ (уточню)
Не знаю

Нужна ли админ-панель? Что в ней должно быть:
Админ‑панель — это раздел для “администратора” (обычно 1–3 человека), где настраиваются пользователи, роли, справочники, процессы, интеграции и прочее. Если админка не нужна — так и напишите (“нет”), а пункты ниже оставьте пустыми.

Типовые разделы админ‑панели (можно выбрать несколько) Пользователи, роли, права доступа
Справочники/каталоги (типы работ, причины, статусы, города и т.п.)
Настройка процессов/статусов/переходов (воронки, правила)
Настройка форм и полей (обязательность, подсказки, скрытие по ролям)
Шаблоны уведомлений (email/SMS/Telegram) + события
Интеграции (ключи/доступы, лимиты, статусы синхронизации)
Импорт/экспорт данных, массовые операции
Журнал действий (audit): кто что менял, кто выгружал/удалял
Логи ошибок/мониторинг (что сломалось, когда, детали)
Документы/шаблоны печати (счета/акты/поля)
Тарифы/оплаты/лимиты (если есть подписка)
Другое (опишу ниже)

Нужны ли дашборды/аналитика? Какие метрики:
Совет: опишите дашборды по ролям и какие “проваливания” в детали нужны (из KPI → список заявок → карточка).

9.2 Языки, доступность Язык интерфейса:

Нужна ли мультиязычность? Опишите:
Уточните языки, что переводим (интерфейс/уведомления/документы) и нужен ли выбор языка по пользователю.

Требования по доступности (A11y) — чтобы интерфейс был удобен людям с разным зрением/устройствами:
Если проще: это про то, чтобы системой можно было комфортно пользоваться, даже если у человека слабое зрение, он работает только с клавиатуры, или использует “озвучивание” (скринридер). Если специальных требований нет — напишите “нет”. Если есть корпоративные требования/стандарты — укажите их (например, WCAG 2.1 AA).

Примеры (что обычно относится к A11y)

Контраст и читабельность: текст не “серый на сером”, достаточный размер шрифта, понятные состояния кнопок.
Клавиатура: можно пройти форму Tab‑ом, видно фокус, Enter/Space работают на кнопках.
Подписи полей: у каждого поля есть понятная подпись, ошибки объясняют “что сделать”.
Скринридер: элементы имеют корректные названия, структура страницы логичная.
Не полагаться только на цвет: “ошибка” должна быть не только красным цветом, но и текстом/иконкой.

9.3 Навигация и ключевые экраны

Опишите, какие разделы должны быть в меню и какие страницы/экраны — ключевые для работы.

Структура меню/разделов (как вы видите навигацию):

Ключевые экраны/страницы (перечень):
Например: список заявок, карточка заявки, карточка клиента, календарь, отчёт, настройки.

Какой “главный экран” должен открываться после входа (для разных ролей):

Какие действия должны быть доступны прямо из списка (быстрые действия, чтобы не заходить в карточку):
Примеры: назначить ответственного, сменить статус, поставить дедлайн, добавить комментарий, отправить сообщение клиенту, распечатать/скачать документ. Это сильно ускоряет работу и уменьшает “лишние клики”.

Нужно ли по ролям менять меню/видимость разделов (что кому показывать):
Пример: клиент видит только “Мои заявки”, сотрудник — “Мои задачи”, руководитель — “Все + отчёты”.

9.4 Формы, поля, валидации

Подсказка: что такое валидации/ограничения (простыми словами)

Валидация — проверка, что пользователь ввёл корректные данные (телефон в нужном формате, сумма не отрицательная).
Ограничение — правило, которое не даёт сделать “неправильное” действие (нельзя закрыть заявку без причины/фото).
Цель — меньше ошибок и меньше ручных “дозвонов/уточнений”.

Какие поля должны заполняться быстро (автозаполнение/подсказки/шаблоны):
Примеры: автоподстановка клиента по телефону, шаблоны адресов, подсказки из справочников, копирование из прошлой заявки.

Нужны ли маски ввода (телефон, ИНН, дата) и какие форматы:

Какие ошибки/подсказки должны показываться пользователю (текст, примеры):
Совет: пишите сообщения “что сделать”, а не “ошибка”. Пример: “Введите телефон в формате +38…” вместо “Invalid”.

Нужны ли “обязательные поля” по ролям/этапам (динамическая обязательность):
Пример: “перед ‘Счёт выставлен’ обязательна сумма и реквизиты”, “перед ‘Закрыто’ обязательны фото и комментарий”.

Нужны ли черновики/автосохранение при заполнении форм в самой системе:
Пример: пользователь начал заполнять заявку, отвлёкся, закрыл вкладку — при возвращении черновик восстановился.

Подтверждения/отмена действий (где нужен “Вы уверены?” и где нужен “откатить”):
Примеры: удаление/архив, массовые действия, смена статуса “Закрыто”, отмена оплаты, изменение ответственного. Если нужна возможность “откатить” — напишите для каких действий и в течение какого времени.

9.5 Мобильные сценарии (если есть)

Какие мобильные функции нужны (можно несколько) Камера/фото
Геолокация
Оффлайн-режим
Push-уведомления
Сканер QR/штрихкода
Подпись пальцем
Другое

Опишите мобильные сценарии (кто, где, что делает):
Пример: “исполнитель на объекте делает фото, отмечает время и гео, заполняет чек-лист, клиент подписывает”.

Если нужен оффлайн-режим — что должно работать без интернета:

9.6 Брендинг и визуальные предпочтения (без реализации стилей здесь) Есть ли брендбук/гайд (логотип, цвета, шрифты) и где он лежит (ссылка):
Если брендбука нет — можно описать словами: “строго/делово”, “минимализм”, “ярко”.

Предпочтения по “настроению” интерфейса (строго/минималистично/ярко):
Можно дать референсы: 2–5 ссылок/скриншотов “как нравится” и “как не нравится”.

Нужна ли тёмная тема (dark mode):
Если пользователи много работают ночью/в офисе — dark mode часто повышает комфорт.

9.7 Подсказки, обучение, справка Нужны ли подсказки в интерфейсе (tooltips), примеры заполнения, “пустые состояния”:
Пример “пустого состояния”: “У вас пока нет заявок — нажмите ‘Создать’”. Подсказки особенно важны на сложных формах.

Нужны ли инструкции/база знаний внутри системы (FAQ/справка):
Если “да” — уточните: доступ по ролям, поиск, структура разделов, кто обновляет.

Нужен ли онбординг новых пользователей (экран/тур/обучение):
Пример: короткий тур 5 шагов при первом входе + ссылки на инструкции.

9.8 Списки, поиск, массовые действия

Этот блок помогает сделать работу быстрой: найти нужное, отфильтровать, сделать действие “пачкой”, не открывая 50 карточек.

Что должно быть видно в списках/таблицах (ключевые колонки) — по основным объектам:
Совет: колонки должны отвечать на вопрос “что срочно” и “кто отвечает”. Пример: статус, дедлайн, ответственный, клиент, сумма.

Поиск: по чему ищем и как быстро должны находиться записи:
Примеры: поиск по телефону/номеру/имени/адресу, “умный” поиск без точного совпадения, поиск по комментариям/файлам (если нужно).

Фильтры/сортировки/сохранённые представления (“Мои сегодня”, “Просрочено” и т.п.):
Если пользователи часто работают по одним и тем же срезам — лучше сделать сохранённые виды.

Массовые действия (если актуально) Назначить ответственного
Сменить статус/этап
Изменить приоритет
Проставить теги/категории
Экспорт в Excel/CSV
Отправить сообщение/уведомление группе
Архивировать/закрыть пачкой
Удаление (обычно ограничить)
Другое

Примечания по спискам/таблицам (настройка колонок, закрепление, пагинация):

9.9 Карточка объекта: комментарии, файлы, история

Карточка — это “центр управления” объектом (заявка/заказ/клиент). Тут важны: быстрые действия, история, обсуждения, документы, кто и что менял. Чем лучше продумана карточка — тем меньше хаоса в коммуникации и меньше потерь информации.

Пример структуры карточки заявки (понятно)

Шапка: номер, статус, приоритет, дедлайн, ответственный, кнопки действий.
Данные клиента: контакты, адрес, комментарий, история обращений.
Таймлайн: смены статусов, комментарии, звонки/сообщения, кто что сделал.
Файлы: фото/документы, предпросмотр, кто загрузил, когда.
Связанные сущности: задачи, оплаты, документы, выезды/слоты.

Какие блоки должны быть в карточке ключевых объектов (заявка/клиент/заказ):
Укажите по каждому объекту: что видно сразу, что можно свернуть, какие кнопки действий важны.

Комментарии/обсуждения: как должны работать?
Примеры: внутренние комментарии (только сотрудники), комментарии для клиента, упоминания @, шаблоны ответов, запрет редактирования после 5 минут, прикрепление файла к комментарию, реакции/статусы “прочитано”.

Файлы/вложения: какие типы, ограничения и удобство работы:
Пример: фото с телефона, PDF договор, сканы, видео. Укажите лимиты размера/количества и нужно ли хранение “по папкам”.

История изменений в интерфейсе (кто что поменял) — нужна ли и насколько подробная:
Если “да” — уточните: показываем только важное (статусы/ответственный) или все поля, и кто имеет доступ.

Печать/экспорт карточки (PDF) и “поделиться” (ссылка/файл клиенту):
Пример: “акт выполненных работ”, “заказ-наряд”, “сводка заявки”. Укажите, что обязательно должно быть в PDF.

10. Отчёты, аналитика, экспорт

Раздел 10 — чтобы руководитель и команда видели “что происходит”: просрочки, загрузку, причины отмен, KPI. Если не знаете, какие отчёты нужны — начните с вопроса: “какие цифры я смотрю каждую неделю?”

Пример KPI (простыми словами)

Время реакции: среднее время от “Новая” до “В работе”.
% просрочек: доля заявок, которые превысили SLA.
Загрузка: сколько заявок на каждого исполнителя в день.
Причины отмен: топ причин + динамика по месяцам.

Подсказка: как выбрать отчёты и KPI (без “аналитики ради аналитики”)

Шаг 1 (решения): какие решения вы принимаете каждую неделю? (“нанять ещё людей”, “менять процесс”, “выровнять нагрузку”, “увеличить конверсию”).
Шаг 2 (сигналы): какие цифры подсказывают, что “что-то пошло не так” (рост просрочек, падение конверсии, рост отмен).
Шаг 3 (действия): что вы сделаете, если метрика ухудшилась (кого уведомить, какие статусы/приоритеты менять, какие отчёты открыть).

Совет: на старте лучше 5–12 ключевых KPI + 5–15 отчётов, а остальное добавлять по мере работы. Но если вы заранее опишете пожелания — мы заложим правильные данные/структуру, и потом отчёты будут делаться быстрее.

10.1 Отчёты

Отчёт — это “ответ на вопрос бизнеса”. Чем точнее сформулирован вопрос — тем полезнее отчёт и тем быстрее им начинают пользоваться. Если не уверены — отметьте идеи в списке ниже, а затем в поле опишите детали (для кого/как часто/какие фильтры/какие колонки).

Какие отчёты нужны (перечень):
Совет: укажите для кого отчёт, как часто нужен, и что должно быть в фильтрах/группировках.

Каталог идей отчётов (можно отметить галочками)

Отмечайте только то, что реально поможет управлять процессом. Остальное можно добавить позже.

Операционные / процессы (почти всегда полезно) Очередь по статусам (сколько “Новых/В работе/Ожидает/Закрыто”)
Просрочки по SLA (что просрочено, на сколько, у кого)
Время реакции (создано → взято в работу) по ролям/каналам
Время выполнения (в работе → закрыто) + распределение по типам
Зависшие в статусе (долго без движения) + причины
Нагрузка по сотрудникам (сколько “в работе”, сколько “на сегодня”)
Производительность (сколько закрыто/день, по людям/филиалам)
Эффект автоматизации (сколько сработало правил, сколько сэкономили времени — если нужно)

Качество и контроль Возвраты/переработки (сколько раз возвращали на доработку и почему)
Причины отмен/отказов (топ причин + динамика)
Претензии/жалобы (кол-во, причины, сроки решения)
Качество по чек‑листам (если есть проверки/контроль качества)
Аудит действий: кто менял статусы/удалял/экспортировал (для контроля)

Продажи / маркетинг (если есть лиды/воронка) Воронка: конверсия по этапам (лид → сделка → оплата)
Источники (сайт/реклама/партнёры) + конверсия + стоимость лида (если есть)
Эффективность менеджеров (конверсия, скорость ответа, средний чек)
Причины проигрыша/потери сделки
Прогноз выручки (pipeline) по вероятности/срокам
План/факт (если есть план по продажам/выручке)

Финансы (если есть суммы/оплаты) Выручка и динамика (день/неделя/месяц) + сравнение периодов
Оплаты: оплачено/не оплачено/частично + сроки оплаты
Дебиторка (задолженность) по клиентам/срокам
Средний чек / средняя стоимость заказа
Маржинальность/прибыль (если есть себестоимость/расходы)
Возвраты/корректировки/скидки

Клиенты / сервис Повторные клиенты / retention (кто возвращается, через сколько)
Сегменты клиентов (частота, средний чек, категории услуг)
Оценки/NPS/CSAT (если собираете оценки) + динамика
Время первого ответа клиенту (по каналам: сайт/телеграм/почта)
Нагрузка коммуникаций (сколько сообщений/звонков на объект)

Склад/материалы/логистика (если есть) Остатки и дефицит (что заканчивается, что нужно заказать)
Расход материалов по заказам/исполнителям/типам работ
Поставки/логистика: задержки, сроки, причины

Техническое здоровье (если важно контролировать интеграции) Ошибки интеграций (очередь ошибок, причины, ответственный)
Задержка синхронизаций (сколько минут/часов отстаём)
Лимиты API (если есть) и предупреждения

Если отметили пункт — ниже в “перечне” напишите детали: для кого, период, фильтры, группировки и “что считаем успехом”.

Какие показатели важны (KPI):
Примеры: время обработки, % просрочек, конверсия, NPS, повторные обращения, выручка по менеджерам.

Каталог идей KPI (можно отметить галочками)

KPI — это 5–20 метрик, по которым вы регулярно управляете процессом (а не просто “красивые графики”).

Скорость и SLA Среднее время реакции (создано → в работе)
Среднее время выполнения (создано → закрыто)
% нарушений SLA
% выполнено вовремя
Размер очереди (сколько в работе/ожидании)

Нагрузка и производительность команды Закрыто в день/неделю (по людям/филиалам)
Баланс нагрузки (перегруженные/недогруженные)
Кол-во переназначений (как индикатор хаоса)
% “зависших” задач (долго без движения)

Качество Доля переработок/возвратов
Доля отмен/отказов
Доля жалоб/претензий
Оценка качества (по чек‑листам/оценкам клиента)

Продажи (если есть) Конверсия в оплату/заказ
Время до первого контакта с лидом
Средний чек
Выручка (план/факт, динамика)

Клиенты/лояльность Доля повторных клиентов
NPS/CSAT (оценка клиента)
Время первого ответа клиенту

Экспорт (PDF/Excel/CSV) и кто может выгружать:
Уточните: какие отчёты можно экспортировать, в каких форматах, нужны ли шаблоны (логотип, подпись, реквизиты), и нужно ли ограничивать выгрузки (например, чтобы не “утекли” телефоны/финансы).

Идеи по экспорту (что часто нужно бизнесу)

Excel/CSV: для бухгалтерии/аналитика, для “свести в таблицу”, для импорта в другое место.
PDF: красивый отчёт “для руководителя/клиента” с логотипом и подписями.
Ссылка на дашборд: без файлов — всегда актуальные данные (но с правами доступа).
Ограничения: маскирование телефона/email, запрет выгрузки финансов не тем ролям, логирование “кто выгрузил”.

10.2 Дашборды и детализация аналитики

Дашборд — это 1 экран “сводки”, где видно главное и можно быстро провалиться в детали. Обычно дашборды делают по ролям: руководителю — итог и проблемные места, менеджеру — “мои задачи”, исполнителю — “что делать сегодня”.

Идеи дашбордов и виджетов (можно выбрать как ориентир)

Готовые дашборды по ролям Руководитель/собственник: KPI, динамика, просрочки, воронка, финансы
Операционный: очередь по статусам, SLA, нагрузка, зависшие, причины отмен
Продажи: лиды, конверсия по этапам, источники, прогноз, эффективность менеджеров
Финансы: оплаты/неоплаты, дебиторка, выручка, скидки/возвраты
Поддержка/сервис: обращения, время ответа, оценки, жалобы, backlog
Руководитель команды: загрузка по людям, просрочки, качество, переработки
Интеграции: ошибки, задержки синхронизаций, лимиты API, очередь ошибок

Популярные виджеты (что показывать на дашборде) Карточки KPI (например: просрочки, конверсия, выручка)
График динамики (по дням/неделям)
Воронка (конверсия шагов)
Топ‑список проблем (топ просрочек/отмен/претензий)
Разрез по людям/филиалам (столбики/таблица)
Карта (если есть география: города/районы/выезды)

Если отметили — опишите детали ниже: какие именно виджеты, какие фильтры и куда “проваливаться” по клику.

Какие дашборды нужны и для каких ролей:
Например: руководитель — KPI и просрочки; менеджер — мои заявки; исполнитель — мои задачи.

Нужны ли “проваливания” (drill-down) из метрики в список/карточки объектов:

Какие разрезы/фильтры важны в аналитике (филиал, менеджер, тип заявки, период):
Подумайте про группировки: по филиалам, по источникам, по типам, по исполнителям, по причинам отказа.

10.3 Регулярные отчёты и рассылки

Примеры полезных рассылок (если нужно “держать руку на пульсе”)

Ежедневно утром: “просрочки + кто перегружен + что без ответственного”.
Еженедельно: “итог по KPI, динамика, топ причин отмен/возвратов, план работ на неделю”.
Ежемесячно: “выручка/маржа/конверсия, эффективность каналов, топ клиентов/услуг, проблемные процессы”.

Нужны ли отчёты по расписанию (ежедневно/еженедельно) и кому отправлять:

Форматы рассылки:

10.4 BI/выгрузка данных (если нужно) Нужно ли подключение BI (Power BI/Tableau/Looker/Metabase) или выгрузка в DWH:
Если BI уже есть — укажите инструмент и кто будет настраивать дашборды/витрины.

Какие данные и с какой частотой нужно отдавать (витрины/таблицы):
Пример: “витрина заявок, витрина оплат, витрина статусов”; частота: раз в час/день.

11. Нефункциональные требования

Раздел 11 — про качества системы, которые “не видно на кнопках”, но они решают, будет ли удобно и безопасно работать: скорость, стабильность, безопасность, бэкапы, логирование, ограничения среды. Эти ответы сильно влияют на архитектуру, сроки и стоимость: например, 99.9% доступности и строгая безопасность требуют больше работ. Если не знаете точных цифр — это нормально: дайте оценку “минимум/норма/пик” и опишите бизнес‑критичность (“если система недоступна час — это ок / это критично”).

Зачем это нужно (простыми словами)

Скорость: чтобы пользователи не ждали и не уходили обратно в Excel/чат.
Надёжность: чтобы система не “падала” в рабочее время и не теряла данные.
Безопасность: чтобы не утекли персональные данные/финансы и было понятно “кто что сделал”.
Бэкапы: чтобы можно было восстановиться после ошибки/сбоя/случайного удаления.
Логи и мониторинг: чтобы быстро находить проблемы и не искать “вручную почему не работает”.

Пример: как оценить нагрузку (если нет точных цифр)

Пользователей: 10 сейчас / 30 через год. Заявок: 20 в день обычно / 80 в пик. Одновременно в системе: 5–10. Файлы: фото до/после, до 10MB, до 10 фото на заявку.

11.1 Производительность, масштаб Ожидаемая нагрузка (примерные цифры):
Это нужно, чтобы система не “тормозила” и выдерживала ваши пики. Не обязательно знать точно — можно оценить. Важно: сколько людей работает одновременно, сколько заявок/заказов создаётся, и сколько файлов (фото/документы) хранится.

Подсказка: какие цифры самые важные (и пример)

Пользователи сейчас / через год: например “10 сейчас / 30 через год”.
Одновременно онлайн: сколько людей реально в системе в один момент (обычно меньше общего числа).
Объём работы: сколько заявок/заказов в день (обычно/пик), сколько комментариев/звонков/сообщений.
Файлы: фото/сканы/PDF — сколько на одну заявку и какого размера (например 5–10 фото по 5–10MB).
Пики: когда “все заходят одновременно” (утро, конец дня, перед отчётом, сезон).

Если не знаете: напишите “малый/средний бизнес” и дайте грубую оценку (это уже помогает).

Требования к скорости (комфорт работы):
Простыми словами: сколько секунд пользователь готов ждать после клика. Обычно “внутренние” действия должны быть быстрыми, а тяжёлые отчёты/экспорты могут считаться дольше.

Пример “нормально и комфортно” (если нет требований)

Открыть список/карточку: 1–2 сек.
Поиск: до 2 сек.
Сохранение формы: до 1 сек.
Отчёт/дашборд: 3–10 сек (иногда 10–20 сек для тяжёлых).
Экспорт большой таблицы: можно 30–120 сек (если это редкое действие).

Надёжность работы (что будет, если система недоступна):
Здесь важна бизнес‑логика: насколько критичны простои, можно ли “пережить” 30–60 минут, нужна ли работа вечером/в выходные, и есть ли критичные процессы (оплаты, заявки 24/7, производство). Про проценты доступности (99.5/99.9) и бэкапы — отдельный блок ниже, но здесь можно описать смысл простыми словами.

Примеры ответов (очень понятные)

Некритично: “работаем в будни 9:00–19:00, простой до 1 часа терпим, главное — чтобы данные не терялись”.
Критично: “если система лежит 30 минут — теряем деньги/клиентов, нужна высокая стабильность и быстрые уведомления о сбоях”.
Интеграции: “если интеграция с оплатами/1С упала — важно, чтобы данные не потерялись и можно было догнать позже”.

11.2 Безопасность, данные Какие данные будут в системе (что “чувствительное”):
Простыми словами: перечислите, какие данные хранятся. Это влияет на права доступа, аудит и меры безопасности. Если сомневаетесь — просто перечислите поля, которые есть в карточках (клиент/заказ/оплата/документы).

Примеры типов данных

Персональные: имя, телефон, email, адрес, дата рождения, фото.
Финансовые: суммы, оплаты, счета, реквизиты, задолженности.
Коммерческие: прайсы, договоры, условия, скидки, внутренние комментарии.
Регулируемые/особые: медицинские данные, документы личности и т.п. (если есть).

Требования по безопасности и хранению данных (простыми словами):
Если коротко — “кто имеет доступ”, “как защищаем”, “можно ли выгружать данные”, “нужна ли 2FA”, “как отделяем тест от боевой системы”. Тех.термины ниже — это просто варианты, их можно описать своими словами.

Расшифровка простыми словами

Шифрование “в пути”: доступ по HTTPS (данные не “видны” по дороге).
Шифрование “на диске”: база/файлы хранятся в зашифрованном виде (актуально при высоких требованиях).
Доступы: роли, 2FA, запрет общих логинов, ограничения на экспорт.
Тестовая среда: отдельная тест‑версия, где нет реальных персональных данных (или они замаскированы).

Нужен ли журнал действий (audit) — “кто что сделал”:
Audit помогает разбирать спорные ситуации: кто сменил статус, кто удалил, кто выгрузил Excel, кто поменял права. Если есть финансы/персональные данные — обычно лучше выбрать “Да”.

Что обычно пишут в audit

Вход/выход пользователя.
Смена статусов/ответственного/сроков.
Удаление/архив/массовые операции.
Экспорт данных (кто выгрузил и когда).
Изменение ролей/прав.

11.3 Доступность, бэкапы, восстановление Требуемая доступность (uptime) — сколько простоев допускается:
Uptime — это “какую часть времени система должна быть доступна”. Если вы не уверены — выбирайте 99.5% (часто достаточно для внутренних систем) или 99.9% (если критично 24/7).

Что означают проценты (примерно по простою в месяц)

99.0%: до ~7 часов простоя в месяц.
99.5%: до ~3.5 часа простоя в месяц.
99.9%: до ~40–45 минут простоя в месяц.
Best effort: без жёсткой гарантии (но делаем стабильно, просто без дорогих “24/7” требований).

Если выбрали “Другое” — опишите, как вы это понимаете (например “только в рабочее время”):

Окна обслуживания (когда можно делать обновления/даунтайм):
Иногда для обновлений нужен короткий перерыв. Если вы укажете “когда можно” — релизы будут спокойнее. Если система критична 24/7 — можно написать “стараться без даунтайма, но допустимо ночью”.

Примеры

“Ночью с 01:00 до 04:00 по будням”.
“В выходные утром”.
“Только после 20:00 по местному времени”.

Бэкапы (резервные копии): как часто и как долго хранить:
Бэкап — это копия данных, чтобы восстановиться после ошибки/сбоя/удаления. Важно 2 параметра: частота (как часто делаем копию) и срок хранения (сколько копий держим).

Пример “нормально по умолчанию”

Ежедневно: хранить 30 дней.
Ежемесячно: хранить 12 месяцев (если нужно “на всякий случай”).
Для критичных систем: чаще (например каждые 6–12 часов) + более строгие проверки восстановления.

11.4 Логи, мониторинг, алерты Логи (журнал ошибок и событий): что важно записывать и сколько хранить:
Логи помогают быстро понять “почему не работает”. Это не то же самое, что audit (кто что нажал) — логи больше про ошибки и технические события. Если не знаете — перечислите, какие события для вас критичны: “оплата не применилась”, “интеграция упала”, “не отправились уведомления”.

Примеры (что часто логируют)

Ошибки при сохранении формы/создании заявки.
Ошибки интеграций (1С/платежи/SMS) + текст ошибки.
Отправка уведомлений (успешно/ошибка) — особенно для критичных.
Массовые операции (импорт/экспорт) + результат.

Срок хранения часто выбирают 14–90 дней (в зависимости от требований).

Мониторинг и алерты: как узнаём, что что-то сломалось:
Мониторинг — это “датчики” и автоматические уведомления: если ошибок много или система долго отвечает — приходит алерт. Для бизнеса это важно, чтобы проблема не обнаружилась “случайно через 3 дня”.

Примеры алертов (простыми словами)

Система упала: сайт/кабинет не открывается → срочно сообщить.
Много ошибок: “ошибки > 10 за 5 минут” → сообщить.
Интеграция отстала: “нет синхронизации 30 минут” → сообщить ответственному.
Просели скорости: “поиск > 3 сек” → предупредить.

Уведомления об инцидентах (кому и куда):
Инцидент — это ситуация, когда бизнес страдает: не создаются заявки, не проходят оплаты, не работает кабинет, данные не синхронизируются. Укажите людей/каналы и насколько быстро нужно реагировать.

Пример (можно копировать)

Критично: “оплаты/создание заявки не работает” → Telegram руководителю + email.
Некритично: “отчёт строится долго” → только email в рабочее время.

11.5 Совместимость и ограничения по устройствам Поддерживаемые браузеры/версии:
Обычно достаточно “последние 2 версии Chrome/Edge/Safari/Firefox”. Если в компании старые компьютеры/браузеры или есть строгие ограничения — укажите, иначе потом это станет сюрпризом.

Мобильные устройства/ОС (если актуально):
Если сотрудники работают “в полях” — важно знать минимальные версии iOS/Android и примерные модели (чтобы камера/гео/офлайн работали стабильно).

Ограничения корпоративной среды (VPN, прокси, блокировки):
Простыми словами: есть ли у вас “корпоративные правила”, которые мешают обычной работе сайтов/интеграций (прокси, блокировки Telegram/Google, запрет внешних API, необходимость whitelist по IP, корпоративные сертификаты). Если такого нет — напишите “нет ограничений”.

Примеры ограничений

Доступ к системе только через VPN.
Внешние сервисы (Google/Telegram) заблокированы.
Нужно добавить домен/IP в whitelist.
Есть корпоративный прокси и свой сертификат.

12. Технологии и окружение

Раздел 12 — про ограничения и предпочтения: где будем размещать, нужны ли корпоративные стандарты, как делать релизы. Если у вас нет предпочтений — так и пишите: “на усмотрение команды”.

Пример: ответ “нет предпочтений” (это нормально)

Стек: “не принципиально”. Хостинг: “облако”. Docker: “да”. Важно: “нужны бэкапы и доступы только по ролям”.

12.1 Предпочтения Предпочтения по стеку/платформе (если есть):
Если есть корпоративные стандарты (например, только .NET/Java) — укажите. Если нет — можно написать “на усмотрение”.

Предпочтения по БД (если есть):
Примеры: PostgreSQL/MySQL/MSSQL; требования к репликации, бэкапам, on-prem.

Хостинг/размещение:

Нужен ли Docker/контейнеризация:

12.2 Окружения (dev/stage/prod) и доступы Нужны ли отдельные окружения (dev/stage/prod) и какие правила:

Как будут выдаваться доступы к инфраструктуре/админке (кто админ):
Уточните, кто будет администрировать систему после запуска и нужен ли доступ вашей IT-команды.

Требования к домену/SSL/почте для уведомлений (если есть):

12.3 CI/CD, релизы, процесс разработки Процесс релизов: как часто выкатывать, кто согласовывает, нужен ли “чейнджлог”:
Пример: “релиз раз в 2 недели”, “внеплановый хотфикс — по согласованию”, “чейнджлог для пользователей”.

Есть ли у вас обязательные требования к процессу разработки (код-ревью, тесты, безопасность):
Вам не нужно писать код — это вопрос про правила проекта. По умолчанию мы делаем code review и базовые проверки качества. Если у вас есть корпоративные требования (например, SAST/скан секретов, покрытие тестами, запрет прямых пушей в main) — укажите.

Есть ли корпоративные требования к репозиторию/доступам (GitHub/GitLab):
Пример: “только GitLab on-prem”, “2FA обязательно”, “доступ только через VPN”, “branch protection”.

12.4 Аккаунты сторонних сервисов Какие сторонние сервисы будут использоваться (почта, SMS, карты, аналитика) и кто предоставляет доступы:

Нужны ли отдельные sandbox/test аккаунты для интеграций:

13. План работ, сроки, бюджет

Раздел 13 помогает спланировать этапы, коммуникацию и ожидания. Даже примерный бюджет/сроки помогают выбрать правильный объём MVP.

Пример: как писать сроки и этапы

Дедлайн: “хотим запуститься до 01.03”.
MVP: “заявки + статусы + роли + уведомления”.
Этап 2: “отчёты, интеграции, мобильный доступ”.
Команда заказчика: 2 часа в неделю на согласования + 1 воркшоп.

13.1 Сроки Желаемая дата запуска (если есть):

Есть ли критичные даты (сезон, рекламная кампания):
Укажите даты и что должно быть готово к каждой. Пример: “к 01.03 нужен запуск для рекламной кампании”.

Готовность к этапам (MVP → развитие):
Совет: разделите на 2–4 этапа и кратко опишите “что в каждом этапе”. Это помогает быстрее запустить MVP.

13.2 Бюджет и приёмка Бюджет (диапазон) — если готов сказать:

Кто будет принимать результат (роль/человек):

13.3 Управление проектом и коммуникация Какой формат управления вам ближе:
Подсказка: это про как мы планируем работу и согласовываем изменения (а не про “красивые слова”). Если не уверены — выбирайте “Смешанный” или “Не знаю”, мы предложим удобный вариант после уточнений.

Подсказка: что означают варианты (простыми словами)

Scrum/спринты: работа “пачками” по 1–2 недели. В начале спринта фиксируем приоритеты, в конце показываем демо и принимаем результат.
Kanban/поток: задачи идут непрерывно “по мере готовности”. Удобно, когда постоянно появляются новые задачи/улучшения, а приоритеты часто меняются.
Каскадно: сначала подробно описываем требования, затем делаем по этапам. Подходит, когда список работ относительно стабилен и важны формальные согласования.
Смешанный: самый частый вариант для кастомной системы: сначала уточняем процесс и MVP, затем делаем итерациями с регулярными демо.

Пример выбора: если хотите видеть прогресс каждую неделю и уточнять по ходу — чаще подходит Scrum/смешанный. Если есть поддержка/постоянный поток правок — Kanban. Если требования “железные” и нужно согласовать всё заранее — каскадно.

Инструменты управления задачами (Jira/Trello/Notion/другое):
Где будем вести список задач, статусы и комментарии по проекту. Самый простой и понятный вариант: Google Таблица (задачи/статусы/ссылки) + мессенджер (Telegram/WhatsApp) для быстрых вопросов. Если у вас уже есть свой инструмент — укажите его.

Подсказка: что именно написать (пример)

Пример (простой): “Google Таблица ‘Проект CRM’, доступ: по ссылке/добавлю по email … + чат Telegram (участники: …)”. Пример (если уже есть): “Notion, доска ‘Проект CRM’, доступ: invite …” или “Jira, проект ABC, доступ выдаст …”.

Как часто удобно получать демо/промежуточные результаты:

Каналы для оперативной связи по проекту:

13.4 Что делаем сначала (приоритеты и этапы)

Этот блок нужен, чтобы не раздувать первую версию и не “пытаться сделать всё сразу”. Мы делим работу на этапы: MVP (запуск) → Этап 2 (улучшения) → позже/не нужно. Если термины ниже непонятны — просто заполните MVP и что можно потом: этого уже достаточно, чтобы посчитать сроки и бюджет.

Как будем приоритизировать функциональность (если есть предпочтения):
Это про “как решаем, что делать первым”. Можно пропустить и выбрать “Не знаю” — мы предложим простой вариант на созвоне.

Подсказка: как удобно расставлять приоритеты (пример на простом языке)

MVP (обязательно): без этого запуск “не работает”. Пример: “заявка → статус → ответственный → уведомление”.
Этап 2 (важно, но можно позже): усиливает эффект, но не блокирует запуск. Пример: “отчёты по менеджерам”, “интеграция с оплатами”.
Позже: nice-to-have или “когда будет время”. Пример: “тонкие настройки”, “редкие сценарии”.
Не делаем сейчас: чтобы не распыляться (можно вернуться потом).

Если сомневаетесь: задайте себе вопрос “если этого нет, можно ли начать работать?”. Если “нет” — это MVP. Если “да, но будет неудобно” — скорее Этап 2.

Что обязательно должно быть в первой версии (MVP) — чтобы запустить:
MVP = минимальный набор, который даёт пользу “вживую”. Пишите сценариями (что делаем) и добавляйте критерий “готово”. Формат: что → для кого → результат.

Что можно добавить после запуска (Этап 2 / улучшения):
Это функции, которые усиливают эффект, но не обязаны быть в первой версии. Можно писать списком: “отчёты”, “интеграции”, “автоматизация”, “удобства”.

13.5 Участие вашей команды Кто будет выделен на проект со стороны заказчика (ролевая команда):
Например: владелец, аналитик, ключевой пользователь, бухгалтер, интегратор.

Доступность команды заказчика (сколько времени в неделю готовы выделять):

Кто будет готовить/проверять контент (тексты, справочники, шаблоны):
Примеры контента: тексты уведомлений, справочники (категории, причины), шаблоны документов, чек-листы.

13.6 Что может помешать (риски, зависимости, допущения)

Этот блок нужен, чтобы заранее понять, где могут быть задержки и что нужно подготовить. Тут нет “правильных” ответов: чем честнее и конкретнее — тем точнее получится оценка и тем меньше сюрпризов в процессе.

Подсказка: чем отличаются “зависимость”, “риск” и “допущение”

Зависимость — то, что должно прийти “с вашей стороны/со стороны партнёра”, иначе часть работ будет стоять: доступы, данные, решения, ответы.
Риск — то, что может пойти не так (и как мы это заранее уменьшаем).
Допущение — “мы считаем, что …” пока не подтверждено. Если окажется иначе — меняются сроки/стоимость/объём.

Пример на одной теме: “Интеграция с 1С”. Зависимость: нужен доступ к тестовой базе/выгрузкам. Риск: окажется, что API нет и можно только файлами → понадобится больше ручной логики. Допущение: бухгалтерия сможет давать выгрузку раз в день и есть ответственный на вопросы.

Ключевые зависимости (интеграции, доступы, поставщики):
Что нужно получить/согласовать, чтобы не стопориться. Примеры: доступ к текущей CRM/таблицам, доступ к API партнёра, логины к почте/SMS‑сервису, готовые шаблоны документов, тестовые аккаунты, ответственный по интеграциям.

Риски проекта (что может пойти не так) и как их снизить:
Пишите простыми словами: “что может случиться” → “чем это грозит” → “как это предотвращаем”. Можно добавить: кто отвечает и до какой даты нужно закрыть вопрос.

Допущения (assumptions), которые важно зафиксировать:
Допущение = “мы считаем, что …”, но это ещё не подтверждено. Зачем: чтобы потом не было “мы думали иначе”. Примеры: “данные в таблице актуальные”, “у сотрудников есть смартфоны”, “интеграция возможна через API”, “готовы выделять 2 часа в неделю на согласования”.

13.7 Условия оплаты (если готовы обсудить) Как вам удобнее платить:

Есть ли требования по документам для оплаты (инвойс, договор, акт):
Если есть юр.лицо, бухгалтерия, валютный контроль — лучше указать заранее.

14. Дополнительные требования

Раздел 14 — всё, что часто забывают: документы, обучение, поддержка, запуск, “exit plan”. Если не уверены — напишите, что вам важно “по-человечески” (например: “чтобы обучили менеджеров и был чат поддержки”).

Пример: что часто важно в разделе 14

Обучение: 1–2 сессии + запись + короткая инструкция.
Поддержка: реакция на критичные баги в течение дня.
Запуск: пилот на одном филиале 2 недели, потом расширение.
Документы: шаблоны актов/счетов + хранение PDF.

14.1 Юридическое и документы Нужны ли договор/акты/документы/встроенные шаблоны документов:
Примеры: договор, акт, счёт, накладная, чек-лист работ, гарантийный талон. Укажите, что должно формироваться автоматически.

Требования по хранению документов (сроки, доступы):
Про что вопрос: какие файлы/документы будут храниться в системе (PDF, сканы, фото, акты, счета), как долго их хранить, кто имеет доступ (кто может смотреть/скачивать/удалять) и нужно ли фиксировать историю/аудит. Если нет особых требований — напишите: “на усмотрение команды”.

Подсказка: примеры “как обычно бывает”

Сроки хранения: договоры/акты — 3–5 лет; счета/платежные документы — по требованиям бухгалтерии; фото по работам — 6–12 месяцев.
Доступ: клиент видит только свои документы; менеджер — свои заявки/клиентов; бухгалтерия — финансовые документы; админ — всё.
Неизменяемость: после подписания/закрытия этапа документ “замораживается” — нельзя заменить файл, только добавить новую версию.
История: сохраняем “кто/когда загрузил, кто скачал, кто удалил” (полезно для разборов и безопасности).

Если есть строгие правила (например, юридические/регуляторные) — просто перечислите их словами, мы уточним детали.

14.2 Поддержка и развитие Нужна ли поддержка после запуска (SLA/период):
Опишите ожидания: время реакции на баги, канал поддержки, рабочие часы, критичность (P1/P2/P3).

План развития (что точно будет “потом”):
Это не обязаловка, но помогает спланировать архитектуру “с запасом”.

14.3 Обучение и документация Нужно ли обучение пользователей (формат, длительность, для каких ролей):

Какая документация нужна:
Например: инструкция пользователя, инструкция админа, видео, база знаний.

Нужны ли подсказки/примеры заполнения прямо в интерфейсе (кроме внешней документации):
Пример: подсказки в полях, шаблоны примеров, “что дальше делать” после сохранения.

14.4 Права, владение, доступ к коду Кому принадлежит результат (код/дизайн/материалы) и есть ли требования по передаче прав:
Если есть требования: передача исключительных прав, лицензия, запрет использования шаблонов/компонентов — укажите.

Нужен ли доступ к репозиторию/CI со стороны заказчика (GitHub/GitLab):
Простыми словами: репозиторий — это “папка с исходным кодом и историей изменений”, а CI — автоматические проверки/сборка (тесты, сборка, иногда выкладка). Доступ может быть нужен, если у вас есть IT/безопасность, вы хотите хранить код в своей организации, или планируете продолжать разработку своими силами. Если не актуально — выбирайте “Нет” или “Не знаю”.

Подсказка: что выбрать (пример)

Нет: у вас нет своих разработчиков/DevOps и не нужно смотреть код — просто принимаете результат как продукт.
Только чтение: хотите прозрачность (видеть историю изменений), аудит безопасности, контроль “что и когда делали”.
Запись: код должен лежать в вашей организации GitHub/GitLab или ваша команда будет вносить правки/делать релизы.

Если выбрали “чтение/запись”, уточните в комментариях/в поле выше про требования репозитория: где (GitHub/GitLab), в какой организации, кто будет админом, и есть ли правила (2FA, VPN, запрет прямых пушей в main).

Нужны ли передачи доступов/аккаунтов сторонних сервисов (почта, SMS, хостинг) на ваш аккаунт:
Пример: SMS-шлюз и почтовый сервис должны быть на аккаунте заказчика, чтобы оплата и доступы были у вас.

14.5 Запуск (go-live), пилот, миграция Как хотите запускать: сразу всем или пилот на одном филиале/команде:

Критерии готовности к запуску (что должно быть проверено):

План миграции/переключения (если есть):
Пример: “параллельная работа 2 недели”, “заморозка старой системы”, “импорт ночью”, “проверка выборкой”.

14.6 Экспорт данных и “exit plan” Нужно ли иметь возможность выгрузить все данные при прекращении использования системы:

Какие форматы/структуры важны для выгрузки (таблицы, документы, файлы):
Уточните: какие сущности/файлы обязательно выгружать, нужен ли формат для дальнейшего импорта в другую систему.

15. Финальная сводка

Раздел 15 — чтобы зафиксировать главное: приоритеты, риски и что нужно уточнить. Это помогает быстро собрать итоговое ТЗ и план работ.

Пример: “ТОП-3 результата” и “ТОП-3 риска”

Результаты: контроль сроков, прозрачность статусов, меньше ручной рутины.
Риски: пользователи не примут, не успеем к дате, интеграции окажутся сложнее.
Открытые вопросы: какие статусы нужны, кто утверждает скидки, нужна ли интеграция с 1С.

15.1 Главное ТОП-3 самых важных результата от системы:
Пишите результатами, а не функциями. Пример: “контроль сроков”, “прозрачность статусов”, “сокращение времени обработки”.

ТОП-3 самых больших риска/страха/сомнения:
Пример: “пользователи не будут пользоваться”, “не успеем к дате”, “интеграция с 1С сложнее, чем кажется”.

Любая дополнительная информация (всё, что не спросили, но важно):
Сюда можно написать всё: нюансы процессов, ссылки, ограничения, пожелания, примеры документов, “что болит больше всего”.

15.2 Приоритеты и договорённости Расставьте приоритеты: что важнее всего (скорость/качество/стоимость/гибкость/безопасность):

Открытые вопросы, которые нужно уточнить (что осталось непонятно):
Совет: чем конкретнее вопрос, тем быстрее получится закрыть неопределённость и посчитать сроки/стоимость.

Какие решения вы хотите принять на ближайшей встрече/сессии:
Например: утвердить роли, утвердить стадии процесса, выбрать формат разработки, согласовать MVP.

15.3 Контрольный список (чтобы ничего не забыть)

Отметьте, что уже готовы предоставить. Это ускорит анализ и расчёт.

Есть описание текущего процесса (AS-IS)
Есть описание желаемого процесса (TO-BE)
Есть список ролей и прав
Есть список сущностей/данных
Понятны интеграции и источники данных
Есть примеры кейсов/документов
Есть брендбук/макеты (если нужно)
Можно дать доступ к текущим системам для анализа

← На главную