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

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

رهبران تجاری که شرکت‌های مهندسی مانند شرکت من را استخدام می‌کنند، دوست دارند اعداد را ببینند، معیارهایی که ادعا می‌کنند ارزشی را که ما ایجاد می‌کنیم کمیت می‌کنند. در حالی که آنها ممکن است ظرافت‌های باطنی refactoring را برای بهبود خوانایی و مختصر بودن درک نکنند، وقتی پوشش کد از ۸۵% به ۹۰% افزایش می‌یابد می‌توانند درک کنند. اعداد در حال افزایش هستند! بنابراین باید چیزی ارزشمند در حال رخ دادن باشد، درست است؟

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

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

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

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

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

معیارها عالی به نظر می رسند، اما روحیه آن وحشتناک است.

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

اگر مهندسان شما به کیفیت اهمیت می‌دهند – و شما نباید کسانی را استخدام کنید که این کار را نمی‌کنند – آنها می‌دانند که کار پایین‌تری انجام می‌دهند و روحیه آنها بیشتر سقوط می‌کند.

اجازه دهید این به اندازه کافی ادامه یابد، و به زودی هزینه دیگری متحمل خواهید شد: استعدادهای از دست رفته، و تأخیرها و کمبودهای جذب مهندسان جدید در میانه یک پروژه.

اما چون به جای روحیه، معیارها را مدیریت می‌کنید، تا دیر نشده همه این مشکلات را نخواهید دید.

برای مدیریت روحیه، روی ماموریت، خودمختاری و تسلط تمرکز کنید

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

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

در عوض در مورد روحیه‌ای صحبت می‌کنم که تیم‌های شما را برای سرمایه‌گذاری پایدار در موفقیت هر پروژه ترغیب می‌کند.

همانطور که دنیل پینک در کتاب پرفروش خود در سال ۲۰۰۹ نوشت، Drive: حقیقت شگفت‌انگیز درباره آنچه ما را برانگیزد، ممکن است بگوییم انگیزه درونی واقعی – روحیه سرمایه‌گذاری شده -از خودمختاری، تسلط، و هدف می آید.

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

روحیه ریشه در ماموریت دارد (نه معیارها)

مدت‌هاست که نیروی کار «آن را به بیور بسپار» که در یک اتاقک می‌نشیند و هر کاری را که به آنها داده می‌شود، انجام می‌دهد، مدت‌هاست که از بین رفته است. حوزه ما اکنون تحت تسلط Millennials و Generation Z است و این نسل ها تا هسته خود ماموریت دارند. آنها اشتغال صرفاً معاملاتی را رد می کنند. بسیاری می خواهند برای شرکت هایی کار کنند که اصولی و هدفمند هستند.

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

شما نیازی به معیارهای بی معنی ندارید تا خواسته های آنها را هدایت کنید. شما باید به تیم‌های خود کمک کنید تا با مأموریت هر پروژه ارتباط برقرار کنند، موانع موفقیت آنها را برطرف کرده و در هر کاری که برای انجام بهترین کارشان نیاز دارند، از آنها حمایت کنید.

برای توضیح و بحث در مورد هدف پروژه به مهندسان خود به اندازه کافی احترام بگذارید. سعی می کنیم چه کار کنیم؟ چرا ما داریم این کار را می کنیم؟ فایده چیست؟ فلسفه چیست؟

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

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

مشکلات نباید جهانی باشند تا زمانی که مأموریت ایجاد کد با کیفیت برای حل مشکلات ارزشمند مورد احترام و پشتیبانی اساسی قرار می گیرد – و تا زمانی که معیارهای دلخواه مجاز به به خطر انداختن این ماموریت نباشند.

روحیه در استقلال (نه معیارها) فعال می شود

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

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

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

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

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

روحیه با تسلط (نه معیارها) بهبود می یابد

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

آیا مهندسان شما درک روشنی از جهت دارند؟ آیا آنها ابزار مورد نیاز و زمان بی وقفه برای استفاده خوب از آنها را دارند؟ آیا آنها در تعیین جدول زمانی و اختیار تصمیم گیری های مهم صدایی دارند؟

آیا آنها زمان کافی برای انجام درست کار دارند؟ برای کشف و یادگیری؟ برای استراحت، تأمل و بازیابی؟ برای استقرار و اندازه گیری راه حل های آنها به درستی؟

یا ظلم معیارها آنها را وادار می‌کند تا آنچه را که می‌دانند کد شلخته است ارسال کنند و به سمت بلیط بعدی عجله کنند؟ آیا جلسات بیهوده و فرآیندهای خودسرانه حواسشان پرت شده است؟ آیا آنها بیش از حد کار کرده و سوخته اند؟

ابی نودا، یکی از بنیانگذاران و مدیر عامل DX، این عوامل سیستمی را زیر چتر “تجربه توسعه‌دهنده” (DX) جمع‌آوری می‌کند، که به گفته او مستقیماً بر اثربخشی توسعه‌دهنده و موفقیت تجاری تأثیر می‌گذارد. این موضوعی است که نودا با همکاری دکتر. Michaela Greiler و مارگارت-آن استوری، “یک چارچوب عملی برای درک و بهبود تجربه توسعه‌دهنده” (PDF) در Journal of Transaction on مهندسی نرم افزار. و یک برنامه سفید DX بیان می‌کند که نه معیارهای خروجی و نه فرآیند نمی‌توانند به‌دقت تجربه توسعه‌دهنده را اندازه‌گیری کنند.

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

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

مدیریت روحیه منجر به راه‌حل‌های بهتر، حفظ بهتر و فرهنگ بهتر شرکت نیز می‌شود

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

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

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