Ти си уволнен

Как да разработите и управлявате щастлив екип за наука за данни

TLDR: Повечето екипи за машинно обучение не обичат да работят с данни и инфраструктура, защото това не е толкова интересно, колкото моделирането. Лошото управление на проблема може да доведе до голямо текучество и токсична атмосфера в екипа. Искам да споделя решение, наречено Insight-Driven Development (IDD), няколко примера за него и пет стъпки за приемането му. IDD има за цел да създаде високоефективни, ангажирани и щастливи екипи за наука за данни, които прегръщат работата извън ML толкова, колкото и забавните ML неща.

Харесвате това, което четете? Следвайте ме в Medium, LinkedIn, Twitter. Вижте моето ръководство „Влияние с машинно обучение“. Помага на специалистите по данни да комуникират по-добре.

Отказ от отговорност: Тази публикация не е одобрена или спонсорирана от нито една от фирмите, за които работя. Използвам взаимозаменяемо термините Анализ, Наука за данни и машинно обучение.

Ти си уволнен!

„Хей, човече, не се получава. Трябва да те отхвърлим от проекта. Съжалявам. Алекс, компетентен изследовател на данни, ме гледа безчувствено. Чувствам се безпомощен, нервен и тъжен.

Сигурно ме ругае с най-силните езици.

И така, току-що „уволних“ един от двамата специалисти по данни от проекта. Защо?Алекс мразеше да работи с данни. Той е много вокален за това. Той използва всякакви извинения, за да го „претовари“ на някой друг. Говорихме за това; той все още свърши работа наполовина. Други хора се разочароваха и се оплакваха защо само Алекс трябва да прави готините неща. Ние, като екип, щяхме да се провалим, ако това продължи. И така, ето ни.

„Мамка му пич. Съжалявам." – каза Алекс накрая. По дяволите, това е неудобно.

Проблемът

„Проблемът Алекс“ е доста често срещан сред екипите за наука за данни. Много специалисти по данни „се чувстват отегчени и немотивирани“. Мисля, че има две основни причини:

1. има разлика в това, което екипите на Data Science искат да правят спрямо това, което трябва да правим в реалния свят
2. Не-учените по данни желаят да развият най-много (възприеманите) търсени набори от умения

Решението

Онзи ден „управлявах“ проблема с Алекс и се почувствах гадно. В този момент изграждането на високоефективен, ангажиран и щастлив екип за Data Science стана моя мисия.

Като минимум искам система, която ще насърчи екипа за наука за данни да приеме работа, която не е свързана с машинно обучение, и да се забавлява, докато го прави. Е, очевидното решение е да принудим хората да го правят (на всички ни се плаща да работим, нали?). Но това не е устойчиво. Така че решението трябва да бъде практично, приятно и самомотивиращо.

През следващите години започнах пътуване на изпробване и смесване на основни идеи от управление на продукти, гъвкаво разработване на софтуер и управленско консултиране. Мисля, че намерих решението: Развитие, управлявано от прозрения (IDD).

Обхват на този член

Обикновено има два типа ML проекти: фокусирани върху бизнеса и базирани на софтуер проекти. В тази статия нека обсъдим принципите на IDD в контекста на бизнес фокусирани ML проекти. Резултатите от тези проекти обикновено са презентации или табла за управление на изпълнително ниво. Екипът трябва да използва специфични техники за машинно обучение, от прости до сложни, за да намери някаква представа.

В зависимост от това как работи тази публикация, мога да се потопя задълбочено в 1) как IDD работи в ранните, средните и късните фази на проекта и 2) как да адаптирам IDD за софтуерно фокусирани ML проекти (напр. резултатите са пълни- стекови решения, които се интегрират с основните операции).

Предположения за екипите

За да използвате IDD, се нуждаете или от екип от опитни хора с уникални занаяти и са мотивирани да опитват нови неща, или от група младши специалисти, които са мотивирани, могат да свършат нещата и да бъдат формовани. Ако не, IDD не е за вашия екип (и трябва да погледнете отново стратегията си за наемане).

Да се ​​впуснем в това: Принципите на IDD

IDD се свежда до правене на две неща по различен начин:

1. Как да обхванете работата за всеки член на екипа (напр. известен също като „Работен пакет“, какво трябва да предостави всеки).
2. Как да възложим отговорносттаспоред силата на хората

Първо, нека да разгледаме как работните пакети могат да бъдат дефинирани по различен начин с илюстративен пример. По-долу има две Натрупани задачи без и с IDD за един и същ проект, при същия Спринт и със същите непосредствени цели.

Как обикновено управляваме ML проекти? В повечето ML проекти разделяме работните пакети на четири групи:

1. Данни
2. Анализ(използвам това като всеобхватен термин, който обхваща проучвателен анализ и разработване на модел)
3. Софтуер (напр. системна интеграция, настройка на инфраструктурата и CICD)
4. UI дизайн и разработка.

Някои проекти може да имат бизнес сфера, ако това е тип ангажимент за управленско консултиране.

Какво се промени? В IDD най-очевидната промяна е, че има повече елементи „Анализ“ (неща в жълто). Всеки елемент от Анализ е внимателно формулиран в един вид анализ; всеки анализ има за цел да изведе интересни прозрения; всяко прозрение допринася за по-големия бизнес проблем въз основа на нашата хипотеза. Следователно този подход има името Insight-Driven Development.

Какво се случва с работата с данните и инфраструктурата? Ако се вгледаме по-отблизо, всеки елемент от Анализ включва ETL и инфраструктури в „Дефиницията за готово“. Работата по данните и инфраструктурата все още е много критичен. Ние не ги избягваме, а ги правим като част от пътуването към прозрение.Има определени предупреждения за този подход. Например, някои дейности по данни и инфраструктура трябва да бъдат самостоятелни, особено в ранната фаза на проекта. Ще обсъдим повече в последваща публикация.

Как да възлагаме работа? Изглежда, че има много повече елементи, които са свързани с анализа. Не е практично да присвоите всички на специалистите по данни. Хората имат различни силни страни, опит и интереси. И така, това ни отвежда до втория аспект на IDD: възлагане на отговорност.

Обикновено ролите определят отговорността на хората. Например инженерите по данни притежават и работят върху всички и вероятно само върху нещата, свързани с данните.

В IDD отговорността на всеки човек се измества към резултатите от техните непосредствени роли. Екипът „работи около прозрение“. Всеки човек притежава окончателната доставка на прозрения. За да поддържа баланс на качеството, всеки експерт определя стандарта, ръководи програмирането (ако е необходимо) и е последният пазач на качеството за своята експертиза в областта.

Имайки това предвид, работното задание ще изглежда така със и без IDD. Основната разлика е, че хората могат да ръководят работа извън непосредствената си роля и домейн с подкрепата на другите.

Имайте предвид, че конкретна работа все още изисква високоспециализирани умения и е най-добре да възложите на експертите. Вие, като ръководител на проекта, трябва да наблюдавате работното натоварване и да предоставяте достатъчно насоки на хората, които ръководят работата извън техния непосредствен опит (напр. инженер по данни, създаващ клиентски анализ). Всеки член на екипа трябва да работи в тясно сътрудничество и да комуникира очакванията и времето.

Ползите

Използвам IDD както в бизнес, така и в софтуерно фокусирани ML проекти с екипи от бизнес анализатори, експерти по данни, учени по данни и софтуерни инженери с различни години опит. Работи добре и аз ще продължа да използвам и усъвършенствам IDD. По-конкретно, IDD работи, защото позволява на всеки да:

1. включете се в процеса на решаване на проблеми (по-интересно)
2. вижте как работата им пряко допринася за крайната цел (по-ангажирани)
3. разбират как да усъвършенстват дизайна си, като имат повече контекст (повече качество)
4. получите възможност да работите върху нови домейни (повече обучение)
5. продължете да бъдете експерт в своята област (същата сигурност)

Всеки екип във всяка компания работи по различен начин. Така че, моля, вземете принципите и ги прилагайте по съответния начин. Очаквайте малко объркване, напрежение и несигурност. Бъдете търпеливи, нещата ще щракнат.

План за действие

Ако харесвате подхода, ето какво можете да направите, за да приемете IDD във вашата компания.

Стъпка 1.Уверете се, че вашите екипи и приятели разбират IDD. Така че, споделете тази статия с вашите приятели и екипи със заглавието „Задължително за четене.“ 😉

Стъпка 2.Изберете малък ML проект, който е фокусиран върху бизнес прозрения (напр. използвайте ML, за да намерите нов клиентски сегмент и да оцените потенциала). В идеалния случай трябва да е нещо, което можете да завършите в рамките на 2–4 месеца с екип от 5 опитни инженери.

Стъпка 3.Събирайте своя A-отбор. Основният екип трябва да сте вие ​​(като ръководител на проекта), инженер по данни, инженер по машинно обучение, софтуерен инженер и дизайнер на UI. Може да се нуждаете от поддръжка на непълно работно време от бизнес анализатор и ИТ.

Стъпка 4.Отидете на кафе или питие с екипа и се съобразете с този подход (намирам, че хората са по-отворени към нови идеи, когато сме извън офиса).

Стъпка 5.Стартирайте проекта. Устояйте на изкушението да се върнете към стария начин на работа. Дайте малко време на екипа да се научи (и да се провали). Обърнете внимание на това как отделните лица доставят IDD.

Бонус

Ето няколко Не правете, за да ви предпазим от някои неудобни моменти:

• Не избирайте голям и критичен за мисията проект.
• Не избирайте софтуерно фокусиран ML проект (все още)
• Не въвеждайте IDD в проект по време на полет.
• Не стартирайте проекта, освен ако всички не са включени.
• Не принуждавайте хората да ръководят развитието на прозрението, ако не им харесва (можете да преподавате, но не можете да принуждавате хората).

Ако се интересувате от тази тема, нашите приятели от Neptune написаха фантастичен блог на тема Как да изградим екипи за машинно обучение, които дават резултати.

Надявам се това да ви хареса. Бих искал да чуя как IDD работи за вашия екип (и как не). Можете да се свържете с мен в Medium, LinkedIn или Twitter.

В зависимост от това как се развива тази публикация, ще проследя, за да обсъдя как работи IDD за софтуерно фокусирани ML проекти (напр. резултатите са решения с пълен стек, които се интегрират с основните операции).

Може да харесате и тези...