۳۰ شهریور ۱۴۰۳

Techboy

اخبار و اطلاعات روز تکنولوژی

بایدها و نبایدهای مربیگری توسعه نرم افزار

مدیران توسعه نرم افزار می توانند با این هفت نکته از ارزشمندترین دارایی خود یعنی افراد حمایت کنند.

مدیران توسعه نرم افزار می توانند با این هفت نکته از ارزشمندترین دارایی خود یعنی افراد حمایت کنند.

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

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

هدف ها را بیان کنید و همدلی را جمع آوری کنید

Ravs Kaur، CTO در Uplevel، می‌داند که مدیران توسعه همیشه تحت فشار هستند تا ویژگی‌های بیشتری را در هر نسخه و اسپرینت ارائه کنند. پیشنهاد او این است که انگیزه را با همدلی متعادل کنید و یک ارتباط انسانی برقرار کنید. او می‌گوید: «یک مدیر مهندسی می‌تواند به طرق مختلف از اعضای تیم خود حمایت کند، مانند ترسیم اهداف و داشتن ارتباطات باز، اما تاثیرگذارترین کاری که یک مدیر می‌تواند انجام دهد این است که همدل باشد.

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

پروژه زبان Rust حاکمیت را اصلاح می کند

اجازه ندهید توسعه دهندگان از استرس خسته شوند

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

Dawn Parzych، مدیر بازاریابی توسعه‌دهنده در LaunchDarkly، معتقد است که تیم‌های توسعه می‌توانند با استفاده از ابزارها و شیوه‌های توسعه استرس را کاهش دهند. او مطالعه اخیر را به اشتراک گذاشت که نشان می دهد ۹۱٪ از متخصصان توسعه نرم افزار فاقد فرآیند هستند ، مانند استفاده از پرچم‌های ویژگی، احساس استرس را در حین استقرار گزارش می‌کند. او پیشنهاد می کند، “به عنوان یک مدیر، به این فکر کنید که چگونه می توانید استرس را از بین ببرید و به اعضای تیم خود کمک کنید تا با بهبود فرآیندهای ساخت و استقرار از طریق استفاده از روزهای آشفتگی، قابلیت مشاهده یا پرچم های ویژگی، از فرسودگی اجتناب کنند.”

به دنبال افراد مدبر باشید که در مورد راه حل ها تحقیق می کنند

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

مارکوس مرل، معاون استراتژی فناوری در آزمایشگاه سس، بر اهمیت شناسایی جویندگان راه حل هنگام مدیریت تیم های توسعه تاکید کرد. “مواقعی وجود دارد که باهوش ترین فرد با بهترین الگوریتم کسی است که شما به آن نیاز دارید. با این حال، بیشتر اوقات، شما به کسی نیاز دارید که بتواند پاسخ را در کتابخانه یا ابزاری بیابد تا کسی که اولین پاسخ او به مشکلات سخت این باشد: “من می توانم همه اینها را خودم بسازم، از ابتدا!” >

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

البته، وقتی نوبت به کدنویسی می‌رسد، مدیران توسعه نرم‌افزار نقش مهمی در بررسی شیوه‌های توسعه‌دهنده، پایبندی به استانداردها و مسیر بهبود مهارت‌های آن‌ها دارند. Ravi Duddukuru، مدیر ارشد محصول DevGraph، می‌گوید: «کوچینگ بسیار مهم است. کوچینگ نه تنها مهارت های توسعه دهندگان را بهبود می بخشد، بلکه در زمان و هزینه نیز صرفه جویی می کند.”

7 دلیل برای دوست داشتن زبان Rust - و 7 دلیل برای عدم علاقه

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

جزئیات فنی را یاد بگیرید، به‌ویژه برای داده‌ها، یادگیری ماشینی و توسعه‌ها

توسعه نرم‌افزار فقط مربوط به کد نیست و مدیران توسعه باید از جزئیات فنی در مورد معماری‌های ابری، اتوماسیون استقرار، عملیات داده‌ها و مدیریت چرخه توسعه مدل‌های یادگیری ماشین مطلع باشند. مایکل برتولد، مدیرعامل KNIME می‌گوید: «مدیران باید تفاوت‌های ظریف Mlops، modelops، dataops، devops و Xops را درک کنند.

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

برتولد دلیلی برای نگرانی دارد. مطالعات اخیر نشان می دهد که ۹۰% از مدل های یادگیری ماشینی هرگز به تولید نمی رسند. مدیران توسعه نرم افزار باید یک طرز فکر توسعه را در مدل های یادگیری ماشین اعمال کنند. او می‌افزاید: «علم داده‌ها چیزی بیشتر از انداختن یک مدل بسته‌بندی زیبا روی دیوار است.»

همه تصمیمات را نگیرید

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

چرا آپاچی کافکا ZooKeeper را حذف می کند؟

Vlad Mystetskyi، سرپرست تیم دوشنبه Apps در Monday.com، می‌گوید مدیران توسعه نرم‌افزار باید توسعه‌دهندگان را در تصمیم‌گیری مشارکت دهند تا مبادلات را بهتر درک کنند. او می‌گوید: «با به اشتراک گذاشتن مالکیت فرآیند تصمیم‌گیری و دادن توانایی به تیم‌ها برای درس گرفتن از اشتباهات خود، مدیران می‌توانند توسعه‌دهندگان را تشویق کنند تا نسبت به کاری که به دست می‌آورند احساس مسئولیت بیشتری کنند.

Mystetskyi ادامه می دهد، “مدیران باید شفافیت را حتی زمانی که اوضاع نامطمئن است، تقویت کنند تا تیم ها احساس کنند با تصویر کامل یک پروژه درگیر هستند.”

با شرایط تجاری ارتباط برقرار کنید

بخشی از درک تصویر کامل این است که به توسعه‌دهندگان کمک می‌کند تا در مورد کارشان در شرایط و معیارهای تجاری بحث کنند. دکتر کالین تارتو، مدیر مهندسی Starburst Data، می‌گوید: «درک مفاهیمی مانند درآمد مکرر سالانه (ARR) در مقابل درآمد برای یک محصول نرم‌افزاری، یا capex در مقابل opex می‌تواند مفید باشد تا مهندسان بتوانند بینشی در مورد تصمیم‌های بزرگ‌تری کسب کنند. در سازمان آنها.”

او همچنین توصیه می کند که رهبران «در ارتباط بیش از حد اشتباه کنند، به خصوص از نظر نقشه راه و مسیرهای شغلی. مردم دوست دارند بدانند چه چیزی در راه است و چه چیزی می توانند انتظار داشته باشند که در آینده روی آن کار کنند.”

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