برخی تحقیقات نشان می‌دهند بیش از نیمی از پروژه‌های فناوری اطلاعات به دلایل مختلف از تولید ایده ضعیف گرفته تا عدم برقراری ارتباط شکست می‌خورند. بااین‌حال این متخصصان می‌گویند این بدان معنی نیست که سازمان‌ها در حال پیشرفت یا آموختن از این شکست‌ها نیستند. توماس مورفی تحلیلگر ارشد گارتنر گفت: بخشی از مسئله این است که یک سازمان شکست را چگونه تعریف می‌کند. وی افزود: غالباً، گزارش‌های مربوط به موضوع، این دست پروژه‌ها را اگر تأخیر داشته باشند یا از بودجه عبور کرده باشند، شکست خورده تلقی می‌کنند که البته ممکن است شکستی در کار نباشد و این پروژه‌ها فقط انتظارات را برآورده نکرده باشند. مورفی ادامه داد: ” دلایل زیادی برای تلقی شکست وجود دارد. یکی از دلایل این است که توسعه پروژه‌ها بیشتر به سمت Agile رفته است: یعنی پروژه‌های بزرگ ۱۸ ماهه را به‌صورت افزایشی تقسیم کنید تا همه هدف یکسانی داشته باشند. “
می‌رسیم به شکست نوع دوم. عدم تحقق آنچه برنامه‌ریزی و پیش‌بینی شده بود. مورفی گفت: این‌یک عدم موفقیت در برقراری ارتباط است، زیرا ملزومات واضح و روشن نبودند، درک نشده یا در طول پروژه تغییر کردند. وی افزود: حرکت به مست چابک می‌تواند به این امر کمک کند، زیرا این امکان را برای ورود به سیستم فراهم می‌کند تا نحوه پیشرفت پروژه و نیاز آن را ببیند.
مورفی افزود: ” روش چابک اگر به‌درستی انجام شود، باید رویکردی مشترک‌تر و بیشتر مبتنی بر همکاری برای توسعه باشد، به این معنی که ارتباط مستقیمی بین کاربر و تیم توسعه وجود دارد. شرکت‌های Cloud و DevOps این رویکرد را کمی جلوتر بردند و این امکان را به من دادند (با داشتنِ معماری درست و استفاده از امکاناتی مانند Feature Toggles) تا یک ویژگی / تغییر جدید بسازم و سریعاً در اختیار یک گروه کوچک قرار دهم، بازخورد بگیرم و به جلو حرکت کنم. ” عموماً، زمانی که ما در مورد شکست پروژه صحبت کنیم، منظورمان پروژه‌های بزرگ است، مثل انتقال به cloud یا انتقال از روش آبشاری به چابک. مورفی می‌گوید: ” تغییرات بزرگ، ریسک‌های زیادی دارند، ناشناخته‌های زیادی وارد آن‌ها می‌شود و غالباً به‌مانند موردی جادویی دیده می‌شوند یا با لنزهای خیلی ساده- اگر توسعه‌دهندگان ‘با روش چابک عمل کنند‘ ما ۱۰ برابر سریع‌تر خواهیم بود- اما این‌ها پروژه‌های نرم‌افزاری نیستند. “
کریستوفر کاندو تحلیلگر ارشد فارستر گفت: ” بعضی‌اوقات یک توسعه‌دهنده مرتکب خطا می‌شود و مشخصات برنامه را به شکلی که منظم باشد تعیین و تفسیر نمی‌کند. در سایر موارد محصولات به‌درستی طراحی نشده‌اند و نقص طراحی وجود دارد که منجر به مشکلات امنیتی، قابلیت اطمینان و مقیاس‌پذیری می‌شود. همچنین عدم آزمایش کافی یک محصول می‌تواند منجر به بروز مشکلاتی شود. زمانی که فرضیاتی در مورد نحوه اجرای کد مطرح می‌شود، شکست در عملکرد و کارایی هم وجود دارد. موفقیت و شکست اغلب دودویی نیست. مورفی می‌گوید: ” ما به جلو حرکت کردیم و آموختیم که شکست‌خورده نیستیم. ما هنوز به مقصد خود نرسیدیم. “
چگونه از شکست پروژه نرم‌افزاری جلوگیری کنیم؟
کاندو نکات زیر را برای توسعه‌دهندگان به‌منظور اجتناب از نقاط مشترک شکست پروژه نرم‌افزاری پیشنهاد داده است:
۱- هنگام نوشتن کد توسعه نرم‌افزار با مدیر محصول یا صاحب محصول ملاقات کنید. منطق کد خود را با آن‌ها در میان بگذارید و اینکه انتظار دارید چگونه کار کند تا اطمینان حاصل کنید هر دو درک مشترکی پیداکرده‌اید. کاندو ادامه می‌دهد: ” این می‌تواند یک مکالمه ۲۰ دقیقه‌ای با این شخص باشد و شما در آن درباره منطق کسب‌وکار یا گردش‌کاری که درحال‌توسعه آن هستید صحبت کنید و اطمینان حاصل کنید که درواقع این همان چیزی است که آن‌ها فکر می‌کردند اتفاق خواهد افتاد.”
۲- برای یافتن هرگونه خطا و آسیب‌پذیری، تست‌هایی بنویسید که عملکرد را ارزیابی کند و موارد مثبت و همچنین منفی را برای پیدا کردن خطاها و آسیب‌پذیری‌ها بنویسید.
۳- کدهای مختصر و واضح بنویسید تا هر توسعه‌دهنده‌ای بتواند به آن نگاه کند و نواقص منطقی را درک کند. کاندو گفت: ” استانداردهایی داشته باشید تا کل تیم از شما در مورد چگونگی مستندسازی روش‌ها و خصوصیات، جایی که باید در کد وجود داشته باشند، پیروی کنند.”
۴- کاندو ادامه داد: “از بررسی و مرور کدها استقبال کنید. زمانی که بحث ارزیابی و بررسی پیش می‌آید، آن را شخصی نگیرید. این واقعاً در مورد کسب‌وکار و تجارت است. شما به‌احتمال ۹۹% برای یک کمپانی شرکت می‌کنید، شما به نمایندگی از یک شرکت در حال نوشتن کد هستید و آن شرکت می‌خواهد کد نویسی به‌درستی انجام شود. بنابراین بارویی گشاده از بررسی و مرور کدهای خود استقبال کنید و اگر کسی اشتباهی در آن یافت، سپاسگزار باشید. “
