رهبران فناوری که رضایت توسعه‌دهندگان را به حداکثر می‌رسانند و ناامیدی را به حداقل می‌رسانند، در استخدام، حفظ و ارائه نتایج از تیم‌های توسعه‌دهنده خود پاداش دریافت می‌کنند.
حدود یک دهه پیش، من یک CIO بودم که یک راه حل فناوری را ارزیابی می‌کردم و نیازهای اولیه خود را با نماینده فروشنده احتمالی در میان گذاشتم. او حداقل سه محصول را از مجموعه این شرکت به نمایش گذاشت. هر ابزار تجربه کاربری، رویکرد توسعه و الزامات یادگیری خاص خود را داشت، اما هر سه مورد نیاز برای رفع نیازهای تجاری ما بودند. به عنوان CIO، متوجه شدم که بخش‌های مختلف تیم من یا باید با استفاده از این ابزارهای مختلف همکاری کنند، یا باید توسعه‌دهندگان پیشرفته‌تری را استخدام کنم که بتوانند بر همه آنها مسلط شوند. به دلیل پیچیدگی های توسعه، تصمیم گرفتم در این راه حل فناوری سرمایه گذاری نکنم.
مفهوم تجربه توسعه دهنده (DX یا DevEx) در آن زمان یک هدف اولیه یا قابل اندازه گیری نبود. تعداد کمی از رهبران کسب و کار به ارزش بهبود رضایت، بهره وری و شادی توسعه دهندگان فکر می کردند. اما مدیران ارشد فناوری اطلاعات، پیشگامان دیجیتال، مدیران تحویل، و سرنخ های فنی اهمیت آن را درک کردند. به همین دلیل است که فضاهای کاری بزرگ و چند مانیتوری خریدیم، دسکتاپ‌ها را برای استفاده از قوی‌ترین دستگاه‌ها ارتقا دادیم، میزهای فوتبال را برای تشویق به وقفه‌های کاری وارد کردیم، و با تیم‌های توسعه‌دهنده خود، انتشارات بزرگ را جشن گرفتیم.
وارون گوسوامی، رئیس مدیریت محصول در نرم‌افزار Newgen، از Gartner نشان می‌دهد که ۵۸% از رهبران مهندسی نرم‌افزار می‌گویند تجربه توسعه‌دهنده برای C-suite حیاتی است. او می‌گوید: «این نشان‌دهنده نیاز روزافزون به رابط‌های کاربرپسند و بدون درهم‌کاری، اکوسیستم‌های یکپارچه است که یک مرکز متمرکز برای توسعه، مدیریت پروژه، اسناد، مخازن، و همکاری یکپارچه ارائه می‌کند.
توسعه‌دهندگان در سازمان‌هایی که DX را در اولویت قرار می‌دهند، احتمالاً کاربران نهایی را با نوآوری‌ها خوشحال می‌کنند، کد کیفیت را طبق برنامه منتشر می‌کنند و برای بهبود مستمر در فرآیند توسعه نرم‌افزار تلاش می‌کنند. برخی از عناصر یک تجربه توسعه‌دهنده عالی دسترسی به بهترین ابزارها، حداقل وقفه‌ها، بوروکراسی ساده و دانستن اینکه کار فرد مورد قدردانی است. در اینجا ۱۰ روشی که سازمان‌ها برای ایجاد تجربیات توسعه‌دهنده عالی ایجاد می‌کنند، آورده شده است.
نحوه ایجاد تجربیات توسعه دهنده عالی
- یک تیم توسعه دهنده متنوع ایجاد کنید
- ابزارها را برای افزایش بهره وری استاندارد کنید
- به طور سیستماتیک بدهی فنی را برطرف کنید
- به دنبال نظرات توسعه دهنده در مورد تصمیمات معماری باشید
- از ابزارها و استانداردها برای تقویت همکاری استفاده کنید
- مسئولیت‌های زیرساخت و عملیات را روشن کنید
- استانداردها و معیارهای کیفیت را ایجاد کنید
- به تیم‌های توسعه‌دهنده و امنیت برنامه بپیوندید
- فرهنگی را تقویت کنید که از فرسودگی فنی جلوگیری کند
- دانش تجاری تیم توسعه دهنده را افزایش دهید
یک تیم توسعه دهنده متنوع ایجاد کنید
تجربه توسعه‌دهنده عالی نیازمند فرهنگ شرکتی است که به تنوع، نوآوری، همکاری، بهبود مستمر، آزمایش هوشمند و یادگیری مادام العمر.
کیت پیت، موسس و مدیر عامل Buildkite می‌گوید: «شرکت‌های متمرکز بر توسعه‌دهنده تمایل دارند کارکنانی را که خواهان ساختار و سازمان هستند، بیش از حد فهرست کنند. . «در حالی که این کارگران نوع A ضروری هستند، سازمان‌ها همچنین باید فرهنگی را پرورش دهند که برای توسعه‌دهندگان خلاقی که ایده‌های نوآورانه را پیش می‌برند، ارزش قائل شود. در یک صنعت به طور فزاینده خودکار، رهبران فناوری اطلاعات باید محیطی را پرورش دهند که خلاقیت را تشویق کند و خطرات حساب شده را مجازات نکند تا افراد رویایی بتوانند پیشرفت کنند.”
یکی از راه‌هایی که رهبران فناوری می‌توانند فرهنگ را به پیش ببرند، پاداش دادن به هم تیمی‌هایی است که رفتار و تأثیرشان با اهداف سازمانی مطابقت دارد.
ابزارها را برای افزایش بهره وری استاندارد کنید
یک مکتب فکری می‌گوید که تیم‌های توسعه‌دهنده باید در استفاده از ابزارهایی که ترجیح می‌دهند آزاد باشند. یکی دیگر از سازمان‌ها پیشنهاد می‌کند که یک تیم معماری کوچک را به ایجاد استانداردها و تصمیم‌گیری در مورد ابزارهای استفاده اختصاص دهند. راه میانه این است که به توسعه دهندگان اجازه دهید استانداردهای خودسازماندهی< /a> برای ابزارها و شایستگی‌های مورد نیاز و در عین حال برای فناوری‌های جدیدی که مزایای واضحی ارائه می‌دهند باز می‌مانید.
لورنت دوگوین، مدیر روابط و استراتژی توسعه‌دهنده در Couchbase. “پیروزی واقعی از ابزارهایی حاصل می شود که به آنها اجازه می دهد کارهای خود را به راحتی انجام دهند، و این امر به ویژه در زمانی که توسعه دهندگان با genAI آزمایش می کنند تا کارهایی مانند تولید کد دیگ بخار، refactoring یا نوشتن مستندات را خودکار کنند، صادق است.”
ایجاد یک تجربه توسعه‌دهنده عالی مستلزم توسعه پلتفرم‌ها و استفاده از ابزارهای موجود است در حالی که رهبران فرصت‌هایی را برای یادگیری فناوری و اعمال بهترین شیوه‌ها ایجاد می‌کنند. آنها همچنین یک فرآیند شفاف برای انتخاب و آزمایش فناوری های جدید ایجاد می کنند و دستورالعمل های روشنی را در مورد معیارهای سرمایه گذاری ابلاغ می کنند.
«توسعه‌دهندگان اکنون بیش از هر زمان دیگری به دنبال مسیرهای کم اصطکاک برای موفقیت هستند، و تنها داشتن قابلیت‌های پیشرفته کافی نیست – زمان ساخت و زمان نوآوری باید کم باشد.» کودی دی آرکلند، مدیر ارشد انکوباسیون محصول در LaunchDarkly. “این به معنای ساده کردن پیکربندی ها، تنظیم پیش فرض های هوشمند، و داشتن گزینه هایی برای تنظیم تنظیمات پیشرفته است.”
انتظار از توسعه دهندگان برای سفارشی کردن همه چیز در مورد فضای کاری دیجیتالی خود، توانایی همه را برای ارائه فناوری و ویژگی های جدید کاهش می دهد.
به طور سیستماتیک بدهی فنی را رسیدگی کنید
این برای توسعه دهندگان استرس زا است که کدهای ضعیف ساخته شده را به ارث ببرند و سپس تحت مهلت های زمانی محدود برای بهبود عملکرد کار کنند. کسب‌وکارها با تمرکز بیش از حد بر توسعه ویژگی‌ها، بدون اینکه از تیم توسعه‌دهنده بپرسند چه حوزه‌هایی از برنامه نیاز به ارتقا دارند، چرخه را ادامه می‌دهند.
باب کویلین، مدیر ارشد اکوسیستم در vFunction. بدهی‌های فنی، به‌ویژه بدهی‌های فناوری معماری، روحیه تیم را کاهش می‌دهد و افزودن ویژگی‌های جدید و استفاده از فناوری‌های جدید مانند genAI را دشوارتر می‌کند، منابع را تخلیه می‌کند و مانع حفظ و بهره‌وری توسعه‌دهندگان می‌شود.
برای بهبود تجربه توسعه‌دهنده، اهداف روشنی برای تیم‌های توسعه چابک ایجاد کنید تا بدهی فنی را به صورت مداوم کاهش دهید، یک فرآیند روشن برای فهرست بندی مسائل بدهی فنی ایجاد کنید، و دستورالعمل های واضحی را برای اینکه چگونه تیم ها باید اصلاح بدهی فنی را در اولویت قرار دهند، ایجاد کنید. ادارات باید چندین اشکال از بدهی فنی، از جمله بدهی داده، بدهی عملیات، بدهی امنیتی، و بدهی معماری.
Quillin می‌افزاید: «درک معماری فعلی یک برنامه، توسعه‌دهندگان را قادر می‌سازد تا مشکلات آزاردهنده برنامه را در اولویت قرار دهند و مشکلات را قبل از قطع شدن آن حل کنند». «مشاهده‌پذیری معماری یک تغییر فرهنگی را امکان‌پذیر می‌کند که توسعه‌دهندگان را قادر می‌سازد تا اصلاح بدهی فنی را با اهداف پروژه هماهنگ کنند و رفع توشه بدهی فنی را که چرخه‌های آزادسازی را سنگین کرده و بر انعطاف‌پذیری تأثیر می‌گذارد، آسان‌تر می‌کند.»
به دنبال ورودی برنامه‌نویس در مورد تصمیمات معماری باشید
در کتاب خود، پیشگام دیجیتال، جلسات گذشته نگر چابک، طوفان فکری راه حل فراگیر را توصیه می کنم جلسات، و پس از مرگ بی‌عیب به‌عنوان شیوه‌های ضروری برای تجربیات توسعه‌دهنده عالی (همچنین به معرفی روش‌شناسی چابک در InfoWorld مراجعه کنید). هنگام تعریف معماری و انتخاب چارچوب‌های توسعه، من معتقدم میزبانی بحث‌های دانشگاهی، تصمیم‌گیری، گرفتن بازخورد و استانداردهای در حال تغییر مداوم همگی از اقدامات حمایتی برای توسعه‌دهندگان هستند.
Sandhya Sridharan، رئیس پلتفرم مهندسین و تجربه در JPMorgan Chase. «برای ساده‌سازی مؤثر توسعه نرم‌افزار، ایجاد یک پلتفرم بنیادی قوی که دارای نظرات مثبت باشد و همچنین مدلی که یک مدل سلف‌سرویس را تسهیل می‌کند، حیاتی است.»
پیدا کردن تعادل مناسب بین جذب ورودی‌های توسعه‌دهندگان، تقویت آزمایش‌ها و استانداردهای رانندگی آسان نیست، به خصوص در شرکت‌های بزرگ با پلتفرم‌ها و انواع برنامه‌های کاربردی. دیکته کردن استانداردها تجربه توسعه دهندگان را کاهش می دهد، بنابراین مهم است که نحوه و چرایی تصمیم گیری های معماری را به اشتراک بگذارید.
Sridharan توصیه می‌کند، «گرچه این امر ممکن است بدیهی به نظر برسد، اما از رهبران می‌خواهد که به سؤالات پیرامون چالش‌های مهندسان و همچنین اولویت‌های کسب‌وکار کلی پاسخ دهند، اطمینان حاصل کنند که پلتفرم نه تنها قابل اعتماد، مقیاس‌پذیر و ایمن است، بلکه می‌تواند پیچیدگی‌ها را نیز از بین ببرد. ارائه مجموعه‌ای از الگوها و نظرات، که توسعه‌دهنده را همیشه در جریان نگه می‌دارد.”
شرکت‌هایی که به دنبال تجربه توسعه‌دهنده بهینه هستند، باید نابرابری در مجموعه مهارت‌ها و سهولت پذیرش توسعه‌دهندگان جدید را نیز در نظر بگیرند. تعجب آور نیست که نظرات متفاوتی در مورد اینکه معماران و توسعه دهندگان چگونه باید در مورد مسائلی مانند اینکه کجا استانداردها مورد نیاز است، کجا انعطاف پذیری ها سودمند است و چه مستنداتی باید ایجاد شود، شریک شوند.
گیلاد شریکی، یکی از بنیانگذاران Descope. نظر بیش از حد می تواند پایگاه کاربر را محدود کند، در حالی که باز بودن بیش از حد ممکن است توسعه دهندگان در مراحل اولیه را بترساند. برای ایجاد این تعادل، از یک رویکرد محصول منحصر به فرد با مزایای واضح و “وضعیت نهایی”، همراه با وثیقه فراوان، مخزن کد نمونه، آموزش‌ها و پشتیبانی جامعه اطمینان حاصل کنید.”
از ابزارها و استانداردها برای بهبود همکاری استفاده کنید
توسعه‌دهندگان تمایل دارند از جلسات مکرر یا غیرمولد متنفر باشند و ترجیح می‌دهند از ابزارهای همکاری برای اشتراک‌گذاری به‌روزرسانی‌های پروژه استفاده کنند. جوزف وارگزی، یکی از بنیانگذاران و مدیر ارشد فناوری StreamAlive.
«در توسعه‌دهندگان داخلی و استعدادهای فناوری، بسیاری از شرکت‌ها فاقد ابزارها و منابع درگیرکننده لازم برای ایجاد یک فرهنگ شفاف و دعوت‌کننده هستند که ارتباطات و همکاری را تشویق می‌کند – مانع تجربه توسعه‌دهندگان می‌شود. از آنجایی که تیم‌های فناوری و استعدادهای توسعه‌دهنده اغلب ستون فقرات سازمان‌ها هستند، ضروری است که آنها بتوانند به طور مؤثر در مورد مسائل و راه‌حل‌های بالقوه با سایر اعضای تیم در سراسر سازمان‌ها بحث کنند.»
سرنخ های تحویل باید بر تنظیم استانداردها در مناطقی مانند:
- الگوهایی برای نوشتن داستان کاربر که شامل معیارهای پذیرش و نمودارهای جاسازی شده است
- استانداردهای مستندسازی به‌روزرسانی‌های هفتگی به جای زمان‌بندی جلسات به‌روزرسانی وضعیت
- الزامات اسنادی برای مواردی که باید با هر نسخه تولیدی به روز شوند
- بهترین شیوه‌ها برای استفاده از جلسات مجازی و فناوری‌های ارتباطی ناهمزمان به‌عنوان ابزارهای ارتباطی مؤثر
تجربه توسعه‌دهنده عالی بر همکاری با استانداردسازی ابزارهایی که به گردش کار توسعه متصل می‌شوند و تعیین انتظارات ارتباطی واضح تمرکز می‌کند.
مسئولیت‌های زیرساخت و عملیات را روشن کنید
نزدیک به ۱۰ سال پیش، از چه کسی مالک devops است پرسیدم و پیشنهاد کرد که عملیات فناوری اطلاعات روز را غنیمت بشمارند. ایده این بود که زیرساخت‌های ابری را یاد بگیریم و ابزارهای اتوماسیون را برای تثبیت یک مدل عملیاتی توسعه‌دهنده سازنده، مشارکتی، نوآورانه و قابل اعتماد توسعه دهیم.
امروزه، ابزارهای جدید بسیاری برای مدیریت، خودکارسازی و ایمن سازی زیرساخت های ابری وجود دارد و همین امر باعث تغییر در مسئولیت های توسعه دهنده و عملیاتی شده است.
Dattaraj Rao، دانشمند ارشد داده در سیستم های پایدار. توسعه‌دهندگان اکنون برنامه‌ها را کد می‌کنند، ارسال می‌کنند و اجرا می‌کنند در حالی که زیرساخت‌ها به صورت پویا کدگذاری شده و ارائه می‌شوند. این تکامل به سمت مالکیت همه جانبه توسط سرویس‌های هوش مصنوعی مبتنی بر ابر قابل دسترسی تقویت می‌شود و راه‌حل‌های پیچیده را امکان‌پذیر می‌کند.”
هنگامی که به دنبال بهبود تجربه توسعه‌دهنده هستید، مهم است که شناسایی کنید چه کسی مسئول زیرساخت‌ها و سایر مسئولیت‌های عملیات است. یک رویکرد یکسان برای همه وجود ندارد: مقررات، انواع برنامه‌ها، مقیاس استفاده، پیچیدگی داده‌ها و ملاحظات امنیتی تنها برخی از عواملی هستند که ممکن است مسئولیت‌های سازمان و تیم را تعیین کنند.
استانداردها و معیارهای کیفیت را ایجاد کنید
آیا کوپیلوت‌ها و تولیدکنندگان کد همیشه دقیق، با کیفیت و مفید هستند؟ در مقاله من، هیپ چیست و کجاست برای به دست آوردن نتایج با کمک خلبان‌های هوش مصنوعی، من تحقیقاتی را نقل می‌کنم که نشان می‌دهد کاربران ۳۰ درصد کدهای پیشنهادی توسط خلبان‌ها را می‌پذیرند، به این معنی که پیشنهادات کد قبل از استفاده در برنامه‌ها نیاز به بررسی و اعتبارسنجی دارند.
جاناتان ویلا، مدافع توسعه‌دهنده در سونار، می‌پرسد، “بازار پر از ابزارهایی است که به تولید کمک می‌کنند. کد، از جمله IDE ها، پلاگین ها و خدمات آنلاین. هوش مصنوعی در حال تبدیل شدن به یک کالا برای همه آنها است، اما به چه قیمتی؟»
هنگام بازبینی ابزارها، به ویژه ابزارهای هوش مصنوعی مولد با هدف بهبود بهره‌وری، یک رویکرد هوشمندانه برای بهبود تجربه توسعه‌دهنده مستلزم تعریف استانداردهای کیفیت و استفاده از ابزارهای خودکار برای تأیید نتایج است.
ویلا اضافه می‌کند، «لازم است کد تولید شده توسط هوش مصنوعی را قبل از افزودن آن به مخازن خود بررسی کنیم. لاینترها و گیت‌های باکیفیت دروازه‌بان‌های مناسبی هستند که بهترین ارزش را از هوش مصنوعی بدون به خطر انداختن پایه کد دریافت می‌کنند.”
تیم‌هایی که بر کیفیت و بهره‌وری تجربه توسعه‌دهنده خود تمرکز می‌کنند، احتمالاً هنگام طراحی و توسعه برنامه‌ها همین کار را انجام می‌دهند. تعریف استانداردها و معیارهای کیفیت تضمین می‌کند که توسعه‌دهندگان انتظارات و معیارهای پذیرش روشنی برای کار دارند.
پست های مرتبط
۱۰ اصل برای ایجاد یک تجربه توسعه دهنده عالی
۱۰ اصل برای ایجاد یک تجربه توسعه دهنده عالی
۱۰ اصل برای ایجاد یک تجربه توسعه دهنده عالی