Сайт-визитку можно описать одной страницей требований. С веб-платформой так не получится: в ней есть пользователи с разными правами, документы, сроки, оплаты и десятки ситуаций, которые нужно продумать до того, как написана первая строчка кода. Сейчас мы разрабатываем платформу для ведения арбитражных дел онлайн и на её примере покажем, как устроен процесс — он хорошо объясняет, за что платят при разработке на заказ.
Задача
Арбитражное дело — это много участников и много шагов: подача иска, оплата сбора, решение о принятии дела, формирование состава арбитража, обмен документами, заседания, решение. Всё это нужно перенести в одну систему, где каждый участник видит только своё, а любое действие фиксируется.
Шаг 1. Документы до кода
Разработка началась не с дизайна и не с программирования, а с пакета документов: техническое задание, ценовое предложение и договор. Роли пользователей и бизнес-процесс мы вынесли в отдельное приложение к ТЗ. Так основное задание остаётся читаемым, а логику прав и процессов можно обсуждать и менять отдельно, не переписывая всё ТЗ.
На этом этапе обнаруживаются вещи, которые дорого исправлять потом. Например, один из способов оплаты пришлось убрать из проекта ещё на бумаге: для него не было подключённого эквайринга. Выяснить это на этапе ТЗ стоит пару правок в документе, а после запуска — переделку модуля оплаты.
Шаг 2. Роли и права
В системе работают председатель, секретарь, арбитры и стороны дела — истец и ответчик. Для каждой роли мы прописали, что она видит и что может делать:
- председатель решает, принимать ли дело, и рассчитывает арбитражный сбор;
- секретарь ставит задачи участникам и единственный выставляет счета;
- стороны не загружают документы в дело когда угодно, а отвечают на задачи, которые им поставлены.
Роль секретаря, кстати, появилась в процессе обсуждения: стало понятно, что кто-то должен вести дело день за днём, а председателю это не нужно.
Шаг 3. Упростить всё, что можно
Самое важное решение в проекте — вся работа по делу устроена как задачи. Кто-то ставит задачу, кто-то её выполняет. Больше ничего.
Изначально для заседаний планировался отдельный модуль и отдельный статус дела. В итоге заседание стало обычной задачей: дата заседания — это срок задачи, ссылка на видеозвонок — в описании. Один механизм вместо трёх означает меньше кода, меньше ошибок и меньше того, чему нужно учить пользователей.
Тот же принцип — в полях задачи. Всё, что можно написать текстом, пишется в описании, а не выносится в отдельное поле. Сумму сбора председатель указывает в описании задачи для секретаря и прикладывает расчёт. У задачи один автор, а кнопка загрузки для задач с документами всегда называется одинаково. Каждое такое решение по отдельности мелкое, но вместе они делают интерфейс заметно проще.
Шаг 4. Видимость и прослеживаемость
В юридическом процессе важно, кто что видит и на каком основании принято решение. Поэтому у каждой задачи есть настройка «Кто видит задачу» с тремя уровнями: все участники дела, только состав арбитража или только сотрудники арбитражного центра.
К решениям по задачам — продлить срок, отменить задачу, перенести заседание, отклонить доверенность — можно приложить обосновывающий документ. Через год по делу будет видно не только что произошло, но и почему.
Шаг 5. Продумать неочевидные сценарии
Хорошую систему отличает то, как она ведёт себя в нестандартных ситуациях. Например, что будет, если участник захочет удалить аккаунт посреди дела? У нас это невозможно: пока у пользователя есть активные дела, кнопка удаления неактивна, а рядом объясняется почему. Такие сценарии не видны в демо, но именно из-за них сервисы ломаются в реальной работе.
Иск и оплата регистрационного сбора встроены прямо в пошаговый мастер создания дела. Пользователь не может создать дело и «забыть» оплатить сбор — эти шаги нельзя пропустить.
Шаг 6. Сначала MVP, потом развитие
Мы делаем минимально жизнеспособную версию: то, без чего платформа не может работать. Всё, что появилось в ходе проектирования сверх этого, мы описываем отдельно. Часть таких функций заказчик решил взять в работу отдельным пакетом по дополнительному соглашению, а мелкие улучшения, которые мы придумали по ходу, делаем без доплаты. Так бюджет остаётся прозрачным: заказчик видит, за что платит, и сам решает, что добавить сейчас, а что потом.
Почему это нельзя сделать на конструкторе
Роли с разными правами, задачи со сроками и видимостью, оплата внутри процесса, история решений с документами — это веб-приложение, а не сайт из блоков. Для таких проектов мы используем Laravel: он позволяет построить ровно ту логику, которая нужна заказчику, и развивать её дальше. Подробнее о том, где проходит граница между конструктором и разработкой, мы писали в статье «Сайт на Tilda или разработка на заказ».
Что из этого стоит взять себе
- Тратьте время на ТЗ и описание ролей: ошибка в документе стоит минуты, ошибка в коде — дни.
- Ищите, что можно объединить. Один универсальный механизм почти всегда лучше нескольких специальных.
- Отделяйте MVP от пожеланий, чтобы запуститься вовремя и в рамках бюджета.
Если у вас похожая задача — внутренний сервис, личный кабинет или платформа с несколькими ролями, — расскажите нам о ней. Посмотрите, как мы работаем над корпоративными проектами, и напишите нам.
