واژهنامه
تجربهی توسعهدهنده developer experience
پلتفرمِ توسعهدهندهِ داخلی internal developer platform
حاکمیت governance
تحویل delivery
وظیفه task
بارِ ذهنی cognitive load
فراهمسازی provisioning
مهندسیِ پلتفرم platform engineering
توانمندی/قابلیت capability
کارِ گِل toil
مستقر deploy
مدلِ قابلیتِ مهندسیِ پلتفرم Platform Engineering Capability Model
مهندسیِ پلتفرم (platform engineering) چیست؟
مهندسیِ پلتفرم یک رویکردِ مبتنی بر اصولِ DevOps است که به واسطهی بهبودِ تجربهی توسعهدهندگان و ارائهی خدماتِ سلفسرویس در یک چارچوبِ امن و تحت نظارت، به دنبالِ بهبودِ امنیت، انطباق، هزینهها و سرعتِ ارائهی ارزشِ تجاری برای تیمهای توسعه است. این مفهوم هم شاملِ تغییرِ نگرشِ محصولمحور است و هم شاملِ مجموعهای از ابزارها و سیستمهایی است که از این رویکرد پشتیبانی میکنند.
اخیراً اصطلاحِ مهندسیِ پلتفرم توجهِ زیادی را در صنعت به خود جلب کرده است. طبقِ پیشبینیِ گارتنر، تا سالِ ۲۰۲۶، حدودِ ۸۰ درصد از سازمانهای مهندسی، یک تیمِ ویژه برای مهندسیِ پلتفرم خواهند داشت. این تیمها وظیفهی ساختِ چیزی به نام پلتفرمِ توسعهدهندهِ داخلی را بر عهده دارند. فرقی نمیکند که حوزهی فعالیتِ پلتفرم چیست – فروش باشد (مانند Microsoft Dynamics و Salesforce)، تحققِ خدمات باشد (مانند ServiceNow)، یا ارتباطات (مانند Twilio) – پلتفرمها بهطورِ ذاتی طراحی شدهاند تا مقیاسپذیری را محقق کنند و زمانِ لازم برای تحویلِ ارزشِ تجاری را کاهش دهند.
پلتفرمهایی که توسعهدهندگان از آنها استفاده میکنند یا آنها را گسترش میدهند، این توانایی را دارند که با سادهسازیِ عملیات و بهینهسازیِ حداکثریِ تجربهی توسعهدهنده، کارِ گِل (toil) را از سرتاسرِ فرایندِ توسعه حذف کنند. این پلتفرمها شامل ابزارهایی هستند که:
- به توسعهدهندگان کمک میکنند خودکفا باشند (مثلاً کیتهای شروع، افزونههای IDE).
- وظایفِ مشترک را تسهیل میکنند.
- الگوها و رویههای رایج را به کامپوننتهای قابلِ استفادهی مجدد تبدیل میکنند.
- در مراحلِ اولیه، مشکلات یا خطراتِ امنیتی را گوشزد و بازخورد ارائه میدهند.
- با مدیریتِ زیرساخت و ابزارهای زیربنایی، عملیات را سادهتر میکنند.
مدلِ توانمندیهای مهندسیِ پلتفرمِ شرکتِ مایکروسافت، شش توانمندیِ اصلی را برای این حوزه معرفی میکند: سرمایهگذاری (investment)، پذیرش (adoption)، حاکمیت (governance)، مدیریت و فراهمسازی (provisioning)، رابطها (interfaces)، و اندازهگیری و بازخورد (measurements and feedback). برای اینکه بفهمید سازمانِ شما امروز در هر یک از این حوزهها در چه جایگاهی قرار دارد و اهدافِ آینده خود را تعیین کنید، میتوانید به راهنمای مدلِ توانمندیهای مهندسیِ پلتفرم مراجعه کنید.
اگر تاکنون برای شما روشن نشده است که مهندسیِ پلتفرم چیست، و تصور میکنید که گفتههای تا الان مبهم هستند، حق با شماست. برای درکِ درست و بهترِ مهندسیِ پلتفرم تا پایانِ مقاله همراهِ من باشید.
پلتفرمِ توسعهدهندهِ داخلی (IDP) چیست؟
پلتفرمِ توسعهدهندهِ داخلی (Internal Developer Platform) بر روی فرآیندهای داخلیِ توسعهِ (development) یک شرکت تمرکز دارد. در این پلتفرم، مسیرهای پیشنهادی و پشتیبانیشدهای برای توسعه و تحویل به محیط عملیاتی تعریف میشوند. سپس این مسیرها بهتدریج و مرحله به مرحله با استفاده از پلتفرمِ داخلی بهینه و هموار میشوند.
مسیرهای جدید معمولاً ابتدا به صورتِ جادههای خاکی آغاز میشوند، اما با استفادهی بیشتر از آنها، آسفالت (هموار) میشوند تا هم ایمنی افزایش یابد و هم سرعت و بازدهی حفظ شود. مسیرهای هموارشده در یک پلتفرمِ توسعهدهندهِ داخلی نیز اهدافِ مشابهی دارند. این مسیرها طراحی شدهاند تا توسعهدهندگان را از میانِ الزامات و استانداردهای حیاتی هدایت کنند، بدون اینکه سرعتِ تحویلِ پروژههایشان کاهش یابد.
این هدف از طریقِ ارائهی قابلیتهای استاندارد، ایمن و مقیاسپذیر به صورت سلفسرویس به تیمهای توسعهدهنده محقق میشود. در همین حال، عملیات و تیمهای IT نیز میتوانند از کارآمدی، تطابق، و بهینهبودنِ هزینههای زیرساخت و ابزارها اطمینان حاصل کنند. در حالی که برخی از مسیرها ممکن است تنها تا حدودی هموار شده باشند، یک مسیرِ طلاییِ کاملاً هموارشده، بارِ ذهنیِ (cognitive load) توسعهدهندگان و تیمها را به حداقل میرساند.
توسعهدهندگان مشتریانِ اصلیِ یک پلتفرمِ توسعهدهندهِ داخلی هستند. اتوماسیون و تمرکز در این پلتفرمها عملیات را کارآمدتر کرده و در عینِ حال، اطمینان حاصل میکنند که الزاماتِ ذینفعان مانند رعایتِ قوانین نیز برآورده میشود.
در مهندسیِ پلتفرم، با ترکیبِ ذهنیتِ محصولمحور و درسهایی که از DevOps و DevSecOps گرفته شده، یک پلتفرمِ داخلی ایجاد میکنید. این پلتفرم مجموعهای از ابزارها را ارائه میدهد که شامل خودکارسازی، رهگیری (tracking)، حاکمیت، و قابلیت مشاهدهپذیری (observability) است. این ابزارها بهطورِ طبیعی تیمهای توسعه را به سمتِ “موفقیتِ بدونِ دردسر” هدایت میکنند. همانطور که یکی از رهبرانِ مهندسیِ پلتفرم در یک شرکتِ چندملیتیِ رسانهایِ بزرگ گفته است:
“مهندسیِ پلتفرم برای افزایشِ سرعت و شتاب در تحویلِ محصولات به کار گرفته شد. تیمهای متمرکز با حذفِ نیازِ هر تیم برای نگرانی در خصوصِ زیرساخت، بهرهوری را افزایش میدهند… این روش همچنین ایمنی و امنیت را بهبود میبخشد، زیرا همه چیز از پیش تعریفشده است و احتمالِ خطاها کاهش مییابد.”
– دنیل، مهندس ابر، شرکت رسانهای Fortune 500
یک پلتفرمِ توسعهدهندهِ داخلی، به شما کمک میکند دانشِ تخصصی را در کلِ چرخهی عمرِ توسعه و عملیات متمرکز کرده و مقیاس دهید. این کار با کاهش یا حذفِ بارِ ذهنی و گامهای دستی انجام میشود.
پلتفرمهای توسعهدهنده را بهصورتِ تدریجی بسازید، با تمرکز بر خدماتِ سلفسرویس و خودکارسازی.
اجرای استراتژیِ موفق در مهندسیِ پلتفرم کارِ سادهای نیست، اما با توجه نتایجِ آن، ارزشِ تلاش را دارد. در بسیاری از موارد، تیمهایی با کمتر از ۲۰ نفر میتوانند از هزاران توسعهدهنده و صدها پروژه پشتیبانی کنند.
با این حال، ایجادِ پلتفرمِ داخلی برای توسعهدهندگان، یک مسیرِ تدریجی است. ما روشهای شتابزده یا رویکردهای از بالا به پایین را توصیه نمیکنیم. یکی از جنبههای حیاتیِ مهندسیِ پلتفرم این است که با ذهنیتیِ محصولمحور عمل کنید و توسعهدهندگان، متخصصانِ یادگیریِ ماشین، یا دانشمندانِ داده را بهعنوانِ مشتریان خود در نظر بگیرید. همانطور که یک مهندسِ پلتفرم در یک شرکت فناوری توضیح میدهد:
“ابزارهای مهندسیِ پلتفرمِ ما برای حلِ دو مشکلِ اصلی طراحی شدهاند. اولین مشکل، تسهیلِ فرآیند فراهمسازیِ خدمات با استفاده از یک مدلِ سلفسرویس بود… دومین مشکل، ارائهی سیستمهای پشتیبانیِ خودکار، مانندِ متریکهای عملکرد و دردسترس بودنِ (availability) اپلیکیشنها بود. هدف این بود که توسعهدهندگان بتوانند سریعتر و کارآمدتر کار کنند، در حالی که به همهی اطلاعاتِ موردنیاز برای عیبیابی و بهینهسازیِ برنامههای خود دسترسی داشته باشند.”
– الکس، معمارِ ارشد ابر، شرکت بزرگ فناوری
از آنجا که هیچ دو شرکتی شبیهِ به هم نیستند، نیازهای خاصِ مشتریانِ داخلیِ خود را در نظر بگیرید و مسیرِ تدریجیِ خود را برای این سفر ترسیم کنید. با ایجادِ مجموعهای از بلوکهای اصلی که در طولِ زمان سرهم میشوند، میتوانید اطمینان حاصل کنید که پلتفرمِ داخلیِ شما ارزشِ کافی خواهد داشت تا تیمهای توسعهدهنده به آن علاقهمند شوند و خودشان از آن استفاده کنند.
از این اطلاعات برای ایجادِ یک پلتفرمِ حداقلیِ کارا (معادلِ حداقل محصولِ پذیرفتنی برای پلتفرم) استفاده کنید و از آن نقطه، گسترش دهید.
سفرِ مهندسیِ پلتفرمِ خود را شروع کنید
مهندسیِ پلتفرم راهکاری است برای سازمانها تا چرخهی عمرِ توسعهی نرمافزارِ خود را از طریقِ تمرکز بر تجربهی توسعهدهنده بهینه کنند. تجربهی توسعهدهنده به معنای تجربهی روزمرهای است که توسعهدهندگان با آن روبهرو میشوند و شاملِ نقاطِ اصطکاکی است که در کارِ روزانهی خود با آنها مواجه میشوند. مهندسیِ پلتفرم مجموعهای از الگوها و روشها است (و نه یک محصول آماده) که به مدرنسازیِ فرآیندِ تحویلِ نرمافزارِ سازمانها کمک میکند.
به عنوانِ مثال، یک شرکتِ فناوریِ چندملیتی با استفاده از مهندسیِ پلتفرم توانست استانداردسازی را افزایش داده و از تکرارهای غیرضروری در بین بخشهای مختلف جلوگیری کند. این شرکت ابتدا رویکردی مبتنی بر “همه چیز بهصورتِ کد” را بمنظورِ آنبردینگِ تیمها پیادهسازی کرد. سپس برنامههایی که در Kubernetes مستقر میشدند را به شکلی مرتبط کرد که برای توسعهدهندگان منطقی و قابلِ درک باشد تا کشف و شناساییِ آنها آسانتر شود. این رویکرد آنها را در موقعیتی قرار داد تا بتوانند قالبهای برنامهای (application template) بسازند که بِهروشها (best practices) را تشویق میکنند. اکنون تیمهای توسعه میتوانند از اجزای ساختاریِ آماده استفاده کنند، به جای اینکه همه چیز را از ابتدا ایجاد کنند.
برای شروع، از مدلِ قابلیتِ مهندسیِ پلتفرم استفاده کنید تا بزرگترین چالشهای سازمانِ خود را شناسایی کنید و بفهمید کدام الگوها و روشها باید پیادهسازی شوند. سپس، با استفاده از کامپوننتهای آمادهای که توسطِ مایکروسافت، پروژههای متنباز یا سایرِ فروشندگان ارائه شدهاند، یک پلتفرمِ داخلیِ توسعهدهندهِ شخصیسازیشده، بهینه و ایمن ایجاد کنید.
طرحریزیِ سفر با مدلِ قابلیتِ مهندسیِ پلتفرم
برای آغازِ سفرِ خود با مدلِ قابلیتِ مهندسیِ پلتفرم، ابتدا باید وضعیتِ کنونیِ سازمانِ خود را ارزیابی کنید. این مدل به شما کمک میکند تا جایگاهِ سازمانِ خود را در شش زمینهی کلیدی مشخص کنید: سرمایهگذاری، پذیرش، حاکمیت، فراهمسازی و مدیریت، رابطها، و اندازهگیری و بازخورد. همچنین میتوانید اهدافی برای رشدِ آینده در هر یک از این حوزهها تعیین کنید. برای مثال، ممکن است متوجه شوید که سازمانِ شما در مراحلِ ابتدایی سرمایهگذاری است اما در زمینهی پذیرش جلوتر است. برای ترسیمِ وضعیتِ کنونیِ سازمان در مهندسیِ پلتفرم، میتوانید از یک نظرسنجی استفاده کنید یا به صورتِ دستی یک ارزیابی انجام دهید.
ضرورتی ندارد که در تمامِ این شش حوزه بهطورِ همزمان پیشرفت کنید. بهتر است مسیری را انتخاب کنید که با شرایط و نیازهای سازمانِ شما همخوانی داشته باشد. هر سازمانی در برخی از این قابلیتها جلوتر از دیگران هستند. به عنوان نمونه، در نقشهای که ارائه شده، یک سازمان تصمیم گرفته است تمرکزِ خود را بر روی پیشرفت در پذیرش، حاکمیت، و فراهمسازی و مدیریت بگذارد. با استفاده از این مدل، میتوانید یک مسیرِ مشخص برای توسعهی مهندسیِ پلتفرم در سازمانِ خود طراحی کنید که با اهداف و منابعِ شما همراستا باشد.
پیادهسازی
برای هر یک از قابلیتهایی که به عنوانِ حوزههای نیازمندِ بهبود شناسایی کردهاید، باید اهدافی برای پیشرفت تعیین کنید. این اهداف شاملِ یادگیریِ استفاده از قالبها (templates) و دیگر راهحلها برای بهبودِ سیستمهای مهندسی و کاهشِ اصطکاکِ توسعهدهندگان است.
- بکارگیریِ سیستمهای مهندسی نرمافزار: یادگیری نکاتی که به شما کمک میکند درباره چگونگی استفاده مجدد و اصلاح سیستمهای مهندسی برای بهبود قابلیت سلفسرویس و حل مشکلات شناساییشده فکر کنید. یاد بگیرید چگونه از زیرساخت بهعنوان کد (IaC) یا دیگر مصنوعات همهچیز بهعنوان کد (EaC) بهعنوان بلوکهای ساختاری در قالبهای شروع صحیح استفاده کنید.
- اصلاح پلتفرم برنامه: یاد بگیرید چگونه میتوانید مشکلات شناساییشده را با اصلاح پلتفرم برنامه خود حل کنید. این تغییرات ممکن است پرهزینهتر باشند اما میتوانند مزایای قابلتوجهی ارائه دهند، بهویژه اگر بتوانید محصولی آماده را برای برآوردن نیازهای خود پیدا کنید. برای مثال، آیا بهبود استفاده از ابزارهای قابل مشاهدهسازی یا لاگگیری (یا مهاجرت به ابزارهای دیگر) مفید خواهد بود؟ اگر از ابتدا شروع میکنید، مرکز معماری Azure میتواند به شما کمک کند مفاهیم را از پایه شناسایی کنید.
- طراحی بنیاد سلفسرویس توسعهدهنده: درباره معماریای که به یک بنیاد سلفسرویس توسعهدهنده پیشرفتهتر منجر شود یاد بگیرید. این یک تکامل است که شما را به سمت سادهسازی سیستمهای اتوماسیون چندگانه و تجمیع دادهها سوق میدهد. شما در اینجا توسعه نرمافزار بیشتری انجام خواهید داد، بنابراین بهتدریج در این مسیر حرکت کنید بهجای اینکه از اینجا شروع کنید.
از «مدلِ قابلیتِ مهندسیِ پلتفرم» برای بهبودِ روشهای مهندسیِ پلتفرم استفاده کنید
برای ارزیابیِ تلاشهای مهندسیِ پلتفرم در سازمانِ خود و تعیینِ اهداف برای بهبود در آینده، میتوانید از مدلِ قابلیتِ مهندسی پلتفرم (Platform Engineering Capability Model) استفاده کنید.
طبقِ تحقیقاتِ مایکروسافت، شش توانمندیِ اصلیِ مهندسیِ پلتفرم عبارتند از:
- سرمایهگذاری – Investment
- پذیرش – Adoption
- حاکمیت – Governance
- فراهمسازی و مدیریت – Provisioning and Management
- رابطها – Interfaces
- اندازهگیری و بازخورد – Measurement and Feedback
این توانمندیها به طورِ نزدیک با حوزههای کلیدیِ مدلِ بلوغِ (maturity) مهندسیِ پلتفرمِ ارائهشده توسط CNCF همراستا هستند. این توانمندیها از تحلیلِ نتایجِ نظرسنجیها و بیش از ۳۰ مصاحبهي طولانی با مشتریان دربارهی تلاشهای مهندسیِ پلتفرمِ سازمانهایشان استخراج شدهاند.
روشهای کنونیِ خود را ارزیابی کنید و اهدافِ آینده را تعیین کنید
ابتدا با شناساییِ اینکه سازمانِ شما امروز در کدام بخش از توانمندیها قرار میگیرد، شروع کنید.
۱. برای شروعِ ارزیابیِ دستی، این چارتِ خالی را دانلود کنید.
۲. این جدول را که توانمندیها در مراحلِ مختلف را نشان میدهد، دانلود کنید و بهعنوانِ یک مرجع استفاده کنید. احتمالاً سازمانِ شما در هر توانمندی در یک سطحِ یکسان قرار ندارد. همچنین میتوانید دربارهی هر توانمندی اطلاعاتِ بیشتری در اینجا بیاموزید.
۳. برای هر توانمندی، یک دایره را در چارتِ خالیِ ارزیابی پر کنید تا نشان دهید سازمانِ شما در حالِ حاضر در چه سطحی قرار دارد.
۴. نقاط را با یک خطِ عمودی بهم متصل کنید.
۵. برای هر توانمندی، یک دایرهی خالیِ دیگر اضافه کنید که مرحلهی موردنظرِ آیندهی سازمانِ شما را نشان دهد. بهعنوان مثال، سازمانِ شما ممکن است بخواهد از مرحلهی سرمایهگذاریِ اولیه به مرحلهی قابلتکرار حرکت کند. به خاطر داشته باشید که تغییر میتواند تدریجی باشد. لازم نیست که یکباره از مرحلهی اولیه به مرحلهی بهینهسازی بروید. هدفِ موردنظرِ سازمانِ شما نیز لزوماً نباید ستون آخر باشد. شما باید مراحلِ موردنظر را انتخاب کنید که با اولویتهای سازمانتان همسو باشد.
۶. یک خطِ افقی از هر توانمندیِ فعلیِ سازمانتان به توانمندیهای موردنظرِ آینده رسم کنید.
۷. چارتِ خود را بررسی کنید تا وضعیتِ فعلیِ سازمانتان و اهدافِ پیشنهادیِ آینده را بهصورتِ تصویری مشاهده کنید.
در مثال قبلی، مشتریِ یک مؤسسهی مالی میخواهد روی بهبودِ توانمندیهای پذیرش (Adoption)، حاکمیت (Governance)، و فراهمسازی و مدیریت (Provisioning and Management) تمرکز کند. در ادامه، وضعیتِ فعلی و چالشهای آنها آمده است:
- پذیرش (Adoption): تیمِ مهندسیِ پلتفرم بر اجرای سیاستهایی که توسطِ مرکزِ تعالی (center of excellence) تعیین شدهاند تمرکز دارد تا نحوهی عملکردِ تیمهای مهندسی را هدایت کند. عمومیکردنِ شاخصهای عملکردِ هر تیم، بهعنوانِ محرکی برای بهبود عمل میکند. این تیم به دنبالِ افزایشِ استفاده از پلتفرم است بدون اینکه صرفاً به دستورات و شاخصها متکی باشد. با این حال، آنها در ارتقای مهارتهای تیمِ COE برای مدیریتِ تنوعِ فناوریهای موردِ استفادهی تیمهای مهندسی با چالشهایی روبرو هستند. یک مانعِ عمده این است که ممکن است پلتفرم نتواند نیازهای خاصِ تیمهای مختلف را برآورده کند، که میتواند منجر به مشکلاتی در عملکرد شود.
- حاکمیت (Governance): راهحلِ مهندسیِ پلتفرم، یک پورتالِ داخلیِ توسعه یافته است که بهعنوانِ یک مرکزِ اصلی برای توسعهدهندگان عمل میکند و ابزارها، راهنماها، استانداردهای کدنویسی و ویدئوها را ارائه میدهد. این پورتال شاملِ آزمونی برای حداقل الزاماتِ سازمانی (MERS) است تا قبل از شروعِ کدنویسی، اطمینان حاصل شود که الزامات رعایت شدهاند. پورتال همچنین نسخهای از Stack Overflow برای پشتیبانی، پروفایلهای مهندسان تأییدشده، و یک فرآیندِ آشنایی برای توسعهدهندگان جدید ارائه میدهد تا با استانداردها و ابزارها آشنا شوند. هدفِ اصلیِ آینده، سادهسازیِ مدیریتِ منابع و ادغامِ حاکمیت در چرخهی توسعه است تا گلوگاهها حذف شوند و با مجموعهی ابزارهای مدرن، استعدادهای برترِ فنی جذب شوند.
- فراهمسازی و مدیریت (Provisioning and Management): تیمِ مهندسیِ پلتفرم مسیرهای خوشایندی (Happy Paths) برای توسعهدهندگان ایجاد کرده است تا بهرهوری افزایش یابد و در عینِ حال انعطافپذیری حفظ شود. هدف این است که یک مسیرِ کارآمد ارائه شود و در عینِ حال امکانِ سفارشیسازی فراهم باشد. در طراحی این مسیرها، تیم CTO تلاش میکند نیازهای اکثرِ توسعهدهندگان را تأمین کند، اما پیچیدگیِ بانک، با هزاران ابزارِ موردِ استفاده، طراحیِ یک راهکارِ یکسان را دشوار میکند. برای مقیاسپذیریِ پلتفرم، سازمان نیاز به تأمینِ خودکارِ منابع را تشخیص داده است تا نیازهای متنوعِ بسیاری از تیمهای مهندسی را برآورده کند.
هدفگذاری برای توانمندیهای هدف
هر توانمندی یک سؤال مربوط به خود دارد. در زمینههای توانمندی که برای بهبود هدفگذاری کردهاید تحقیق کنید و در مورد چگونگی پیشرفت در شیوههای مهندسی پلتفرم سازمان خود بیاموزید.
سرمایهگذاری: چگونه نیروی انسانی و منابع مالی به توانمندیهای پلتفرم اختصاص داده میشوند؟
پذیرش: چرا و چگونه کاربران راهکار مهندسی پلتفرم شما و توانمندیهای آن را کشف و استفاده میکنند؟
حاکمیت: چگونه اطمینان حاصل میکنید که کاربران به منابع و توانمندیهایی که نیاز دارند دسترسی دارند و هزینهها، دادهها، و مالکیت فکری بهدرستی مدیریت میشوند؟
تأمین و مدیریت منابع: کاربران چگونه منابع را ایجاد، مستقر و مدیریت میکنند؟
رابطها: کاربران چگونه با توانمندیهای پلتفرم تعامل کرده و از آنها بهرهبرداری میکنند؟
اندازهگیری و بازخورد: فرآیند سازمان شما برای جمعآوری و گنجاندن بازخورد چیست و چگونه موفقیت شیوههای مهندسی پلتفرم اندازهگیری میشود؟
سرمایهگذاری - Investment: تخصیصِ بودجه و نمایشِ بازگشتِ سرمایه (ROI)
سرمایهگذاری در مدلِ توانمندیِ مهندسیِ پلتفرم به نحوهی تخصیصِ نیروی انسانی و منابعِ مالی به قابلیتهای پلتفرم اشاره دارد. در مراحلِ اولیهی (initial) سرمایهگذاری در مهندسیِ پلتفرم، سازمانها اغلب به تلاشهای داوطلبانه و پراکنده برای ایجاد و نگهداریِ قابلیتهای پایه متکی هستند. در بالاترین سطح، رهبریِ سازمان، نوآوری را برای حفظِ پلتفرم ترویج میدهد و تیمهای پلتفرم بهینهسازیِ (optimize) فراتر از قابلیتهای پایه را دنبال میکنند.
حوزههای تمرکز شاملِ بودجه و نیروی انسانی، و همچنین اندازهگیریِ بازگشتِ سرمایه (ROI) میباشد.
مرحلهی اولیه (Initial)
داوطلبانه
ممکن است توانمندیهای فردی برای ارائهی زیرساختهای متداول برای عملکردهای عمومی یا حیاتی وجود داشته باشند. این قابلیتها به دلیلِ ضرورت، ایجاد و نگهداری میشوند، نه بر اساسِ برنامهریزی و تأمینِ مالی هدفمند.
این قابلیتها توسطِ افرادی که به صورتِ موقت یا داوطلبانه مشارکت میکنند، ساخته و نگهداری میشوند؛ هیچ بودجه یا نیروی انسانیای به صورتِ هدفمند به آنها اختصاص داده نمیشود. قابلیتها به نیازهای تاکتیکیِ فعلیِ کاربرانِ خود وابسته هستند. تصمیمگیریها بر اساس دادههای ناقص یا نامربوط انجام میشود که منجر به اولویتبندیهای نادرست میشود.
رهبری بیشتر به بحرانها واکنش نشان میدهد تا اینکه به صورتِ فعالانه تغییر را هدایت کند، که این موضوع منجر به همکاریِ پراکنده و ناکارآمدی در تیمها میشود.
تخصیص بودجه و نیروی انسانی برای نگهداری قابلیتهای متداول: توسعهدهندگان یا تیمهای فردی مسئولیتِ رفعِ نیازهای فوریِ فنی و قابلیتها را بر عهده میگیرند. این کار همیشه هزینهگذاری نمیشود و توسعهدهندگان این وظایف را علاوه بر مسئولیتهای فعلی خود انجام میدهند.
مدیریتِ محدوده (scope): مهندسان بر رفعِ نیازها در چارچوب یا محدودهی خاصی که نیاز در آن به وجود آمده تمرکز میکنند، بدون اینکه راهحل را برای کاربردهای گستردهتر به اشتراک بگذارند.
نمایشِ بازگشتِ سرمایه: بازگشتِ سرمایه بر اساسِ میزانِ موفقیتِ فرد یا تیم در رفعِ مشکلِ خاص و تأثیر آن بر کارهای اصلیِ پروژهشان اندازهگیری میشود.
مرحلهی تکرارپذیر (repeatable)
مشارکتهای موردی (adhoc)
با رشدِ سازمان، چالشهای فنی تکرارشونده مانند فراهمسازیِ ناپایدارِ زیرساخت، شیوههای امنیتیِ پراکنده، و گلوگاهها در پایپلاینهای دیپلویمنت بیشتر نمایان میشوند. این چالشها معمولاً منجر به تأخیر (delay)، افزایشِ زمانِ خرابی، و ناکارآمدیهایی میشوند که سرعت و قابلیتِ اطمینانِ کلیِ تحویلِ نرمافزار را مختل میکنند. در پاسخ، سازمان شروع به تشکیلِ تیمهای اختصاصی برای رسیدگیِ سیستماتیک به این مشکلات میکند. با این حال، این تلاشها عمدتاً واکنشی باقی میمانند و بیشتر بر رفعِ مشکلاتِ فوری تمرکز دارند تا پیشگیریِ فعالانه از آنها.
دامنهی کاری این تیمها معمولاً به نگرانیهای خاصی محدود میشود—مانند بهبودِ یک فرآیندِ استقرارِ خاص یا استانداردسازیِ بخشی از پروتکلهای امنیتی—بدونِ اتخاذ رویکردی جامع برای بهبودِ کلِ پلتفرم.
رهبری سازمان تلاش میکند ناکارآمدیها را با ترویج همکاریهای ابتدایی و معرفی معیارهایی برای سنجشِ بهبودها برطرف کند، اما این تلاشها همچنان واکنشی و محدود به بخشهای خاص باقی میمانند و قدرتِ اجرایی در سراسرِ سازمان محدود است.
تخصیصِ بودجه و نیروی انسانی برای نگهداریِ قابلیتهای متداول: تیمهایی برای کار روی نگرانیهای کلیدی و گسترده تشکیل میشوند، اما اغلب به صورتِ واکنشی عمل میکنند.
مدیریتِ محدوده (scope): محدودهی کاری محدود به یک نگرانیِ خاص است.
نمایشِ بازگشتِ سرمایه: بازگشتِ سرمایه با اندازهگیریِ بهبودها در نگرانیهای کلیدی و گسترده، مانند کاهش اندازهی بکلاگ (لیست کارهای عقبافتاده)، ارزیابی میشود.
مرحلهی تعریفشده (defined)
عملیاتیسازی با تیمِ اختصاصی
بودجه و نیروی انسانی برای حمایتِ مداوم از افراد و منابع تخصیص داده میشود. افرادِ تعیینشده مسئولِ ارائهی مجموعهای از قابلیتهای موردنیاز هستند تا فرآیندِ تحویل نرمافزار را تسریع کنند. این تیمها اغلب بر رفعِ نیازهای فنیِ واکنشی تمرکز دارند. ممکن است به آنها نامهایی مانند DevOps، توانمندسازی مهندسی (Engineering Enablement)، تجربهی توسعهدهنده (DevEx یا DevX)، ابزارهای مشترک (Shared Tools)، مرکزِ تعالی (Centre-Of-Excellence)، یا حتی پلتفرم داده شود. این تیمها به صورت مرکزی تأمینِ مالی شده و بهعنوان مراکز هزینه (Cost Centers) در نظر گرفته میشوند.
تیمهای پلتفرم اکنون بهعنوان بخشی حیاتی از موفقیتِ سازمان شناخته میشوند و تلاشهایی برای اندازهگیری و توجیه مشارکتهای آنها انجام میشود. بااینحال، تمرکز ممکن است همچنان بر بازدهیِ فوری باشد تا رشدِ بلندمدت.
رهبریِ سازمان بهطورِ فعال همکاریِ بینوظیفهای و اجرای اولیهی شیوههای DevOps را ترویج میدهد، اما با چالشهایی در اندازهگیریِ ارزشِ تیمِ پلتفرم و همسو کردنِ راهحلها با نیازهای کاربران روبهرو است که منجر به دشواریهایی در توجیهِ سرمایهگذاریها و حفظِ کارایی میشود.
تخصیصِ بودجه و نیروی انسانی برای نگهداری قابلیتهای متداول: تیمهای مرکزی بر اساسِ دانش و نیازهای فنیِ موجود تأمینِ مالی میشوند تا فرآیندِ تحویلِ نرمافزار را تسریع کنند.
مدیریت محدوده: محدودهی کاریِ گسترده اما سطحی است. تیم راهحلهایی ایجاد میکند که سعی دارند بزرگترین نقطهی اشتراکِ نیازهای تمامِ تیمها را پوشش دهند. تیمِ مرکزی بر درکِ نیازهای مشترکِ همهی تیمها تمرکز میکند و به دنبالِ روشهایی برای تنظیم یا پیکربندیِ راهحلها بر اساسِ این نیازها نیست.
نمایشِ بازگشت سرمایه: بازگشتِ سرمایه با اندازهگیریِ بهبود در سرعتِ تحویل ارزیابی میشود.
مرحلهی مدیریتشده (managed)
مقیاسپذیری بهعنوانِ یک محصول
سرمایهگذاری در پلتفرمهای داخلی و قابلیتهای آنها مشابه سرمایهگذاری در محصولات خارجی و جریانهای ارزشی یک سازمان است: بر اساس ارزشی که انتظار میرود برای مشتریان خود فراهم کنند. مدیریت محصول و تجربه کاربری بهصورت صریح مورد توجه و سرمایهگذاری قرار میگیرند. ممکن است از یک سیستم بازپرداخت هزینه (Chargeback) برای نشان دادن تأثیر پلتفرمها بر جریانهای ارزشی مستقیم و محصولات مشتریان آنها استفاده شود. سازمان با استفاده از شاخصهای عملکرد مبتنی بر داده و حلقههای بازخورد، بودجه و نیروی انسانی را به ابتکارات مناسب اختصاص میدهد. در نهایت، تیمهای پلتفرم میتوانند کسبوکار را بهینه کرده و به افزایش سودآوری کمک کنند.
در این سطح، شاهد تغییر فرهنگی قابل توجهی در سازمان هستیم که در آن توسعهدهندگان بهعنوان مشتریان ارزشمند شناخته و با آنها برخورد میشود. رهبری سازمان بر ایجاد فرهنگی از همدلی و رشد تأکید دارد، رویکردی مبتنی بر محصول را هدایت میکند و بهبود مستمر را تشویق میکند، اما باید اطمینان حاصل کند که این ارزشها بهطور عمیق در سازمان نهادینه شوند تا تأثیر پایداری بهدست آید.
تخصیص بودجه و نیروی انسانی برای نگهداری قابلیتهای مشترک: تیم پلتفرم مرکزی مانند سایر تیمهای محصول سازماندهی و مدیریت میشود. نقشها شامل توسعه، مدیریت محصول، طراحی، تحقیق و محتوا هستند. تیمها بر اساس نقشه راه (Roadmap) تأمین مالی میشوند.
مدیریت دامنه: تیم نقشه راه محصولات را برای توصیف برنامهها و تأثیر مورد انتظار بر سازمان تولید میکند. تیم پلتفرم با تیمهای مهندسی تعامل دارد تا نیازها را جمعآوری کرده و فرصتهای جدید را شناسایی کند. مهندسان بر تأمین نیازهای تمام تیمهای توسعه درون سازمان تمرکز دارند.
نشان دادن بازگشت سرمایه: بازگشت سرمایه با اندازهگیری و گزارشدهی بهبود در رضایت توسعهدهندگان ارزیابی میشود.
مرحلهی بهینهسازی (optimizing)
بهینهسازی با یک اکوسیستمِ توانمند
تیمهای پلتفرم راههایی برای افزایش کارایی و اثربخشی در کل سازمان فراتر از قابلیتهای پایه پیدا میکنند. نگهدارندگان اصلی پلتفرم بهطور هدفمند تلاش میکنند تا زمان عرضه به بازار برای محصولات جدید را بهینه کنند، هزینهها را در سراسر سازمان کاهش دهند، حکمرانی و انطباق کارآمد برای خدمات جدید را امکانپذیر سازند، بارهای کاری را بهسرعت و بهآسانی مقیاسپذیر کنند، و سایر نیازهای کلیدی را برآورده سازند. این نگهدارندگان اصلی بر توانمندسازی متخصصان قابلیت تمرکز دارند تا نیازها و پیشنهادات خود را بهطور یکپارچه در بخشهای موجود و جدید پلتفرم ادغام کنند. علاوه بر این، سازمان افراد و منابع را از حوزههای تخصصی مانند امنیت، عملکرد، و کیفیت به تعامل با چارچوبهای ارائهشده توسط پلتفرم هدایت میکند تا ویژگیهای پیشرفتهای معرفی شود که تیمهای محصول را در تسریع دستیابی به اهداف سازمانی توانمند کند، بدون اینکه به بکلاگ تیم مرکزی وابسته باشند.
رهبری سازمان استقلال و مسئولیتپذیری تیمها را ترویج میدهد، نوآوری را تشویق میکند و در عین حال تعادل میان حکمرانی و خلاقیت را حفظ میکند، با تمرکز بر حفظ ارتباط و اثربخشی پلتفرم در محیطی که بهسرعت در حال تغییر است.
تخصیص بودجه و نیروی انسانی برای نگهداری قابلیتهای مشترک:
تیم پلتفرم مرکزی مانند سایر تیمهای محصول سازماندهی و مدیریت میشود، اما بودجه بیشتری برای مشارکت در سراسر سازمان اختصاص داده میشود. تیمهای مهندسی و غیرمهندسی بودجه مشخصی برای مشارکت در پلتفرم دارند.
مدیریت دامنه:
مهندسان بر توانمندسازی مشارکت در پلتفرم تمرکز دارند تا اشتراکگذاری سریع دانش در سراسر سازمان را امکانپذیر سازند.
نشان دادن بازگشت سرمایه:
بازگشت سرمایه با اندازهگیری و گزارشدهی بهبود در رضایت توسعهدهندگان ارزیابی میشود.