Где работать в ИТ в 2021: GigAnt
Сегодня в рубрике «Где работать в ИТ» расскажем вам о компании GigAnt, которая занимается развитием сервиса для временных сотрудников в ритейле и общепите и работает с топ-10 ритейлеров России. Компания быстро выросла и в декабре прошлого года получила инвестиции от Авито.
В этом году сотрудники оценили работодательские качества GigAnt на 4,79 из пяти. Ребята занимают пятое место в нашем рейтинге среди компаний со штатом от 100 до 1000 человек. О том, как всё устроено в Гиганте нам рассказали эйчар-менеджер Ольга Бессонова, продакт Игорь Фалин, лид разработки Яков Макаров и технический писатель Николай Красильников.
Оценивайте своих работодателей на Хабр Карьере и помогите ИТ-сообществу узнать, как вам там работается.
Навигация по выпуску
О компании
GigAnt — это Убер для «синих воротничков». Сервис соединяет людей, ищущих удобную подработку, с компаниями, которым нужны надежные исполнители временной работы. Основанная в 2019 году компания сейчас сотрудничает с такими лидерами рынка, как «Вкусвилл», Лента, Дикси, Spar и др. Сервис уже работает в Москве, Санкт-Петербурге, Новосибирске, Твери и Ульяновске и география присутствия продолжает расширяться.
На Хабр Карьере сотрудники оценили GigAnt на 4,79 из пяти, особо отметив интересные задачи, карьерный рост и то, что компания делает мир лучше. Посмотрите оценки и комменты в профиле Гигант на Хабр Карьере.
Оценка компании GigAnt на Хабр Карьере в 2021 году
Кстати, ребята сейчас активно набирают себе разработчиков, аналитиков и тестировщиков! Взгляните на их открытые вакансии, может вам что-то придется по вкусу.
Об условиях работы
Какой в вашей компании сложился рабочий график и какое отношение к переработкам?
Ольга Бессонова: Мы работаем по гибридному графику: в офисе и удаленно. Ребята пару раз в неделю встречаются в офисе (можно и удаленно) для синхронизации по важным и текущим вопросам, есть летучки, но у каждой команды они проходят по-разному. Есть те, кто проводит их каждый день утром по полчаса, в основном это команда HRM и мобильной разработки. Переработок у нас нет, так как все четко формируют свой график в зависимости от задач проекта.
Офис GigAnt в Санкт-Петербурге
Какие бытовые условия ждут нового сотрудника на рабочем месте?
Ольга: У нас просторный офис в Санкт-Петербурге в современном БЦ «Leader Tower» на 140-метровой высоте 40 этажа с потрясающим панорамным видом. По организации пространства — это open space со стеклянными перегородками и свободной рассадкой. Есть закрепленные рабочие места у тех сотрудников, кто постоянно работает в офисе. Мебель — эргономичные кресла, небольшие столы с розетками. Есть переговорная, столовая, зона для отдыха и любимый аквариум с акулами.
Есть ли возможность удаленной работы?
Ольга: Да, конечно, у нас многие сотрудники сейчас работают удаленно, например, у нас есть ребята в Сочи, Екатеринбурге, Москве или везде и сразу.
Какой социальный пакет получают сотрудники?
Ольга: Мы предоставляем все социальные гарантии в соответствии с ТК РФ. Зарплатный проект в «Альфа-банке», дополнительные выходные в случае плохого самочувствия, юридическая и финансовая помощь в сложных ситуациях. ДМС пока нет, но его подключение планируется в ближайшее время.
Какие бонусы, премии и компенсации предусмотрены в компании?
Ольга: Сегодня огромного списка бонусов и «плюшек» мы пока не можем предоставить, однако это связано не с отсутствием желания, а с нашей молодостью. Мы стремимся полностью покрывать потребности наших ребят — рабочие и развлекательные поездки в Москву, участие в профильных конференциях, премии самым крутым и всего по мелочи уже есть, но на этом мы точно не останавливаемся.
Какие есть перспективы для образования и личного развития у сотрудников?
Ольга: Помимо того, что в команде большое количество специалистов с интересным опытом, которые готовы и жаждут делиться знаниями, есть возможность вертикального развития: к примеру, технический писатель год назад уже сейчас может интегрироваться на продакт-менеджера, а помощник руководителя стать бизнес-аналитиком. И это все благодаря активному росту команды и сервиса.
Ну и само собой, этой вертикальное развитие подкрепляется предоставлением компанией возможности участия в конференциях, прохождения различных курсов, которые в совокупности позволят добрать требуемые компетенции и знания.
Валерия Бричалова, офис-менеджер Петербургского офиса разработчиков
О найме
Во сколько этапов проходит найм и что на них ожидает соискателя?
Ольга: Первый этап — это беседа с эйчаром. Мы смотрим, насколько релевантен опыт, знакомим с компанией, проектом, задачами. Выясняем ожидания кандидата. Второй этап — техническое интервью, где проверяем теоретические и практические знания. Третий этап — тестовое задание (опционально).
Даете ли вы тестовое задание кандидатам? Как оно устроено?
Ольга: В тестовых заданиях мы в первую очередь хотим оценить не погруженность в технологию, а подход и особенности мышления кандидатов. Однако тестовое требуется не всегда — бывают случаи, когда и без него понятно — это наш человек!
Как отличается подход к найму в зависимости от позиции и стека?
Ольга: Различия начинаются на самом входе — разработчиков, аналитиков или менеджеров мы подбираем на разных площадках и в разных комьюнити.
Далее, в зависимости от стека и позиции, может отличаться и количество проходимых этапов — собеседований, тестов. Как и отличается состав наших коллег, которых мы привлекаем к подбору подходящих кандидатов.
Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?
Ольга: «За орду!» — шутка 🙂 На самом деле, списка стоп-фраз у меня нет, но из недавних собеседований — есть кандидаты, которые отвечают вопросом на вопрос, например:
— Каким проектом вы больше всего гордитесь?
— Вы мое резюме читали? Там есть ссылки.
Денис Решанов, основатель и CEO GigAnt, на встрече с пользователями сервиса в 2021 году
Кого последнего вы уволили и почему?
Ольга: Не поверите, но увольнений у нас пока не было, даже тех, которые «по собственному желанию». Да и вообще, IT-команду покидает только один сотрудник из своих личных соображений, при этом оставаясь с нами на аутсорсинге.
Как происходит онбординг нового сотрудника?
Ольга: Онбординг ложится на плечи непосредственного руководителя при поддержке со стороны HR. Перед выходом нового сотрудника, помимо офисной и бумажной подготовки, внутри команды выбирается наставник, который помогает с адаптацией и погружением в продукт и инструменты. Сам процесс хронологически разделен на три этапа, по итогам которого собирается фидбэк и с новичка, и с наставника, и с руководителя, дабы уловить хоть малейший возможный дискомфорт и устранить его причину.
О команде
Какая методология разработки у вас используется и почему?
Игорь Фалин: Основополагающая методология у нас Agile. Если говорить именно про фреймворки, которые используем, то это смесь Kanban и Scrum, или Scrumban. Все задачи собираются и приоритезируются согласно дорожной карте — мы не бьем на четкие спринты и работаем в цикле постоянной выкладки: задача выполняется, мы ее реализуем, затем цикл повторяется. Это позволяет нам быстро обкатывать новый функционал, получать обратную связь и дорабатывать наш продукт. При этом мы не исключаем перехода на более «плавный ход» — к примеру, тем же спринтам — при масштабировании команды в несколько раз.
Каковы размеры и структуры команд?
Игорь: Наш IT-департамент разделен на три полноценные команды, плотно взаимодействующие между собой. Это Команда HRM, Команда Мобильного приложения и Команда Личного кабинета.
Каждая из команд укомплектована таким образом, чтобы имелась возможность обособленной разработки. На примере Личного кабинета расскажу про состав команды — продакт-менеджер, бизнес-аналитики, аналитики и data-инженеры, главный инженер, backend и frontend-разработчики, тестировщики, UX/UI, технический писатель и Devops-инженер. Последние трое принимают участие в разработке сразу нескольких продуктов.
Сотрудники ИТ-отдела
При этом на верхнем уровне менеджеры IT-команд являются составными частями вертикальных бизнес-команд — вот такой живой организм получается, жизнь которого позволяет быть уверенными в том, что любая крупная фича или доработка не станет неприятным сюрпризом для других частей продукта.
По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?
Игорь: У нас пока нет четкой градации. Сейчас внутри команды мы делим ребят по компетенциям и уровню погружения в продукт. В зависимости от этого кто-то из разработчиков работает только над task-задачами, а другие — участвуют в ревью и декомпозиции задач, а порой и помогают с бизнес-логикой.
Кто чаще возглавляет команды — продуктовый специалист или технический?
Игорь: Тут, наверное, надо разграничить два варианта: команда целиком и feature-команды. В первом случае руководство скорее ложится на продуктовую часть — это Product-менеджер и техлид. Во втором, при разработке каких-то важных и больших штук, уже главные технические специалисты перехватывают бразды для ускорения процесса и решения продуктовой задачи. В общем и целом, у нас получается гармония продукта и техники!
Как часто люди меняют команды?
Игорь: Так как мы существуем сравнительно недавно, то команды не меняются. Те, кто являются менеджерами в продуктовой команде, могут друг друга подменять в чем-то. Это не узконаправленные специалисты и они могут покрывать пул задач, связанных как с бизнесом, так и с разработкой. Разработчик может заниматься базой знаний и управлять задачами, так как он уже погрузился в это. В технической команде специалисты могут переходить на другие направления, например, у нас есть разработчики, которые из HRM ушли в мобильную разработку. Также есть и те ребята, которые взяли на себя управленческие задачи, при этом зная, что если им придется это не по душе, то можно все откатить обратно.
Что важнее, софт-скиллы или хард-скиллы?
Игорь: Если смотреть с технической стороны, нам очень важны хард-скиллы, но, если человек не обладает хотя бы базовыми софт-скилами, то с таким человеком будет сложно. Мы в компании при подборе новых кадров ориентируемся на четыре софт-скилла:
Инициативность: сотрудник не только приходит сделать свою работу хорошо, он пытается улучшить продукт своими знаниями, предлагает решения проблем.
Ответственность: здесь каждый член команды готов нести ответственность за принятые им решения и понимает, что каждое из них отражается на продукте.
Работа на результат: готов совершенствовать свои знания и продукт.
Позиция Win-Win: Сотруднику интересно реализовывать проекты и достигать цели, а компания «не мешает» и всецело поощряет.
Как много собраний у вас проводится? Есть ли особые подходы к ним?
Игорь: Некоторые стандарты мы взяли из Scrum. Например, стендапы по 15 минут на направление: утром встречаются HRM-команда и команда мобильного приложения (состав незначительно отличается, так как пока что много людей задействовано на обоих проектах). Мы отмечаем моменты, по которым необходимо собрать Adhoc-встречи. Также есть ретро, на которых разбираем прошедший квартал или большой этап разработки и выявляем слабые места для их дальнейшей проработки. Ну и наконец, демо-дни — бизнес рассказывает про то, чего мы добились компанией и куда мы движемся.
В будущем, при расширении команды, набор митингов сохранится. Возможно, несколько поменяется формат, однако пока каждое наше очное общение оказывает только положительный эффект на разработку.
Игорь Фалин, продакт-менеджер компании GigAnt
Как вы боретесь с выгоранием сотрудников?
Игорь: У нас сведены к минимуму факторы выгорания. У нас по большей части только осмысленные задачи и все понимают, зачем они их выполняют. Мы стараемся дать больше свободы в планировании своих задач. Конечно, мы ставим приоритеты, но, если, например, кому-то нужно взять день на отдых или по другим обстоятельствам, конечно, мы его предоставляем. Всегда есть возможность сдвинуть график. И мы не поддерживаем постоянное давление и постановку сложных задач, мы ко всему подходим с пониманием.
О технологиях
Какие языки, фреймворки и библиотеки используются на проекте?
Яков Макаров: Для баз данных мы используем PostgreSQL, потому что это надежная система с достаточной производительностью. Бэкенд пишем на PHP, от команды к команде версия отличается — это либо 7.4, либо 8.0, в планах перейти на 8 версию. Мы используем везде фреймворк Symfony и нам сейчас как раз нужны люди с экспертизой в Symfony. Сервисы, требующие параллельного исполнения и которые должны очень быстро работать мы пишем на Go.
Веб интерфейс написан на Vue с TypeScript. Vue показал себя как удобное средство для разработки. Сознательно был выбран TypeScript, потому что строгая типизация позволяет отлавливать большое количество багов и значительно упрощает внесение правок. Для мобильной разработки у нас используется Flutter, его мы выбрали потому что одна команда разработчиков может сразу делать приложение, релизить его и под Android и под iOS.
Наши аналитики используют Python. Он также используется для подготовки данных.
Яков Макаров, Lead Engineer в GigAnt
Что вы можете рассказать об архитектуре проектов?
Игорь: Она постоянно меняется. Изначально это был MVP, построенный на Google-таблицах. Сейчас же мы используем облачную инфраструктуру, в частности, Яндекс.Облако, в которой развертываем проекты, состоящие из взаимодействующих между собой контейнеров. Подробно описать архитектуру без приведения графических материалов кажется нереальным, поэтому ограничусь таким кратким ответом.
Какая у вас принята политика код-ревью?
Игорь: Сейчас из-за небольшого количества разработчиков, у нас ревью проводят сами же разработчики. У нас есть условие, чтобы были Unit-тесты и правильно закоммитченные комментарии.
Сейчас код-ревью проводят несколько самых опытных разработчиков. При этом есть условие попадания кода на ревью: написанные Unit-тесты и правильно зафиксированные комментарии. Возможно в будущем подход будет меняться, но на данный момент придерживаемся принципа «просто = хорошо».
Как тестируется код?
Яков: На данный момент у нас пишутся Unit-тесты и происходит ручное тестирование. Юнит-тесты гоняются каждый раз при коммитах в репозитории, дальше тестировщик проверяет ветку с реализованной функциональностью и затем реализованная функциональность попадает в мастер, где уже в мастере, перед релизом происходит очередное ручное финальное тестирование. После этого функциональность попадает в продакшн и становится доступна пользователям. В этом направлении мы сейчас продолжаем развиваться. В планах у нас добавить автотесты с использованием Selenium.
Кроме этого, мы планируем учитывать покрытие кода тестами, чтобы тестировщики при ручном тестировании особое внимание обращали на тестирование функциональности, которое не покрыто автотестами. В ближайшее время мы также будем внедрять системы PHPUnit и Behat — это по сути фундамент, фреймворки, на базе которых мы будем развивать свои собственные решения.
Сотрудники ИТ-отдела компании GigAnt
Как устроен процесс документации и ведения базы знаний на проектах?
Николай Красильников: В документировании на проектах можно выделить два ключевых процесса: техническое описание продуктов и документация API. Техническое описание продуктов предназначено для сохранения всех знаний о продукте, что упрощает разработку, онбординг новых сотрудников и многие другие процессы. Обновление функционала, добавление новых, устранение багов и другие работы документируются параллельно с их выкаткой в production.
На этапе декомпозиции задачи и передачи ее в development заводится отдельный task на технического писателя, в рамках которого последний добавляет правки или создает новые страницы в документации. Инструмент документирования — Notion. Благодаря настроенным интеграциям между инструментами разработки, документация включает в себя автоматически обновляемые UI-киты и бизнес-процессы, связанные с функционалом, а также элементы кода и ссылки на трекер задач.
Документирование API происходит непосредственно разработчиком. Инструмент: Postman. Однако сейчас мы уже подключаем Swagger, поэтому через неделю-две мой ответ изменится кардинально 🙂
Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?
Игорь: Так как коду у нас чуть больше года, то про это говорить еще рано.
Оценивайте своих работодателей на Хабр Карьере и делитесь мнением о них с теми, кто сейчас ищет работу в ИТ. Это анонимно.
GigAnt’ские инвестиции: как Логомашина делала брендинг для сервиса, который привлёк полмиллиарда
Ещё полтора года назад все сотрудники «GigAnt» помещались в съёмной квартире в Чертаново, а сегодня это компания, которая получила многомиллионные инвестиции от «Авито». Команда «Логомашины» рассказывает, как придумывала имя и создавала айдентику для рекрутингового сервиса.
Идея создания рекрутингового сервиса для part-time сотрудников у предпринимателя Дениса Решанова возникла ещё в 2017 году — вдохновила проблема с наймом магазинами сотрудников на полсмены: люди не хотели работать за ползарплаты, а бесконечно «стыковать» смены тех, кто изредка берёт подработку, для крупных ритейлеров было практически невозможно.
«GigAnt» был создан, чтобы решить эту проблему: сервис работает подобно «Tinder» — соединяет графики исполнителей и ритейлеров. При этом исполнитель выходит на смену с 99% вероятностью: «GigAnt» это гарантирует. Бизнес-модель позволяет сделать дополнительный заработок постоянным, а поиск сотрудников на несколько часов быстрым и надёжным. Сейчас сервис обслуживает более пятисот торговых точек «Пятёрочки», «ВкусВилла», «Cinnabon» и «Lacoste». Выйти на смену к ним готовы три тысячи исполнителей из Москвы, Петербурга, Новосибирска, Ульяновска, Твери и Калуги.
«GigAnt» — это умный алгоритм плюс внимательная персонализированная работа с клиентами и исполнителями
Команде «Логомашины» предстояло разработать для стартапа название, логотип и фирменный стиль, которые выделили бы «GigAnt» на фоне других сервисов по подбору «синих воротничков».
Проведя исследования, мы выяснили, что большинство игроков на рынке по подбору линейного персонала используют в фирменном стиле тёмные и приглушённые цвета. «GigAnt» захотел идти собственной дорогой, привлекая внимание аудитории за счёт яркой и современной айдентики.
Изначально «GigAnt» задумывался как открытый маркетплейс, где работники и работодатели смогли бы найти друг друга самостоятельно, однако таких предложений на рынке было достаточно, поэтому особенностью сервиса стала гарантия качества ритейлерам и постоянной занятости исполнителям.
По результатам исследования «GigAnt» выбрал стратегию изменений, взяв в качестве архетипа волшебника: сервис решает задачи ритейлеров и пользователей с помощью новых технологий, перестраивает бизнес-модели, разрабатывает современные IT-решения.
Целевая аудитория проекта — линейный персонал от 25 до 45 лет, который нуждается в дополнительном заработке, и ритейлеры, которых хотят разгрузить штатный персонал в часы-пик и снизить затраты на сотрудников в спокойное время.
Изучив рынок, мы обнаружили, что более 60% компаний используют в названиях слова «staff» или «персонал». Мы решили посмотреть на нейминг свежим взглядом, не забыв при этом отразить в имени проекта одну из его ключевых идей. В шорт-лист названий вошли следующие варианты:
В итоге остановились на названии «GigAnt». Gig (от «gig worker» — «фрилансер») напрямую отражает формат работы пользователей сервиса, а ant («муравей») означает трудолюбие будущих исполнителей.
Кроме того, название «GigAnt» легко произносится и для русскоязычных пользователей ассоциируется с масштабом и размахом.
Дизайнеры «Логомашины» разработали округлый логотип, который транслирует идею проекта: «GigAnt» — это надёжный и открытый партнёр, который выручит в трудный час.
В знак мы поместили символы человека и улыбки. Если необходимо, знак можно использовать отдельно: например, преобразовать в смайлики или простой паттерн.
Автоматизация процессов в стартапе: боль и ошибки GigAnt
Когда компания растет быстро, неизбежно увеличивается количество новых задач. В какой-то момент мы столкнулись с тем, что сотрудники начали тонуть в бумагах и бесконечной коммуникации.
В таких случаях выступает автоматизация, благодаря которой можно убрать под капот повторяющиеся прогнозируемые действия и высвободить ресурсы. Делимся опытом, как мы в GigАnt автоматизировали рабочие процессы: через какие ошибки прошли и что можно сделать, чтобы их избежать.
Как готовиться к процессу автоматизации
Сначала нужно понять, какие процессы точно нужно автоматизировать. Например:
растущие с такой же скоростью, что и компания,
те, от которых нельзя отказаться.
Так формируется список и возможная очерёдность их автоматизации.
Первым делом мы составили карту бизнес-процессов и трудозатрат. Это было нужно для того, чтобы понять, какие трудозатраты будут расти вместе с масштабированием и фокусироваться именно на них.
Также мы учитывали те процессы, которые радикально не поменяются, но и отказаться от них без последствий для ключевой метрики мы не можем. В нашем случае это показатель SLA (соглашение об уровне сервиса).
Иногда оказывается, что от процесса проще отказаться, потому что он не даёт весомый результат, и его автоматизация будет невыгодной.
Подготовка к автоматизации конкретного процесса
Для начала неплохо получить метрики, чтобы понимать, что можно автоматизировать. Они позволяют понять, как процесс себя поведёт при масштабировании.
Например, так мы сделали в отделе реализации, который отвечает за выполнение заказов и решение проблем с исполнителями.
Мы измерили, сколько ресурсов тратится на ту или иную ежедневную задачу. Оказалось, что больше всего времени требуется на обзвон и подтверждение выхода исполнителей на заказ. Чем больше заказов, тем больше таких сообщений будет. Так стало ясно, что этот процесс нужно автоматизировать.
Также стоит пообщаться со стек-холдерами процесса. На бумаге всё может выглядеть одним образом, а в жизни совсем иначе.
Так было с задачей, где менеджер вручную подбирает исполнителя на заявку, на которую никто не откликнулся. Нам нужно было автоматизировать этот процесс, однако выяснилось, что общих сценариев очень мало, и их надо детально прорабатывать.
То есть фактически мы поняли, что нам нужно создать новый процесс, и потом его автоматизировать.
Если во время изменений что-то ломается, проще всего призвать на помощь тех, кто уже работает с процессом. Например, для настройки рассылок SMS и пуш-уведомлений исполнителям нужно было, чтобы менеджеры сами прошли этот путь: это быстрее и проще. Плюс так можно совершить меньше ошибок при автоматизации и последующей поддержке продукта.
Что может пойти не так
Основные вопросы при автоматизации — выдержит ли система нагрузку и можно ли её потом масштабировать и добавить что-то новое. Иначе можно оказаться в ситуации, когда заказчику нужна новая функция, а ваша система её не поддерживает.
К тому же, стоит проверять на прочность необкатанные бизнес-процессы — особенно, если вы не уверены, что будете пользоваться ими много лет.
Например, нам было крайне важно собирать паспортные данные. Но на этом этапе у нас отваливалось 50% лидов. Мы обговорили этот вопрос с юристами. И оказалось, что можно построить процесс иначе — без сбора паспортных данных.
При интеграции есть большая вероятность, что возникнут ошибки. Вопрос в том, насколько это будет серьёзно. Тут стоит помнить, что рано или поздно переезжать всё равно придется. С этой проблемой сейчас столкнулись большие компании, которые развивались в 90-е. Они просто не могут перевести на современные рельсы свои системы, а поддержка старых технологий уже заканчивается.
Где можно использовать автоматизацию и какие ресурсы для этого использовать
В GigAnt автоматизация есть на уровне аналитики, финансов и технической части. Также есть возможность частично автоматизировать задачи онбординга.
Нашим первым инструментом были «Google Таблицы», сейчас мы ещё используем их в онбординге amoCRM. Он позволяет масштабироваться за счёт сторонних ресурсов и подключать их. Это прослойка между каналами привлечения, которая снимает груз с разработки.
Также мы привлекли для автоматизации финансов сервис «Рокет Ворк». Так мы решили вопрос своевременного формирования, отправки и проверки чеков нашими исполнителями. Чеки нужны для отчёта перед налоговой.
С подключением сервиса нагрузка снизилась, и теперь перед нами стоит задача автоматизировать уведомления для того, чтобы исполнители подключали «Рокет Ворк».
В будущем мы также планируем автоматизировать через «Рокет Ворк» выплаты. Это позволит увеличить скорость работы и снизит нагрузку на финансистов. При этом нужно будет автоматизировать сверку с заказчиком — мы планируем, что этот процесс будет проводиться в нашем интерфейсе. В результате мы придём к выплатам день в день и разгрузим отдел финансов.
Для автоматизации онбординга мы выбрали AcademyOcean из-за гибкости настроек системы мониторинга и сбора аналитики. Многие похожие системы сейчас можно интегрировать в процессы, а разработкой своей собственной аналитики веб-событий пока занимаются только гиганты рынка.
Готовые решение или свои разработки
Лучший вариант — это когда всё работает и желательно бесплатно. Но всё зависит от того, насколько решение закрывает текущие потребности бизнеса. Если можно что-то интегрировать — это хороший вариант. Но во многих задачах такие решения могут не подходить.
К примеру, нам нужно было автоматизировать работу с онбордингом. Мы пересмотрели много вариантов: сайты на Tilda, использование LMS или создание своей системы. Первый вариант не подошёл из-за качества и требуемых времени и денег. Самостоятельная разработка была бы сложной и долгой из-за отсутствия ресурсов. А в LMS нужен был только небольшой кусок функционала.
В результате мы нашли подходящее решение, о котором говорили в прошлом пункте. Но мы понимаем, что в какой-то момент понадобится переходить на свою разработку или пересматривать функционал с текущей компании.
Из собственных разработок мы используем свой алгоритм, который соотносит свободное время исполнителей и заказы клиентов. А также второй алгоритм, который прогнозирует требуемое количество исполнителей к определённому времени и в определённом магазине.
Тем не менее, готовое решение может помочь, когда есть целый пул работ, но нет ресурсов для их реализации. Так мы использовали amoCRM для работы со статусами, распределения задач по менеджерам. Когда появились ресурсы и ушли более важные задачи, мы просто собрали похожую систему у себя в HRM.
