چرا تیم‌های علم داده به افراد با تخصص عمومی نیاز دارند، نه افرادی با یک تخصص؟

خلاصه مقاله:

اغلب کسب و کارها برای بهره‌وری و کارآمدی ایجاد می‌شوند. آن‌ها این کار را از طریق تخصصی‌سازی فعالیت‌ها انجام می‌دهند. کارگرانی که در یک کار مشخص مهارت بالایی دارند، می‌توانند مهارت خود را تکمیل کرده و هنگامی در خط مونتاژ قرار می‌گیرند، کالاهایی با کارایی بالا تولید کنند. تیم‌های علم داده نیز به همین شیوه تشکیل می‌شوند و وظایف کاملا تخصصی به افراد واگذار می‌شود و آن‌ها برای ایجاد ظرفیت‌های تجاری جدید با یکدیگر همکاری می‌کنند. اما این روش اشتباهی برای تشکیل یک تیم علم داده است زیرا دانشمندان داده اغلب نمی‌دانند چه چیزی تولید می‌کنند تا زمانی که به آن برخورد کنند. هدف آنها باید یادگیری باشد نه کارآمد بودن. برای به حداکثر رساندن یادگیری، تیم‌ها باید به‌عنوان گروه‌هایی از متخصصان عمومی سازماندهی شوند که می‌توانند بسیاری از وظایف علم داده را انجام دهند. این مساله بسیاری از تنگناهای کلاسیک در علم داده  که منجر به نتایج ضعیفی می‌شوند را کاهش می‌دهد. تیمی که از متخصصان عمومی و همه فن حریف تشکیل شده باشد، کارایی بهتری داشته و به کسب‌وکار بیش‌تر کمک می‌کند.

در ثروت ملل، آدام اسمیت با استفاده از مثال واضح خط مونتاژ کارخانه پین، نشان می‌دهد که چگونه تقسیم کار، منبع اصلی افزایش بهره‌وری است: «یکی سیم را بیرون می‌کشد، دیگری آن را صاف می‌کند، سومی آن را برش می‌دهد. چهارمی نشانه‌گذاری می‌کند، پنجمی آن را می‌کوبد.» ” با گرایش به سوی تخصصی شدن حول عملکرد، هر کارگر در یک کار محدود که منجر به کارایی می‌شود مهارت بالایی پیدا می‌کند. خروجی به ازای هر کارگر چندین برابر افزایش می‌یابد و در نتیجه کارخانه در تولید پین بسیار کارآمد می‌شود.

امروزه این تقسیم کار  بر اساس عمل چنان در ما ریشه دوانده‌است که ما به سرعت تیم‌هایمان را براساس آن تشکیل می‌دهیم. علم داده نیز از این قاعده مستثنی نیست.

یک قابلیت در کسب‌وکار الگوریتمی end-to-end به توابع زیادی نیاز دارد، و بنابراین شرکت‌ها معمولا تیمی با حضور متخصصان مانند دانشمندان پژوهشی (research scientist)، مهندسان داده، مهندسان یادگیری ماشین، دانشمندان استنتاج علّی (causal inference scientists) و … را تشکیل می‌دهند. کار این متخصصان توسط یک مدیر محصول، با دست به دست شدن بین توابع به شیوه‌ای که شبیه به کارخانه پین است، هماهنگ می‌شود: “یک شخص داده را تامین می‌کند، دیگری آن را مدل می‌کند، سومی آن را اجرا می‌کند، و چهارمی آن را اندازه‌گیری می‌کند” و این فرایند ادامه دارد. 

افسوس، ما نباید تیم‌های علم داده خود را برای افزایش بهره‌وری بهینه‌سازی کنیم. اقدام برای افزایش بهره‌وری زمانی اتفاق می‌افتد که شما بدانید به دنبال تولید چه چیزی هستید مانند پین. هدف خطوط مونتاژ اجرا است.مانند پین در مثال اسمیت، ما دقیقا می‌دانیم که چه می‌خواهیم  اما می‌توان به هر محصول یا سرویسی فکر کرد که در آن الزامات به طور کامل تمام جنبه‌های محصول و رفتار آن را توصیف می‌کنند. سپس نقش کارگران این است که آن الزامات را به بهترین نحو ممکن اجرا کنند.

اما هدف علم داده اجرا کردن نیست. در عوض، هدف یادگیری و توسعه قابلیت‌های عمیق تجاری جدید است. محصولات و خدمات الگوریتمی مانند سیستم‌های توصیه‌‌ای، روش‌های تعامل مشتری، طبقه‌بندی سبک‌های اولویت‌بندی، تطبیق اندازه در سیستم‌های طراحی مد، بهینه‌سازهای لجستیک، آشکارسازی روند فصلی و غیره را نمی توان از پیش طراحی کرد. آن‌ها باید یاد گرفته شوند. هیچ برنامه کاری برای دنبال کردن وجود ندارد. این موارد قابلیت‌های جدیدی با عدم قطعیت ذاتی هستند. ضرایب، مدل‌ها و انواع آن، پارامترهای بیشتر و تمام عناصری که نیاز دارید باید از طریق آزمایش، آزمون و خطا و تکرار یاد گرفته شوند. با استفاده از پین‌ها، یادگیری و طراحی  در ابتدا انجام می‌شود، قبل از این که شما آن را بسازید. با علم داده، شما همانطور که پیش می‌روید، یاد می‌گیرید، نه قبل از شروع آن

در کارخانه پین، وقتی که یادگیری در درجه اول قرار می‌گیرد، ما نه انتظار داریم و نه می‌خواهیم که کارگران در هر جنبه از محصول نوآوری داشته باشند، به جز این که باعث تولید محصول موثرتری شوند. در این جا سازماندهی تیم  با کمک بررسی عملکرد منطقی به نظر می‌رسد زیرا تخصصی سازی کار منجر به کارایی فرآیند و سازگاری تولید می‌شود (‏هیچ تغییری در محصول نهایی وجود ندارد)‏.

اما زمانی که محصول هنوز در حال تکامل و هدف یادگیری است، تخصصی سازی به روش‌های مختلف مانع از رسیدن به اهداف ما می‌شود:

۱- این کار هزینه‌های هماهنگی را افزایش می‌دهد.

اینها هزینه‌هایی هستند که در زمان صرف شده‌برای برقراری ارتباط، بحث، توجیه، و اولویت‌بندی کارهایی که باید انجام شوند، افزایش می‌یابند. این هزینه‌ها به صورت خطی با توجه به تعداد افراد درگیر با پروژه مقیاس گذاری می‌شوند. 

(همانطور که جی ریچارد هاکمن به ما آموخت، تعداد روابط (r) به عنوان تابعی از تعداد اعضا (n) در این معادله افزایش می یابد: r = (n^2-n) / 2. و هر رابطه مقداری از هزینه‌های هماهنگی)

وقتی دانشمندان داده توسط عملکرد سازمان دهی می‌شوند، بسیاری از تخصص‌ها ممکن است در یک مرحله، یک تغییر و یک جابجایی مورد نیاز باشند و این موضوع هزینه‌های هماهنگی را بالا می‌برند. برای مثال، متخصصان مدلسازی آماری که می‌خواهند ویژگی‌های جدید را امتحان کنند، باید با مهندسان داده هماهنگ شوند که مجموعه داده‌ها را هر بار که می‌خواهند چیز جدیدی را امتحان کنند، زیاد می‌شوند. همین طور، هر مدل جدید آموزش داده به این معنی است که مدلساز برای استقرار به کسی نیاز دارد تا با او هماهنگ شود. هزینه‌های هماهنگی مثل مالیات در یک اسپرینت عمل کرده و آن را سخت‌تر و پر هزینه‌تر می‌کنند و به احتمال زیاد باعث دلسرد شدن افراد در جست‌وجو می‌شوند. که می تواند یادگیری را مختل کند.

۲- این کار زمان انتظار را زیاد می‌کند.

حتی بدتر از هزینه‌های هماهنگی، زمانی است که بین انجام کارها  تلف می‌شود. به طور معمول هزینه‌های هماهنگی را می‌توان بر حسب ساعت‌ اندازه‌گیری کرد مثل مدت زمان برگزاری جلسه‌ها، بحث‌ها و بررسی طراحی‌ها. زمان انتظار معمولا در طی روزها یا هفته‌ها یا حتی ماه‌ها اندازه‌گیری می‌شود!

تنظیم برنامه‌های متخصصان عملکردی کار دشواری است زیرا هر متخصص زمان خود را به چند طرح اختصاص می‌دهد. یک جلسه یک ساعته برای بحث در مورد تغییرات ممکن است هفته‌ها طول بکشد. و زمانی که این تغییرات هماهنگ شوند، انجام اصل کار در زمینه پروژه‌های متعدد دیگری که نیاز به زمان گذاشتن از سوی متخصصان دارند، هم باید برنامه‌ریزی شوند. کارهایی مانند تغییرات کد یا تحقیقاتی که تنها به چند ساعت یا چند روز برای تکمیل نیاز دارند، هنوز هم ممکن است به دلیل در دسترس نبودن منابع، خیلی طولانی‌تر انجام شوند. تا آن زمان، تکرار و یادگیری به کندی پیش می‌رفت.

۳- زمینه را محدود می کند.

تقسیم کار می‌تواند به صورت ساختگی یادگیری را با پاداش دادن به افراد برای ماندن در مسیرشان محدود کند. به عنوان مثال، دانشمند محققی که باید به وظیفه خود پایبند بماند، انرژی خود را روی آزمایش بر انواع الگوریتم‌ها متمرکز می‌کند: رگرسیون، شبکه‌های عصبی، جنگل تصادفی (random forest) و … مطمئناً، انتخاب الگوریتم خوب می‌تواند منجر به بهبود تدریجی شود. اما معمولاً از فعالیت‌های دیگر مانند یکپارچه‌سازی منابع داده‌های جدید سود بیشتری می‌توان کسب کرد. همچنین ممکن است او مدلی درست کند که هر ذره‌ای از شرح و  توان توضیحی اصلی داده‌ها را تخلیه کند. با این حال، بزرگ‌ترین فرصت او ممکن است در تغییر تابع هدف یا کاهش محدودیت‌های خاص باشد. دیدن و یا انجام این کار زمانی که عملکرد شغلی او محدود باشد، سخت است. از آن جایی که این دانشمندان در بهینه‌سازی الگوریتم‌ها متخصص است، احتمال کمتری دارد که به دنبال هر چیز دیگری بگردد، حتی زمانی که مزایای زیادی به همراه داشته باشد.

زمانی که تیم‌های علم داده مانند کارخانه‌های پین عمل می‌کنند، علائمی آشکار می‌شوند، برای مثال در بروزرسانی‌های ساده وضعیت: «انتظار برای تغییرات pipeline» و «انتظار در منابع ML Eng» موانع رایجی هستند. 

رضایت حاصل از دستیابی به کارایی فرآیند می‌تواند این حقیقت تلخ را پنهان کند که سازمان از یادگیری و ارزشمندی آن محروم است و کاملا به آن آگاه نیست.

البته راه‌حل این مشکل خلاص شدن از شر کارخانه پین است. به منظور تشویق یادگیری و تکرار، نقش‌های علم داده باید کلی‌تر شوند، با مسئولیت‌های گسترده‌ای که منکر عملکرد فنی هستند. به عبارت دیگر، دانشمندان داده را طوری سازماندهی کنید که برای یادگیری بهینه‌سازی شوند.

این کار به معنای استخدام “full stack data scientists” است که می‌توانند کارهای متنوعی را انجام دهند: از تعریف مفاهیم گرفته تا مدل‌سازی، اجرا و اندازه‌گیری. توجه به این نکته مهم است که در نظر داشته باشید :من پیشنهاد نمی‌کنم که استخدام full stack data scientists در مجموع منجر به استخدام افراد کمتری می‌شود. در عوض، من صرفاً پیشنهاد می‌کنم که وقتی به‌طور متفاوتی سازماندهی می‌شوند، انگیزه‌های آن‌ها برای یادگیری و در ادامه کسب دستاوردهای کارآمد همسو می‌شوند. به عنوان مثال، بگویید یک تیم سه نفره دارید که سه قابلیت در کسب‌وکار ایجاد می‌کنند. در کارخانه پین، یک سوم ظرفیت هر فرد به هر پروژه اختصاص می‌یابد، زیرا هیچ‌کس دیگری نمی‌تواند کار او را انجام دهد. در فول استک، هر یک از افراد با دانش عمومی به طور کامل به یک قابلیت تجاری اختصاص داده شده‌اند، که این کار معیار و یادگیری را افزایش می‌دهد.

با توجه به اینکه افراد کمتری در این حلقه باقی می‌مانند، هزینه‌های هماهنگی کاهش می‌یابد. متخصص عمومی راحت‌تر هماهنگ می‌شود،pipeline داده‌ها را برای اضافه کردن داده‌های بیشتر، گسترش می‌دهد، ویژگی‌های جدید را در مدل امتحان می‌کند، نسخه‌های جدید را برای تولید و سنجش گسترش می‌دهد، و مراحل را به همان سرعتی که ایده‌های جدید به او می‌رسند، تکرار می‌کند.

البته، متخصص عمومی  کارهای مختلف را به طور متوالی و نه موازی انجام می‌دهد چون در نهایت او فقط یک نفر است. با این حال، انجام کار به طور معمول زمان انتظار بسیار کم تری را نسبت به یک منبع تخصصی و در دسترس دیگر نیاز دارد. بنابراین، زمان تکرار کاهش پیدا می‌کند.

ممکن است نیروی عمومی ما به اندازه یک متخصص در هر یک از وظایف مهارت نداشته نباشد. اما ما به دنبال برتری در عملکرد  یا بهبود تدریجی جزئی نیستیم. در عوض، ما به دنبال یادگیری و کشف تمام قابلیت‌های کسب‌وکار جدید با تاثیر و تغییر چند مرحله‌ای هستیم. با داشتن پیش زمینه کامل پیدا کردن یک برای راه حل جامع، فرصت‌هایی را می بیند که یک متخصص با دید محدود، نمی‌تواند. او ایده‌های بیش‌تری دارد و چیزهای بیش‌تری را امتحان می‌کند و بیشتر هم  شکست می‌خورد. با این حال، هزینه این شکست‌ها کم و مزایای یادگیری آن زیاد است. 

لازم به ذکر است که این مقدار استقلال و تنوع در مهارت اعطا شده به full stack data scientist ها  تا حد زیادی با فرض وجود پلتفرم داده بستگی دارد که بر روی آن کار کند.  پلتفرم داده‌ای که خوب ساختاربندی شده باشد، دانشمندان داده را از پیچیدگی‌های کانتینرسازی، پردازش توزیع‌شده، شکست خودکار و دیگر مفاهیم پیشرفته علوم کامپیوتر، رها می‌کند. 

این اجزا توسط مهندسان پلتفرم داده طراحی و ساخته می‌شوند، اما برای روشن شدن، هیچ تبادلی از سمت دانشمند داده با یک تیم پلتفرم داده وجود ندارد. این دانشمند داده است که مسئول تمام کدهایی است که برای اجرا در  پلتفرم مستقر شده است.

با جذابیت کارایی فرآیندها، من هم زمانی شیفته روش تقسیم کار مبتنی بر عملکرد شدم. اما،  با کمک آزمون و خطا (‏هیچ راه بهتری برای یادگیری وجود ندارد)، متوجه‌شده‌ام که نقش‌های کلی‌تر یادگیری و نوآوری را بیشتر تسهیل می‌کنند و باعث مقایسه درست‌تری شامل کشف و ساخت  قابلیت‌های کسب‌وکار بیش‌تری در مقایسه با رویکرد تخصصی، فراهم می‌کنند. 

(یک راه کارآمدتر برای یادگیری در مورد این رویکرد به سازمان‌ها، در مقابل انجام آزمون و خطا خواندن کتاب Amy C. Edmondson “Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy” است).

یکسری شرایط مهم وجود دارند که ممکن است این رویکرد سازمانی را در بعضی از شرکت‌ها کم و بیش قابل دفاع کند. این فرآیند هزینه کم تکرار آزمون و خطا را در نظر می‌گیرد. اگر هزینه خطا بالا باشد، ممکن است بخواهید درباره آن تجدید نظر کنید (‏به عنوان مثال، برای موارد استفاده پزشکی یا تولیدی توصیه نمی‌شود)‏. 

از سوی دیگر، اگر با حجم داده‌ای مانند پتابایت یا اگزابایت سروکار دارید، تخصص در مهندسی داده ممکن است باعث تضمین شود. یا برای مثال، اگر حفظ پایداری و دسترسی یک کسب‌وکار آنلاین از بهبود آن مهم تر باشد، برتری در عملکرد ممکن است یادگیری را تحت‌تاثیر قرار دهد. در نهایت، مدل full-stack data science متکی بر مفروضات افراد ماهراست. آن‌ها مثل اسب تک‌شاخ نایاب نیست. هم می‌توان آن‌ها را پیدا کرد و هم ساخت. اما پیشنهادات شغلی زیادی دارند و برای جذب و حفظ آن‌ها پاداش‌های رقابتی، وجود ارزش‌های مستحکم در شرکت و کار جالب توجه لازم است. دقت کنید که فرهنگ شرکت شما بتواند از این موضوع پشتیبانی کند.

حتی با تمام آنچه گفته شد، من معتقدم که مدل full-stack data science نقطه شروع بهتری را آماده می‌کند. کار را با آن‌ها شروع کنید. زمانی که کاملا ضروری باشد و آگاهانه به سمت تقسیم کار مبتنی بر عملکرد حرکت کنید.

تخصصی کردن عملکرد جنبه‌های منفی دیگری هم دارد. این کار می‌تواند باعث از دست رفتن مسئولیت‌پذیری و شور و شوق کارکنان  شود. اسمیت خود تقسیم کار را مورد انتقاد قرار می‌دهد و اشاره می‌کند که این تقسیم کار منجر به بی‌حوصلگی افراد مستعد می‌شود و آن‌ها را به کارگرانی نادان و منزوی تبدیل می‌کند، چون نقش‌آن‌ها به چند کار تکراری محدود می‌شود.  تخصصی سازی ممکن است بازده فرآیند را افزایش دهد، اما احتمال الهام بخشی کم‌تر برای کارکنان دارد. 

در مقابل، نقش‌های عمومی همه چیزهایی را فراهم می‌کنند که باعث رضایت شغلی می‌شوند: استقلال، تسلط و هدف. استقلال از این جهت که برای موفقیت به شخص دیگری وابسته نیستند. تسلط به این دلیل که به آن‌ها ظرفیت کسب و کار را از ابتدا به انتها می‌دانند. و هدف از این جهت است که با کسب و کاری در جریان ارتباط مستقیمی دارند و بر آن با تأثیر می‌گذارند.  اگر ما موفق شویم که مردم را نسبت به کارشان مشتاق کنیم و تاثیر بزرگی را که بر شرکت دارند،مشخص کنیم، بقیه موارد به صورت طبیعی سر جای خود قرار می‌گیرند. 

این مقاله ترجمه شده Why Data Science Teams Need Generalists, Not Specialists از وبسایت HRB‌ است.