از توسعه دهنده ۱۰x تا تیم ۱۰x

ایجاد یک تیم توسعه نخبه با کنار گذاشتن فانتزی توسعه دهندگان ۱۰x و پذیرش رویکرد مدرن تر برای بهره وری توسعه دهندگان شروع می شود.

Bigfoot و توسعه‌دهنده افسانه‌ای ۱۰x مشترکات زیادی دارند: مشاهده‌ها نادر هستند و قطعی نیستند. با این حال، اگرچه بسیاری از مردم تصوری مبهم در مورد ظاهر Bigfoot دارند، مشخصات توسعه‌دهنده ۱۰x – توسعه‌دهنده‌ای که ۱۰ برابر بهره‌ورتر از همتایان خود است – مبهم‌تر است.

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

علیرغم تمسخر و طرد شدن توسط توسعه دهندگان از زمان پیدایش، مفهوم توسعه دهنده ۱۰x، که برای اولین بار در تحقیقات منتشر شده در Peopleware در حدود سال ۱۹۸۷ معرفی شد، با رهبری فناوری اطلاعات زنده است. چرا؟ این با این فرض رایج مطابقت دارد که بهره‌وری اساساً یک مسئله مردمی است که می‌توان با استفاده از بهترین شیوه‌ها و ابزارهای مدیریت، مانند شیوه‌های استخدام، تجزیه و تحلیل شکاف مهارت، آموزش، نظارت بر فعالیت، نظرسنجی‌ها، و استراتژی‌های جبران خسارت به آن پرداخت.

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

مهندسی بهره وری توسعه دهنده را وارد کنید

تیم‌های توسعه نخبگان می‌دانند که بسیاری از رویکردهای سنتی مدیریت بهره‌وری، اگرچه ضروری و مؤثر هستند، کافی نیستند. آنها محدودیت‌های رویکردی را درک می‌کنند که بر مقیاس‌سازی بهره‌وری فردی از یک توسعه‌دهنده ۱ برابری به ۱۰ برابری تمرکز دارد. در نتیجه، آنها رویکرد مدرن تری را برای بهره وری توسعه دهندگان به نام «مهندسی بهره وری توسعه دهندگان» (DPE) پذیرفته اند. DPE روشی نوظهور است که توسط شرکت هایی مانند Airbnb، American Express، Apple، JPMorgan Chase، Google و Netflix برای بهبود بهره وری توسعه دهندگان و تجربه توسعه دهندگان استفاده می شود. DPE تمرکز رهبران فناوری اطلاعات را از پرورش توسعه دهندگان ۱۰ برابری به سمت ایجاد یک تیم ۱۰ برابری تغییر می دهد.

اگر در مورد وجود توسعه دهندگان ۱۰ برابری یا مفید بودن این مفهوم شک دارید، منطقی است که در مورد مفهوم تیم های توسعه ۱۰ برابری شک دارید. در نتیجه، بسیار مهم است که “تیم توسعه ۱۰x” را به عنوان یک چشم انداز و استراتژی برای بهبود مستمر که با تمرین DPE فعال می شود، در نظر بگیرید. DPE به خودی خود یک تیم ۱۰x ایجاد نمی کند.

بعلاوه، یک تیم ۱۰x هدف متحرکی است که مقایسه مربوطه با تیم های توسعه رقبای شما انجام می شود. در نتیجه، ارزش کسب‌وکار در سفر است و نه مقصد، زیرا هرگز نمی‌دانید که وارد شده‌اید، زیرا رقبا به طور مداوم برای جابجایی تیرک‌های دروازه تلاش می‌کنند. با این حال، پیمایش موفقیت آمیز این سفر یک ماموریت حیاتی است. موفقیت مبتنی بر پذیرش سه تغییر در تفکر استراتژیک است که در مرکز رویکرد DPE قرار دارند.

از مشکل مردم تا چالش فناوری

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

به عبارت دیگر، در حالی که مدیریت بهره‌وری توسعه‌دهنده سنتی بر پاسخ دادن به سؤالاتی مانند «چگونه توسعه‌دهندگان را در زمان انتظار برای تکمیل چرخه‌های ساخت و آزمایش بهره‌ورتر کنیم؟» تمرکز دارد. DPE می پرسد: «چرا در وهله اول این همه زمان برای تکمیل چرخه های ساخت و آزمایش طول می کشد؟ چگونه می توانیم داده ها و فناوری را برای رفع این مشکل تحمل کنیم؟»

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

این مهندسی مجدد ساخت‌ها و آزمایش‌ها بر بهره‌وری و کیفیت توسعه‌دهنده اثر «تغییر به چپ» دارد، زیرا مشکلات کمتر در CI نشان داده می‌شوند، جایی که شناسایی و رفع آنها گران‌تر است. علاوه بر این، هنگامی که خرابی رخ می دهد، عیب یابی ساختمان های شکسته می تواند باعث زحمت و ناامیدی شود. فناوری‌های DPE مانند Gradle Build Scan یافتن و رسیدگی به علت اصلی خرابی‌های ساخت را به طور چشمگیری کارآمدتر می‌کند.

از خروجی فردی تا نتایج تیمی

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

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

از ROI نرم تا تصمیم‌گیری سرمایه‌گذاری ROI سخت

تعیین بازگشت سرمایه در طرح‌های مدیریت بهره‌وری سنتی غیرممکن است. معیارهای DPE می‌توانند نتایج قابل‌اندازه‌گیری کسب‌وکار را ارائه دهند که می‌توان برای تعیین بازگشت سرمایه (ROI) سخت کسب درآمد کرد و از آن برای توجیه پرونده اولیه کسب‌وکار و سرمایه‌گذاری‌های در حال انجام برای بلوغ اقدامات DPE استفاده کرد.

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

در نهایت، DPE نشان‌دهنده یک رویکرد انقلابی برای بهره‌وری توسعه‌دهنده است، زیرا از فناوری‌های مدرن برای بالا بردن سطح نتایج تیم استفاده می‌کند. اگرچه تمرین DPE به خودی خود تیمی ۱۰ برابری را ارائه نمی دهد، اما یک استراتژی برای بهبود مستمر ارائه می دهد. ارزش کسب و کار در سفر است و نه مقصد، و هدایت سفر برای سلامت رقابتی هر شرکتی حیاتی است. با آن، به جای تمرکز بر روی یافتن Bigfoot بعدی در میان توسعه دهندگان نرم افزار – توسعه دهنده ۱۰x – شرکت ها باید DPE را در تعقیب تیم ۱۰x بپذیرند.

هانس داکتر مدیر عامل و بنیانگذار Gradle Inc.، مخترع ابزار متن باز Gradle Build Tool است. و متخصص پیشرو در جهان و مدافع روش نوظهور مهندسی بهره‌وری توسعه‌دهنده (DPE) است که Gradle Enterprise پلتفرم فناوری توانمند پیشرو برای آن است. هانس سابقه طولانی و افتخار آمیزی با جامعه منبع باز دارد. Gradle Build Tool محبوب ترین ابزار ساخت پروژه های منبع باز JVM در GitHub است. Gradle Enterprise یک پلت فرم باز است که علاوه بر ابزار Gradle Build از چندین ابزار متن باز از جمله Apache Maven و Bazel پشتیبانی می کند.

—

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.