Skip to main content

PM တစ်ယောက် ဖြတ်သန်းရတဲ့ Phase များ

Product Manager တစ်ယောက်နဲ့ တစ်‌ယောက် လုပ်ကိုင်ရတဲ့ Roles and Responsiblities တွေက အနည်းနဲ့ အများ ကွာခြားနိုင်ပါတယ်။ ဒါကလည်း မိမိ လုပ်ကိုင်နေတဲ့ Company ရဲ့ အရွယ်အစား၊ Product Team ရဲ့ အရွယ်အစားနဲ့ Company ရဲ့ လိုအပ်ချက်တွေအပေါ် မူတည်ပါတယ်။ Company အရွယ်အစားသေးရင် (သို့) Team Member နည်းသေးရင် Product Manager က နေရာတော်တော်များများ ဝင်ပါရလေ့ရှိပြီး၊ Team Member များများနဲ့ Run နေပြီဖြစ်တဲ့ Company ဖြစ်ရင်တော့ Product အတွက် Roles and Responsiblities တွေကို ခွဲလုပ်ကိုင်ရလေ့ရှိပါတယ်။ ဒီဆောင်းပါးမှာတော့ Product Manager အနေနဲ့ Product Development မှာ ယေဘူယျ ဖြတ်သန်းရတဲ့ Phase တွေကို ခွဲခြမ်းလေ့လာကြည့်ရအောင်။


Product တစ်ခုအတွက် ရှိသင့်တဲ့ Phase များကို ဒီအတိုင်းခွဲကြည့်မယ်။
  1. Product တစ်ခု စရင် Design လိုတဲ့ အတွက် Design Phase
  2. Design ထွက်ရင် Develop လုပ်ဖို့ Implementation Phase
  3. Develop ပြီး Product စမ်းဖို့ Testing Phase
  4. Testing ပြီးရင် User တွေဆီရောက်ဖို့ Launch Phase
  5. Launch လုပ်လိုက်တဲ့ Features/ Product ကို စောင့်ကြည့်ဖို့ Review Phase
ဒါကတော့ Product တစ်ခု ထွက်ဖို့ မရှိမဖြစ်လိုအပ်တဲ့ Phase တွေဖြစ်ပါတယ်။ PM တစ်ယောက်ဖြတ်သန်းရတာတွေပြောပါဆိုရင် ဒီ Phase တွေပါပဲ။ အဲ့တော့ ဒီ Phase တွေမှာ PM တစ်ယောက်အနေနဲ့ ဘယ်လိုပါဝင်ရလဲဆိုတာကို ဆက်လေ့လာရအောင်။

၁။ Design (UIUX)
ဒီ Phase မှာတော့ PM က Design Team နဲ့ အနီးကပ်အလုပ်လုပ်ရတာပါ။ Design Phase မှာ Mocks နဲ့ Specification တွေထွက်ဖို့ အဓိက လုပ်ဆောင်ရပါတယ်။ အဲ့လို ထွက်ဖို့ မိမိ Feature / Product ရဲ့ Problem, Solution, Background Story တွေကို Review လုပ်ပြီး Design Team နဲ့ Brainstorm ထိုင်လုပ်ရပါတယ်။ အကယ်၍ Team သေးရင် PM ကိုယ်တိုင် Mock (သို့) Wireframe လိုက်ဆွဲရတာမျိုးလည်း လုပ်ကောင်းလုပ်ရနိုင်ပါတယ်။

၂။ Implementation
Design ရပြီဆိုတော့ Development Tem နဲ့ Project Manager တို့နဲ့ အတူ ဘယ်လို Develop လုပ်မယ်ဆိုတာ တိုင်ပင်ရပါမယ်။ တိုင်ပင်ရာမှာ အဓိကထား ဆွေးနွေးရမှာက Requirement တွေ စုံရဲ့လား? တခြား မစဉ်းစားမိတဲ့ Edge Cases တွေရှိသေးလားဆိုတာကို ဆွေးနွေးရပါမယ်။ မိမိ တစ်ယောက်ထဲ စဉ်းစားထားတဲ့ Idea တွေကို Team ကို ချပြပြီး Technically Feasible ဖြစ်လားဆိုတာကို စဉ်းစားတိုင်ပင်ရပါတယ်။ ဒါ့အပြင် Develop လုပ်နေတဲ့ Timeline ကို တစိတ်တပိုင်း ဝင်ကြည့်ပေးရတတ်ပါတယ်။ အဓိကက Development က On Track ဖြစ်ရဲ့လား၊ Team Develop လုပ်နေတဲ့ Feature / Product မှာ တခြား အခက်အခဲတွေ၊ Blocker တွေ ရှိနိုင်လားဆိုတာကို PM တစ်ယောက်အနေနဲ့ ဝင်ရောက်ဖြေရှင်းပေးဖို့ပါ။

၃။ Testing
Development ပြီးရင် နောက်တစ်ဆင့်အနေနဲ့ Test လုပ်ရပါမယ်။ များများ Test လေ မိမိ Product က အမှားနည်းလေပဲ မဟုတ်လား။ Test က အဓိကအားဖြင့် Quality Assurance (QA) Team က လုပ်ဆောင်ရပေမယ့် PM တစ်ယောက်အနေနဲ့လည်း မိမိ Define လုပ်ထားတဲ့ Feature / Product က Accpetance Criteria တွေပြည့်ရဲ့လား၊ Launch ဖို့အတွက် Quality မိပြီလားဆိုတာတွေကို အသေးစိတ်ရင် စိတ်နိုင်သလောက် စမ်းသပ်ရပါတယ်။

၄။ Launch
Develop လုပ်ပြီးသကာလ အရေးကြီးတဲ့အချိန်ကတော့ Launch Period ပဲဖြစ်ပါတယ်။ Excitment တွေနဲ့ ပြည့်နေသလို စိုးရိမ်စိတ်တွေလည်းရှိမယ့်အချိန်ပါပဲ။ ဒါကြောင့် Launch Strategy ကောင်းကောင်းရှိဖို့က ဒီ Phase မှာ အရေးအကြီးဆုံးဖြစ်ပါတယ်။ များသောအားဖြင့် စဉ်းစားရမှာက Silent Launch (သေချာကြီး Marketing မလုပ်ပဲ) လုပ်မှာလား၊ Big Launch (User တွေအတွက် Hype ဖြစ်အောင် လုပ်မှာ) လား၊ User Demographic နည်းနည်းစီနဲ့ ဖြည်းဖြည်းချင်း Launch လုပ်မှာလား စသဖြင့် စဉ်းစားကြရပါတယ်။

၅။ Review
Product အနေနဲ့ အရေးကြီးဆုံး Phase ကတော့ Review (Monitoring and Controlling) Phase လို့ပြောရင် ပြောလို့ရပါတယ်။ User ဆီပေးလိုက်တဲ့ Feature ကို ပိုကောင်းအောင် ဘယ်လိုလုပ်ရမလဲ စောင့်ကြည့်ပြင်ဆင်ချိန်ဖြစ်လို့ Maximize Phase လို့လဲ ပြောနိုင်ပါတယ်။ Feature တွေ၊ Product တွေပဲ ထုတ်နိုင်သလောက် ဆက်တိုက်ထုတ်ပြီး ပိုကောင်းလာအောင် စောင့်ကြည့်ပြုပြင်တာ မလုပ်ရင် Feature Factory Product ပဲ ဖြစ်နေပါလိမ့်မယ်။ ဒါကြောင့် Review အနေနဲ့ ဒီ Feature က ‌User တွေကြားမှာ ဘယ်လို ရေပန်းစားလဲ? User ဘယ်လောက်များများကို Impact ဖြစ်နေလဲ? စတာတွေကို လေ့လာရပါတယ်။ လေ့လာစူးစမ်းချက်တွေထဲက ကောင်းတာတွေကို ဆောင်၊ ဆိုးတာတွေကို ရှောင်နိုင်အောင် အားထုတ်ရပါတယ်။

ဒါက Product တစ်ခု Development စလုပ်တဲ့အချိန်မှာ Product Management အနေနဲ့ ဖြတ်သန်းရတဲ့ အဆင့်တွေကို ဖော်ပြထားတာဖြစ်ပါတယ်။ Develop မလုပ်ခင် Phase တွေဖြစ်တဲ့ Idea ရှာတဲ့အဆင့်တွေ၊ လုပ်သင့်/မလုပ်သင့် ဆုံးဖြတ်တဲ့အဆင့်တွေနဲ့၊ ဘယ်လိုလုပ်သင့်လဲ Plan ချတဲ့ အဆင့်တွေ မပါဝင်ပါဘူး။ Product သို့မဟုတ် Feature ကို စအကောင်အထည်ဖော် Develop လုပ်ချိန်မှာ Development Team နဲ့ Develop စလုပ်ကြရင် လုပ်ဆောင်ရတဲ့ Phase တွေကို ဆွေးနွေးထားတာပါ။

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

Follow us on Facebook and Linkedin for the 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 ကို အပြည

Product Death Cycle ထဲမဝင်မိအောင်

User-centric Product ဖြစ်ဖို့ ကိုယ့် User တွေရဲ့ Feedback တွေကို အမြဲနားထောင်ပြီး လိုအပ်ချက်တွေ ဖြည့်ဆည်းဖို့၊ Product ကို Improve လုပ်သွားဖို့ အရေးကြီးပါတယ်။ ဒါပေမယ့် ကိုယ့် Existing User တွေက အတောမသတ်နိုင်တဲ့ Feature Request တွေ၊ Changes တွေကို တောင်းဆိုနေ၊ Feedback တွေ ပေးနေခဲ့ရင်ရော? ဒါနဲ့ပတ်သက်ပြီး Product သမားတိုင်း သတိထားမိသင့်တဲ့ စိတ်ဝင်စားစရာ Product Death Circle ဆိုတဲ့ Concept အကြောင်းကို ဝေမျှချင်ပါတယ်။ Feature Factory Product နဲ့လည်း ဆက်စပ်နေတာမို့ စိတ်ဝင်စားရင် ProductBaze က ရေးသားခဲ့တဲ့ Feature Factory Product ဆောင်းပါးကို ဖတ်ကြည့်ဖို့ တိုက်တွန်းပါတယ်။ “Product Death Cycle” ဆိုတဲ့ အခေါ်အဝေါ်ကို Silicon Valley မှာရှိတဲ့ နာမည်ကြီး Author နဲ့ Founder ဖြစ်သူ David Bland က Twitter မှာ ဒီပုံလေးတင်ပြီး ဝေမျှခဲ့ရာကနေ စတင်ပါတယ်။ Product မှာ New User တွေ ရဖို့ခက်ခဲနေတယ်၊ ဘယ်သူမှ သိပ်လာမသုံးကြဘူး။ ဒီအခါ ရှိပြီးသား User တွေကို ဘာအဆင်မပြေလို့လဲ၊ ဘာ Feature တွေ လိုအပ်နေလဲ စသဖြင့် Feedback တွေ တောင်းကြလေ့ရှိပါတယ်။ User တွေကပေးတဲ့ Feedback ပေါ်မူတည်ပြီး Product ကို ပြင်ဆင်ကြ