Когда нужен web-сервис, а не ещё одна таблица

Почти каждый рабочий процесс начинается с таблицы, и это правильно. Таблицу заводят за пять минут, её понимает любой сотрудник, её не нужно согласовывать с подрядчиком. На первых десятках записей она обыгрывает любую систему.

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

Признаки роста процесса

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

• к таблице появились правила, которые нигде не записаны
• историю изменений восстанавливают по переписке
• часть данных нельзя показывать всем, кто имеет доступ к файлу
• внешние участники — клиенты, партнёры — в таблицу не пускаются, и им пишут вручную
• появились копии «на всякий случай», и непонятно, какая главная

Роли и доступы

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

Web-сервис начинается именно с этого вопроса: кто входит, что видит, что может изменить. Роли описываются до интерфейса, потому что от них зависит вся структура: какие экраны нужны, какие действия доступны, что происходит при попытке сделать лишнее.

Ролей обычно оказывается больше, чем называют вначале. Кроме клиента и менеджера почти всегда находится кто-то ещё: бухгалтер, которому нужны только документы; руководитель, которому нужна сводка и ничего больше; подрядчик, которого пускают в одну конкретную заявку. Каждая такая роль — не отдельный продукт, а несколько правил доступа, но заложить их лучше сразу.

Кабинет клиента

Кабинет чаще всего окупается не функциями, а снятой нагрузкой. Клиент, который видит статус своей заявки, не пишет менеджеру вопрос «как там у нас». Клиент, у которого документы лежат в одном месте, не просит переслать их ещё раз.

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

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

Admin area

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

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

История действий тут важнее, чем кажется. Когда клиент утверждает, что документ отправлял, а менеджер — что не получал, спор разрешается за десять секунд, если видно, кто что сделал и когда. Без истории он разрешается разговором на повышенных тонах и чьей-нибудь уступкой.

MVP сервиса

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

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

У переезда есть цена, о которой стоит сказать честно. Таблицу правит кто угодно и когда угодно, сервис — только там, где это предусмотрено. Первое время это раздражает: привычное действие «просто поправить ячейку» вдруг требует отдельной кнопки, которой ещё нет. Поэтому первый список доработок собирают не через полгода, а через две недели после запуска, пока раздражение свежее и конкретное.

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