CrewSplit: учёт выездов и распределения выплат

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

Учёт жил в Google Таблицах: один выезд оформлялся 15-20 минут, расчёт периода занимал около часа ручной сверки, а статусы выплат держались в голове и разрозненных пометках.

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

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

Количественные результаты я сравнивал с исходным процессом в таблицах:

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

Сложная математика распределения, включая пропорции участия, коэффициенты вклада и непроданные позиции, спрятана за простыми действиями: отметил выезды, увидел предпросмотр долей, сохранил расчёт и повёл выдачу по статусам.

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

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

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

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

Отдельное решение - имена. Система не навязывает справочник ФИО: уникальность имени плюс свободный формат покрывают реальную практику бригад, где людей знают по фамилии или прозвищу. В данных спокойно живут два Андрея, два Сергея и «Саня (крановщик)», и путаницы нет.

Главный экран и список работников

Выезд оформляется за секунды вместо прежних 15-20 минут: дата, объект и состав бригады кликами по чипам с именами. Если человека ещё нет в системе, его не нужно заводить отдельно: вписал имя, нажал Enter, и он уже в составе.

Коэффициент вклада - редкий сценарий, поэтому он спрятан за отдельной кнопкой и не загромождает ежедневный поток. Если коэффициент задан, участник помечается в списке жёлтой меткой «×2», и отклонение от нормы видно сразу.

Оформление выезда: чипы состава и коэффициент вклада

С одного объекта обычно приходит сразу несколько позиций, поэтому форма поддерживает мультистрочный ввод с сохранением одним действием, вместо повторного захода на каждую позицию.

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

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

Материалы: мультистрочный ввод и журнал по выездам

Формула под капотом непростая: выручка каждого выезда делится между его участниками пропорционально весам, итог по человеку складывается из его долей по всем выездам периода. Но в интерфейсе это выглядит как простой чек-лист: отметь выезды и смотри готовый предпросмотр долей. Позиции материалов подтягиваются автоматически.

Колонка «Был: 2 из 4» отвечает на главный вопрос бригадира: «почему у меня столько?». Пользователю не нужно понимать формулу, чтобы доверять результату: достаточно видеть, что участие каждого учтено. Сумма долей всегда сходится с суммой к распределению копейка в копейку. Это проверено тестами, включая сценарии с коэффициентами.

Расчёт: чек-лист выездов и живой предпросмотр

Сохранённый расчёт превращается в рабочий список выдачи. В шапке карточки показаны сумма, количество выездов и индикатор «Оплачено 3/9», который остаётся красным, пока есть долг.

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

Дальше возник вопрос доверия: что мешает случайно или намеренно снять отметку об оплате? Интерфейс защищает от ошибки, аудит - от злоупотребления. Снятие «Оплачено» требует подтверждения с объяснением последствий, каждая оплата фиксирует дату, а откат оставляет видимый след: «возвращён статус „не оплачено" 03.07.2026 в 15:32». Действие с чужими деньгами не может быть бесследным.

История выплат: переключатели статусов и след отката

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

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

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

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

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