পাঠ ৫৭ · ৫৮-এর মধ্যে · মডিউল ১৩
Home / Courses / Software Engineering Principles & Git / প্রজেক্ট ম্যানেজমেন্ট ও চূড়ান্ত প্রকল্প

রিস্ক ম্যানেজমেন্ট ও টিম কোলাবোরেশন

Risk management & team collaboration
৮ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • রিস্ক এক্সপোজার সূত্র এবং কেন এটি ঝুঁকি অগ্রাধিকারের একটি সহজ, কার্যকর মাপকাঠি
  • চারটি স্ট্যান্ডার্ড রিস্ক-রেসপন্স স্ট্র্যাটেজি এবং কখন কোনটি যুক্তিসঙ্গত
  • একটি সম্পূর্ণ রিস্ক রেজিস্টার — এক্সপোজার অনুযায়ী সাজানো, প্রতিটি হাতে-যাচাই করা
  • এই কোর্সের টিম-কোলাবোরেশন প্র্যাক্টিসগুলো কীভাবে সবই একই "আগে ধরা পড়া সস্তা" থিমের বাস্তবায়ন

১ · রিস্ক ম্যানেজমেন্ট ও এক্সপোজার সূত্র

রিস্ক ম্যানেজমেন্টRisk Managementসম্ভাব্য সমস্যা ঘটার আগেই তা চিহ্নিত, মূল্যায়ন ও প্রশমন করার শৃঙ্খলা। হলো M2/L07-এর স্পাইরাল-মডেল রিস্ক-অ্যানালাইসিস কোয়াড্রান্টের সাধারণীকৃত রূপ — এখন একটি সাধারণ প্রজেক্ট- ম্যানেজমেন্ট প্র্যাক্টিস হিসেবে, যেকোনো SDLC মডেল (M2) ব্যবহার করা হোক না কেন প্রযোজ্য। রিস্ক মূল্যায়নের স্ট্যান্ডার্ড সূত্র (M2/L07-এর একই সূত্রের পুনর্ব্যবহার):

সূত্র · Formula

$$risk\_exposure = probability \times impact$$ উচ্চ probability ও উচ্চ impact উভয়যুক্ত ঝুঁকি জরুরি মনোযোগ পাওয়ার যোগ্য; খুব কম probability বা খুব কম impact-এর ঝুঁকি সাধারণত গ্রহণযোগ্য/মনিটরযোগ্য হিসেবে বিবেচিত হতে পারে, সক্রিয় হস্তক্ষেপ ছাড়াই।

২ · চারটি রিস্ক-রেসপন্স স্ট্র্যাটেজি

Avoid
পরিকল্পনা বদলে ঝুঁকিটি সম্পূর্ণভাবে বাদ দেওয়া — সাধারণত খুব উচ্চ probability ও উচ্চ impact উভয়যুক্ত ঝুঁকির জন্য।
Mitigate
probability অথবা impact কমাতে সক্রিয় পদক্ষেপ নেওয়া — মাঝারি এক্সপোজারের ডিফল্ট, বাস্তবসম্মত পন্থা।
Transfer
ঝুঁকিটি অন্য পক্ষের কাছে সরিয়ে দেওয়া (যেমন ইন্স্যুরেন্স, বা ঝুঁকিপূর্ণ অংশ আউটসোর্স করা) — সাধারণত কম-probability কিন্তু উচ্চ-impact ("বিমাযোগ্য") ঝুঁকির জন্য উপযুক্ত।
Accept
সচেতনভাবে সিদ্ধান্ত নেওয়া যে ঝুঁকিটি যথেষ্ট কম, তাই শুধু মনিটর করা হবে, সক্রিয় হস্তক্ষেপ ছাড়াই — L51-এর "সচেতন, ট্র্যাক করা টেকনিক্যাল ডেট"-এর সৎ ফ্রেমিং-এর সরাসরি পুনর্ব্যবহার।

৩ · একটি রিস্ক রেজিস্টার — সাজানো ও যাচাইকৃত

নিচের কোড সেলে একটি Risk ক্লাস ও recommend_response() ফাংশন দিয়ে ৫টি বাস্তব প্রজেক্ট-ঝুঁকির একটি রেজিস্টার বানানো হয়েছে — প্রতিটির এক্সপোজার সত্যিকারের সূত্র দিয়ে গণনা করা, এবং চারটি স্ট্র্যাটেজিই (Avoid, Mitigate, Transfer, Accept) অন্তত একবার সুপারিশ করা হয়েছে বাস্তব উদাহরণ দিয়ে।

Python
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-এ বারবার ফিরে আসা একই "আগে ধরা পড়লে সস্তা" থিমের একটি চূড়ান্ত, কোর্স-ব্যাপী সিন্থেসিস পয়েন্ট এটি।

মূল কথা · Key takeaway

রিস্ক ম্যানেজমেন্ট মানে ঝুঁকি শূন্যে নামানো নয় (যা প্রায়ই অবাস্তব বা অতিরিক্ত ব্যয়বহুল) — বরং প্রতিটি ঝুঁকিকে সচেতনভাবে চিহ্নিত করে, এক্সপোজার অনুযায়ী অগ্রাধিকার দিয়ে, সঠিক স্ট্র্যাটেজি (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-এর ডেইলি স্ট্যান্ডআপ কীভাবে একটি "রিস্ক ম্যানেজমেন্ট" মেকানিজম, যদিও এটি সেই নামে পরিচিত নয়?

স্ট্যান্ডআপে প্রতিটি সদস্য তার ব্লকার (আটকে থাকার কারণ) প্রতিদিন জানায় — একটি ব্লকার মূলত একটি ঝুঁকি যা ইতিমধ্যে বাস্তবে দেখা দিয়েছে বা দিতে যাচ্ছে। প্রতিদিন এই তথ্য সবার সামনে আসায়, সমস্যাটি একদিনের মধ্যেই টিমের নজরে আসে, সপ্তাহ পরে নয় — ঠিক এই পাঠের "আগে ধরা পড়লে সস্তা" নীতিরই একটি দৈনন্দিন, হালকা-ওজনের বাস্তবায়ন।

অনুশীলন

  1. চিন্তা করুন: একটি ঝুঁকি 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" সুপারিশ করবে, যেহেতু এই ঝুঁকি যথেষ্ট কম যে সক্রিয় হস্তক্ষেপ ছাড়াই শুধু মনিটর করাই যুক্তিসঙ্গত।

  2. পরীক্ষা করুন: উপরের কোড সেলের রেজিস্টারে একটি ষষ্ঠ Risk (আপনার নিজের বর্ণনা, probability ও impact দিয়ে) যোগ করে Run চেপে দেখুন এটি সাজানো তালিকায় ঠিক কোথায় বসে এবং কোন রেসপন্স পায়।

    যেহেতু sorted(register, key=lambda r: r.risk_exposure(), reverse=True) প্রতিবার সম্পূর্ণ তালিকা নতুন করে সাজায়, নতুন ঝুঁকিটি তার এক্সপোজার স্কোর অনুযায়ী স্বয়ংক্রিয়ভাবে সঠিক অবস্থানে বসবে — বিদ্যমান পাঁচটির মধ্যে কোথাও, তার exposure মান অন্যদের তুলনায় কত বড় বা ছোট তার উপর নির্ভর করে।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
এস্টিমেশন টেকনিক — স্টোরি পয়েন্ট ও প্ল্যানিং পোকার