دفتر مدیریت پروژهمطالب ویژه

۱۳ نشانه شکست پروژه نرم‌افزاری شما (بخش آخر)

۱. چشمک زدن به چیز جدید و برق زننده

زبان‌های جدید، کتابخانه‌ها و معماریها عالی هستند اما جای خودشان رادارند و اغلب در پشته بحرانی- مأموریت جایی نباید داشته باشند. برای سمت اکتشافی و نمایشی پروژه‌ها خوب هستند. برای میکرو سرویس‌های غیرضروری روی بخش جنبی پروژه خوب هستند. اگر تیم زمان‌بندی مناسبی داشته باشد و انتخاب دیگری نداشته باشد، ممکن است قابل‌قبول باشند. به‌هرحال واقعیت این است که به دنبالِ راهکار نرم‌افزاری جدید بودن احتمالاً نشان‌دهنده این است که توسعه‌دهندگان با پروژه کنونی یا معماری کشمکش دارند. برنامه فعلی ممکن است بینظمیهای موقتی، باگ‌ها و دردسرهایی داشته باشد. ممکن است آن‌ها به‌زور تلاش کنند تا برخی از کتابخانه‌های غیرمتناسب را برای ارتباط با یک API به کار ببرند. ممکن است کد چسبنده بیشتر از کد واقعی داشته باشیم. نارضایتی از رویکرد کنونی ممکن است منجر به سرگردان و منحرف شدن چشم‌های توسعه‌دهندگان شود.

۲. مشخصات نامشخص کسب‌وکار

آیا چشم‌انداز این فرآیند، فوق‌العاده مبهم است؟ آیا پر از کلمات بیخود مانند “disrupt” (اختلال) و “meta” است به‌جای اصطلاحاتی مانند “HTTP” یا “AJAX”؟ آیا درباره “تغییر دادنِ دنیا” زیاد صحبت شده و در مورد انتخاب‌های پایگاه داده یا استراتژیهای معماری کم؟ ایجاد نرم‌افزار مستلزم تصمیمات فنی سخت است و گاهی اوقات رؤیاپردازانی که تصور میکنند روی پروژه به‌اندازه کافی زمان نگذاشته‌اند، درباره اینکه چگونه کار خواهد کرد فکر میکنند. برخی اوقات خوش‌شانس هستند و شخص باهوشی قادر است نرم‌افزار را بسازد، اما اغلب اوقات مشخصات نامشخص کسب‌وکار منجر به پروژه‌های شکست‌خورده میشوند. شاید نیاز به پهنای باند خیلی زیاد باشد. شاید تأخیر  (مفهومی در شبکه) رابط کاربر را کند کند. شاید درآمد تبلیغات و حق عضویت هزینه همه آن ماشین‌های ابری را پوشش ندهد. ما نمیدانیم چه اتفاقی خواهد افتاد چراکه طرح و نقشه‌های مستندات وارد جزییات نشده‌اند.

۳. پیچیدگی کنترل نشده

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

۴. نقشه ضعیف تست نرم‌افزار

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

۵. انتظارات نامعقول

گاهی اوقات برخی چیزها با نرم‌افزار آن‌قدر ساده هستند که افراد درگیر پروژه فراموش میکنند که فرانید ساخت نرم‌افزار چقدر سخت است. پروژه‌های زیادی میتوانند با خطاهای کم کامپایل و اجرا شوند، اما اگر چیزی که مشتریان میخواهند را فراهم نکنند، شکست‌خورده محسوب میشوند. گاهی اوقات مشکل کدها نیستند، بلکه رؤیاهای غیرقابل مدیریتِ افرادی هستند که از آن استفاده خواهند کرد. برای مثال: پایگاه داده جدید کچلی سر من را هم درمان میکند؟ یا مثلاً تصور میکردم قرار است مثل فیلم Star Trek مثل برق ازاینجا به‌جای دیگر بروم. توسعه‌دهندگان نرم‌افزار باید برای اطمینان از عدم کنترل رؤیاپردازان جسور یا کسانی که افکار غیرواقعی و بزرگ دارند، کنترل پروژه را به دست‌گیرند. اگر انتظارات مدام بررسی شوند، پروژه برای رسیدن به آن شانس دارد. اگر انتظارات بررسی نشوند حتی یک اپلیکیشنِ بدون خطا و با تأخیر کم و شگفت‌انگیز که کاملاً در پیشرفت قرار دارد هم ناامیدکننده به نظر خواهد آمد.

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا