هر پروژه نرم‌افزاری با فانتزی و خوش‌بینی پرشور شروع می‌شود. حتی شب‌بیداری‌های پروژه هم آرزوی افراد تیم است. تیم متقاعد شده که پروژه با چند خط کد و تعدادی کتابخانه متن‌باز[۱]کامل می‌شود و برای این کار شگرف و ظریف پاداش دریافت خواهد کرد. اما بعد از چند ماه که از رؤیا بیدار شدیم می‌بینیم که مخزن‌های git (سایت گیت هاب)[۲] پرشده از تصمیم و بازنگری و بازنگری و بازنگری. آیا این خوب است؟ آیا به انتظاراتی که از پروژه داشتیم نزدیک است؟ آیا تابه‌حال کسی واقعاً از آن استفاده کرده است؟ تیم‌های نرم‌افزاری همیشه در پروژه‌ها عمیق می‌شوند تا به پاسخ نه برای حداقل بعضی از این پرسش‌ها برسند. آیا راهی برای پیش‌بینی پاسخ‌ها وجود دارد؟
گاهی اوقات درست است که بهترین طرح‌های برنامه‌ریزی‌شده، بدون هیچ هشداری به گمراهی کشیده می‌شوند. اما اغلب اوقات مشخص است که پایان کار افتضاح خواهد بود لذا کسی رغبت نمی‌کند که به پروژه از نزدیک توجه کند.
در اینجا چندین نشانه هشداردهنده احتمال شکست پروژه‌های نرم‌افزاری مطرح‌شده است.
جابجایی در مدیریت پشتیبانی
آیا قهرمان پروژه صبح بعد درحالی‌که سعی داشته فرزندش را به USC یا Yale ببرد دستگیرشده است؟ آیا CIO[3] سه جلسه آخر بررسی را کنسل کرده است؟ اگر بخواهید محاسبات را گِرد کنید، از آخرین باری که CIO را دیده‌اید، یک سال گذشته است؟ آیا CFO[4] حقوق کارمندان شما را پرسیده است؟ آیا قرار است نصف نمودار سازمانی از بین برود؟ بسیاری از پروژه‌های نرم‌افزار به دلایلی شکست می‌خورند که هیچ ارتباطی به افرادی که کد را نوشته‌اند ندارد. فردی در مدیریت عاشق پروژه نرم‌افزاری شما است و در فرآیندهای تصویب و تصدیق از آن حمایت می‌کند و اگر آن شخص برود یا ناپدید شود، پشتیبانی هم فرومی‌ریزد و از بین می‌رود. مهم نیست که دید شما چقدر عالی باشد. اگر بخش دیگری دید متفاوتی برای جهت‌گیری کمپانی داشته باشد و کنترل شرکت به دست آن قسمت بیفتد، ممکن است پروژه شما بر باد برود. لذا هرچقدر هم که مایل نباشید به سیاست‌ها توجه کنید.
تغییرات در بازار
تنها حمایت داخلی اهمیت ندارد. مصرف‌کنندگان و بازار مصرف آن‌ها هم می‌تواند تمایلات آن‌ها را تغییر دهد. درحالی‌که پروژه‌های نرم‌افزاری برای کامل شدن به ماه‌ها زمان نیاز دارند، بازار می‌تواند ظرف چند هفته یا چند روز یا حتی چند دقیقه از دست برود. اگر هدف پروژه شما بازاری باشد که به‌سرعت در حال تکامل و رشد است، احتمال اینکه بازار زمانی که کدها را به پایان رساندید کاملاً متفاوت باشد، بالا است. حتی اگر پروژه شما در حوزه‌ای مستحکم‌تر و باثبات‌تر هم باشد، یک‌شبه می‌تواند رقابت جدیدی به وجود بیاید. اگر تیم شما برای تطبیق با تغییرات گرایش‌ها برنامه‌ای ندارد، شانس اینکه شکست بخورید بالا است.
سکوی پرتاب برنامه نویسان
مردم همواره شغل خود را تغییر می‌دهند و برنامه نویسان زبده خواهان زیادی دارند اما اگر تیم دائماً در حال از دست دادن نیروهای خود است، یک جای کار اشتباه است. اگر حقوق‌ها به‌اندازه کافی بالا باشند و مزایای شغلی زیاد باشد، ممکن است خودِ پروژه مشکل داشته باشد. شاید کد نویسان با الزامات پروژه گیج شده‌اند و برای اینکه استرس ذهنی نگیرند، از پروژه کنار می‌کشند. شاید تمام معماری پروژه اشتباه باشد و اعضاء نتوانند پروژه را راه بیندازند. شاید اخلاق و خصوصیات سمی از شخصی در تیم وجود دارد که همه را از کار دور می‌کند. برون‌ریزی تیم نشانه خوبی است مبنی بر اینکه چیزی در تیم از مسیرش منحرف‌شده و امکان دارد شانس موفقیت پروژه شما را کاهش دهد.
کارهای ساده هم زیاد طول می‌کشند
تیم به تغییرات ساده با چه سرعتی پاسخ می‌دهد؟ آیا آن‌ها می‌توانند رنگ پس‌زمینه را تغییر دهند؟ یک Checkbox را چند پیکسل حرکت دهند؟ اگر تغییرات کوچک به‌سرعت انجام نگیرند، تغییرات بزرگ خیلی بیشتر طول خواهند کشید. گاهی تصمیمات بدِ معماری برخی چیزهای ساده را نزدیک به غیرممکن می‌کند. روی پروژه‌ای کار می‌کردم و از من خواسته شد تا یک ستون اضافی را در پایگاه داده پرکنم و این کار مستلزم تغییر پنج میکرو سرویس مختلف بود. این به معنی چک کردن پنج پروژه مختلف، کار با خلاصه کدهای نوشته‌شده از پنج پروژه مختلف و نوشتن پنج مجموعه مختلف تست‌های واحد است. همه این کارها برای به‌روزرسانی یک عدد در یک سطر است.
توسعه‌دهندگان گاهی تغییرات ساده را بیش‌ازحد پیچیده می‌کنند و گاهی اوقات باهوش‌ترین توسعه‌دهندگان بدترین هستند. برخی تغییرات بسیار سخت هستند اما اگر تیم برای اداره و رفع تغییرات کوچک مشکل دارد، نشانه این است که پایه خیلی پیچیده است.
[۱] Open Source
[۲] Git Repository
[۳] Chief Information Officer
[۴] Chief Financial Officer
