واژهنامه
تجربهی توسعهدهنده developer experience
کاربرمحوری user centricity
پلتفرمِ توسعهدهندهِ داخلی internal developer platform
تحویل delivery
دورا DORA
ادغامِ مستمر continuous integration
مهندسیِ پلتفرم platform engineering
فراهمسازی provisioning
قابلیت capability
پیشگفتار
مهندسیِ پلتفرم یک رشتهی مهندسیِ نوظهور است که در سالهای اخیر توجه و علاقهی زیادی را در صنعت به خود جلب کرده است. شرکتهای پیشرو مانند اسپاتیفای و نتفلیکس و همچنین کتابهایی مانند Team Topologies باعثِ ایجادِ هیجان در این حوزه شدهاند.
مهندسیِ پلتفرم یک رشتهی اجتماعی-فنی است که مهندسان در آن بر تقاطعِ تعاملاتِ اجتماعی بینِ تیمهای مختلف و جنبههای فنی مانند خودکارسازی، ارائهی خدمات به صورتِ سلفسرویس و تکرارپذیریِ فرآیندها، تمرکز میکنند. مفاهیم پشتِ این رشته سالها موردِ مطالعه قرار گرفتهاند، از جمله توسطِ گروهِ DORA.
به طورِ کلی، تحقیقاتِ DORA بر نحوهی تحویلِ نرمافزار به کاربرانِ خارجی متمرکز است، در حالی که خروجیِ تیمهای پلتفرم معمولاً مجموعهای از APIها، ابزارها و خدماتی است که برای پشتیبانی از چرخهی توسعه و عملیاتِ نرمافزار طراحی شدهاند و بیشتر نگاهِ داخلی دارند. رویکردِ این مقاله نیز منطبق بر تمرکزِ DORA است.
در مهندسیِ پلتفرم، انرژی و تمرکزِ زیادی صرفِ بهبودِ تجربهی توسعهدهنده میشود. این کار با ایجادِ مسیرهای طلایی انجام میگیرد. مسیرهای طلایی فرآیندهایی کاملا خودکار و سلفسرویس هستند که کاربرانِ پلتفرم بمنظورِ تامینِ منابعِ موردنیاز برای تحویل و اجرای اپلیکیشن از آنها استفاده میکنند. هدفِ این مسیرها این است که پیچیدگیهای ساخت و تحویلِ نرمافزار را از دیدِ توسعهدهنده پنهان کنند تا او تنها روی کدنویسی تمرکز کند.
برخی از وظایفی که در مسیرهای طلایی باید به صورتِ خودکار انجام شود شاملِ موارد زیر هستند:
- فراهمسازیِ (provisioning) اپلیکیشنهای جدید
- فراهمسازیِ پایگاه داده
- مدیریتِ اسکیما
- اجرای تست (test execution)
- فراهمسازیِ زیرساختهای ساخت (build) و استقرار (deployment)
- مدیریتِ DNS
مفاهیمی در مهندسیِ پلتفرم مانند انتقالِ قابلیت به سطحِ پلتفرم (گاهی به آن “shifting down” گفته میشود) ممکن است در نگاهِ اول با رویکردهایی مانند “شما میسازید، شما اجرا میکنید” در تضاد به نظر برسد. با این حال، مهندسیِ پلتفرم در واقع روشی برای گسترشِ این رویکردها در سطحِ سازمان است. دلیلِ آن این است که وقتی یک قابلیت (capability) به پلتفرم اضافه میشود، تیمهای دیگر نیز با استفاده از پلتفرم بهطورِ رایگان به آن قابلیت دسترسی پیدا میکنند.
برای مثال، اگر پلتفرم قابلیتی برای اجرای تستهای واحد (Unit Tests) فراهم کند و نتیجهی اجرای تست را مستقیما به تیمِ توسعه گزارش کند، بدون آنکه این تیمها نیاز به ساخت و مدیریتِ محیط اجرای تست داشته باشند، تیمهای توسعه میتوانند بواسطهی این ویژگیِ ادغامِ مستمرِ پلتفرم فقط روی نوشتنِ تستهای باکیفیت تمرکز کنند.
در این مثال، ویژگی ادغامِ مستمر (Continuous Integration) میتواند در کلِ سازمان در دسترس شود و به تیمهای مختلف کمک کند تا تواناییهای خود را در زمینه تستِ مستمر و خودکارسازی تستها بهبود دهند.
یک عاملِ کلیدی برای موفقیت، داشتنِ مهندسیِ پلتفرم با رویکردی مبتنی بر کاربرمحوری (البته در زمینهی پلتفرمهای توسعهدهندهِ داخلی (internal developer platform)، کاربران همان توسعهدهندگان هستند.)، استقلالِ توسعهدهنده و تفکرِ محصولمحور است. این موضوع چندان هم تعجبآور نیست، زیرا کاربرمحوری (user centricity) به عنوانِ یکی از عواملِ کلیدیِ بهبودِ عملکردِ سازمانی در سال جاری و سالهای گذشته شناخته شده است. بدون یک رویکردِ کاربرمحور، پلتفرم ممکن است به جای تسهیل، به مانعی برای کاربران تبدیل شود.
در گزارشِ امسال، دورا به بررسیِ رابطهی بینِ پلتفرمها و عملکردِ تحویلِ نرمافزار و عملکردِ عملیاتی پرداخته و نتایج مثبتی یافته است:
- کاربرانِ پلتفرمِ توسعهدهندهِ داخلی (IDP) ۸٪ افزایش در بهرهوریِ فردی و ۱۰٪ بهبود در عملکردِ تیمی داشتند.
- عملکردِ عملیاتی و تحویلِ نرمافزارِ سازمانها با استفاده از پلتفرم، ۶٪ افزایش یافت.
با این حال، این پیشرفتها بدون هزینه نبودند. کاهشهایی نیز مشاهده شد:
- کاهشِ ۸ درصدی در توان عملیاتی (throughput)
- کاهشِ ۱۴ درصدی در پایداریِ تغییرات (change stability)
این نتایج تعجبآور بودند و نیازمند بررسیِ بیشتر هستند.
در بخشهای بعدی، به جزئیاتِ بیشتری در موردِ این ارقام، نکاتِ ظریف و دادههای غیرمنتظرهای که این نظرسنجی آشکار کرده است، خواهیم پرداخت. ابتکارِ مهندسیِ پلتفرمِ شما چه تازه آغاز شده باشد و چه سالها از اجرای آن گذشته باشد، استفاده از یافتههای کلیدی میتواند به موفقیتِ بیشترِ پلتفرمِ شما کمک کند.
وعدهی مهندسیِ پلتفرم
پلتفرمهای توسعهدهندهی داخلی (IDP) به دلیلِ افزایشِ پتانسیلِ بهرهوری و کارایی، مورد توجهِ گستردهای از سوی توسعهدهندگانِ نرمافزار و صنعتِ فناوریِ اطلاعات قرار گرفتهاند. در نظرسنجیِ امسالِ DORA، تعریفِ پلتفرمِ توسعهدهندهی داخلی را نسبتاً باز گذاشتند و متوجه شدند که ۸۹٪ از پاسخدهندگان از پلتفرمِ توسعهدهندهی داخلی استفاده میکنند. اما مدلهای تعامل با این پلتفرمها در میانِ این جمعیت بسیار متنوع هستند.
این دادهها با سطحِ گستردهی علاقهی صنعت به مهندسیِ پلتفرم و ماهیتِ نوظهورِ این حوزه همخوانی دارند.
به طورِ کلی، تأثیرِ پلتفرم، مثبت بوده است؛ وقتی از یک پلتفرمِ توسعهدهندهی داخلی استفاده شده است، افراد ۸٪ بهرهوری بیشتری داشتهاند و تیمها عملکردشان ۱۰٪ بهتر شده است.
فراتر از بهرهوری، بهبودهایی نیز در عملکردِ کلیِ سازمانها دیده میشود. با استفاده از پلتفرم، عملکردِ سازمان ۶٪ افزایش یافته است. در مجموع، سازمان قادر است سریعتر نرمافزار تحویل دهد، نیازهای کاربران را برآورده کند و ارزشِ تجاری ایجاد کند.
وقتی سنِ پلتفرم را در ارتباط با بهرهوری بررسی میکنیم، میبینیم که در ابتدای نوآوریِ مهندسیِ پلتفرم، بهبودهایی در عملکرد وجود دارد، سپس کاهش و در نهایت بازیابیِ بهرهوری با بلوغ و پایداریِ پلتفرم اتفاق میافتد. این الگو برای نوآوریهای تحولی معمول است که در ابتدا پیشرفتهای سریع را تجربه میکنند اما در ادامه با چالشهایی مواجه میشوند.
در بلندمدت، افزایشِ بهرهوری حفظ میشود که نشاندهنده پتانسیلِ کلیِ پلتفرمِ توسعهدهندهی داخلی در فرآیندهای تحویلِ نرمافزار و عملیاتِ سازمان است.
یافتهی کلیدی - تأثیرِ استقلالِ توسعهدهندگان
استقلالِ توسعهدهندگان تأثیرِ قابلتوجهی بر بهرهوری، هم در سطحِ فردی و هم تیمی، هنگامِ استفاده از یک پلتفرمِ توسعهدهندهی داخلی دارد. استقلالِ توسعهدهندگان به معنای “تواناییِ توسعهدهندگان برای انجامِ وظایفِ خود در کلِ چرخهی عمرِ برنامه بدون نیاز به وابستگی به تیمهای پشتیبان” تعریف میشود.
در هر دو سطحِ تیمی و فردی، زمانی که کاربرانِ پلتفرم میتوانند وظایفِ خود را بدونِ نیاز به دخالتِ تیمِ پشتیبان انجام دهند، بهرهوری ۵٪ بهبود یافته است. این یافته به یکی از اصولِ کلیدیِ مهندسیِ پلتفرم اشاره دارد: تمرکز بر فعالسازیِ فرآیندهای سلفسرویس.
برای تیمهای پلتفرم، این موضوع بسیار حیاتی است، زیرا نشان میدهد که جمعآوری بازخورد از کاربران یکی از بخشهای مهم فرآیند مهندسی پلتفرم است. پاسخهای نظرسنجی به شکل دقیق مشخص نکردهاند که کدام شکلهای بازخورد مؤثرتر هستند، اما روشهای رایج شامل گفتگوهای غیررسمی، پیگیری مشکلات، همکاری مداوم در توسعه، نظرسنجیها، دادههای تلهمتری و مصاحبهها است.
همه این روشها میتوانند در درک توانایی کاربران برای انجام مستقل وظایفشان مؤثر باشند. دادههای نظرسنجی همچنین نشان داده است که جمعآوری نکردن بازخورد از پلتفرم تأثیر منفی بر عملکرد دارد.
یافتهی فرعی - تأثیرِ تیمِ پلتفرمِ اختصاصی
نکته جالب این است که تأثیر تیم پلتفرم اختصاصی بر بهرهوری افراد ناچیز بوده است. با این حال، این امر منجر به افزایش ۶٪ بهرهوری در سطح تیم شده است. این یافته به دلیل تأثیر نامتوازن آن جالب است و نشان میدهد که تیم پلتفرم اختصاصی برای افراد مفید است، اما تأثیرگذاری بیشتری بر کل تیم دارد.
از آنجا که تیمها شامل چندین توسعهدهنده با مسئولیتها و مهارتهای مختلف هستند، به طور طبیعی وظایف متنوعتری در مقایسه با یک مهندس منفرد دارند. ممکن است وجود یک تیم مهندسی پلتفرم اختصاصی باعث شود پلتفرم بتواند از تنوع وظایف موجود در یک تیم بهتر پشتیبانی کند.
به طور کلی، وجود یک پلتفرم توسعهدهنده داخلی تأثیر مثبتی بر بهرهوری دارد. عوامل کلیدی این تأثیر عبارتند از:
- رویکرد کاربرمحور که استقلال توسعهدهندگان را از طریق فرآیندهای خودخدمتی و امکان انجام مستقل وظایف فعال میکند. لازم به یادآوری است که در زمینه پلتفرم، کاربران تیمهای مهندسی و توسعه داخلی هستند.
- همانند سایر تغییرات تحولآفرین، الگوی “منحنی J” نیز در مهندسی پلتفرم صادق است، بنابراین بهرهوری از طریق بهبود مستمر تثبیت خواهد شد.
جنبههای غیرمنتظره
در حالی که مهندسی پلتفرم مزایای مشخصی مانند افزایش احساس بهرهوری در تیمها و افراد و بهبود عملکرد سازمانی دارد، یک جنبهی غیرمنتظره از آن نیز مشاهده شد: کاهش در نرخ تغییرات و پایداری تغییرات.
به طور غیرمنتظره، ما به ارتباط جالبی بین ناپایداری تغییرات و فرسودگی شغلی پی بردیم.
نرخِ تغییرات
در مورد نرخ تغییرات، مشاهده کردیم که در مقایسه با کسانی که از پلتفرم استفاده نمیکنند، حدود 8 درصد کاهش وجود دارد. ما فرضیاتی در مورد علت این کاهش داریم.
اول، ماشینری اضافهای که تغییرات باید از آن عبور کنند تا به مرحله تولید برسند، نرخ کلی تغییرات را کاهش میدهد. به طور کلی، زمانی که از یک پلتفرم داخلی توسعهدهنده برای ساخت و ارائه نرمافزار استفاده میشود، معمولاً تعداد “انتقالها” بین سیستمها و به طور ضمنی تیمها افزایش مییابد.
به عنوان مثال، زمانی که کد در کنترل منبع ثبت میشود، به طور خودکار توسط سیستمهای مختلف برای تست، بررسیهای امنیتی، استقرار و نظارت پردازش میشود.
هر یک از این انتقالها فرصتی برای اضافه شدن زمان به فرآیند کلی است که منجر به کاهش نرخ تغییرات میشود، اما در عین حال توانایی انجام کار را افزایش میدهد.
دوم، برای پاسخدهندگانی که گزارش دادهاند مجبورند “منحصراً از پلتفرم برای انجام وظایف در طول چرخه عمر برنامه استفاده کنند”، کاهش 6 درصدی در نرخ تغییرات مشاهده شد. در حالی که این ارتباط قطعی نیست، ممکن است با فرضیه اول مرتبط باشد.
اگر سیستمها و ابزارهای درگیر در توسعه و انتشار نرمافزار با حضور پلتفرم افزایش یابند، الزام به استفاده از پلتفرم در شرایطی که ممکن است مناسب نباشد یا افزایش طبیعی تأخیر در فرآیند میتواند رابطه بین انحصار و کاهش بهرهوری را توضیح دهد.
برای مقابله با این موضوع، مهم است که به نیازهای کاربر توجه کرده و به سمت استقلال کاربران در ابتکارات مهندسی پلتفرم حرکت کنیم.
ناپایداری تغییرات و فرسودگی شغلی
هنگام بررسی پایداری تغییرات در برنامههایی که با استفاده از یک پلتفرم داخلی توسعهدهنده ایجاد و اجرا میشوند، کاهش شگفتآور 14 درصدی در پایداری تغییرات مشاهده شد. این موضوع نشان میدهد که نرخ شکست تغییرات و نیاز به کار مجدد به طور قابل توجهی با استفاده از پلتفرم افزایش مییابد.
جالبتر اینکه، در نتایج ما مشخص شد که ناپایداری تغییرات همراه با پلتفرم به سطوح بالاتری از فرسودگی شغلی مرتبط است. این به این معنا نیست که پلتفرمها منجر به فرسودگی شغلی میشوند، اما ترکیب ناپایداری و پلتفرمها بهویژه در ایجاد فرسودگی شغلی مشکلساز است. مشابه کاهش نرخ تغییرات، دلیل این تغییر در فرسودگی شغلی کاملاً مشخص نیست، اما چند فرضیه داریم.
اول، پلتفرم به توسعهدهندگان و تیمها امکان میدهد تغییرات را با اعتماد بیشتری اعمال کنند که در صورت بد بودن تغییر، میتوان آن را سریعاً اصلاح کرد. در این حالت، سطح بالاتر ناپایداری لزوماً چیز بدی نیست زیرا پلتفرم به تیمها قدرت میدهد تا آزمایش کنند و تغییرات را اعمال کنند، که این موضوع منجر به افزایش نرخ شکست تغییرات و نیاز به کار مجدد میشود.
ایده دوم این است که پلتفرم در تضمین کیفیت تغییرات و/یا استقرار در محیط تولید کارآمد نیست.
همچنین ممکن است که پلتفرم قابلیت تست خودکار را فراهم کند که تستهایی را که در برنامه گنجانده شدهاند اجرا میکند، اما تیمهای برنامه به طور کامل از این قابلیت استفاده نمیکنند و اولویت را به نرخ تغییرات به جای کیفیت میدهند و تستهای خود را بهبود نمیبخشند.
در هر یک از این سناریوها، تغییرات نامطلوب از فرآیند عبور کرده و منجر به کار مجدد میشوند.
احتمال سوم این است که تیمهایی که سطح بالایی از ناپایداری تغییرات و فرسودگی شغلی دارند، تمایل به ایجاد پلتفرمها دارند تا پایداری را بهبود داده و فرسودگی شغلی را کاهش دهند. این موضوع منطقی است زیرا مهندسی پلتفرم اغلب به عنوان یک روش برای کاهش فرسودگی شغلی و افزایش توانایی ارسال تغییرات کوچکتر به طور مداوم دیده میشود. با این فرضیه، مهندسی پلتفرم نشانهای از یک سازمان با فرسودگی شغلی و ناپایداری تغییرات است.
در دو سناریوی اول، کار مجدد ناشی از پلتفرم میتواند به عنوان یک بار اضافی تلقی شود که ممکن است فرسودگی شغلی را نیز افزایش دهد. به ویژه در سناریوی دوم که پلتفرم باعث تغییرات نامطلوب میشود، این موضوع بیشتر به فرسودگی شغلی کمک میکند، اما در هر دو سناریو تیم یا فرد ممکن است همچنان احساس بهرهوری داشته باشد به دلیل توانایی آنها در اعمال تغییرات و ویژگیها. در سناریوی سوم، ناپایداری تغییرات و فرسودگی شغلی پیشبینیکننده یک ابتکار مهندسی پلتفرم هستند و پلتفرم به عنوان راهحلی برای این چالشها دیده میشود.
متعادل کردن موازنهها
مهندسی پلتفرم اگرچه راهحلی جامع نیست، اما میتواند یک رویکرد قدرتمند در فرآیند کلی توسعه و عملیات نرمافزار باشد. مانند هر رویکرد دیگری، مهندسی پلتفرم نیز دارای مزایا و معایبی است.
بر اساس تحقیقات ما، چند اقدام وجود دارد که میتوانید برای متعادل کردن موازنهها هنگام آغاز یک ابتکار مهندسی پلتفرم انجام دهید. این اقدامات به سازمان شما کمک میکند تا از مزایای مهندسی پلتفرم بهرهمند شود و در عین حال بتواند هرگونه معایب بالقوه را نظارت و مدیریت کند.
اول، قابلیتهایی را در پلتفرم اولویتبندی کنید که به استقلال توسعهدهندگان و توانایی خودخدمتی آنها کمک کند. هنگام انجام این کار، به تعادل بین الزام به استفاده انحصاری از پلتفرم برای تمام جنبههای چرخه عمر برنامه و ممانعت از استقلال توسعهدهندگان توجه کنید.
به عنوان یک رویه خوب، پلتفرم باید روشهایی را برای کاربران فراهم کند تا بتوانند در صورت نیاز از ابزارها و اتوماسیونهای ارائهشده در پلتفرم خارج شوند. این امر به استقلال کمک میکند، اما به قیمت افزایش پیچیدگی تمام میشود. این موازنه را میتوان با داشتن یک تیم اختصاصی پلتفرم که به طور فعال با کاربران پلتفرم همکاری کرده و بازخورد آنها را جمعآوری میکند، کاهش داد.
همکاری و بازخورد، کاربرمحوری ابتکار پلتفرم را بهبود میبخشد و به موفقیت بلندمدت پلتفرم کمک میکند. همانطور که در دادهها مشاهده شد، روشهای مختلفی برای جمعآوری بازخورد وجود دارد، بنابراین برای حداکثر کردن جمعآوری بازخورد، از بیش از یک روش استفاده کنید.
دوم، ناپایداری تغییرات برنامه خود را به دقت نظارت کنید و سعی کنید بفهمید که آیا این ناپایداری عمدی است یا خیر. پلتفرمها این قابلیت را دارند که امکان آزمایشگری در قالب ناپایداری را فراهم کنند، بهرهوری را افزایش دهند و عملکرد در مقیاس را بهبود بخشند.
با این حال، همین ناپایداری میتواند به قیمت ناپایداری و فرسودگی شغلی تمام شود، بنابراین باید به دقت نظارت و در طول مسیر مهندسی پلتفرم مدیریت شود. هنگام انجام این کار، مهم است که میزان تحمل خود در برابر ناپایداری را درک کنید.
استفاده از اهداف سطح خدمات (SLOs) و بودجههای خطا از مهندسی قابلیت اطمینان سایت (SRE) میتواند به شما در سنجش تحمل ریسک و اثربخشی پلتفرم در فعالسازی ایمن آزمایشگری کمک کند.
پلتفرمهای داخلی توسعهدهندگان تأکید زیادی بر تجربه توسعهدهنده دارند، اما تیمهای دیگری (مانند مدیران پایگاه داده، امنیت و عملیات) نیز برای ارائه و اجرای موثر نرمافزار مورد نیاز هستند.
در ابتکارات مهندسی پلتفرم خود، فرهنگی از کاربرمحوری و بهبود مستمر در تمام تیمها ایجاد کنید که با اهداف سازمان همسو باشد.
انجام این کار باعث میشود ویژگیها، خدمات و APIهای پلتفرم به بهترین شکل ممکن نیازهای فردی و تیمی را در مسیر ارائه نرمافزار و ارزش تجاری تأمین کنند.
