MRKT

Во второй половине 2017 года я начал заниматься разработкой торговой площадки. На ней компании проводят тендеры и аукционы на сельскохозяйственную продукцию и комплектующие.

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

Работу над проектом мы разбили на 6 частей:

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

Регистрация пользователей

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

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

Регистрация компании

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

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

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

Страница компании

Вся информация о компании отображается на её странице.

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

Создание торгов

Компании с премиум-аккаунтом могут создавать торги. При создании торгов организатор описывает правила, сроки, рассылает приглашения участникам, указывает место поставки или отгрузки, условия поставки и товары, по которым ведутся торги.

Одной из самых сложный частей был конструктор позиций в создании торгов:

В торгах участники откликаются на позиции и делают предложения по ним.

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

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

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

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

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

Выбор победителей в торгах

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

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

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

Участник увидит разницу и сможет подтвердить поставку или отказаться.

Если все участники подтвердили поставку, то торги считаются завершёнными.

Чему научился

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

• Я разобрался со многими паттернами проектирования. Об адаптере написал статью.
• Понял важность документации, а особенно — причин, по которым решение принималось. Причины быстро забываются, но именно они определяют поведение интерфейса.
• Научился правильно описывать баги.
• Разобрался с новыми технологиями, например, с веб-воркерами и инструментами для интеграционного тестирования.
• Убедился в важности релизов и обратной связи.
• Понял важность смены деятельности и чередования задач.
• Узнал, что «не баг, а фича» — не шутка. Иногда команда может просто забыть, что какая-то часть интерфейса должна работать определённым образом.