توسعه دهندگان، متحد شوید! به مبارزه برای کیفیت کد بپیوندید

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

• چرا کیفیت مهم است؟
• بنابراین چگونه آن را انجام می دهید؟
• ایجاد اجماع ۱۰۱
• آیا وقت آن رسیده که به دنبال شغل دیگری بگردید؟
• کیفیت ارزش تلاش را دارد

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

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

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

بیایید بررسی کنیم که چرا کیفیت در وهله اول مهم است—و چگونه می‌توانید بدون به خطر انداختن شغلتان از آنچه درست است دفاع کنید.

چرا کیفیت مهم است؟

دلیل شماره ۱: کیفیت سریعترین مسیر برای رسیدن به ارزش است

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

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

دلیل شماره ۲: کیفیت محافظت از برند است

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

«فقط ۵۹ درصد از کاربران فکر می‌کنند ممکن است شرکتی که تجربه کاربری ضعیفی را ارائه می‌کند محصولی با کیفیت ارائه کند،» جان کلی در CIO می نویسد. “به عنوان مثال، اگر کسب و کار شما تلفن های همراه است و پلت فرم سفارش گیج کننده ای دارید، ۴۱٪ از مشتریان تصور می کنند که شما تلفن های بدی تولید می کنید… یک خطا اعتماد را از بین می برد.”

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

دلیل شماره ۳: کیفیت کار دستی است

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

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

دلیل شماره ۴: کیفیت کار درستی است

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

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

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

بنابراین چگونه آن را انجام می دهید؟

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

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

شما احتمالاً همیشه با همتایان خود اجماع دارید. آیا برای MVP خود به این سمت حرکت می کنیم؟ آیا برای نوشتن API خود به این سمت می رویم؟ چگونه خطوط لوله خود را طراحی کنیم تا بتوانیم چیزها را سریعتر به تولید برسانیم؟

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

ایجاد اجماع ۱۰۱

مرحله ۱: نگرانی های خود را در راستای منافع شرکت و مشتریان خود تنظیم کنید

اگر می‌خواهید افراد بالاتر حرف شما را بشنوند، باید به زبان آنها صحبت کنید. اهداف برتر برای C-suite چیست؟ اگر بتوانید خط مشخصی را برای آن اهداف ترسیم کنید، رهبران انگیزه ملموسی برای در نظر گرفتن یک رویکرد جدید خواهند داشت. در پایان، تاکید بیشتر بر کیفیت به نفع پروژه است و این ارزش تمرین را برای شرکت شما، برای شرکت مشتری شما (در صورت وجود) و برای کاربر نهایی افزایش می‌دهد. بنابراین این موردی است که کاملاً می توانید بسازید.

مرحله شماره ۲: سعی کنید مسائل را از دیدگاه رهبر خود ببینید

اگر به نظر می رسد که فرد بالاسر شما از پیشنهاد شما بیزار است، به یاد داشته باشید که امرار معاش در خطر است. اگر آنها با هدف خاصی (احتمالاً در حدود سرعت استقرار) وظیفه داشته باشند، و به نظر می رسد درخواست شما آن هدف را به خطر می اندازد، دفاع بالا خواهد بود. و چرا نباید باشند؟ در پایان روز کاری، مدیر شما باید به خانه برود و غذا را روی میز بگذارد. حتی اگر این شخص از نظر تئوری با شما موافق باشد، باز هم باید ایده های شما را در مقابل اهمیت شغل سودمند متعادل کند.

با توجه به این واقعیت، چه سازش بهتری می توانید به رهبران خود پیشنهاد دهید تا استانداردهای کیفیت را بدون به خطر انداختن شغل خود افزایش دهند؟

مرحله ۳: انتقال مکالمه با کیفیت از نظرات به حقایق

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

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

مرحله شماره ۴: به خاطر داشته باشید، شما در حال مذاکره برای اجماع هستید

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

آیا وقت آن رسیده که به دنبال شغل دیگری بگردید؟

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

چه زمانی باید موضع سخت بگیرید و چه زمانی باید به دنبال شغل جدید بگردید؟

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

کیفیت ارزش تلاش را دارد

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