آبجی
18th October 2009, 11:29 AM
معمولاً وقتی سازمان یا شركتی نرم‌افزاری را سفارش می‌دهد، هیچ‌گاه به این موضوع فكر نمی‌كند كه ممكن است قبل از تحویل گرفتن آن، نرم‌افزار او بمیرد و از آن محصول نتواند استفاده كند. یا اگر نرم‌افزار را سالم تحویل بگیرد باز هم به این موضوع فكر نمی‌كند كه این نرم‌افزار روزی می‌میرد.
سازمان‌های بزرگ هزینه‌های قابل‌توجهی را صرف خرید تجهیزات IT از سخت‌افزار گرفته تا نرم‌افزار و تجهیزات شبكه‌ای می‌كنند و نكته قابل توجه این‌كه بیشترین درصد خرابی و مشكلات از آن نرم‌افزار است، اما به راستی چرا این‌گونه است؟ چرا در اكثر پروژه‌های نرم‌افزاری كشورمان این مشكل دیده می‌شود؟ تجربه شخصی من برای پاسخ دادن به این سؤالا‌ت، عدم توجه به هشت نكته مهم را دخیل می‌داند:
1- یكی از مشكلات پروژه‌های نرم‌افزاری نداشتن برنامه كاری یا داشتن برنامه زمان‌بندی غیرحقیقی است. به عنوان مثال، در حالی كه نظر كارشناسی این است كه مدت زمان اتمام پروژه با توجه به اجزای آن چهار ماه طول خواهد كشید، شما به عنوان مدیر پروژه نرم‌افزاری نباید قول بدهید كه پروژه دو ماه دیگر به اتمام می‌رسد. این كار باعث خواهد شد به دلیل كمبود وقت كیفیت نرم‌افزار كم شود.
2- به‌كارگیری نرم‌افزاری كه كیفیت پایینی داشته باشد حتماً با شكست روبه‌رو می‌شود. تصور كنید كه روی اجزای سیستم‌های نرم‌افزاری آزمایش كاملی صورت نگیرد و از روش‌های آزمایش مكرر در هنگام برنامه‌نویسی استفاده نشود. اگر نیازهای كاربران (نه به صورت كامل بلكه جزئی) تغییر كند سیستم دیگر نمی‌تواند قابل استفاده باشد.
3- نباید فكر كنیم اتفاق خارق‌العاده‌ای رخ می‌دهد و كاربران سیستم همان‌گونه كه ما به آن‌ها می‌گوییم، با سیستم رفتار می‌كنند. شاید ورود اطلاعات زیاد و رفتارهای مختلف كاربران در سیستم تأثیر داشته باشد و باعث شود نتیجه خوبی از پروژه نگیریم.
4- اگر چه تغییر كلی نیازهای كاربران پروژه نرم‌افزاری را با مشكل روبه‌رو می‌كند، اما باور كنید كه كاربران نیازهای جدیدی خواهند داشت. بهتر است در پروژه‌های نرم‌افزاری از روش‌های آبشاری قدیمی استفاده نكنیم و از روش‌های نوین مانند test driven development بهره بگیریم.
5- در پروژه‌های نرم‌افزاری از نیروهای آزموده و حرفه‌ای استفاده كنیم. اگر چه نیروهای غیرحرفه‌ای می‌توانند برنامه‌های كوچكی تولید كنند، اما پروژه‌های نرم‌افزاری بزرگ هم به تخصص و تجربه زیادی نیاز دارند. به صرف این‌كه فردی تنها تحصیلات دانشگاهی عالی در رشته نرم‌افزار دارد نمی‌توان گفت كه می‌تواند عضوی از تیم پروژه باشد. در انتخاب نیروهای پروژه دقت كنید، چون دلیل از بین رفتن اغلب پروژه‌های نرم‌افزاری استفاده از نیروهای غیرمتخصص است.
6- برخی از كاربران سیستم كه خود به استفاده از سیستم راغب نبودند و سرپرستشان آن‌ها را مجبور می‌كرد از سیستم استفاده كنند، در مقابل سیستم و نرم‌افزار مقاومت می‌كردند و می‌خواستند همچنان به صورت دفتری كار خود را انجام دهند، زیرا به نظر آن‌ها استفاده از سیستم‌های نرم‌افزاری حیطه وظایف آن‌ها را محدود می‌كند و نمی‌گذارد آن‌ها در انجام وظایف كوتاهی كنند (یا به عبارتی از زیر كار در بروند). شاید هم هنوز به نرم‌افزارها اعتماد ندارند و بر این گمانند كه مغزشان در امور محاسباتی از كامپیوتر بهتر كار می‌كند.
7- كاربران اصلی سیستم در طول مراحل طراحی نرم‌افزارها حضور ندارند، به همین دلیل است كه وقتی نرم‌افزار آماده می‌شود می‌خواهند آن را تغییر دهند. كار آن‌ها مانند این موضوع است كه تنها اندازه‌های خود را به خیاط بدهیم و بگوییم حوصله پرو را نداریم. حاصل كار شاید لباسی باشد كه اندازهِ شما باشد، اما به احتمال خیلی زیاد كارایی كافی را نخواهد داشت.
8- فرض كنید نرم‌افزار عاری از اشكال است و در اختیار كاربر قرار می‌گیرد. حال اگر كاربر به دلیلی وقت خود را صرف ایرادگیری از سیستم كند یا اطلاعات مورد نیاز را به آن وارد نكند پروژه نرم‌افزاری به نتیجه نخواهد رسید. برخی از كاربران سیستم فكر می‌كنند كه وظیفه برنامه‌نویس وارد كردن اطلاعات به سیستم است.
در كشورهای صنعتی درصد مشكلات پروژه‌های نرم‌افزاری بسیار كمتر از كشور ما است. تجربه به ما نشان داده كه تقریباً بیست‌درصد از پروژه‌های نرم‌افزاری كوچك و حدود ده تا پانزده درصد از پروژه‌های نرم‌افزاری بزرگ مشكل دارند. در واقع این پروژه‌ها آنقدر مشكل دارند كه نمی‌توان آن‌ها را اصلاح كرد. جالب‌تر این‌كه برخی از مدیران پروژه‌های نرم‌افزاری كه پروژه‌‌هایشان با مشكل روبه‌رو می‌شود، نمی‌خواهند این واقعیت را بپذیرند كه نرم‌افزارشان مرده است و دیگر نمی‌توان كاری برایش انجام داد.
به عنوان مثال، حدود دو سال پیش در یكی از سازمان‌های دولتی به وسیلهِ گروهی كه تخصص نرم‌افزاری نداشته و تنها فنی بودند سیستمی طراحی شد و تیم نرم‌افزاری مسئولیت اجرای آن را به عهده گرفت. بعد از آماده سازی محصول كاربر سیستم تغییرات زیادی در سیستم به وجود آورد كه ساختار كلی آن را تغییر داد و هنوز بعد از این همه مدت هیچ‌گاه سیستم عملیاتی نشده است.
نمی‌توانیم تمامی اشكالات را به كاربر یا مدیر پروژه نسبت بدهیم. به نظر من اگر بتوانیم تمامی هشت نكته‌ای را كه در بالا اشاره شد، در نظر بگیریم، درصد كمتری از پروژه‌های نرم‌افزاری ما با شكست روبه‌رو می‌شوند.
سازمان‌های بزرگ هزینه‌های قابل‌توجهی را صرف خرید تجهیزات IT از سخت‌افزار گرفته تا نرم‌افزار و تجهیزات شبكه‌ای می‌كنند و نكته قابل توجه این‌كه بیشترین درصد خرابی و مشكلات از آن نرم‌افزار است، اما به راستی چرا این‌گونه است؟ چرا در اكثر پروژه‌های نرم‌افزاری كشورمان این مشكل دیده می‌شود؟ تجربه شخصی من برای پاسخ دادن به این سؤالا‌ت، عدم توجه به هشت نكته مهم را دخیل می‌داند:
1- یكی از مشكلات پروژه‌های نرم‌افزاری نداشتن برنامه كاری یا داشتن برنامه زمان‌بندی غیرحقیقی است. به عنوان مثال، در حالی كه نظر كارشناسی این است كه مدت زمان اتمام پروژه با توجه به اجزای آن چهار ماه طول خواهد كشید، شما به عنوان مدیر پروژه نرم‌افزاری نباید قول بدهید كه پروژه دو ماه دیگر به اتمام می‌رسد. این كار باعث خواهد شد به دلیل كمبود وقت كیفیت نرم‌افزار كم شود.
2- به‌كارگیری نرم‌افزاری كه كیفیت پایینی داشته باشد حتماً با شكست روبه‌رو می‌شود. تصور كنید كه روی اجزای سیستم‌های نرم‌افزاری آزمایش كاملی صورت نگیرد و از روش‌های آزمایش مكرر در هنگام برنامه‌نویسی استفاده نشود. اگر نیازهای كاربران (نه به صورت كامل بلكه جزئی) تغییر كند سیستم دیگر نمی‌تواند قابل استفاده باشد.
3- نباید فكر كنیم اتفاق خارق‌العاده‌ای رخ می‌دهد و كاربران سیستم همان‌گونه كه ما به آن‌ها می‌گوییم، با سیستم رفتار می‌كنند. شاید ورود اطلاعات زیاد و رفتارهای مختلف كاربران در سیستم تأثیر داشته باشد و باعث شود نتیجه خوبی از پروژه نگیریم.
4- اگر چه تغییر كلی نیازهای كاربران پروژه نرم‌افزاری را با مشكل روبه‌رو می‌كند، اما باور كنید كه كاربران نیازهای جدیدی خواهند داشت. بهتر است در پروژه‌های نرم‌افزاری از روش‌های آبشاری قدیمی استفاده نكنیم و از روش‌های نوین مانند test driven development بهره بگیریم.
5- در پروژه‌های نرم‌افزاری از نیروهای آزموده و حرفه‌ای استفاده كنیم. اگر چه نیروهای غیرحرفه‌ای می‌توانند برنامه‌های كوچكی تولید كنند، اما پروژه‌های نرم‌افزاری بزرگ هم به تخصص و تجربه زیادی نیاز دارند. به صرف این‌كه فردی تنها تحصیلات دانشگاهی عالی در رشته نرم‌افزار دارد نمی‌توان گفت كه می‌تواند عضوی از تیم پروژه باشد. در انتخاب نیروهای پروژه دقت كنید، چون دلیل از بین رفتن اغلب پروژه‌های نرم‌افزاری استفاده از نیروهای غیرمتخصص است.
6- برخی از كاربران سیستم كه خود به استفاده از سیستم راغب نبودند و سرپرستشان آن‌ها را مجبور می‌كرد از سیستم استفاده كنند، در مقابل سیستم و نرم‌افزار مقاومت می‌كردند و می‌خواستند همچنان به صورت دفتری كار خود را انجام دهند، زیرا به نظر آن‌ها استفاده از سیستم‌های نرم‌افزاری حیطه وظایف آن‌ها را محدود می‌كند و نمی‌گذارد آن‌ها در انجام وظایف كوتاهی كنند (یا به عبارتی از زیر كار در بروند). شاید هم هنوز به نرم‌افزارها اعتماد ندارند و بر این گمانند كه مغزشان در امور محاسباتی از كامپیوتر بهتر كار می‌كند.
7- كاربران اصلی سیستم در طول مراحل طراحی نرم‌افزارها حضور ندارند، به همین دلیل است كه وقتی نرم‌افزار آماده می‌شود می‌خواهند آن را تغییر دهند. كار آن‌ها مانند این موضوع است كه تنها اندازه‌های خود را به خیاط بدهیم و بگوییم حوصله پرو را نداریم. حاصل كار شاید لباسی باشد كه اندازهِ شما باشد، اما به احتمال خیلی زیاد كارایی كافی را نخواهد داشت.
8- فرض كنید نرم‌افزار عاری از اشكال است و در اختیار كاربر قرار می‌گیرد. حال اگر كاربر به دلیلی وقت خود را صرف ایرادگیری از سیستم كند یا اطلاعات مورد نیاز را به آن وارد نكند پروژه نرم‌افزاری به نتیجه نخواهد رسید. برخی از كاربران سیستم فكر می‌كنند كه وظیفه برنامه‌نویس وارد كردن اطلاعات به سیستم است.
در كشورهای صنعتی درصد مشكلات پروژه‌های نرم‌افزاری بسیار كمتر از كشور ما است. تجربه به ما نشان داده كه تقریباً بیست‌درصد از پروژه‌های نرم‌افزاری كوچك و حدود ده تا پانزده درصد از پروژه‌های نرم‌افزاری بزرگ مشكل دارند. در واقع این پروژه‌ها آنقدر مشكل دارند كه نمی‌توان آن‌ها را اصلاح كرد. جالب‌تر این‌كه برخی از مدیران پروژه‌های نرم‌افزاری كه پروژه‌‌هایشان با مشكل روبه‌رو می‌شود، نمی‌خواهند این واقعیت را بپذیرند كه نرم‌افزارشان مرده است و دیگر نمی‌توان كاری برایش انجام داد.
به عنوان مثال، حدود دو سال پیش در یكی از سازمان‌های دولتی به وسیلهِ گروهی كه تخصص نرم‌افزاری نداشته و تنها فنی بودند سیستمی طراحی شد و تیم نرم‌افزاری مسئولیت اجرای آن را به عهده گرفت. بعد از آماده سازی محصول كاربر سیستم تغییرات زیادی در سیستم به وجود آورد كه ساختار كلی آن را تغییر داد و هنوز بعد از این همه مدت هیچ‌گاه سیستم عملیاتی نشده است.
نمی‌توانیم تمامی اشكالات را به كاربر یا مدیر پروژه نسبت بدهیم. به نظر من اگر بتوانیم تمامی هشت نكته‌ای را كه در بالا اشاره شد، در نظر بگیریم، درصد كمتری از پروژه‌های نرم‌افزاری ما با شكست روبه‌رو می‌شوند.