Сначала экраны, потом сервер
Все роли сперва собрали на демо-данных. Готовый интерфейс стал точной спецификацией для API, и экраны переводятся на сервер по одному, не ломая остальное.
01 / 04Платформа заказов
Малый бизнес заказывает сайт, бота или интеграцию и получает их с фиксированной ценой и сроком. Между заказчиком и работой — один менеджер и понятный ход заказа.
На обычной бирже заказчик сам ищет исполнителя, торгуется и надеется, что тот не пропадёт. Здесь за результат отвечает площадка: менеджер превращает сырую заявку в ТЗ с ценой и сроком, принимает работу по качеству и остаётся единственным, с кем говорит клиент.
Нужно было сделать так, чтобы клиент в любой момент понимал, что с заказом и чей сейчас ход, — а менеджер вёл десятки заказов и ничего не терял.
Шесть этапов — от подготовки ТЗ до результата. На каждом видно, чей ход и что нажать. Круги доработки спрятаны внутрь проверки: клиент видит «Проверка», а не пятую правку.
У клиента, менеджера, исполнителя и владельца свои экраны и свои права. Клиент не видит кухню: только своего менеджера и одну цену.
Менеджер собирает ТЗ из заявки, клиент принимает его одной кнопкой и оплачивает до начала работ. Выплаты исполнителям — реестром после закрытия заказа.
Вход по коду из письма, файлы с проверкой доступа, письма клиенту по имени — без обещаний сроков, которых нет.
PostgreSQL с миграциями, копия базы перед каждой новой миграцией, внешний сторож, который проверяет сайт снаружи и сразу сообщает, если тот перестал отвечать.
Все роли сперва собрали на демо-данных. Готовый интерфейс стал точной спецификацией для API, и экраны переводятся на сервер по одному, не ломая остальное.
Расчёты сумм, сроков и выборки закреплены тестами на живой базе — каждый ловит случай, на котором код уже ошибался.
Менеджер живёт в кабинете часами, поэтому никаких лишних эффектов: движение только там, где подтверждает действие или показывает состояние.
Похожая задача? Расскажите, что мешает работать, — ответим, как это собрать, сколько займёт и во сколько обойдётся.
Обсудить проект