Крекс, Пекс, Фекс — и платформа для самозанятых WIDU готова!

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

Сказано – сделано! Так, «Логема» с нуля разработала портал для работы с внештатными сотрудниками, на котором любой крупный бизнес может творить чудеса.

В 2020 году мы разработали электронную площадку для самозанятых. Клиент получил платформу для ведения документооборота и расчетов заказчиков с самозанятыми исполнителями, которая была написана на Битриксе. После завершения проекта, мы провели ретроспективу и пришли к выводу, что 1С-Битрикс не лучшая основа для подобных систем. Чего нам не хватило:


1. Отсутствие «взрослых» инструментов для командной работы. В системе из коробки не предусмотрены миграции. Мы хотели масштабировать команду, но упирались в технические ограничения.

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

Битрикс обладает рядом преимуществ для решения типовых задач. В этом комбайне есть необходимое, чтобы отображать статьи, новости, любые справочники с данными, в том числе каталог товаров или услуг. У Битрикса нет проблем с отображением корзины и оформлением заказа, а модули интеграции с платежными (или логистическими) сервисами работают из коробки. Но все это не было нужно нашему клиенту, а повторно низкоуровнево программировать бизнес-логику никто не хотел. Наш подход к проектам индивидуален, но когда решение касается сложной бизнес-логики, мы стараемся брать за основу такую систему или фреймворк, в которой или уже частично решена наша задача или есть что-то, что сократит время разработки и повысит качество. 

В начале 2022 к нам обратилось руководство кадрового агентства Widu за разработкой современного сервиса для самозанятых. 

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

❛❛ Ранее наш клиент привлекал большое количество самозанятых на проекты для своих заказчиков — всех их приходилось настойчиво просить зарегистрироваться на популярных площадках для самозанятых. Головная боль из оправданий о том, что кто-то забыл пароль, не помнит своих учетных данных, не знает, как пользоваться сервисом целиком ложилась на рекрутеров, у которых, на самом деле, хватает своих забот. Неприятный бонус в виде оплаты комиссий площадкам тоже не нравился руководству.

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

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

— как будут взаимодействовать самозанятый и заказчик;

— как должна происходить генерация договоров между площадкой и исполнителем;

— где понадобится интеграция с налоговой и банком;

— когда, наконец, кадровое агентство получит свою комиссию. 


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

По нашему, главный критерий MVP – хорошо решать задачу целевой аудитории и не делать ничего лишнего. Исходя из этого, мы сформулировали следующие задачи:

— платформа должна полностью автоматизировать взаимодействие с самозанятым – от регистрации до оплаты налога. Все конкуренты уже делают так. MVP без этих процессов будет несостоятельным;

— все договоры между заказчиком и самозанятым должны были генерироваться автоматически;

— надежная интеграция с налоговой и банком, которая спокойно переживает обрыв связи;

— требовалась интеграция с банком и автоматическая оплата заданий из личного кабинета заказчика;

— функционал холдирования средств заказчика;

— нужен был автоматизированный инструмент проверки исполнителей «на самозанятость», а также проверка, можно ли им перечислить деньги за работу в данным момент; 


— требовалась новая функциональность, позволяющая пользователям входить в систему по номеру телефона: для заказчика это удобная возможность получать информацию через sms, а для исполнителя — основной идентификатор в системе самозанятости;

— также клиент хотел загружать задания на сервис большим списком (т.н. «реестр заданий»). Чтобы все данные по задаче и исполнителям можно было одним кликом отправить через «реестр» и получить за это комиссию. 

Источник нашей уверенности в своих силах — предыдущая работа с похожим проектом и хорошее понимание бизнес-среды клиента. Мы решили подойти к задаче с с новыми мощными инструментами DDD и GraphQL. Примерно на этом этапе у команды появилось много оптимистичных надежд и сейчас вы узнаете, почему эти надежды не оправдались. 

❛❛ К созданию сервиса мы попробовали подойти, используя сразу два новых для команды подхода: DDD и GraphQL. Применение Domain-Driven Design обещало упростить моделирование предметной области, однако в реальности мы столкнулись с проблемами преобразования абстракций в конкретные форматы данных.

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

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

Что касается GraphQL — мы ожидали, что он станет удобным инструментом для получения данных, позволяя запрашивать сразу необходимую информацию с сервера (всего 1 запрос, Карл)!

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

Эти выводы совсем не означают, что идея с DDD не найдет своего отражения в других проектах. Но совершенно точно команда «Логемы» больше не будет внедрять две новых технологии одновременно. В защиту первоначального выбора (и это тема отдельной статьи, которую мы может быть когда-нибудь напишем) скажем только, что DDD действительно хорошо себя показывает в проектах со сложной бизнес-логикой, однако добавляет слишком много накладных расходов. Если же команда на практике уже знает, как работает этот инструмент, у вас получится очень хороший код. 

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

❛❛ Нужно было учесть, что реестр мог быть большим, а его обработка — сложной и длительной. Например: не будет нужной колонки в импортируемом excel-файле или вместо одного типа данных, клиент загрузит другие. Что делать, куда бежать? Все эти процессы требовалось предусмотреть:

— перед обработкой данных мы проверяем файл на соответствие требованиям;

— построчно разбираем этот файл и на основе каждого задания отправляем исполнителя в очередь проверок;

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

Статистика говорит, что в файлах реестра задач всегда присутствуют нестыковки.

Поэтому последним этапом в каждую строку файла дописываем статус «ОК» или уточнение по проблеме.

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

Что касается «внутренней кухни» платформы, мы наполнили ее стандартной функциональностью: 

— после регистрации пользователь может выбрать роль, заполнить данные о себе;

— чтобы стать заказчиком, достаточно ввести ИНН и банковские реквизиты;

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

Для исполнителей процесс чуть сложнее — нужно не только заполнить свой профиль на стороне сервиса, но и подтвердить в приложении «Мой Налог» разрешение на доступ к данным. Платформа позволяет также производить автоматическую проверку на наличие самозанятости у исполнителя, указывать банк, отвечающий за получение платежей по СБП.


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


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

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

Нам интересно фокусироваться на работе с такими проектами. Это не просто пример очередной многоступенчатой сложной разработки с большим количеством окружающих процессов (вокруг продукта или с технической точки зрения), а кое-что больше. Платформы подобного рода подходят многим компаниям: тем, кто работает в аутстаффинге или аутсорсинге, рекрутерам. Для «Логемы» — это большой пул интересных и разносторонних задач, и мы заинтересованы в том, чтобы клиенты приходили к нам за разработкой схожих сервисов. 

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

— внедрили современный стек технологий, который позволил использовать пайплайн для сборок проекта и переноса изменений на боевой сервер — нам стали доступны автотесты, которые можно прогонять 100500 раз, перед каждым переносом изменений на бой;

— протестировали несколько гипотез, связанных с новым для себя DDD-подходом;

— получили ценный опыт работы с GraphQL и сформировали свой подход к продукту.

Почему вам тоже нужна подобная платформа для работы с самозанятыми? 

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

— Скоринговая система ФНС и пристальное внимание к компаниям, которые работают с самозанятыми — не байка, а реальность. Автоматизация документооборота позволяет бизнесу оперативно решать любые возникающие проблемы. Получается, что такая платформа выступает «единым окном» для компаний, это уже вопрос удобства. 

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

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