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

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

После того, как деньги приходят и бухгалтер подтверждает поступление, автоматически происходит следующее:

1. Фиксируется поступление в Google-таблицах, которые используются в качестве базы данных.
2. Добавляется премия для менеджера за продажу.
3. Создается доска в trello.com
4. Создается рабочая папка на Google-диске для проекта. С нужной структурой вложенности. И выдачей прав для конкретного менеджера.
5. Вся информация добавляется в Planfix — учетную систему проектов.
6. После того, как в проект добавили акт и он прошел ручную проверку, то отправляется бонус за управление проектом.

Чтобы проект успешно закрывались, нужно, чтобы менеджер выполнял как можно меньше ручной мелкой работы и не допускал ошибок. Эта система позволяет сократить и то и другое.

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

Учет проектов у нас ведется в Planfix, это центральное хранилище информации по проекту. Вся информация напрямую отправляется по API туда.

1. Для каждого этапа есть своя колонка, где фиксируется сам проект. После добавления он добавляется на первый этап.
2. Еженедельно проекты проходят проверку с руководителем отдела, что позволяет не забывать во время менять статус проекта.
3. При попытке переместить проект на проверку руководителю, проверяется, что прикреплен отзыв клиента и заполнено поле «Ссылка на акт».

Так как наш стек это: 1С-Битрикс, Laravel + React. Вполне ожидаемо, что мы использовали связку Laravel + React. Битрикс едва ли может подойти для разработки настолько не типовых сервисов.

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

Но переодически возникали ошибки, которые требовалось исправлять + нереактивный интерфейс, который хоть и был с использованием jQuery, но по настоящему удобным не был. Требовал во многих случаях перезагрузки страницы и ожидания подгрузки данных.

React позволил существенно ускорить работу менеджера. Добавить возможность без перезагрузки страницы добавлять, редактировать и дублировать оплаты.

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

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

Это позволило собрать макет. Визуально делали на bootstrap 5. Наиболее быстрое и простое решение, к тому же есть для Figma и React.

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

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

Для ручных тестов была собрана матрица трассировки. В которой было прописано 15 основных сценариев и отмечена необходимость тестирования отдельно для менеджеров и отдельно для администратора.

В качестве юнит-тестов мы использовали Jest. Наиболее удобная на наш взгляд библиотека для написания тестов на React.

И для End-2-End тестов мы использовали Playwright. Эта библиотека позволила симулировать действия пользователя и облегчить большинство рутиной работы при тестах.