အခန်း ၁၀ :: People, Process, and Planning

Software Engineering ဆိုသည်မှာ Code ရေးရုံသက်သက် မဟုတ်ပါ။ Code ကောင်းတစ်ခု ရေးဖို့အတွက် Engineering Skill လိုသလို၊ Project တစ်ခု အောင်မြင်ဖို့အတွက် Management Skill လိုအပ်ပါသည်။

"The biggest hurdle is the people and the process change that goes with it. It's not the technology."

"Project တစ်ခု ကျရှုံးရခြင်းသည် နည်းပညာကြောင့် ဖြစ်လေ့မရှိဘဲ၊ လူများ (People) နှင့် လုပ်ငန်းစဉ်များ (Process) ကြောင့်သာ ဖြစ်လေ့ရှိသည်။"

Phil Davis (Vice President of Google Cloud)

Developer အတော်များများက "ငါက Code ပဲ ရေးမှာပါ၊ Management နားလည်စရာ မလိုပါဘူး" ဟု ယူဆတတ်ကြသည်။ သို့သော် Senior Level သို့ ရောက်လာသောအခါ မိမိရေးသော Code ထက်၊ Team တစ်ခုလုံး မည်သို့ ရှေ့ဆက်မည်နည်း ဆိုသည်ကို ဦးဆောင်ရသည့် အခန်းကဏ္ဍက ပိုအရေးပါလာပါသည်။

၁၀.၁ The Project Management Triangle (The Iron Triangle)

Project Manager တစ်ယောက် ဖြစ်လာပြီဆိုလျှင် ပထမဆုံး နားလည်ထားရမည့် သီအိုရီမှာ Project Management Triangle သို့မဟုတ် Iron Triangle ဖြစ်ပါသည်။ Project တစ်ခုတွင် ကန့်သတ်ချက် (Constraint) ၃ ခု အမြဲ ရှိနေပါသည်။

  1. Scope (အတိုင်းအတာ): Project မှာ ဘာ Feature တွေ ပါမလဲ။ (ဥပမာ - Login, Payment, Report ပါမယ်)။
  2. Time (အချိန်): ဘယ်တော့ ပြီးမလဲ။ (Schedule)
  3. Cost (ကုန်ကျစရိတ်): လူအင်အား ဘယ်လောက်သုံးမလဲ၊ ဘတ်ဂျက် ဘယ်လောက်ရှိလဲ။ (Resources)

ဤ ၃ ခု၏ အလယ်တွင် Quality (အရည်အသွေး) ရှိနေပါသည်။

Quality သည် Constraint မဟုတ်ဘဲ Outcome ဖြစ်သည်။ Scope, Time, Cost ကို ဘယ်လို ဆုံးဖြတ်လဲဆိုတဲ့ ရလဒ်အဖြစ် Quality က ထွက်လာခြင်း ဖြစ်ပါသည်။

graph TD
    subgraph "The Iron Triangle"
        S((Scope)) --- T((Time))
        T --- C((Cost))
        C --- S
        
        S --- Q{Quality}
        T --- Q
        C --- Q
    end
    
    style Q fill:#ffeb3b,stroke:#fbc02d,stroke-width:2px

"Pick Two" Concept

လောကကြီးတွင် "Fast, Good, Cheap. Pick Two." (မြန်ချင်တယ်၊ ကောင်းချင်တယ်၊ ဈေးသက်သာချင်တယ်... ၃ ခုလုံးတော့ မရဘူး၊ ၂ ခုပဲ ရွေး) ဆိုသော စကားရှိပါသည်။

Project Manager တစ်ယောက်၏ တာဝန်မှာ ဤသုံးပွင့်ဆိုင် ဆက်ဆံရေးကို မျှတအောင် ထိန်းညှိပေးခြင်း (Balancing Constraints) ဖြစ်ပါသည်။

၁၀.၂ Software Estimation: The Cone of Uncertainty

Software Project များကို ခန့်မှန်းရခြင်း (Estimation) သည် မိုးလေဝသ ခန့်မှန်းရသကဲ့သို့ ခက်ခဲပါသည်။ "Login page ရေးဖို့ ဘယ်လောက်ကြာမလဲ" ဟု မေးလျှင် "၂ ရက်" ဟု ဖြေမိမည်။ သို့သော် တကယ်ရေးသောအခါ Error တက်ခြင်း၊ Requirement ပြောင်းခြင်းတို့ကြောင့် ၅ ရက် ကြာသွားနိုင်သည်။

Project အစပိုင်းတွင် မသေချာမှု (Uncertainty) အများဆုံး ဖြစ်ပြီး၊ Project ပြီးခါနီးမှသာ အချိန်အတိအကျကို သိရှိနိုင်ပါသည်။ ၎င်းကို Cone of Uncertainty ဟု ခေါ်ပါသည်။

၁၀.၂.၁ Traditional Estimation (COCOMO)

ဟိုးအရင်က COCOMO (Constructive Cost Model) ကို သုံးလေ့ရှိသည်။ ၎င်းသည် Project ၏ အရွယ်အစား (Lines of Code) ပေါ်မူတည်ပြီး လူဘယ်နှစ်ယောက်လိုမယ်၊ ဘယ် နှစ်လ လောက်ကြာမယ် ဆိုတာကို သင်္ချာ Formula နှင့် တွက်ချက်ခြင်း ဖြစ်သည်။ ယနေ့ခေတ် Agile / Product-driven Development များတွင် COCOMO ကဲ့သို့ LOC-based Estimation များသည် အလွန်အကန့်အသတ်ရှိသော်လည်း၊ Large-scale / Government Project များတွင် Reference Model အဖြစ် အသုံးချနေဆဲ ဖြစ်ပါသည်။

၁၀.၂.၂ Agile Estimation (Story Points & Planning Poker)

Agile တွင် "အချိန် (နာရီ)" ဖြင့် ခန့်မှန်းမည့်အစား "Story Points" ဖြင့် ခန့်မှန်းကြပါသည်။

Story Point ဆိုတာ ဘာလဲ?

Task တစ်ခု၏ ခက်ခဲမှု (Complexity)၊ လုပ်ရမည့် ပမာဏ (Effort) နှင့် မသေချာမှု (Uncertainty) တို့ကို ပေါင်းစပ်ပြီး ပေးထားသော ရမှတ် ဖြစ်သည်။

အမှတ်ပေးရာတွင် Fibonacci Series (1, 2, 3, 5, 8, 13, 21...) ကို သုံးလေ့ရှိသည်။ ဘာကြောင့် 1, 2, 3, 4 မဟုတ်ရသလဲဆိုတော့ Task ကြီးလေလေ၊ မှန်းရခက်လေလေ ဖြစ်တာကြောင့် ကွာဟမှု ကြီးကြီး (5 ပြီးရင် 8, 8 ပြီးရင် 13) ထားခြင်း ဖြစ်သည်။

Planning Poker ကစားနည်း

Developer တစ်ယောက်တည်းက ဆုံးဖြတ်လျှင် မှားနိုင်သဖြင့် Team လိုက် ဆုံးဖြတ်သော နည်းလမ်းဖြစ်သည်။

  1. User Story တစ်ခုကို ဖတ်ပြသည်။ (ဥပမာ - "Login with Facebook")

  2. Team Member တိုင်းက မိမိထင်သော Story Point ကတ်ပြားကို မှောက်ထားသည်။

  3. အားလုံး တပြိုင်နက်တည်း ကတ်ပြားကို လှန်ပြသည်။

  4. သဘောထားကွဲလွဲမှု: တစ်ယောက်က 3 ပေးပြီး၊ တစ်ယောက်က 13 ပေးထားလျှင် အဘယ်ကြောင့် ကွာဟရသလဲ ဆွေးနွေးကြသည်။ (Senior က လွယ်တယ်ထင်ပေမယ့် Junior က မလုပ်တတ်လို့ ခက်တယ် ထင်တာ ဖြစ်နိုင်သည်)။

  5. ညှိနှိုင်းပြီး အမှတ်တစ်ခု သတ်မှတ်သည်။

ဤနည်းလမ်းသည် Team အတွင်း နားလည်မှု လွဲမှားခြင်းများကို ညှိနှိုင်းပေးရာ ရောက်ပါသည်။

၁၀.၃ Planning and Tracking

Velocity (အရှိန်အဟုန်)

Velocity ဆိုသည်မှာ Sprint တစ်ခု (ဥပမာ - ၂ ပတ်) အတွင်း Team က Story Point စုစုပေါင်း ဘယ်လောက် ပြီးအောင် လုပ်နိုင်သလဲ ဆိုသည့် နှုန်းထား ဖြစ်သည်။

ဥပမာ -

Manager အနေဖြင့် နောက် Sprint မှာ အလုပ်ဘယ်လောက် လက်ခံလို့ရမလဲ (Capacity Planning) တွက်ရာတွင် ဤ Velocity ကို အသုံးပြုရသည်။

Velocity သည် KPI မဟုတ်ပါ။

Team တစ်ခုနှင့် တစ်ခု Velocity နှိုင်းယှဉ်၍ မရပါ။ ဒီအချက်က Team တစ်ခုလုံး အနေနဲ့ သေချာနားလည်ထားဖို့ လိုပါတယ်။

Anti-pattern: Velocity ကို မြှင့်ရန် Story Point ကို လိုက်လျောညှိနှိုင်းခြင်း၊ သို့မဟုတ် Team အချင်းချင်း Velocity နှိုင်းယှဉ်ခြင်းသည် Agile Anti-pattern ဖြစ်ပါသည်။

Burndown Charts

Sprint တစ်ခုအတွင်း အလုပ်တွေ တကယ် ပြီးနေရဲ့လား စောင့်ကြည့်ရန် Burndown Chart ကို သုံးသည်။

xychart-beta
    title "Sprint Burndown Chart"
    x-axis ["Day 1", "Day 2", "Day 3", "Day 4", "Day 5", "Day 6", "Day 7", "Day 8", "Day 9", "Day 10"]
    y-axis "Story Points" 0 --> 50
    line [50, 45, 40, 35, 30, 25, 20, 15, 10, 5, 0]
    line [50, 48, 48, 40, 35, 38, 30, 20, 10, 5, 0]

၁၀.၄ Team Structure & Engineering Culture

Software Engineering တွင် Team များကို ဖွဲ့စည်းပုံ (Structure) နှင့် လုပ်ပိုင်ခွင့် (Ownership) ပေါ်မူတည်၍ အဓိက (၃) မျိုး ခွဲခြား သတ်မှတ်နိုင်ပါသည်။

၁၀.၄.၁ Team Topologies Evolution

၁။ Component Teams (Silo Teams)

System Architecture ၏ အစိတ်အပိုင်းတစ်ခု (Component/Layer) ကိုသာ သီးသန့်တာဝန်ယူသော ဖွဲ့စည်းပုံဖြစ်သည်။
(ဥပမာ - Frontend Team, Backend Team, QA Team)

၂။ Cross-Functional Feature Teams

Feature တစ်ခု (ဥပမာ - Checkout Flow) ကို ပြီးစီးအောင် လုပ်ဆောင်နိုင်ရန် လိုအပ်သော ကျွမ်းကျင်သူများ (Specialists) အားလုံးကို တစ်ဖွဲ့တည်းတွင် စုစည်းထားခြင်းဖြစ်သည်။

၃။ Stream-Aligned Teams (Modern & Autonomous)

ဒါက Modern Engineering Organization များ၏ စံထားလောက်သော ဖွဲ့စည်းပုံ (Team Topologies Standard) ဖြစ်သည်။ Business Flow သို့မဟုတ် User Journey တစ်ခုလုံးကို (Idea မှ Production အထိ) လွတ်လပ်စွာ တာဝန်ယူ လုပ်ဆောင်နိုင်သော အဖွဲ့ဖြစ်သည်။

ဤပုံစံတွင် Full Stack Culture သည် မရှိမဖြစ် လိုအပ်ချက် (Enabler) ဖြစ်လာသည်။

Stream-Aligned Team ၏ အဓိက လက္ခဏာရပ်များ:

  1. Own the Flow: Feature တစ်ခု ရေးသားရုံသာမက၊ အသုံးပြုသူလက်ထဲ ရောက်သည်အထိ (Build, Test, Deploy, Operate) လုပ်ငန်းစဉ် တစ်လျှောက်လုံးကို ပိုင်ဆိုင်သည်။
  2. Reduce Dependencies: "Backend API မပြီးသေးလို့ Frontend ရေးမရသေးဘူး" ဆိုသည့် မလိုအပ်သော လူမှုပိုင်းဆိုင်ရာ မှီခိုရမှု (Human Handovers) များကို အတတ်နိုင်ဆုံး လျှော့ချသည်။ Developer တစ်ယောက်သည် (Security & Compliance ဘောင်အတွင်းမှ) လိုအပ်လျှင် Database မှ UI အထိ Vertical Slice ဝင်ရောက် လုပ်ကိုင်နိုင်သည်။
  3. T-Shaped Skills: Developer တိုင်းသည် နေရာစုံကို နားလည်ထားပြီး (Broad knowledge)၊ မိမိအားသန်ရာ တစ်နေရာတွင် ကျွမ်းကျင်သူ (Deep expertise) ဖြစ်လာစေရန် အားပေးသည်။

၁၀.၄.၂ The Role of "Full Stack" in Stream-Aligned Teams

Stream-Aligned Team တစ်ခု ထိရောက်စွာ လည်ပတ်နိုင်ရန် Full Stack Mindset ကို အောက်ပါအတိုင်း နားလည်ထားရပါမည်။

"Mastery" မဟုတ်ပါ၊ "Capability" ဖြစ်သည်
Full Stack Developer ဆိုသည်မှာ အရာရာကို ကျွမ်းကျင်သော "One Man Army" မဟုတ်ပါ။ မိမိ၏ Core Skill (ဥပမာ- Backend) အပြင် အခြားအပိုင်းများ (Frontend, DevOps) ကိုပါ အလုပ်ဖြစ်အောင် ဝင်ရောက်လုပ်ကိုင်နိုင်စွမ်း (Capability) ရှိသူကို ဆိုလိုသည်။

DevOps & Infrastructure ၏ အခန်းကဏ္ဍ
Team ၏ Autonomy (လွတ်လပ်စွာ စီမံခန့်ခွဲခွင့်) အတွက် DevOps Skill သည် အရေးပါသည်။

graph TD
    subgraph "Evolution to Stream-Aligned Teams"
        direction TB
        
        subgraph "1. Component (Silo)"
            FE[Frontend Team] -.->|Blocking Dependency| BE[Backend Team]
        end

        subgraph "2. Feature Team"
            FT[FE Specialist + BE Specialist]
            note2[Sit together, but separate tasks]
        end

        subgraph "3. Stream-Aligned Team (Flow)"
            SAT[Stream-Aligned Team]
            
            SAT -->|Owns| Biz[Business Value Stream]
            SAT -->|Capabilities| FS[Full Stack Mindset]
            SAT -->|Support| P[Platform/DevOps Expert]
            
            FS -->|Reduces| Wait[Dependencies]
            P -->|Enables| FS
        end
    end
    
    style SAT fill:#ccffcc,stroke:#333,stroke-width:2px

Summary:
Engineering Culture သည် "Stream-Aligned" ကို ဦးတည်သည်။ ဆိုလိုသည်မှာ သင်သည် Business Value တစ်ခုကို အစအဆုံး ဖန်တီးပေးနိုင်သော အဖွဲ့ ၏ အစိတ်အပိုင်း ဖြစ်သည်။ ထိုသို့ဖြစ်လာစေရန် Full Stack Mindset (Learn & Adapt) နှင့် DevOps Capabilities (You Build It, You Run It - with platform support) တို့ကို မွေးမြူထားရန် လိုအပ်ပါသည်။

၁၀.၄.၃ Tuckman's Stages of Group Development

Team Structure ကောင်းမွန်ရုံဖြင့် High-performance team တစ်ခု ချက်ချင်း ဖြစ်မလာနိုင်ပါ။ Bruce Tuckman ၏ သီအိုရီအရ Team တစ်ခုသည် အောက်ပါ အဆင့် (၄) ဆင့်ကို မဖြစ်မနေ ဖြတ်ကျော်ရလေ့ရှိသည်။

1. Forming (စုဖွဲ့ခြင်း)
Team အသစ်စဖွဲ့ချိန် သို့မဟုတ် လူသစ်များ စတင်တွေ့ဆုံချိန်ဖြစ်သည်။

2. Storming (မုန်တိုင်းထန်ခြင်း - ပဋိပက္ခကာလ)
လက်တွေ့အလုပ် စလုပ်သောအခါ အမြင်မတူမှုများ၊ အငြင်းပွားမှုများ စတင်ဖြစ်ပေါ်သည်။

3. Norming (စည်းမျဉ်းချမှတ်ခြင်း)
ပဋိပက္ခများကို ကျော်လွှားပြီး အလုပ်လုပ်မည့် ပုံစံများကို သဘောတူညီမှု ရယူနိုင်သည့် အဆင့်ဖြစ်သည်။

4. Performing (စွမ်းဆောင်ရည်ပြခြင်း)
Team သည် အသားကျသွားပြီး အလုပ်ကို တွင်တွင်ကျယ်ကျယ် လုပ်ဆောင်လာနိုင်သည့် အဆင့်ဖြစ်သည်။

Note: Team Structure ပြောင်းလိုက်တိုင်း သို့မဟုတ် လူအသစ် ဝင်လာတိုင်း Team သည် Forming သို့မဟုတ် Storming အဆင့်သို့ ပြန်လည်ရောက်ရှိသွားတတ်သည်ကို သတိပြုရပါမည်။

၁၀.၅ Stakeholder Management & RACI Matrix

Stakeholder ဆိုသည်မှာ Project နှင့် ပတ်သက်ဆက်နွယ်သူ အားလုံး (Customer, Boss, Team Member, End User) ဖြစ်သည်။ သူတို့ကို စီမံခန့်ခွဲရာတွင် "ဘယ်သူက ဘာလုပ်ရမလဲ" ရှင်းလင်းဖို့ RACI Matrix ကို သုံးလေ့ရှိသည်။

Task Project Manager Developer Architect Client
Define Requirements A C C R
Design Architecture A C R I
Write Code A R C I
User Testing A I I R

၁၀.၆ Project Management in the AI Era (AI ခေတ် စီမံခန့်ခွဲမှု)

၂၀၂၅ ခုနှစ် အလွန် Software Project Management သည် ယခင်နှင့် လုံးဝ မတူညီတော့ပါ။ AI Coding Assistants (Copilot, Cursor) များ၊ Vibe Coding ပုံစံများ ပေါ်ပေါက်လာခြင်းက စီမံခန့်ခွဲမှုပုံစံကိုပါ ပြောင်းလဲစေခဲ့ပါသည်။

၁။ Estimation ၏ သဘောတရား ပြောင်းလဲလာခြင်း

ယခင်က "Login Form ရေးရန် ၃ ရက်ကြာမည်" ဟု ခန့်မှန်းခဲ့လျှင်၊ AI ကြောင့် "၃ နာရီ" သာ ကြာတော့မည့် အနေအထား ဖြစ်လာသည်။ သို့သော် သတိပြုရန် အချက်များမှာ -

၂။ The "Vibe Coding" Challenge

Developer များသည် Syntax တစ်လုံးချင်းစီ ရိုက်နေတော့မည် မဟုတ်ဘဲ၊ မိမိလိုချင်သော "Vibe" (Intention) ကို Prompt ရိုက်၍ တည်ဆောက်လာကြသည်။

၃။ AI-Assisted Management

Project Manager ကိုယ်တိုင်လည်း AI ကို အသုံးပြုလာရပါမည်။

၄။ Hidden Risks in AI Era

AI ကို အသုံးပြုခြင်းသည် ကောင်းကျိုးများစွာ ရှိသော်လည်း အောက်ပါ Hidden Risk များကို သတိပြုရပါမည်။

၁၀.၇ Risk Management (အန္တရာယ် စီမံခန့်ခွဲမှု)

Project တစ်ခုတွင် "ဖြစ်လာမှ ရှင်းမယ်" (Firefighting) လုပ်တာထက်၊ "မဖြစ်ခင် ကြိုကာမယ်" (Risk Management) က ပိုကောင်းပါသည်။

Risk အမျိုးအစားများ:

  1. Technical Risk: သုံးမည့် နည်းပညာက ခက်လွန်းနေတာ၊ Server မနိုင်တာ။

  2. Schedule Risk: အချိန်မှီ မပြီးနိုင်တာ။

  3. Resource Risk: အဓိက Developer အလုပ်ထွက်သွားတာ၊ နေမကောင်းဖြစ်တာ။

Risk Response Strategies:

၁၀.၈ Change & Configuration Management

Change Management

Requirement တစ်ခု ပြောင်းလဲတိုင်း "ရတယ်.. လုပ်ပေးမယ်" ဟု ချက်ချင်း လက်ခံ၍ မရပါ။ Scope Creep ဖြစ်ပြီး Project ပျက်စီးသွားနိုင်သည်။ ပြောင်းလဲမှု တစ်ခု လာတိုင်း -

  1. Impact Analysis လုပ်ရမည်။ (ဒါပြင်ရင် ဘယ်လောက်ကြာမလဲ၊ ဘယ်နေရာတွေ ထိမလဲ)။

  2. Cost/Time ပြန်တွက်ရမည်။

  3. Change Control Board (CCB) သို့မဟုတ် Stakeholder ၏ အတည်ပြုချက် (Approval) ယူပြီးမှ လုပ်ရမည်။

Configuration Management

Code တွေ၊ Document တွေ ဗရပွ မဖြစ်နေစေရန် ထိန်းသိမ်းခြင်း ဖြစ်သည်။

၁၀.၉ Psychological Safety

Google ၏ Project Aristotle လေ့လာမှုအရ စွမ်းဆောင်ရည် အမြင့်မားဆုံး Team များတွင် တွေ့ရသည့် အဓိက အချက်မှာ "နည်းပညာတော်ခြင်း" မဟုတ်ဘဲ Psychological Safety (စိတ်ပိုင်းဆိုင်ရာ လုံခြုံမှု) ရှိခြင်း ဖြစ်သည်။

ဆိုလိုသည်မှာ -

Manager တစ်ယောက်အနေဖြင့် Team Member များကို အကြောက်တရားဖြင့် မဟုတ်ဘဲ၊ ယုံကြည်မှုဖြင့် ဦးဆောင်ခြင်းသည် Project အောင်မြင်မှု၏ သော့ချက် ဖြစ်ပါသည်။

Summary

Software Project Management သည် ကျယ်ပြန့်သော ဘာသာရပ်တစ်ခု ဖြစ်သော်လည်း၊ အထက်ပါ အခြေခံများကို နားလည်ထားခြင်းဖြင့် သင်သည် Code ရေးရုံသာမက Team တစ်ခုလုံးကိုပါ ဦးဆောင်နိုင်သော Software Engineer တစ်ယောက် ဖြစ်လာမည် ဖြစ်သည်။

  • Software Engineering is about People first, then Process, then Tools
  • High-performing teams are designed, not accidentally formed
  • In the AI era, management focus shifts from “writing code” to “validating value”