بررسی شکست پروژه های نرم افزاری

مقدمه

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

بررسی شکست

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

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

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

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

برخی برنامه نویسان که بعد از مدتی برنامه نویسی  شروع به کار تحلیل می کنند نا خود آگاه و یا به تبعیت از دیگر اعضای تیم از این روش استفاده می کنند. در این میان برخی هم هستند که ممکن است از همان شروع کار از روش های دیگری استفاده کنند. نکته مهم این هست که یک برنامه نویس حتی اگر بیست سال هم برنامه نویسی کند لزوما به یک تحلیل گر تبدیل نمی شود و برای کار تحلیل گری باید دوره ها و کتابهای آن را مطالعه کند.

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

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

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

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

مثال 1 :

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

بزودی کار  را شروع کرده و حدود دو هفته روی موضوع کار کردم و در این مدت چندین بار هم تلفنی صحبت کردیم.

وقتی نهایاتا نرم افزار را نشانش دادم جلسه زیاد خوب پیش نرفت و در پایان آنقدر تغییرات از من خواست که کلافه شدم.

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

در نهایت دقیقا به همان اندازه که قبلا وقت صرف کرده بودم روی آن کار کردم و نرم افزار از اول نوشتم. 

این نرم افزار شکست خورده بود.

بررسی شکست :

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

ما درک مشترکی از نرم افزار نداشتیم. چیزی که دوستم تجسم کرده بود با چیزی که من برایش ساخته بودم فرق داشت.

دوستم در ابتدای کار هنوز دید واقعی نسبت به نرم افزار نداشت و تازه زمانی که نرم افزار را دید ذهنش باز شد و چیزهای جدید می خواست.

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

مثال 2 :

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

بررسی شکست:

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

مثال  3 :

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

 بررسی شکست : 

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

مثال 4 : 

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

نسخه دوم در مرحله کدنویسی متوقف شد. 

بررسی شکست :

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

همچنین در پروژه بیش از دو مورد تکنولوژی جدید که برای برنامه نویسان نا آشنا بود به کار گرفته شد که ادامه کار را با مشکل مواجه کرد.