مدیریت تیم های پلت فرم: چگونه مهندسی پلتفرم را بسازیم و ساختار دهیم؟

مدیریت تیم های پلت فرم: چگونه مهندسی پلتفرم را بسازیم و ساختار دهیم؟- مصاحبه با کامیل فورنیه (مدیرعامل دو سیگما)

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

چه زمانی باید تیم پلتفرم خود را راه اندازی کنید؟

چه نوع مهندسانی را در تیم پلت فرم خود می خواهید؟

چگونه می‌توانید ارتباط بسیار دشوار را برطرف کنید و از ایجاد خون بد با تیم محصول جلوگیری کنید؟

ما پاسخ این سوالات را از رهبر افسانه ای کامیل فورنیه برای شما آورده ایم. او در حال حاضر مهندسی پلتفرم را به عنوان مدیر عامل دو سیگما اداره می کند. این پست بر اساس مصاحبه در قسمت 50 پادکست Level-up Engineering به میزبانی کارولینا توث است.

این پست وبلاگ شامل:

• نقش یک تیم پلت فرم
• مشتریان داخلی در مقابل مشتریان خارجی
• تیم های پلت فرم پروژه های طولانی تری دارند
• جلوتر از منحنی ماندن
• نوسازی سیستم های قدیمی
• برنامه ریزی را هماهنگ کنید
• از مدیران محصول استفاده کنید
• ارتباط مستقیم بهترین است
• دیر تماس گرفتن با تیم پلتفرم
• جدا کردن تیم پلت فرم
• مهارت های سخت
• مهارت های نرم
• نکات مصاحبه برای مهارت های نرم

چگونه یک تیم پلت فرم را تعریف می کنید؟



تیم پلتفرم در Two Sigma زیرساخت نرم افزاری بخش تیم مهندسی است.

از نظر تاریخی، شما ممکن است تیم هایی را که کار مشابهی انجام می دهند، تیم های زیرساختی نامیده باشید. تفاوت در این است که مهندسی زیرساخت تمایل دارد بر زیرساخت های فیزیکی تمرکز کند.

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

تیم‌های پلتفرم باعث می‌شوند که ارائه‌های ابری مختلف به شیوه‌ای قابل نگهداری با هم کار کنند.

نقش یک تیم پلت فرم

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

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

شما وقتی به یک ابزار سفارشی یک طرفه نیاز دارید ، تیم پلتفرم را درگیر نمی کنید.



تفاوت بین تیم های مهندسی پلتفرم و تیم های مهندسی محصول چیست؟



مشتریان داخلی در مقابل مشتریان خارجی

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

دو موقعیت منحصر به فرد سیگما

در دو سیگما ، ما در درجه اول برای مشتریان داخلی کار می کنیم. ما مستقیماً با مشتری های داخلی خود کار می کنیم ، چالش های آنها را درک می کنیم و برای تأمین نیازهای آنها نرم افزاری می سازیم.

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

تیم های پلت فرم پروژه های طولانی تری دارند

تیم های پلتفرم تمایل دارند پروژه های طولانی تر با تمرکز عملیاتی تر بسازند. سیستم عامل ها به معنای سیستم های طولانی مدت هستند که مقادیر کلیدی شامل موارد زیر است:

• بهره وری
• ثبات
• کارایی
• به موقع

ثبات می تواند برای تیم های محصول از اهمیت کمتری برخوردار باشد. توسعه دهندگان محصول غالباً روی ساخت نمونه های اولیه تمرکز می کنند ، جایی که قابلیت اطمینان از نظر ماموریت مهم نیست. در این حالت ، این در مورد ثبات نیست ؛این در مورد کار با مدیران محصول و تبدیل سریع مشخصات به یک نسخه ی نمایشی است.

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

اولویت ها بین تیم های پلتفرم و تیم های محصول تفاوت دارند؟



تیم های سکوی جلوتر از منحنی هستند

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

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

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

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

شما می توانید از این آزمایشات نتایج مفیدی بگیرید، به عنوان مثال:

• یاد بگیرید که چگونه آنها را در پلتفرم خود بپذیرید.
• بیاموزید که چرا در پلتفرم شما مناسب نیست.
• یاد بگیرید که فقط یک تیم به آن نیاز دارد، بنابراین آنها می توانند خودشان آن را اداره کنند.

تیم های پلت فرم سیستم های قدیمی را مدرن می کنند

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

این کار اضافی برای تیم های محصول است زیرا مهاجرت به فناوری جدید یک فرآیند بی اهمیت نیست. آنها می توانند از تقاضا برای ارتقاء و مهاجرت ناامید شوند. هیچ کس از جابجایی از پایتون 2 به پایتون 3 خوشحال نیست، زمانی که در نقشه راه تیم محصول ظاهر می شود.

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