Нанимать и растить сотрудников, знакомить заводы с ИИ: опыт rdl by red_mad_robot

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

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

Именно от этих вводных будет зависеть решение по формированию команды и возможности нанять в неё джуна. К сожалению, мы не сможем этого сделать, если:

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

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

С одной стороны, можно за короткий период прокачать джуна в мидла под определённый тип задач, но это не гарантирует, что он будет способен решать иные, более сложные задачи. Для целостного развития из джуна в мидла и далее нужны время и последовательность. Поэтому мы в rdl просчитали пропускную способность разных практик (разработки и не только): сколько у нас есть тимлидов и сеньоров, способных и готовых взять джунов к себе на менторство.

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

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

Помочь сотруднику определить его карьерные цели и желания может HR: с одной стороны, именно он отвечает за разработку процесса развития людей внутри компании, с другой — за локальную проработку 1–2–1 с каждым сотрудником (начиная от помощи в определении мотивации, заканчивая совместным выстраиванием траектории развития внутри компании). Это помогает продлить жизненный цикл сотрудника внутри компании, сохранять и развивать компетенции внутри.

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

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

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

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

При завершении испытательного срока сотрудник вместе с руководителем проводит ретроспективу по прошедшему периоду, где они обсуждают успехи и lessons learnt, обмениваются обратной связью и определяют траекторию развития нового сотрудника на следующие 6–9 месяцев, когда происходит более глубокое встраивание в команду и бизнес. Для этого мы используем скиллсеты и индивидуальные планы развития.

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

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

Чтобы замерять результаты, у нас также есть система периодических ассессментов. Ассессмент в rdl — это ретроспектива предыдущих 6–9 месяцев работы, где сотрудник анализирует, с какими задачами он сталкивался, что в его работе было полезного для бизнеса и для него самого, с какими сложностями он столкнулся и какие выводы из этого сделал. На ассессменте робот сверяется с индивидуальным планом развития, проводит новый цикл самооценки по скиллсету, валидирует его с руководителем и фиксирует новые цели в плане.

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

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

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

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

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

Их цель — аккуратно подобрать из набора всех существующих в мире технологий те, из которых можно будет в итоге спроектировать решение. Чтобы не делать лишнюю работу, не тратить время и деньги клиента, мы приступаем к этапу proof of concept — тестируем ряд гипотез, чтобы понять, какая в итоге сможет превратиться в MVP именно с теми эффектами, которые необходимы заказчику.

Когда этап proof of concept позади, гипотеза есть, технологические средства для её проверки тоже определены, а все сложности с камерами решены, можно приступать к съёмке.

Чтобы натренировать computer vision, допустим, для контроля гранулометрического состава руды, нужно очень много разных образцов для сравнения. А если мы хотим сделать так, чтобы с помощью CV оператор технологического процесса смог легко отбраковывать негабаритные куски руды, то нам нужен не один и не два таких негабарита, а сотни.

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

Вместо этого мы использовали Stable Diffusion. Из одной фотографии негабаритного камня нейросеть сгенерировала множество вариаций. Благодаря этому мы смогли натренировать модели с использованием минимального количества физической руды, сфотографированной во время планового обслуживания конвейера, и без неудобств для производства.

Над материалом работали:

Чтобы ничего не пропустить, следи за развитием цифры вместе с нами:

Redmadnews

Design Jam

red_mad_product

red_mad_dev

LinkedIn

VK