Одному кадровому агентству надоело платить комиссии и разбираться с чехардой правил на разных платформах при работе с самозанятыми. Нужен был понятный, доступный сервис, который можно будет масштабировать и за это не придется много платить. Сказано – сделано! Так, «Логема» с нуля разработала портал для работы с внештатными сотрудниками, на котором любой крупный бизнес может творить чудеса.
В 2020 году мы разработали электронную площадку для самозанятых (свояработа.рф). Клиент получил платформу для ведения документооборота и расчетов заказчиков с самозанятыми исполнителями, которая была написана на Битриксе. После завершения проекта, мы провели ретроспективу и пришли к выводу, что 1С-Битрикс не лучшая основа для подобных систем. Чего нам не хватило:
Битрикс обладает рядом преимуществ для решения типовых задач. В этом комбайне есть необходимое, чтобы отображать статьи, новости, любые справочники с данными, в том числе каталог товаров или услуг. У Битрикса нет проблем с отображением корзины и оформлением заказа, а модули интеграции с платежными (или логистическими) сервисами работают из коробки. Но все это не было нужно нашему клиенту, а повторно низкоуровнево программировать бизнес-логику никто не хотел. Наш подход к проектам индивидуален, но когда решение касается сложной бизнес-логики, мы стараемся брать за основу такую систему или фреймворк, в которой или уже частично решена наша задача или есть что-то, что сократит время разработки и повысит качество.
В начале 2022 к нам обратилось руководство кадрового агентства Widu за разработкой современного сервиса для самозанятых.
Главная страница сервиса для самозанятых
Мы продумали концепцию, предложили оптимальный, на наш взгляд, технический стек и рассказали, как наше решение позволит отказаться от использования сторонних площадок и сэкономить на комиссиях.
“Ранее наш клиент привлекал большое количество самозанятых на проекты для своих заказчиков — всех их приходилось настойчиво просить зарегистрироваться на популярных площадках для самозанятых. Головная боль из оправданий о том, что кто-то забыл пароль, не помнит своих учетных данных, не знает, как пользоваться сервисом целиком ложилась на рекрутеров, у которых, на самом деле, хватает своих забот. Неприятный бонус в виде оплаты комиссий площадкам тоже не нравился руководству.
Решение создать собственную платформу, которая пройдет через все официальные стадии взаимодействия с налоговой и банками лежало на поверхности. Оставалось только найти разработчиков с опытом такой работы. Ну очень большим опытом.”
Сергей Горелов, генеральный директор компании «Логема»
Разработка сервиса, который решает реальную бизнес-задачу компании, требует погружения в детали. Со стороны «Логемы» над проектом работали — один проектный менеджер, один аналитик и архитектор, один тестировщик и специалисты по бэку и фронту. Всем им нужно было понять:
Структурирование процесса и обратная связь от заказчика в продуктовом подходе — половина успеха. Такой универсальный язык взаимодействия помог нам на старте определиться с тем, как будут выглядеть флоу процессов:
Как работает сервис для самозанятых
По нашему, главный критерий MVP – хорошо решать задачу целевой аудитории и не делать ничего лишнего. Исходя из этого, мы сформулировали следующие задачи:
Источник нашей уверенности в своих силах — предыдущая работа с похожим проектом и хорошее понимание бизнес-среды клиента. Мы решили подойти к задаче с с новыми мощными инструментами DDD и GraphQL. Примерно на этом этапе у команды появилось много оптимистичных надежд и сейчас вы узнаете, почему эти надежды не оправдались.
“К созданию сервиса мы попробовали подойти, используя сразу два новых для команды подхода: DDD и GraphQL. Применение Domain-Driven Design обещало упростить моделирование предметной области, однако в реальности мы столкнулись с проблемами преобразования абстракций в конкретные форматы данных. Иными словами, команда хотела создать решение, которое отражало бы структуру и логику работы бизнеса, а именно взаимодействие с самозанятыми сотрудниками и заказчиками. Предполагалось, что каждый аспект работы, такой как процессы найма, расчеты, документооборот и т. д., будет ясно отражен в программном коде.
На практике это привело к низкой эффективности кода и увеличению сложности разработки. Например, когда мы пытались отправить информацию о работниках в налоговую или банк, нам приходилось преобразовывать эти абстрактные представления в форматы, которые эти системы могли понять и обработать.
Что касается GraphQL — мы ожидали, что он станет удобным инструментом для получения данных, позволяя запрашивать сразу необходимую информацию с сервера (всего 1 запрос, Карл)!
На деле сложность этой штуки оказалась такой, что приходилось бороться с ней, а не с задачей. На этом этапе решили вернуться к ламповому REST, чтобы перестать кодить по ночам.”
Павел Машанов, технический директор компании «Логема»
Эти выводы совсем не означают, что идея с DDD не найдет своего отражения в других проектах. Но совершенно точно команда «Логемы» больше не будет внедрять две новых технологии одновременно. В защиту первоначального выбора (и это тема отдельной статьи, которую мы может быть когда-нибудь напишем) скажем только, что DDD действительно хорошо себя показывает в проектах со сложной бизнес-логикой, однако добавляет слишком много накладных расходов. Если же команда на практике уже знает, как работает этот инструмент, у вас получится очень хороший код.
О функциональности реестра заданий мы уже писали выше. Крупные заказчики «не мелочатся», если им нужно нанять три тысячи курьеров, то должен быть инструмент, которые позволяет удобно работать с большими данными. Возможность опубликовать задания и получить чеки с помощью одной кнопки — мастхэв в такой ситуации.
Реестр заданий в Excel
Реестр заданий со списком исполнителей в ЛК сервиса
Реестр заданий со статусами в ЛК сервиса
“Нужно было учесть, что реестр мог быть большим, а его обработка — сложной и длительной. Например: не будет нужной колонки в импортируемом excel-файле или вместо одного типа данных, клиент загрузит другие. Что делать, куда бежать? Все эти процессы требовалось предусмотреть:
перед обработкой данных мы проверяем файл на соответствие требованиям;
построчно разбираем этот файл и на основе каждого задания отправляем исполнителя в очередь проверок;
после завершения проверок, стартует импорт данных в систему — это уже безопасный процесс.
Статистика говорит, что в файлах реестра задач всегда присутствуют нестыковки. Поэтому последним этапом в каждую строку файла дописываем статус «ОК» или уточнение по проблеме.
При этом пользователь не обязан сидеть и ждать результат с открытым окном браузера. Даже если у него выключится свет и интернет, обработка на стороне сервера будет завершена и никакие данные не будут утеряны — после получения файла показываем уведомление, что обработка идет, а как только она завершится, сразу отображаем результат.”
Сергей Горелов, генеральный директор компании «Логема»
Что касается «внутренней кухни» платформы, мы наполнили ее стандартной функциональностью:
Для исполнителей процесс чуть сложнее — нужно не только заполнить свой профиль на стороне сервиса, но и подтвердить в приложении «Мой Налог» разрешение на доступ к данным. Платформа позволяет также производить автоматическую проверку на наличие самозанятости у исполнителя, указывать банк, отвечающий за получение платежей по СБП.
Про сложности реализации платформы с технической стороны мы тоже обязательно расскажем — историй набралось на отдельную статью. Что касается более «типичных» проблем, с которыми мы столкнулись, они, в основном, коснулись творческого подхода дизайнеров к функциональным требованиям.
Клиент нанял стороннюю организацию, которую посоветовали мы, для отрисовки макетов, что привело к неожиданному результату:
Например, в готовых макетах полностью отсутствовала концепция ролей пользователей. Пришлось отталкиваться от того, что есть, дополняя макеты на лету.
Нам интересно фокусироваться на работе с такими проектами. Это не просто пример очередной многоступенчатой сложной разработки с большим количеством окружающих процессов (вокруг продукта или с технической точки зрения), а кое-что больше. Платформы подобного рода подходят многим компаниям: тем, кто работает в аутстаффинге или аутсорсинге, рекрутерам. Для «Логемы» — это большой пул интересных и разносторонних задач, и мы заинтересованы в том, чтобы клиенты приходили к нам за разработкой схожих сервисов.
На примере этого кейса нам удалось подсветить, как компания может сэкономить на проверке, подборе и оформлении исполнителей, не нарушая при этом законодательство. Заодно мы:
Почему вам тоже нужна подобная платформа для работы с самозанятыми?
Это стало возможным благодаря тому, что команда глубоко погрузилась в бизнес-процессы заказчика, на старте была продумана логика работы сервиса. Попутно мы попробовали внедрить два новых для себя подхода, но отказались от этой идеи — теперь в компании работает правило «не более одной нанотехнологии на проект».