Skip to main content

Product Backlog ကို ဘယ်လိုကိုင်တွယ်မလဲ

Product Backlog ဆိုတာ Product Team အတွက် ရှေ့ဆက်လုပ်ဆောင်ရမယ့်အရာတွေကို တန်းစီထားတဲ့ List လို့ပြောလို့ရပါတယ်။ Backlog ထဲမှာ Feaures အသစ်တွေပါမယ်၊ Bugs (သို့) Issues တွေ ပါမယ်၊ Idea အကြမ်းဖျင်းတွေလည်း ပါနိုင်သလို Technical နဲ့ပတ်သက်တဲ့ Tasks တွေလည်းပါနိုင်ပါတယ်။ Product Team အတွက် ဆက်လုပ်ရမယ့် အလုပ်တွေအားလုံးကို တစ်နေရာထဲကနေ စုထားတာကြောင့် Sprint Planning တွေမှာ ဒီ Backlog ကိုအခြေခံပြီး ဆွေးနွေး၊ Sprint Backlog ထဲထည့်၊ Tasks တွေခွဲကြရုံပါပဲ။ ဒါကြောင့် Product Backlog က Agile Product Team တွေအတွက် မရှိမဖြစ်အရေးပါတဲ့ အစိတ်အပိုင်းလည်းဖြစ်ပါတယ်။

Product Manager တစ်ယောက်အနေနဲ့ မိမိ Product Backlog ကို အကောင်းဆုံးဘယ်လိုကိုင်တွယ်မလဲနဲ့ Product Backlog နဲ့ပတ်သက်ပြီး သတိထားသင့်တဲ့ အချက်တွေကို ဆွေးနွေးချင်ပါတယ်။


Product Roadmap နဲ့ Product Backlog ဘာကွာလဲ
Product Roadmap နဲ့ Product Backlog နှစ်ခုလုံးက Product Developent အတွက် အရေးပါပြီး တစ်ခုနဲ့တစ်ခုက ချိတ်ဆက်နေပါတယ်။ သို့သော် သူတို့နှစ်ခုက အတူတူပဲလို့တော့ အမှတ်မမှားစေချင်ပါဘူး။ Product Roadmap က Product ရဲ့ Vision နဲ့ ရှေ့ဆက်သွားမယ့် Strategy ကို High Level View အနေနဲ့ ကြည့်နိုင်ဖို့ ရေးဆွဲထားတဲ့ Plan ဖြစ်ပြီး၊ Product Backlog ကတော့ Roadmap အတိုင်းဆက်သွားဖို့ရာ လုပ်ဆောင်ဖို့လိုတဲ့ Tasks တွေကို Priority စီထားတဲ့ List ဖြစ်ပါတယ်။


Image from Roman Pichler’s blog

Product Roadmap ကိုကြည့်ရင် ရှေ့လျှောက် Product က ဘာတွေဆက်လုပ်ပြီး ဘယ်လိုရုပ်လုံးပေါ်နေမလဲ သိစေနိုင်တဲ့ Plan မျိုးပါ။ Product Backlog ကတော့ Development Team အနေနဲ့ ရှေ့လျှောက် ဘယ်လို Task တွေစောင့်နေလဲ သိစေနိုင်တဲ့အရာမျိုးလို့ ဆိုနိုင်ပါတယ်။ Roadmap မှာ များသောအားဖြင့် Features တွေ၊ Major Epic တွေဖြစ်တတ်ပြီး၊ Backlog ကတော့ Agile ရဲ့ User Story တွေ၊ Tasks တွေ၊ Issues တွေဖြစ်ပါတယ်။

Product Roadmap နဲ့ Product Backlog ကွာခြားချက်ကို ရှင်းပြီးနောက်မှာ Product Backlog ကို ဘယ်လိုကိုင်တွယ်မလဲဆိုတာနဲ့ပတ်သက်ပြီး ဆက်ကြည့်ရအောင်။

၁။ Backlog List ထဲစုပြုံထည့်တာမျိုး မလုပ်ပါနဲ့။ ဒါက Product Manager တွေ တော်တော်များများ လုပ်လေ့ရှိတာပါ။ ကော်ဖီသောက်ရင်း ရလာတဲ့ Idea အသစ်တွေ၊ နောက်မှပြင်မယ်လို့ ရွှေ့ထားတဲ့ Bug တွေ၊ Customer Feedback နဲ့ပတ်သက်တဲ့ ပြင်ဆင်မှုတွေ၊ Operation Team က တောင်းဆိုတဲ့ Feature တွေ၊ Development Team နဲ့ ဆွေးနွေးထားတဲ့ Tech Tasks တွေ… အကုန်လုံးကို Backlog ထဲ ပစ်ထည့်ထားတတ်ပါတယ်။ အကျိုးဆက်က အဆုံးမရှိ ရှင်းမပြီးတဲ့ Backlog ကြီး ပိုက်မိနေတာပါပဲ။ “How to say No” ဆောင်းပါးမှာ ရေးခဲ့တဲ့အချက်အတိုင်းပါပဲ.. ကိုယ့် Product နဲ့ မသင့်တော်တဲ့ Feature Request မျိုးဆို အကျိုးသင့်အကြောင်းသင့် ငြင်းလိုက်တာက Backlog ထဲပစ်ထည့်ထားလိုက်တာထပ် ပိုသင့်တော်ပါတယ်။

၂။ Backlog ထဲက Tasks တွေကို Priority စီပါ။ Development Team နဲ့ Stakeholders တွေ မြင်သာအောင် Business အတွက် အရေးအကြီးဆုံး၊ Value အမြင့်ဆုံးတွေကို ထိပ်ဆုံးထားပြီး စီနိုင်သလို၊ Value Effort Matrix မျိုးသုံး Business Value နဲ့ Development Effort ကိုချိန်ထိုးပြီး Priority အထက်အောက် စီနိုင်ပါတယ်။ Value Effort Matrix သုံးနည်းကို Feature Prioritization ဆောင်းပါး မှာ အသေးစိတ်ဖတ်နိုင်ပါတယ်။

၃။ Backlog Grooming (ရှင်းလင်းရေး) ပုံမှန်လုပ်ပါ။ Backlog Grooming ဆိုတာ Product Manager နဲ့ Product Team က လိုအပ်တဲ့သူတွေ (Project Manager, Tech Lead တွေ) Meeting ထိုင်ပြီး Backlog ကို ပြန်ရှင်းလင်းတာဖြစ်ပါတယ်။ Agile Product Team တွေမှာ ပုံမှန်လုပ်သင့်တဲ့ Activity တစ်ခုလည်းဖြစ်ပြီး Backlog ထဲမှာရှိတဲ့ User Story တွေက Up to date ဖြစ်ဖို့၊ Product Team ရဲ့ ရှေ့ဆက် Development တွေအတွက် Ready ဖြစ်ဖို့ ရည်ရွယ်ပါတယ်။ Backlog Grooming Meeting မှာ ဘာတွေလုပ်ကြလဲဆိုတော့
  • Develop မလုပ်ဖြစ်တော့တဲ့ / မလိုတော့တဲ့ User Story တွေကို Backlog ထဲက ဖယ်ထုတ်
  • User Story အကြီးတွေကို အသေးလေးတွေ ပြန်ခွဲ
  • စီထားတဲ့ Priority တွေကို Product Team နဲ့ Review ပြန်လုပ်
  • လိုတဲ့ User Story တွေ၊ Task တွေ ရှိခဲ့ရင် ထပ်ထည့်… စတာတွေ လုပ်ဆောင်ပါတယ်။
Product Manager အနေနဲ့ကတော့ အချို့ User Story တွေ မဖယ်ထုတ်ခင်မှာ Develop မလုပ်တော့ဘူးဆိုတာသေချာဖို့ Data တွေကြည့်၊ Research တွေ၊ Analysis တွေ လုပ်ရပါလိမ့်မယ်။


၄။ Backlog နဲ့ပတ်သက်တဲ့ Discussion တွေမှာ Development Team ကို ဝင်ရောက်ဆွေးနွေး၊ Feedback ပေးခိုင်းပါ။ Feature Prioritize လုပ်ရာမှာ ဘယ် User Story က ဘယ်လောက် Development Effort လိုမယ်ဆိုတာပါ ထည့်စဥ်းစားရတာမို့ Development Team ကို သူတို့ရဲ့ ထင်မြင်ချက်တွေ ဝင်ရောက်ဆွေးနွေးဖို့၊ ထုတ်ပြောဖို့ လမ်းဖွင့်ပေးပါ။ ပြီးတော့ Backlog ထဲက Tasks တွေကို Develop လုပ်မှာ Developers တွေပဲဖြစ်တာကြောင့် သူတို့ကို ဝင်ဆွေးနွေးခိုင်းတာက Ownership Sense ကိုပါပေးစေပါတယ်။

၅။ Product Backlog မှာ ရှိနေတဲ့ Priority စီထားတဲ့ List နဲ့၊ လက်ရှိ Sprint မှာ ဘယ် Task တွေကို လုပ်နေကြောင်း Stakeholder တွေကို ပေးသိပါ။ ဒီအချက်က Product Roadmap နဲ့အတူတူပါပဲ။ Stakeholders တွေလည်း သိသင့်တဲ့အချက်အလက်တွေဖြစ်လို့ Backlog List ကို ပွင့်ပွင့်လင်းလင်း ဝေမျှထားတာ အကောင်းဆုံးဖြစ်ပါတယ်။

ဒီအချက်တွေကတော့ Product Manager အနေနဲ့ Product Backlog ကို ကိုင်တွယ်ရမှာ အကျိုးရှိစေမယ့် နည်းလမ်းတွေဖြစ်ပါတယ်။ Product Backlog နဲ့ပတ်သက်ပြီး ထပ်သိချင်တာရှိရင်လည်း မေးနိုင်ပါတယ်။ မိမိတို့ Product ရဲ့ လက်ရှိ Backlog ကို ဘယ်လို Manage လုပ်လဲ၊ ဘာတွေအဆင်ပြေပြီး၊ ဘယ်လို Learning တွေရှိခဲ့လဲ စတာတွေကို ဝေမျှခဲ့ပါဦး။

နောက်ထပ် ဖတ်ချင်တဲ့ Topic တွေရှိရင်လည်း ဒီ Google Form ကနေတဆင့် အကြံပေးနိုင်ပါတယ်။ ProductBaze မှ Product သမားအချင်းချင်း idea တွေ၊ knowledge နဲ့ experience တွေ share ဖို့ နွေးနွေးထွေးထွေးဖိတ်ခေါ်ပါတယ်။ ProductBaze အကြောင်း (၁) မိနစ်စာ မိတ်ဆက် post လေးကို ဒီ link မှာ ဖတ်လို့ရပါတယ်။ ProductBaze ကို ဆက်သွယ်ချင်ရင် productbaze@gmail.com သို့ ပေးပို့ ဆက်သွယ်နိုင်ပါတယ်။

Follow us on Facebook and Linkedin for latest updates.

Comments

Popular Posts

အသုံးများတဲ့ Product Testing တွေ

Webinar တစ်ခုမှာ Product Testing တွေအကြောင်းထည့်ပြောတော့ နောက်ဆုံးအမေးအဖြေအချိန်မှာ အမေးခံရဖူးတာလေး မှတ်မှတ်ရရရှိလို့ပါ။ “A/B Testing ဆိုတာ Alpha Testing, Beta Testing ကို ပြောတာလား” ဆိုတဲ့ မေးခွန်းပါ။ သိတဲ့သူအတွက်တော့ ဘာမှမဆိုင်တဲ့ Testing တွေမှန်း တန်းသိနိုင်ပေမယ့် တစ်ဖက်မှာလည်း မေးလည်းမေးချင်စရာ အခေါ်အဝေါ်က ခပ်ဆင်ဆင်တူနေတာကိုးလို့ တွေးမိပါတယ်။ ဒါကြောင့် ဒီဆောင်းပါးမှာ မကြာမကြာလည်း ပြောဖြစ်ကြပြီး၊ အသုံးလည်းများ၊ အသုံးလည်းဝင်တဲ့ Alpha Testing, Beta Testing နဲ့ A/B Testing တို့အကြောင်းကို တီးမိခေါက်မိအောင် ရေးချင်ပါတယ်။ Feature Development တွေပြီးတဲ့အခါ Product Owner နဲ့ Development Team တွေ User Acceptance Testing (UAT) ကို အတူတကွ ပြုလုပ်ကြပါတယ်။ QA က အဓိက Test တာဖြစ်နိုင်ပေမယ့် အားလုံးက ပူးပေါင်းလုပ်ဆောင်ကြရတာပါ။ Product (သို့) Feature က UAT လည်းပြီးပြီ၊ Release လုပ်တော့မယ်လို့ စ Plan တဲ့အခါ Alpha Testing နဲ့ Beta Testing အခန်းကဏ္ဍဆီ ရောက်ပါတယ်။ Alpha Testing Alpha Testing ဆိုတာ လွယ်လွယ်ပြောရရင် ကိုယ့်လူနဲ့ကိုယ် အရင်စမ်းသပ်တဲ့ Testing အမျိုးအစားပါ။ မိမိရဲ့ Software

SMART Goal ဘယ်လိုတည်ဆောက်မလဲ

Personal အတွက်ဖြစ်စေ၊ လုပ်ငန်းခွင်မှာဖြစ်စေ.. ရည်မှန်းချက်ကြီးမားတာ ကောင်းပေမယ့် ကိုယ်စိတ်ကူး ပေါ်ရာ ကိုယ်ဖြစ်ချင်ရာ ရည်မှန်းချက်တွေ ရမ်းသမ်းချမှတ်တာက လက်တွေ့မကျတဲ့၊ ချသာ ချမှတ်ထားပြီး အသုံးမဝင် Effective မဖြစ်တဲ့ ရည်မှန်းချက်တွေ ဖြစ်နေနိုင်ပါတယ်။ မဖြစ်နိုင်တဲ့ Goal နောက်ကိုလိုက်ရင်း ရင်းနှီးမြှုပ်နှံရတဲ့ အချိန်တွေ၊ ငွေကြေးတွေ၊ Resource တွေလည်း ဆုံးရှုံးမှုတွေဖြစ်စေနိုင်ပါတယ်။ “SMART Goal ဖြစ်ဖို့တော့ လိုမယ်နော်” ဆိုတဲ့ စကားမျိုး ကြားဖူးကြပါလိမ့်မယ်။ SMART Goal ဆိုတဲ့ concept ကို စီးပွားရေးလောက၊ Marketing အပြင် နယ်ပယ်အသီးသီးမှာ တွင်တွင်ကျယ်ကျယ်အသုံးပြုကြပါတယ်။ SMART Goal ဆိုတာ တိုတိုပြောရရင် တိကျရှင်းလင်းပြီး လက်တွေ့ကျတဲ့ Goal တွေချမှတ်ခြင်းလို့ ပြောနိုင်ပါတယ်။ မိမိ Business အတွက်၊ Product အတွက်၊ Team အတွက်၊ Personal အတွက် Goal တွေ ချမှတ်တဲ့အခါ လက်တွေ့ဖြစ်နိုင်ချေရှိတဲ့ ရည်မှန်းချက်ကို သေချာသတ်မှတ်ပေးနိုင်တဲ့ SMART Objective နည်းလမ်းကို သုံးကြည့်သင့်ပါတယ်။ SMART Goal ဆိုတာက ကိုယ့်ချမှတ်ရေးဆွဲမယ့် Goal တွေက S (Specific) - ဘာကိုရရှိအောင်လုပ်မယ်ဆိုတာ တိတိကျကျဖြစ်ရမယ် M (

Cross-Functional Team အကြောင်း တစေ့တစောင်း

Cross-functional Team ဆိုတာ အပြောလည်းများသလို အသုံးလည်းများပါတယ်။ Product Team တွေမှာလည်း Cross-functional Team ပုံစံကို တော်တော်များများ အသုံးပြုကြပါတယ်။ ProductBaze ဆောင်းပါးအချို့မှာလည်း ထည့်ရေးဖူးပြီး၊ Product Squad ဆောင်းပါးမှာ Squad တည်ဆောက်ပုံက Cross-functional Team ပုံစံကို အခြေခံတဲ့အကြောင်းရေးရင်းနဲ့ Cross-functional Team အကြောင်းလေးကိုပါ မိတ်ဆက်ပေးဖို့ ဖြစ်လာပါတယ်။ ပုံမှန် Organization တွေမှာ Department တွေ, Team တွေက လုပ်ငန်းသဘောသဘာဝ တူညီရာ (Tech, Marketing, Sales, Operation…) စသဖြင့် အသီးသီး ဖွဲ့စည်းထားကြပြီး ဖွဲ့စည်းပုံကလည်း အထက်ကနေ အောက် Hierarchy အတိုင်းဖြစ်ကြပါတယ်။ Decision တစ်ခုလိုအပ်ရင်လည်း Hierarchy အတိုင်း အပေါ်ကို ပြန်တက်ပြီး Request လုပ်ကြရသလို၊​ Company တစ်ခုထဲက Team အသီးသီးက အခြား Department တွေ ဘာလုပ်နေလဲဆိုတာ သိဖို့ ထင်သလောက် မလွယ်ကူပါဘူး။ Silos Team (တသီးတသန့် အလုပ်လုပ်တဲ့ Team) တွေ ဖြစ်လာပြီး Direction တွေ ညှိရခက်တတ်ပါတယ်။ Cross-functional Team ဆိုတာက Organization ထဲမှာ ကျွမ်းကျင်မှုမတူ (သို့မဟုတ်) ဌာနမတူတဲ့ လူတွေကို Team အနေနဲ့ဖွဲ့ပေးပြီး Project တစ်

ကိုယ့် Boss ကို ဘယ်လို Manage လုပ်မလဲ

“Manage My Boss” ဆိုတဲ့ ခေါင်းစဉ်ကြီးဖတ်လိုက်ရလို့ တမျိုးကြီးဖြစ်သွားမယ်ထင်ပါတယ်။ သို့ပေမယ့် ကျွန်တော် အခုပြောပြမယ့် “How to Manage your Boss” က Management အကြောင်း လေ့လာတဲ့အခါတွေမှာလည်း ပါဝင်လေ့ရှိသလို အပြင်လုပ်ငန်းခွင်မှာလည်း တကယ်အရေးပါတဲ့ ကိစ္စရပ်ပါပဲ။ ကိုယ်ကိုယ်တိုင်က Middle Management Level လို့ပြောကြတဲ့ Manager ဖြစ်နေမယ်၊ ကိုယ့်အောက်မှာ Team Members တွေရှိသလို၊ ကိုယ့်အပေါ်မှာလည်း ကိုယ် Report လုပ်ရတဲ့ Senior Manager သော်လည်းကောင်း၊ Head သော်လည်းကောင်း၊ C-Level သော်လည်းကောင်း ကိုယ့် Boss ရှိမယ်ပေ့ါ။ Management Term အရဆိုရင် ကိုယ့် Team ကို Manage လုပ်ရတာကို “Managing Down” or “Downward Management” လို့ ခေါ်ပြီး၊ ကိုယ့် Boss ကို Manage လုပ်တာကို “Managing Up” or “Upward Management”လို့ခေါ်ပါတယ်။ အဲ့တော့ အခုဆွေးနွေးမှာက Upward Management အကြောင်းပါ။ အိုကေ… ကိုယ့် Boss ကို ဘယ်လို Manage လုပ်တာလဲ??? ကိုယ်က Manage လုပ်ခံရမှာမဟုတ်ဘူးလား??? ကိုယ့်အတွက်ရော ဘယ်လို အကျိုးရှိမှာလဲ??? “Boss ကို Manage လုပ်တယ်ဆိုတာ ဘာလဲ” ကနေ စရအောင်ပါ။ Boss ကို Manage လုပ်တဲ့ အဓိက Goal က Boss ကို အပြည

Agile ဆိုတာဘာလဲ

Agile က Software Development တွေမှာ အဓိကသုံးတဲ့ နည်းစနစ်ဖြစ်ပြီး၊ Develop လုပ်နေတဲ့ ကာလတောက်လျှောက်မှာ Requirements အပြောင်းအလဲတွေကို ကောင်းကောင်းလက်ခံနိုင်တဲ့ နည်းစနစ်ဖြစ်တာကြောင့် အလွန်အသုံးများလာကြပါတယ်။ Project Management အတွက် Agile ကို တွင်တွင်ကျယ်ကျယ်သုံးလာတာနဲ့ အမျှ Project Manager, Product Manager, Scrum Master, Business Owner, Delivery Manager နဲ့ Software Engineers တွေပါ Agile အကြောင်းကို လေ့လာဖို့လိုအပ်လာပါတယ်။ ဒါကြောင့် ဒီဆောင်းပါးမှာ Agile နဲ့ပတ်သက်ပြီး မိတ်ဆက် ပြောပြသွားပါမယ်။ Agile ဆိုတာဘာလဲ Agile ဆိုတာ Software Industry မှာ Product (သို့) Service တစ်ခုကို Customer ဆီကို အစောဆုံးနဲ့ စဥ်ဆက်မပြတ် ထုတ်ပေးနိုင်ဖို့ အသုံးပြုတဲ့ နည်းစနစ်ဖြစ်ပါတယ်။ Agile နည်းက မြန်ဆန်ပေ့ါပါးပြီး အပြောင်းအလဲတွေကို လိုက်လျောညီထွေ လက်ခံနိုင်တဲ့ နည်းစနစ် ဖြစ်တာကြောင့်၊ Market လိုအပ်ချက်၊ Customer လိုအပ်ချက်တွေနဲ့အညီ Product ကို အချိန်မီ ထုတ်ပေးနိုင်စေပါတယ်။ Product တစ်ခုလုံးကို အစ-အဆုံး ပြီးအောင် တည်ဆောက်ပြီးမှ Customer ကို ပေးသုံးတာမဟုတ်ပဲ… Customer ရဲ့ လိုအပ်ချက်ပေါ်မူတည်ပြီး Feature တွေက