রিস্ক ম্যানেজমেন্ট ও টিম কোলাবোরেশন
এই পাঠে যা শিখবেন
- রিস্ক এক্সপোজার সূত্র এবং কেন এটি ঝুঁকি অগ্রাধিকারের একটি সহজ, কার্যকর মাপকাঠি
- চারটি স্ট্যান্ডার্ড রিস্ক-রেসপন্স স্ট্র্যাটেজি এবং কখন কোনটি যুক্তিসঙ্গত
- একটি সম্পূর্ণ রিস্ক রেজিস্টার — এক্সপোজার অনুযায়ী সাজানো, প্রতিটি হাতে-যাচাই করা
- এই কোর্সের টিম-কোলাবোরেশন প্র্যাক্টিসগুলো কীভাবে সবই একই "আগে ধরা পড়া সস্তা" থিমের বাস্তবায়ন
১ · রিস্ক ম্যানেজমেন্ট ও এক্সপোজার সূত্র
রিস্ক ম্যানেজমেন্টRisk Managementসম্ভাব্য সমস্যা ঘটার আগেই তা চিহ্নিত, মূল্যায়ন ও প্রশমন করার শৃঙ্খলা। হলো M2/L07-এর স্পাইরাল-মডেল রিস্ক-অ্যানালাইসিস কোয়াড্রান্টের সাধারণীকৃত রূপ — এখন একটি সাধারণ প্রজেক্ট- ম্যানেজমেন্ট প্র্যাক্টিস হিসেবে, যেকোনো SDLC মডেল (M2) ব্যবহার করা হোক না কেন প্রযোজ্য। রিস্ক মূল্যায়নের স্ট্যান্ডার্ড সূত্র (M2/L07-এর একই সূত্রের পুনর্ব্যবহার):
$$risk\_exposure = probability \times impact$$ উচ্চ probability ও উচ্চ impact উভয়যুক্ত ঝুঁকি জরুরি মনোযোগ পাওয়ার যোগ্য; খুব কম probability বা খুব কম impact-এর ঝুঁকি সাধারণত গ্রহণযোগ্য/মনিটরযোগ্য হিসেবে বিবেচিত হতে পারে, সক্রিয় হস্তক্ষেপ ছাড়াই।
২ · চারটি রিস্ক-রেসপন্স স্ট্র্যাটেজি
পরিকল্পনা বদলে ঝুঁকিটি সম্পূর্ণভাবে বাদ দেওয়া — সাধারণত খুব উচ্চ probability ও উচ্চ impact উভয়যুক্ত ঝুঁকির জন্য।
probability অথবা impact কমাতে সক্রিয় পদক্ষেপ নেওয়া — মাঝারি এক্সপোজারের ডিফল্ট, বাস্তবসম্মত পন্থা।
ঝুঁকিটি অন্য পক্ষের কাছে সরিয়ে দেওয়া (যেমন ইন্স্যুরেন্স, বা ঝুঁকিপূর্ণ অংশ আউটসোর্স করা) — সাধারণত কম-probability কিন্তু উচ্চ-impact ("বিমাযোগ্য") ঝুঁকির জন্য উপযুক্ত।
সচেতনভাবে সিদ্ধান্ত নেওয়া যে ঝুঁকিটি যথেষ্ট কম, তাই শুধু মনিটর করা হবে, সক্রিয় হস্তক্ষেপ ছাড়াই — L51-এর "সচেতন, ট্র্যাক করা টেকনিক্যাল ডেট"-এর সৎ ফ্রেমিং-এর সরাসরি পুনর্ব্যবহার।
৩ · একটি রিস্ক রেজিস্টার — সাজানো ও যাচাইকৃত
নিচের কোড সেলে একটি Risk ক্লাস ও recommend_response() ফাংশন দিয়ে ৫টি বাস্তব
প্রজেক্ট-ঝুঁকির একটি রেজিস্টার বানানো হয়েছে — প্রতিটির এক্সপোজার সত্যিকারের সূত্র দিয়ে গণনা করা, এবং
চারটি স্ট্র্যাটেজিই (Avoid, Mitigate, Transfer, Accept) অন্তত একবার সুপারিশ করা হয়েছে বাস্তব উদাহরণ দিয়ে।
class Risk:
def __init__(self, description, probability, impact):
self.description = description
self.probability = probability # 0-1
self.impact = impact # 1-10 স্কেল
def risk_exposure(self):
return self.probability * self.impact
def recommend_response(risk, exposure_threshold):
exposure = risk.risk_exposure()
if risk.probability >= 0.6 and exposure >= exposure_threshold:
return "Avoid" # উচ্চ probability + উচ্চ এক্সপোজার -- পরিকল্পনা বদলে বাদ দাও
if risk.impact >= 8 and risk.probability < 0.3:
return "Transfer" # কম-probability, উচ্চ-impact -- "বিমাযোগ্য" ধরনের ঝুঁকি
if exposure <= 1.2:
return "Accept" # যথেষ্ট কম -- সক্রিয় হস্তক্ষেপ ছাড়াই মনিটর করা যথেষ্ট
return "Mitigate" # ডিফল্ট -- probability/impact সক্রিয়ভাবে কমানোর চেষ্টা
register = [
Risk("মূল ডেভেলপার প্রজেক্ট ছেড়ে দেওয়া (bus factor)", probability=0.3, impact=9),
Risk("থার্ড-পার্টি পেমেন্ট গেটওয়ের আউটেজ", probability=0.2, impact=8),
Risk("শেষ মুহূর্তে বড় রিকোয়ারমেন্ট পরিবর্তন", probability=0.8, impact=7),
Risk("নতুন ফিচারে ছোট UI অ্যালাইনমেন্ট বাগ", probability=0.5, impact=2),
Risk("টিমের এক সদস্য অল্প সময়ের জন্য ছুটিতে যাওয়া", probability=0.6, impact=4),
]
EXPOSURE_THRESHOLD = 5.0
# এক্সপোজার অনুযায়ী descending সাজানো
register_sorted = sorted(register, key=lambda r: r.risk_exposure(), reverse=True)
print(f"{'ঝুঁকি':48} | {'P':>4} | {'I':>3} | {'Exposure':>8} | রেসপন্স")
print("-" * 90)
for risk in register_sorted:
exposure = risk.risk_exposure()
response = recommend_response(risk, EXPOSURE_THRESHOLD)
print(f"{risk.description:48} | {risk.probability:>4} | {risk.impact:>3} | {exposure:>8.2f} | {response}")
0.8×7=5.6, bus factor 0.3×9=2.7,
ছুটি-ঝুঁকি 0.6×4=2.4, পেমেন্ট-আউটেজ 0.2×8=1.6, UI-বাগ 0.5×2=1.0 —
descending ক্রম: 5.6 > 2.7 > 2.4 > 1.6 > 1.0 (সঠিক)। রেসপন্স: রিকোয়ারমেন্ট-পরিবর্তন
(probability 0.8≥0.6 এবং exposure 5.6≥5.0) → Avoid। পেমেন্ট-আউটেজ (impact 8≥8, probability 0.2<0.3) →
Transfer। bus factor (impact 9≥8 কিন্তু probability 0.3, যা <0.3 শর্ত পূরণ করে না) ও ছুটি-ঝুঁকি
(কোনো শর্তই পূরণ করে না) → ডিফল্ট Mitigate। UI-বাগ (exposure 1.0≤1.2) → Accept। চারটি স্ট্র্যাটেজিই
বাস্তব উদাহরণে ব্যবহৃত হয়েছে।
৪ · টিম কোলাবোরেশন — একই থিমের পুনরাবৃত্তি
এই কোর্সের একাধিক প্র্যাক্টিস — M2/L09-এর স্ট্যান্ডআপ (ব্লকার আগেভাগে সারফেস করে), M9/L40-এর PR রিভিউ কালচার, M11/L52-এর গঠনমূলক ফিডব্যাক নর্ম — সবই মূলত সমস্যা (ঝুঁকি) আগেভাগে সারফেস করার একেকটি মেকানিজম, যখন সেগুলো ঠিক করা সবচেয়ে সস্তা — L02, L51, L53, L55-এ বারবার ফিরে আসা একই "আগে ধরা পড়লে সস্তা" থিমের একটি চূড়ান্ত, কোর্স-ব্যাপী সিন্থেসিস পয়েন্ট এটি।
রিস্ক ম্যানেজমেন্ট মানে ঝুঁকি শূন্যে নামানো নয় (যা প্রায়ই অবাস্তব বা অতিরিক্ত ব্যয়বহুল) — বরং প্রতিটি ঝুঁকিকে সচেতনভাবে চিহ্নিত করে, এক্সপোজার অনুযায়ী অগ্রাধিকার দিয়ে, সঠিক স্ট্র্যাটেজি (Avoid/Mitigate/ Transfer/Accept) বেছে নেওয়া — যাতে কোনো ঝুঁকিই "চোখের আড়ালে" অব্যবস্থাপিতভাবে পড়ে না থাকে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ উপরের রেজিস্টারে "bus factor" ঝুঁকিটি Transfer না হয়ে Mitigate সুপারিশ পেল কেন — এটি কি যুক্তিসঙ্গত?
হ্যাঁ, বাস্তবসম্মতভাবে যুক্তিসঙ্গত — bus factor ঝুঁকি সত্যিকার অর্থে "ট্রান্সফার" করা কঠিন (কোনো ইন্স্যুরেন্স কোম্পানি একজন ডেভেলপারের জ্ঞান ফিরিয়ে দিতে পারবে না), কিন্তু ডকুমেন্টেশন লেখা, পেয়ার প্রোগ্রামিং করা, বা কোড রিভিউয়ের (M11/L52) মাধ্যমে জ্ঞান ছড়িয়ে দেওয়া — এই সবই probability/impact সক্রিয়ভাবে কমানোর প্রকৃত পদক্ষেপ, যা ঠিক Mitigate-এর সংজ্ঞা।
প্র ০২ পেমেন্ট গেটওয়ে আউটেজ ঝুঁকিটির exposure (1.6) UI-বাগের চেয়ে (1.0) বেশি হলেও, কেন এটি "Accept" না হয়ে "Transfer" পেল?
কারণ recommend_response-এর শর্তগুলো ক্রমানুসারে চেক হয় — Transfer-এর শর্ত
(impact≥8 এবং probability<0.3) Accept-এর শর্ত (exposure≤1.2) চেক করার আগেই পূরণ হয়ে যায়, তাই
Transfer আগে রিটার্ন হয়। এটি দেখায় শুধু exposure সংখ্যাই যথেষ্ট নয় — impact ও probability-এর নির্দিষ্ট
কম্বিনেশনও গুরুত্বপূর্ণ প্রেক্ষাপট দেয় (একটি বিরল কিন্তু ভয়াবহ ঘটনা সবসময় "কম exposure" বলে উপেক্ষা
করার মতো নয়)।
প্র ০৩ M2/L09-এর ডেইলি স্ট্যান্ডআপ কীভাবে একটি "রিস্ক ম্যানেজমেন্ট" মেকানিজম, যদিও এটি সেই নামে পরিচিত নয়?
স্ট্যান্ডআপে প্রতিটি সদস্য তার ব্লকার (আটকে থাকার কারণ) প্রতিদিন জানায় — একটি ব্লকার মূলত একটি ঝুঁকি যা ইতিমধ্যে বাস্তবে দেখা দিয়েছে বা দিতে যাচ্ছে। প্রতিদিন এই তথ্য সবার সামনে আসায়, সমস্যাটি একদিনের মধ্যেই টিমের নজরে আসে, সপ্তাহ পরে নয় — ঠিক এই পাঠের "আগে ধরা পড়লে সস্তা" নীতিরই একটি দৈনন্দিন, হালকা-ওজনের বাস্তবায়ন।
অনুশীলন
-
চিন্তা করুন: একটি ঝুঁকি probability=0.1, impact=3 হলে তার exposure হাতে-কলমে গণনা করুন, এবং
recommend_responseকোন স্ট্র্যাটেজি সুপারিশ করবে তা ব্যাখ্যা করুন।exposure = 0.1 × 3 = 0.3। প্রথম শর্ত (probability≥0.6) মিথ্যা, দ্বিতীয় শর্ত (impact≥8) মিথ্যা, তৃতীয় শর্ত (exposure≤1.2) সত্য — তাই
recommend_response"Accept" সুপারিশ করবে, যেহেতু এই ঝুঁকি যথেষ্ট কম যে সক্রিয় হস্তক্ষেপ ছাড়াই শুধু মনিটর করাই যুক্তিসঙ্গত। -
পরীক্ষা করুন: উপরের কোড সেলের রেজিস্টারে একটি ষষ্ঠ
Risk(আপনার নিজের বর্ণনা, probability ও impact দিয়ে) যোগ করে Run চেপে দেখুন এটি সাজানো তালিকায় ঠিক কোথায় বসে এবং কোন রেসপন্স পায়।যেহেতু
sorted(register, key=lambda r: r.risk_exposure(), reverse=True)প্রতিবার সম্পূর্ণ তালিকা নতুন করে সাজায়, নতুন ঝুঁকিটি তার এক্সপোজার স্কোর অনুযায়ী স্বয়ংক্রিয়ভাবে সঠিক অবস্থানে বসবে — বিদ্যমান পাঁচটির মধ্যে কোথাও, তার exposure মান অন্যদের তুলনায় কত বড় বা ছোট তার উপর নির্ভর করে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৮টি পাঠ কোর্সের একদম শেষ পাঠ — চূড়ান্ত ক্যাপস্টোন প্রজেক্ট আসছে।
- স্পাইরাল মডেল L07 এই পাঠের risk_exposure সূত্রের মূল উৎস — SDLC-এর মধ্যে রিস্ক-অ্যানালাইসিস কোয়াড্রান্ট।
- ক্যাপস্টোন — সম্পূর্ণ প্রজেক্ট সিমুলেশন L58 · চূড়ান্ত পাঠ পুরো কোর্সের সবকিছু একসাথে — একটি সম্পূর্ণ, শেষ-থেকে-শুরু প্রজেক্ট সিমুলেশন।