لینکدین منبع باز چارچوب بهره وری و شادی توسعه دهندگان خود است

چگونه بهره وری توسعه دهندگان را اندازه گیری می کنیم و چگونه از آن برای بهبود محصولات و محل کار استفاده می کنیم؟

با نگاهی به سال ۲۰۲۳، دو موضوع کلیدی زیربنای بسیاری از مواردی بود که ابزارها و فناوری‌های جدید را در کل اکوسیستم توسعه هدایت کردند. یکی هوش مصنوعی بود که هم از آن استفاده می‌کرد و هم ساخت آن، و دیگری بهره‌وری بیشتر توسعه‌دهندگان بود.

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

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

اندازه گیری بهره وری

تمرکز بر بهره وری مستلزم این است که به سؤالات کلیدی پاسخ دهیم: بهره وری چیست؟ چگونه آن را اندازه گیری کنیم؟ همه ما داستان‌های غیرمعمول شرکت‌هایی را می‌دانیم که بهره‌وری توسعه‌دهندگان را با تعداد خطوط کد نوشته شده یا تعداد باگ‌های رفع‌شده اندازه‌گیری می‌کنند، و اینکه چگونه این معیارها نتایج مورد انتظار را ارائه نمی‌دهند (یا مهندسان چگونه آنها را به نفع خود بازی می‌کنند).

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

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

ارتباط با بهره وری و شادی توسعه دهندگان

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

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

LinkedIn محصول توسعه دهندگان آن است و این شرکت باید آنها را سازنده و راضی نگه دارد. بنابراین، باید بداند که این دو الزام کلیدی برای آن به عنوان یک سازمان چه معنایی دارند. با تکیه بر تجربیات خود و سایر سازمان‌ها، از جمله موزیلا، یک بهره‌وری توسعه‌دهنده را گردآوری و پیاده‌سازی کرده است. چارچوب شادی (DPH) که دستورالعمل‌هایی را برای اندازه‌گیری فرآیندهای توسعه خود ارائه می‌دهد.

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

تغییر روش های توسعه نیازمند تغییر مدیریت است

یکی از بخش‌های مهم چارچوب DPH LinkedIn درک روش توسعه نرم‌افزار است. . ما همیشه درک کرده‌ایم که زمان‌های ساخت باید در هر معیار بهره‌وری لحاظ شود، اما تغییر از آبشار به چابک و CI/CD (ادغام مداوم و تحویل مداوم) آن را تغییر داده است. اکنون هر فشار کد می تواند منجر به ساخت، با تست های خودکار که بخشی از فرآیند است، شود. همچنین باید بررسی کد، زمان صرف شده برای آزمایش و پردازش درخواست‌های کشش را قبل از پذیرش تغییرات در نظر بگیریم.

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

این مدل جدید به روش‌های جدیدی برای کار نیاز دارد. توسعه‌دهندگان دیگر نمی‌توانند بلوک‌های عظیمی از کد را ارائه کنند، زیرا منتظر تکمیل بررسی خواهند ماند. و بازبینی‌کنندگان کد نمی‌توانند اجازه دهند یک بک لاگ ایجاد شود. با استفاده از معیارهای DPH، می‌توانیم بفهمیم که چه چیزی کار هر دو طرف را آسان‌تر می‌کند. این امر ممکن است منجر به ارسال‌های مکرر اما کوچک‌تر شود که درک آن آسان‌تر، آزمایش آسان‌تر و تأیید سریع‌تر باشد—که حفظ و درک کد را آسان‌تر می‌کند.

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

از اعداد تا نتایج

داشتن چارچوبی برای تعیین بهره‌وری توسعه‌دهنده و تعریف معیارهای استفاده شده بسیار خوب است، اما چگونه می توانیم آن داده ها را به عمل تبدیل کنیم؟ یکی از عناصر کلیدی داشتن نوعی داشبورد یا پورتال برای نمایش داده ها و اعمال اهمیت آماری است. لینکدین چیزی را ساخته است که آن را a می نامد. Developer Insights Hub در اطراف DPH، دیدن داده‌های کلیدی، مانند میانگین زمان انتظار برای تکمیل ساخت، همراه با موارد پرت را آسان می‌کند.

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

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

مراحل بعدی: ایجاد ارتباط با سایر سازمان‌ها

منبع‌باز کردن چارچوبی مانند این مرحله مهمی است. این به سازمان‌ها اجازه می‌دهد تا تعیین کنند چه سیگنال‌ها و معیارهایی برای آنها کار می‌کند و بینش و درس‌ها را با جامعه وسیع‌تری به اشتراک بگذارند. اگر چیزی از انتشار LinkedIn کم است، آن یک انجمن رسمی DPH است.

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

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