مدیریت پروژه در حوزه IT
 
قالب وبلاگ
نويسندگان
پيوندهاي روزانه

چکیده

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

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

دلایل شکست را در ادامه مطلب بخوانید.


2) شکست چیست؟

ابتدا لازم می‌نماید که بدانیم شکست در یک پروژه به چه معناست. شکست در پروژه‌های نرم‌افزاری در هر یک از چهار مورد «هزینه»، «زمان»، «کیفیت» و «دست‌یابی به اهداف» مطرح می‌گردد؛ بدین معنا که اگر پروژه‌ای با صرف هزینه‌ی بیشتر یا زمان بیشتر یا با کیفیت پایین‌تر انجام گردد، علی‌رغم به پایان رسیدن پروژه، آن را توأم با شکست می‌دانیم.

1-2) 
آمــار
طبق آماری که نویسنده به دست آورده است تنها یک ششم پروژه‌های نرم‌افزاری تعریف شده (67/16%) در زمان معین و با هزینه‌ی پیش‌بینی شده به پایان رسیده استیک سوم پروژه‌ها (33/33%) فوراً متوقف گردیده و نیمه‌ی باقی‌مانده مورد بحث این مقاله است؛ که از این میان به طور متوسط پروژه‌ها با صرف 89/1 برابر بودجه (%189+) و 22/2 برابر زمان (%222+) انجام شده و تنها به 61/0 مشخصات تعریف شده دست یافته‌اند(61% اهداف).

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

مطالعات انجام شده مبین این نکته است که ریشه‌ی بیشتر علل شکست، در پیش از اولین خط کد نوشته شده یافته شده است، یعنی «طراحی». البته این موضوع را با شرح جزئیات بیشتر می‌توان کالبدشکافی نمود و جنبه‌های مختلفی را متذکر گردید که همگی در حیطه‌ی طراحی می‌گنجد.

3) 
علل اصلی شکست پروژه‌ها

بنا بر این مطالعه می‌توان موارد زیر را به عنوان «دلایل اصلی عدم توفیق در پروژه‌های نرم‌افزاری» ذکر نمود:
• 
ضعف ورودی کاربر
• 
نیازمندی‌های مبهم
• 
تخمین دور از واقعیت برای هزینه و زمان
• 
ناهماهنگی در مهارت‌ها
• 
هزینه‌های پنهان
• 
شکست طراحی
• 
طبقه‌بندی ارتباطات
• 
معماری ضعیف
• 
تأخیر در اعلان شکست
در بخش‌های بعد هر یک از موارد بالا را تشریح خواهیم کرد.

1-3) 
ضعف ورودی کاربر

هنگامی که مشاهده شود که سیستم به نیازهای کاربر پاسخ نمی‌دهد به چنین موردی بر می‌خوریم. این ضعف در سیستم از آنجا ناشی می‌شود که داده‌های اولیه در طراحی از ناظران سطح بالا اخذ گردیده است، که اینان به طور معمول از سیستم استفاده نمی‌کنند. در اینجا به گفته‌ی «پاول هیویت»، مشاور مرکز پشتیبانی فنی نرم‌افزار(STSC) ، اشاره می‌کنیم:«پروژه‌ها با مشکل مواجه خواهند شد مگر اینکه کاربران آگاه طی هر فاز استخراج نیازمندی‌ها، طراحی محصول و ساخت، داده‌های ورودی با معنی به طراح بدهند. کاربر باید بپرسد: چگونه همه‌ی کارهایم را با سیستم انجام دهم؟ آیا سیستم ابزار درست و کارآمد را برای من تأمین می‌کند؟ باید چه چیز بهسیستم بدهم و در مقابل چه به دست خواهم آورد؟».
نکته‌ی دیگر در این باره را «شاری لاورنس فلیگر»، رییس شرکت نرم‌افزاری Systems در واشینگتن دی سی بیان می‌دارد:«... با وجود این کاربر نباید به بخش تعیین نیازمندی‌ها بیش از حد نزدیک شود. چون باعث بروز تداخل(Conflict) می‌گردد. کاربران درباره‌ی آنچه می‌خواهند و تبعات آن فکر نمی‌کنند، اینان تنها به این می‌اندیشند که کارها چگونه انجام می‌شده‌اند و در آینده چگونه انجام خواهد شد.».

2-3) 
ابهام در نیازمندی‌ها

بیانات «ماریا داتیز» رییس Peripheral Visions در هوستون تگزاس، درباره‌ی تجربیاتش در این خصوص مفید است:«کارفرما درباره‌ی آنچه که برنامه باید انجام بدهد ایده‌ای کلی دارد و در آن زمان که پروژه در دست مطالعه و طراحی است، ایده‌هایش را پالایش و اصلاح می‌کند. بنابراین در هر مرحله طراحان ناچار به عقب‌گرد می‌شوند ونتیجه آنکه هزینه‌ی پروژه و کیفیت به سرعت از کنترل خارج می‌شود، که البته نهایتاً شرکت ما مقصر شناخته می‌شود! بنابراین باید از ابتدا scope به حد کافی باریک و محدود باشد.

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

3-3) 
تخمین دور از واقعیت برای هزینه و زمان

پروژه‌های نرم‌افزاری همانند همه‌ی فعالیت‌های مهندسی دیگر، نیازمند تعیین حداقل هزینه و زمان هستند. یعنی یکنقطه‌ی مینیمم برای هزینه و زمان در هر پروژه وجود دارد که با مطالعه‌ی بیشتر روی آن حتماً مقدارش رشد خواهد داشت. «... اما خست به خرج دادن باعث طراحی‌های ضعیف، چگالی بالای عیوب، دوباره‌کاری و آزمون‌های بی‌پایانمی‌گردد. نهایتاً پروژه با پول و زمان بیشتر و کیفیت بدتر انجام خواهد شد.». این گفته‌ی «رابرت گزلتر» مشاور نرم‌افزار شرکت فلاشینگ در نیویورک می‌باشد.
«
کیپرز جونز» رییس مؤسسه‌ی تحقیقات بهره‌وری نرم‌افزار می‌گوید:«برای علاج این مشکل باید در تخمین هزینه و زمان پروژه از چند ابزار مختلف سود جُسته، پارامترهای عددی به دست آمده را ترکیب کرد تا به تخمینی واقعی‌تر دست یافت. حتی گاهی پیش از تعریف دقیق نیازمندی‌ها، برآورد لازم است.».

4-3) 
ناهماهنگی در مهارت‌ها

این مورد بیشتر در پروژه‌های دولتی مشهود بوده است و آن بدین خاطر است که در پروژه‌های دولتی قوه‌ی تصمیم‌گیری در دست اشخاصی است که خبره‌گی فنی ندارند.
پروژه‌هایی که به فناوری بالا متکی‌اند (High Tech) ، باید مدیرانی با مهارت‌های فنی بالا داشته باشند. اختیارات چنین طرح‌ها و پروژه‌هایی نیز باید در دست افرادی باشد که آگاهی فنی دارند و ریسک‌های فنی را می‌فهمند.
مجموعه‌ی مهارت‌ها برای مدیریت و برنامه‌نویسی از جدا می‌باشند. مدیریت پروژه‌های بزرگ نیاز به مهارت‌های عالی در «طرح‌ریزی»، «سازمان‌دهی»، «افق دید وسیع و عمیق» و «ارتباطات» دارد. استخدام افراد ماهر با حقوق بیشتر، از استخدام افرادی با حقوق کمتر که مدت‌ها طول می‌کشد تا صاحب تخصص شوند، به مراتب به‌صرفه‌تر است.
ماریا داتیز می‌گوید:«You get what you pay for! ، هر چه پول بدهی آش می‌خوری! اگر نمی‌توانی یهترینتکنسین‌ها(فنی‌ها) را استخدام کنی، بهترین مدیران را استخدام کن!».

5-3) 
هزینه‌های پنهان

ارزان تمام کردن، باعث بُروز هزینه‌های پنهان می‌شود. در تخمین هزینه و زمان باید متوجه هزینه‌های پنهان نیز بود. به عنوان مثال در نظر گرفتن تورم در تخمین هزینه‌ها مؤثر می‌باشد.

6-3) 
شکست طراحی

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

7-3) 
طبقه‌بندی ارتباطات

تیم‌های درگیر کار طراحی و کدنویسی باید با یکدیگر مراوده داشته باشند. چون حین انجام کار همواره مشکلات مشابهی پیش می‌آید، به خصوص اگر تیم‌ها در سایت‌های مختلف کار کنند؛ وجود مراوده و تبادل اطلاعات و مبادله‌ی تجربیات بسیار حائز اهمیت بوده، از صرف هزینه و وقت اضافی جلوگیری می‌کند.
برای انجام این امر باید فردی وجود داشته باشد که به کل کار محیط بوده و این هماهنگی‌ها را انجام دهد. در عین حال باید جلسات متعدد، متناوب و مستمر داشته باشیم تا هر کس بداند جزء کوچکی را که می‌سازد در کجای این پیکره‌ی عظیم قرار می‌گیرد.
ضمناً در طی این جلسات مشکلات هر تیم بیان شده و احیاناً اگر این مشکلات را حل کرده‌اند راه‌حل‌ها را نیز به اطلاع دیگران رسانیده و اگر در تیم دیگری چنین مشکلی بروز کند آنها راه حل را پیشاپیش خواهند دانست و ناچار به تجربه کردن تجربیات نخواهند بود.
نتیجتاً سرعت کار بیشتر شده و قطعاً هزینه نیز کاهش می‌یابد. هزینه‌ی مذکور شامل پول و زمان می‌باشد.

8-3) 
معماری ضعیف

در بحث «معماری ضعیف» تمرکز این مقاله بر روی انعطاف‌پذیری معماری می‌باشد. مثلاً نمونه‌ی تجربی موجود در جنگ خلیج دیده شده است. موشک «پاتریوت» برای مقابله با موشک «اسکاد» طراحی نشده بود ولی نرم‌افزار قادر به تغییر ساختار(برای پشتیبانی از عملکرد جدید) بود.
در سوی دیگر این طیف، برنامه‌های «حفاظت متون حساس» هستند که به سیستم عامل وابسته‌اند.
در طراحی نباید پروژه چنان طرح‌ریزی شده باشد که به ساختار ویژه یا سیستم عامل خاصی چنان وابسته باشدکه در پشتیبانی و به‌روزرسانی و افزودن بخش‌های جدید به سیستم دچار مشکل یا صرف هزینه‌ی گزاف شویم.
گزلتر در این باره می‌گوید:«نباید قایق بسیار زیبایی را در کارگاه ساخت که از در کارگاه بیرون نمی‌رود
ضمناً باید توجه داشت که: «اگر کارت را درست انجام دهی کسی نمی‌فهمد، ولی اگر اشتباه کنی ... !»
بنابراین در معماری و طراحی ساختاری سیستم، باید حداقل‌ها را در نظر گرفته، وابستگی سیستم بهplatformهای سخت‌افزاری و نرم‌افزاری را به حداقل رسانید.

9-3) 
تأخیر در اعلان شکست

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

نتیجه‌گیری

علاوه بر موارد مذکور، مشکلات و موانع بسیار دیگری نیز موجودند. به گفته‌ی جونز:«راه‌های شکست بسیارند، در حالی که تنها راه‌های اندکی برای موفقیت وجود دارند.».
اما با توجه به همین موارد معدود که شرح آن رفت، می‌توان تا حدود بسیار زیادی از بروز مشکلات جدی در هر پروژه بالاخص پروژه‌های نرم‌افزاری پیش‌گیری نمود.
من حیث‌المجموع در انجام هر نوع فعالیت مهندسی صرف زمان هنگام طراحی و بررسی کلیه‌ی جوانب کار بسیار به‌صرفه‌تر است از صرف هزینه‌های گزاف در فازهای بعدی پروژه، به منظور اصلاح مشکلاتی که اساساً می‌توانستپیش نیاید.

.

خلاصه مقاله:

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

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

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

منبع:

http://gol-barg.mihanblog.com/post/2

[ جمعه ٢٥ اسفند ،۱۳٩۱ ] [ ٥:٠٥ ‎ب.ظ ] [ لیلا آذری ]
.: Weblog Themes By WeblogSkin :.
درباره وبلاگ

کارشناس ارشد معماری سیستم های کامپیوتری - عضو انجمن مدیریت پروژه ایران - بیش از 8 سال سابقه کار در زمینه مدیریت پروژه IT - تحلیل - ساخت داشبوردهای مدیریتی با Tableau و ...
صفحات ديگر
امکانات وب