مدیریت ریسک یک سیستم برای شناسایی، رسیدگی و حذف مسائلی است که ممکن است به هزینه، زمان‌بندی یا موفقیت فنی یک پروژه یا روحیه تیم پروژه آسیب برساند.
«مشکلات فردا، ریسک‌های امروز هستند.» بنابراین، «ریسک» به وضوح به عنوان یک مشکل تعریف می‌شود که می‌تواند آسیب‌هایی ایجاد کند یا زمان‌بندی پروژه را تهدید کند، اما هنوز اتفاق نیفتاده است.
اگر ابتکار عمل برای مدیریت ریسک‌ها را نداشته باشید، با ریسک‌ها مواجه خواهید شد.
توسعه نرم‌افزاریک فعالیت با ریسک بالا است و ممکن است در هر مرحله از فرآیند توسعه پروژه ریسک‌هایی وجود داشته باشد. اتخاذ یک روش مدیریت ریسک فعال می‌تواند فرآیند پروژه را پایدارتر کند، توانایی بالایی برای پیگیری و کنترل پروژه به دست آورد و بتواند ریسک‌ها را اجتناب یا منتقل کند، یا اثرات منفی ریسک‌ها را کاهش دهد.
مدیریت ریسک فرآیند شناسایی، تحلیل، پاسخگویی و نظارت بر ریسک‌های پروژه است. این یک فعالیت مدیریتی بسیار مهم در مدیریت پروژه است. اجرای مؤثر مدیریت ریسک نرم‌افزار تضمینی برای تکمیل روان توسعه پروژه نرم‌افزار است.
دستیابی به مدیریت ریسک باید شامل سه عنصر باشد:
- یک برنامه مدیریت ریسک باید در برنامه توسعه پروژه تدوین شود؛
- بودجه پروژه باید شامل منابع مالی مورد نیاز برای حل ریسک باشد؛
- هنگام ارزیابی ریسک، تأثیر ریسک نیز باید در برنامه‌ریزی پروژه گنجانده شود.
بیایید بحث کنیم که چگونه می‌توانیم اقداماتی پیشگیرانه برای کاهش ریسک‌هایی که اغلب در طول توسعه نرم‌افزار رخ می‌دهند، انجام دهیم.
- نیازمندی‌های نامشخص— نیازمندی‌های نامشخص مشکلاتی هستند که به طور مکرر در فرآیند توسعه نرم‌افزار با آن‌ها مواجه می‌شویم. چنین مشکلاتی معمولاً در جنبه‌های مختلفی مانند دامنه نامشخص نیازمندی‌ها، نیازمندی‌های تصفیه‌نشده، توصیف نامشخص نیازمندی‌ها، نیازمندی‌های گمشده و نیازمندی‌های متضاد بروز می‌کنند. در چرخه عمر فرآیند توسعه نرم‌افزار، هدررفت ناشی از نیازمندی‌های نامشخص بزرگ‌ترین مشکل است و باید هر چه سریع‌تر حل شود. تعیین نیازهای کاربر بسیار دشوار است.
اقدامات پیشگیرانه
- اجازه دهید کاربران از طریق بحث‌ها و جلسات کوتاه و مکرر در توسعه شرکت کنند
- توسعه و ارتباط با ذینفعان با استفاده از پروتوتایپ‌های وایرفریم / رابط کاربری
2. برای پروژه‌هایی با توزیع وسیع کاربران و تعداد زیاد کاربران، معمولاً جمع‌آوری جامع نیازمندی‌های کاربران دشوار است و معمولاً جلسات تحقیق نیازمندی‌ها برای تأیید نیازمندی‌ها برگزار می‌شود.
اقدامات پیشگیرانه
چند هفته قبل از جلسه، نیازهای کاربران در مناطق و بخش‌های مختلف را بررسی کردیم و سپس نمایندگان کاربران از تمام مناطق یا بخش‌ها را جمع‌آوری کردیم تا یک سمینار نیازمندی‌ها برگزار کنیم و از طریق جلسه نیازمندی‌ها را جمع‌آوری کنیم. این روش برای کاربرانی که تجربه خاصی در IT دارند مناسب است.
2. تله 80/20— وقتی یک مدیر پروژه یا یک توسعه‌دهنده می‌گوید که 80٪ از کار انجام شده است، باید محتاط باشید. زیرا 20٪ باقی‌مانده ممکن است 80٪ از زمان را بگیرد یا ممکن است هرگز تکمیل نشود.
پروژه‌های توسعه نرم‌افزار اغلب از نظر پیشرفت پروژه و کیفیت نرم‌افزار فاقد شفافیت هستند. هر چه پروژه کمتر شفاف باشد، کنترل پروژه سخت‌تر می‌شود و احتمال شکست آن بیشتر است. ما می‌توانیم از طریق توسعه تکراری، بازبینی فنی و ادغام مداوم شفافیت پروژه را افزایش دهیم.
اقدامات پیشگیرانه:
- توسعه تکراری با استفاده از یک مدل توسعه تکراری، فرآیند تحویل محصول به چندین مرحله تقسیم می‌شود و به تدریج بر اساس عملکردها تحویل داده می‌شود.
- بازبینی فنی بخش مهمی از تضمین کیفیت نرم‌افزار است. بازبینی فنی شامل بررسی کد، بازبینی جلسه و بازبینی همتا است. بررسی کد می‌تواند یک بررسی متقابل بین توسعه‌دهندگان یا بررسی توسعه‌دهندگان عادی توسط توسعه‌دهندگان ارشد باشد؛ بازبینی جلسه معمولاً حداقل هر دو هفته یک بار انجام می‌شود و زمان هر بررسی نباید خیلی طولانی باشد که این یک تضمین مهم برای موفقیت پروژه است.
- ادغام مداوم می‌تواند فرآیند نهایی ادغام و راه‌اندازی بزرگ‌مقیاس را به پیشرفت توسعه هفتگی و روزانه پروژه تقسیم کند. به طوری که هر کسی در پروژه بتواند در هر زمان پیشرفت کلی فعلی را درک کند و به سرعت مشکلات موجود در فرآیند ادغام را پیدا و حل کند.
3. نوآوری فناورییک فعالیت فناوری و اقتصادی اکتشافی و خلاقانه است. در فرآیند توسعه، معرفی فناوری‌های جدید به طور اجتناب‌ناپذیری با ریسک‌های مختلفی مواجه خواهد شد. اقداماتی مانند توسعه نرم‌افزار به شکل T و پروتوتایپ‌سازی با فناوری جدید با داستان‌های کاربری اسپایک.
4. مسائل عملکردی— به دلیل کمبود بینش طراحی نرم‌افزار، مشکلات عملکردی معمولاً پس از استقرار سیستم یا استفاده از یک سیستم جدید برای مدتی بروز می‌کنند. مشکلات عملکردی معمولاً به کارهای بهینه‌سازی زیادی نیاز دارند یا حتی ممکن است نیاز به طراحی مجدد جزئی یا جامع داشته باشند. نه کاربران و نه توسعه‌دهندگان نمی‌خواهند با مشکلات عملکردی مواجه شوند. تیم باید از این مشکل آگاه باشد، برنامه‌ریزی و آزمایش عملکرد را در طول فرآیند توسعه پیاده‌سازی کند و نیازمندی‌های عملکردی را در نیازمندی‌های غیرعملکردی گنجانده شود.
5. مسائل قابلیت استفادهقابلیت استفاده نرم‌افزار شامل عوامل زیادی است، از جمله اینکه آیا نرم‌افزار کارآمد است، یادگیری آن آسان است، به خاطر سپردن آن آسان است، خوشایند است و اشتباه کردن در آن آسان نیست. اغلب به دلیل قابلیت استفاده ضعیف نرم‌افزار، کاربران ناراضی هستند و حتی ممکن است از بازار حذف شوند. در توسعه پروژه، باید به مسائل قابلیت استفاده توجه شود تا از ریسک‌های قابلیت استفاده نرم‌افزار جلوگیری شود.
ساختار شکست ریسک
ما می‌توانیم از ساختار شکست ریسک برای طبقه‌بندی ریسک‌های بالقوه در جنبه‌های مختلف استفاده کنیم:
ساختار شکست ریسک، تجزیه سلسله‌مراتبی ریسک‌ها است که از عنصر گره ریشه که نمایانگر پروژه است شروع می‌شود و به دسته‌های مختلف ریسک و سپس ریسک‌های سطح پایین‌تر می‌رسد.
علاوه بر ارائه ریسک‌های پروژه در یک ساختار شکست ریسک، امکان ترکیب استفاده از افسانه رنگ در نمایندگی تأثیر ریسک وجود دارد. به مثال ساختار شکست ریسک زیر نگاهی بیندازید، یک افسانه تأثیر با پنج مورد تنظیم شده است که پنج سطح تأثیراتی را که ریسک‌ها ممکن است بر پروژه داشته باشند با پنج کد رنگ متمایز نشان می‌دهد.
در اینجا یک مثال از ساختار شکست ریسک آورده شده است:
(این ساختار شکست ریسک را به صورت آنلاین ویرایش کنید)
ابزارهای مدیریت ریسک زیادی وجود دارد که می‌توانید در ساختاردهی ریسک‌ها استفاده کنید. علاوه بر ساختار شکست ریسک، می‌توانید ازنمودار علت و معلولنیز استفاده کنید (که به عنوان نمودار ماهی نیز شناخته می‌شود).
نتیجه‌گیری
هر چه زودتر ریسک شناسایی و مدیریت شود، احتمال بیشتری دارد که از ریسک جلوگیری شود یا تأثیر ریسک در زمان وقوع کاهش یابد. به ویژه در پروژه‌های پیچیده با تعداد زیادی از شرکت‌کنندگان پروژه، دامنه وسیعی از مشارکت و محتوای فنی بالا باید تقویت شود.
This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.