Skip to main content

Product Manager တစ်ယောက် အလုပ်သစ်မှာ ဘယ်လိုအခြေချမလဲ

အလုပ်သစ်ထဲ ဝင်ရတာ အထိုက်အလျောက်တော့ အခက်အခဲတွေရှိပါတယ်...
ဘယ်လောက်ဘဲ Job Background တောင့်တောင့်၊ Skill ရှိရှိ လုပ်ငန်းသစ်ထဲဝင်ပြီး လုပ်ငန်းဖော်တွေနဲ့ အဆင်မပြေ၊ မိမိအလုပ်ကို ထင်ထားတဲ့အတိုင်း အထိုက်အလျောက် ဝင်မပါရဘူးဆိုရင် သေချာပြီ... သင်အလုပ်သစ်မှာ stress တွေများမယ် မပျော်ရဘဲ...ရေရှည်လဲ လက်တွဲချင်မှာ မဟုတ်ဘူး။

ကျွန်တော်ကတော့ ကံကောင်းတယ်ပဲ ပြောရမလား၊ ကံဆိုးတယ်ပဲ ပြောရမလား...အဲ့လိုမျိုးတွေနဲ့ ကြုံဖူးတယ်ဗျ။ ကံကောင်းတယ်ဆိုတာကတော့… ကိုယ့်အတွက် အတွေ့အကြုံရတာမျိုးပါ… ကိုယ်ဒီထက် ရာထူးကြီးလာရင် ကိုယ့်လုပ်ဖော်ကိုင်ဖက်တွေ အဲ့လိုမဖြစ်အောင် ဘယ်လိုကာကွယ်နိုင်မယ်ဆိုတဲ့ အတွေ့အကြုံရတယ်။ ကံဆိုးတာကတော့… မထင်ထားတဲ့ လုပ်ငန်းခွင် အခက်အခဲတွေကြောင့် give up လုပ်မိခဲ့တာမျိုးမှာ ကိုယ်လုပ်ချင်တဲ့ Project တွေ၊ tasks တွေ၊ တွေ့ကြုံချင်တဲ့ challenges တွေ မရတော့ပဲ အားမလိုအားမရ ဖြစ်ခဲ့ရတာမျိုးပါ။
ကဲ… ဒါဆို… Product Manager တစ်ယောက် အနေနဲ့ အလုပ်သစ်ထဲ စဝင်ရင် ပြင်ဆင်လို့ရတဲ့ နည်း အနည်းငယ် share ချင်ပါတယ်…

၁။ လူတိုင်းနဲ့ စကားပြောကြည့်ပါ။
Slow Down...အရှိန်လျှော့ပါ…
ကျွန်တော်တို့တွေ လုပ်ငန်းသစ်ရရင် ဖြစ်တတ်ကြတာက… ငါအလုပ်သစ်မှာ ဒါတွေလုပ်မယ်၊ ငါ့ Skills တွေ၊ Experience တွေကို ကြွားမယ်၊ ငါဘာကောင်လဲဆိုတာ သိအောင်လုပ်ပြမယ်.. စသဖြင့်ပေါ့...Motivation တွေရပြီး အစွမ်းကုန်ကြိုးစားချင်တတ်ကြပါတယ်။
ဒါတွေမလုပ်ခင် အရှိန်လျှော့ဖို့ အကြံပေးချင်ပါတယ်… နေရာတိုင်းမှာ ကိုယ့်ထက်တော်တဲ့လူတွေ ရှိသလို၊ ကိုယ်က ဦးဆောင်ပေးရတဲ့ လူတွေလည်း ရှိမှာပါ… ပြီးတော့ Industry တူတယ်ပဲပြောပြော..လုပ်ငန်းတစ်ခုနဲ့ တစ်ခုတော့ မတူပါ… Company တစ်ခုမှာရှိတဲ့ Department အချင်းချင်းတောင် ခံယူချက်၊ လုပ်ငန်းစဉ်တွေ ကွာပါတယ်..
Product Manager ဆိုတာက စေ့စပ်ညှိနှိုင်းပေးရတဲ့လူဆိုလည်း မမှားပါဘူး...Communicator/ Facilitator ပေါ့။ Department အားလုံးနဲ့ ညှိနှိုင်းပြီး အကောင်းဆုံး Features တွေ၊ Solutions တွေကို ဦးဆောင်ထုတ်ပေးရသူဆိုတော့ အလုပ်သစ်ဝင်ရင် ပထမဆုံး လုပ်သင့်တာက Company တစ်ခုလုံးက လူများနဲ့ စကားပြောကြည့်ပါ။ Company ရဲ့ People Culture ကို အရင်လေ့လာကြည့်ပါ။ Personal Tip အနေနဲ့တော့ Company အကြောင်း ဝေဖန်သူများအနားနေကြည့်ပါ။ သူတို့ဆီမှ Company ရဲ့ လစ်ဟာနေတဲ့ အချက်များကို လေ့လာမိပါမယ်...မမြောသွားစေဖို့တော့ အကြံပေးလိုပါတယ်။ ဝေဖန်ချက်​တွေကို ယူ...မိမိကိုယ်ကို ဆန်းစစ် ပြီး အကောင်းဆုံးဘယ်လို Contribute လုပ်နိုင်မယ်ဆိုတာ စဉ်းစားကြည့်ပါ။ 
၂။ အကူအညီတောင်းဖို့ မရှက်ပါနဲ့။
Steve Jobs ၁၂ နှစ်အရွယ်တုန်းက Bill Hewlett ကို ဖုန်းဆက်ပြီး အကူအညီတောင်းခဲ့တယ်။ သဘောကျသွားလို့ အကူအညီရခဲ့သလို အလုပ်မလျှောက်ပဲ အလုပ်ပါ ပေးခံရဖူးတယ်။ ဒီလိုပါပဲ ကျွန်တော် ငယ်ငယ်ထဲက အကူအညီတောင်းရမှာ အရမ်းကြောက်ခဲ့တယ်၊ ရှက်ခဲ့တယ်… အကျိုးဆက်ကတော့ လိုချင်တာတွေ၊ ရချင်တာတွေ မရနိုင်တော့ဘူးဖြစ်သွားတာပေါ့။ Product Manager တစ်ယောက်ဆိုတာ CEO of the Product လို့ပြောကြတဲ့အတိုင်း လုပ်ငန်းခွင်ထဲမှာ လူပေါင်းမျိုးစုံ၊ Team ပေါင်းမျိုးစုံ နဲ့ အလုပ်တူတူလုပ်ရတာပါ။ သူတို့ဆီက အကူအညီတောင်းဖို့ ရှက်နေရင် မိမိ Product ပဲ အထိနာမှာဖြစ်တယ်။ ဒါကြောင့် အကူအညီတောင်းဖို့ မမေ့ပါနဲ့…
ကံကောင်းရင် ကိုယ်လိုချင်တဲ့ အကူအညီရသွားမယ်၊ ကံဆိုးရင်တောင် reject လုပ်ခံရယုံဘဲ...အရှုံးမရှိပါဘူး။ နှုတ်ပိတ်နေရင်တော့ မိမိလိုချင်တဲ့ Resources တွေ မရဘဲ ကိုယ့် Product Development မှာ နောက်ကောက်ကျန်နေတတ်ပါတယ်။
၃။ Company နဲ့ Process အကြောင်းစပ်စုပါ။
Product Manager လို့ပြောတိုင်း Features တွေ၊ Product တွေပဲ စွတ်ထုတ်နေလို့မရပါဘူး။ Product Vision သည် Company ရဲ့ Vision ကို Support ပေးနိုင်မှ Company လည်း Profit ရ၊ အဲ့ Product လဲ ရေရှည်တည်မြဲမှာဖြစ်ပါတယ်။ အဲ့တော့ Product ရဲ့အရင်းအမြစ် ဖြစ်တဲ့ Company အကြောင်းကို အရင်လေ့လာသင့်ပါတယ်။ ဆိုတော့ Company အကြောင်းလို့ပြောရင် ဘာတွေလေ့လာမလဲ…
Company Vision & Objectives တွေ၊ Company အကြောင်း Publish လုပ်ထားတဲ့ Articles တွေ၊ Company ရဲ့ Report တွေ၊ ပြိုင်ဘက်တွေအကြောင်း၊ နောက်ပြီး Company ရဲ့ Failed Stories တွေ၊ Success Stories တွေ ဆိုရင် လုံလောက်ပါတယ်။ Process အနေနဲ့ကတော့ မိမိဝင်လုပ်ကိုင်ရမယ့် Product Team ရဲ့ လုပ်ငန်းစဉ် တွေပေါ့။ ဘယ် Tools တွေသုံးပြီး Communicate လုပ်ကျလဲ၊ Features တွေကို ဘယ်လို Develop နဲ့ Deliver လုပ်ကျလဲ… အဓိကအားဖြင့်တော့ Internal Process တွေပါ့။ Company က Documentation ကောင်းကောင်းလုပ်ရင် အဲ့ဒီ Documents တွေလိုက်ဖက်ပြီး၊ Documentation ထားတာ အားနည်းရင်တော့ မိမိရဲ့ colleagues ဒါမှမဟုတ် မိမိရဲ့ Supervisor ကို မေးကြည့်ပြီး လေ့လာကြည့်ပါ။
၄။ Tech Team နဲ့ နေပါ။
Product Manager ဖြစ်သွားပြီဆိုပြီးတော့ Development နဲ့မဆိုင်တော့ဘူး၊ ဝင်မပါချင်တော့ဘူးလို့ တစ်သတ်မတ်တည်း မယူဆပါနဲ့... ဖြစ်နိုင်ရင် Tech Team နဲ့ အချိန်ကုန်ဆုံးကြည့်ပါ။ သူတို့ရဲ့ Struggles တွေ၊ သူတို့ လုပ်ချင်တဲ့ Features တွေနားထောင်ကြည့်ပါ၊ သူတို့ရဲ့ Architecture တွေ၊ API တွေ Tech Stack တွေ အကြောင်းအခွင့်ရရင် လေ့လာကြည့်ပါ။ Digital Product တွေလုပ်နေရတာဖြစ်တဲ့အတွက် Tech Team နဲ့ Product Team တူတူလုပ်ကိုင်၊ Knowledge ကောင်းကောင်းဖလှယ်မှ အကောင်းဆုံး လုပ်ကိုင်နိုင်မှာပါ။ ဖြစ်နိုင်ရင် Tech Team နဲ့ အမြဲ Brainstorm လုပ်ကြည့်ပါ။ သူတို့ကို Feature အသစ်လုပ်တိုင်း ဘာကြောင့်လုပ်တာလဲ (Reason “Why”)ကို ရှင်းပြပေးကြည့်ပါ။ ကိုယ်က “ဒါလိုချင်တယ်...အဲ့အတိုင်းလုပ်ပေး” “တခြား Product တွေမှာတောင်ရှိတယ်...မလုပ်နိုင်ဘူးလား” ဆိုတဲ့ စကားလုံးတွေ မသုံးစေချင်ပါဘူး..Company အချင်းချင်းမတူသလိုဘဲ Tech Stack တွေ၊ ဖြစ်နိုင် မဖြစ်နိုင်တာတွေ ကွာပါတယ်။ အဓိက က မိမိ Customers တွေအတွက် ဖြေရှင်းပေးချင်တဲ့ ပြသနာကို ဖြေရှင်းပေးဖို့ပါ...UI တွေလှအောင်လုပ်...Features တွေအများကြီး ထည့်ပြီး ပြသနာကိုကျ မဖြေရှင်းပေးနိုင်ရင် အဲ့ Product က သူများတွေထက် နောက်ကျနေပါလိမ့်မယ်။ Feature Factory Product ကြီးပဲဖြစ်နေပါလိမ့်မယ်။ ဒါကြောင့်...Tech Team နဲ့များများစကားပြောပြီး ဒီ ပြသနာတွေကို ဖြေရှင်းဖို့ကြိုးစားကြည့်ပါ။
၅။ Customer Feedback ယူပါ။
အရေးကြီးဆုံး Stakeholder တစ်ယောက်ဖြစ်တဲ့ Customer တွေရဲ့ Feedback က မိမိ Product Development မှာ အရမ်းအထောက်အကူဖြစ်ပါတယ်။ နောက်ဆုံးမှာ မိမိ ဖြေရှင်းပေးချင်တာ သူတို့ရဲ့ ပြသနာတွေ၊ အခက်အခဲတွေပါ။ ဒါကြောင့် သူတို့ရဲ့ Feedback က Customer Retain လုပ်တဲ့နေရာမှာ အသုံးဝင်သလို၊ မိမိ Product မှာလည်း Input Source တစ်ခုဖြစ်နိုင်ပါတယ်။ ဆိုတော့ ဘယ်လို Customer Feedback ယူကြမလဲ? မြန်မာနိုင်ငံအတွက် ကတော့ Blog တွေ Articles တွေထက် Facebook မှာ သွားယူတာ ပိုမို အဆင်ပြေပါလိမ့်မယ်။ မိမိ Product Facebook Page ရှိရင် အဲ့ Page မှာ Comments တွေ Interaction တွေ ဖတ်ကြည့်ပါ။ နောက်တစ်နေရာကတော့ မိမိ Company မှာ Sales Channel တွေ ရှိရင် အဲ့ကနေလဲ ယူလို့ရပါတယ်။ Sales သမားတွေနဲ့ စကားပြောကြည့်ပြီး သူတို့ကို Complain အတတ်ဆုံး Problems တွေက ဘာတွေလဲ ဆိုတာ လေ့လာနိုင်ပါတယ်။ မိမိက App ရှိတယ်ဆိုရင်တော့ Play Store တို့ App Store တို့မှာလဲ Review တွေသွားဖတ်နိုင်ပါသေးတယ်။ အခွင့်သင့်ရင် Customers တွေနဲ့ စကားပြောကြည့်တာလဲ အဆင်ပြေနိုင်ပါတယ်။
၆။ အရာရာတိုင်းတာပါ။
ဒီမှာ ပြောချင်တာက Product Metrics တိုင်းတာဖို့တစ်ခုပဲမဟုတ်ပါဘူး၊ မိမိရဲ့ Productivity ကိုပါတိုင်းတာမယ်။ Team ရဲ့ Productivity ကိုလည်းတိုင်းတာမယ်. တိုင်းတာနိုင်တဲ့ အရာတိုင်းကို Record လုပ်ထားဖို့ဖြစ်ပါတယ်။ ဘာကြောင့်ဒီလိုလုပ်လဲဆိုတော့ မိမိအနေနဲ့ Self Review ပြန်လုပ်လို့ရသလို...Team မှ မိမိ Input များတောင်းတဲ့အချိန်ရောက်ရင် အဆင်သင့် ပေးနိုင်နေပါလိမ့်မယ်။ ဆိုတော့ Product Metrics များမရှိသေးရင် မိမိရဲ့ Product Team (သို့) Internal Stakeholders များနဲ့ ထိုင်ပြီး Metrics များသတ်မှတ်စေလိုပါတယ်။ Product Manager တစ်ယောက်အနေနဲ့ Features များ Deliver လုပ်နိုင်ယုံနဲ့ မပြီးဘဲ မိမိ Customers တွေလက်ထဲမှာ အဲ့ဒီ Features တွေ ဘယ်လို Perform လုပ်နေလဲ၊ ဘယ်လို Enhance လုပ်လို့ရနိုင်မလဲဆိုတာ ကို သိဖို့ Product Metrics တွေ သတ်မှတ်ထားဖို့လိုပါတယ်။ မိမိရဲ့ Productivity ဒါမှမဟုတ် Team ရဲ့ Productivity ကို တိုင်းတာသင့်တယ်ဆိုတာကတော့ Align ဖြစ်နေဖို့ပါ။ တစ်ခါတစ်လေ ကိုယ်ကလုပ်ချင်တာ များတယ်၊ ကိုယ့် Team က မလိုက်နိုင်ရင် နှစ်ဖက်စလုံးပဲ Stress ပိနိုင်ပါတယ်။ Project Manager နဲ့စကားပြောပြီး သူ့ဆီကနေ Team ရဲ့ Performance တွေ Feedback ရနိုင်ပါတယ်။
၇။ နားထောင်ပါ။
နောက်ဆုံးအနေနဲ့ Share ချင်တာကတော့ နားစွင့်ဖို့ပါပဲ.. .မိမိ အလုပ်သစ်မှာ ပတ်ဝန်းကျင်အသစ်ကို နားစွင့်ဖို့ပါ။ Product Manager တစ်ယောက်ဟာ Problem Solver ဆိုလဲ မမှားပါဘူး။ အဲ့လို Problem တွေ ဖြေရှင်းဖို့အတွက် မိမိက အရင် နားထောင်ဖို့လိုပါတယ်။ အရင်ဆုံး ကိုယ့်ဟာကိုယ် အရင်နားထောင်ကြည့်ပါ။ Steve Jobs ရဲ့ ဆောင်ပုဒ် “Have the courage to follow your heart and intuition” လိုပေါ့.. မိမိစိတ်ထဲမှာ လုပ်ချင်တာတွေ ဖြစ်ချင်တာတွေကို အရင်ဆုံးနားထောင်ပါ။ ဒုတိယအနေနဲ့ကတော့ လုပ်ငန်းခွင်ထဲက တခြားသူပြောတာကိုနားထောင်ကြည့်ပါ။ တစ်ယောက်ချင်းစီမှာ သူ့ရဲ့ Background Story တွေရှိပြီးသားပါ။ ကိုယ့်ထက် ဒီCompany မှာဝါကြီးတော့ ကိုယ့်ထက်လည်း ပိုသိထားမှာပါ။ သူတို့ရဲ့ story တွေနားထောင်ပြီး ကိုယ့် အတွေအကြုံတွေနဲ့ ပေါင်းလိုက်ရင် သေချာတယ် လုပ်ငန်းတွေတွင်ကျယ်လာမှာပါ။ နားထောင်ယုံနဲ့လည်းမပြီးပါဘူး...သူတို့ များများပြောလာအောင် ကိုယ့်ဘက်ကလဲ Open Ended Question တွေများများမေးပေးဖို့ပါပဲ (Personal Favorite အနေနဲ့ကတော့ 5 Whys ကို အသုံးချကြည့်ဖို့ တိုက်တွန်းချင်ပါတယ်။)

ဒီ ၇ ချက်ကတော့ ကျွန်တော် ကိုယ်တိုင် ကြုံတွေ့ဖူးပြီး တကယ်လဲ အသုံးချနေတဲ့ နည်းလမ်းလေးတွေဖြစ်ပါတယ်။ ကျွန်တော့်လိုပဲ တွေ့ကြုံနေရတယ်ဆိုရင်တော့ ဒီနည်းလမ်းလေးတွေနဲ့ Try ကြည့်ကြည့်ပေါ့...အလုပ်သစ်ထဲ ပြောင်းမှမဟုတ်ပဲ...အခုအလုပ်ထဲမှာလည်း စမ်းကြည့်နိုင်ပါတယ်...Feedback တွေ၊ တခြား နည်းလမ်းတွေနဲ့ Try ဖူးရင်လည်း အောက်က Comment လေးမှာ Share ပေးပါဦး။
----
Product သမားအချင်းချင်း idea တွေ၊ knowledge နဲ့ experience တွေ share ဖို့ နွေးနွေးထွေးထွေးဖိတ်ခေါ်ပါတယ်။ နောက်ထပ် Post တွေမှာ product management နဲ့ ပတ်သက်တဲ့ ဘယ်လို topic တွေဖတ်ချင်လဲဆိုတာ ဒီ Google Form ကနေတဆင့် အကြံပေးနိုင်ပါတယ်။
ProductBaze အကြောင်း (၁) မိနစ်စာ မိတ်ဆက် post လေးကို ဒီ link မှာ ဖတ်နိုင်ပါတယ်။ ProductBaze ကို ဆက်သွယ်ချင်ရင် productbaze@gmail.com သို့ ပေးပို့ ဆက်သွယ်နိုင်ပါတယ်။

Comments

Popular Posts

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 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

၅ မိနစ်စာ Product Roadmap

Product တစ်ခုစလုပ်ရင် အလိုအပ်ဆုံးက Product Roadmap လို့ပြောလို့ရမယ်။ Product Roadmap က မိမိ လုပ်မယ့် Product အကြောင်း Overview ပြောပြပေးနိုင်သလို၊ မိမိ Product Goal တွေကို ဘယ်လိုရောက်အောင် လျှောက်မလဲဆိုတာကို ချပြပေးလို့ပါပဲ။ Product Roadmap မရှိရင် ကိုယ်ထင်ရာ လုပ်မိနေနိုင်ပြီး မိမိ Goals တွေကို လက်လှမ်းမမှီနိုင်ဖြစ်သွားလိမ့်မယ်။ Product Roadmap ရှိတော့ ကိုယ့် Team Member တွေဖြစ်ဖြစ်၊ CEO ဒါမှမဟုတ် Investor တွေနဲ့ပဲပြောပြော အသုံးဝင်ပါလိမ့်မယ်။ ဒါဆို Product Roadmap ဘယ်လိုဆွဲရမလဲလို့မေးမယ် ။ အလုပ်အဖြစ်ဆုံး Product Roadmap Template ဆိုပြီးတော့မရှိပါဘူး။ မိမိ Roadmap ကို ကြည့်မယ့်လူပေါ်မူတည်ပြီး Roadmap ဒီဇိုင်းတွေကပြောင်းလဲရပါမယ်။ ဥပမာ… CEO က Timeline တွေနဲ့ ဘယ်နေ့ဘာ Feature ပြီးမှာလဲကို ကြည့်ချင်နေတဲ့အချိန် ကိုယ်က Feature List ပဲ သွားပြလို့မရပါဘူး။ Template မရှိပေမယ့် ဒီနေရာမှာ Share ပေးချင်တာက ကျွန်တော့် အတွက် အလုပ်ဖြစ်ခဲ့တဲ့ Roadmap Key Components တွေနဲ့ တခြား popular ဖြစ်တဲ့ Product Roadmap တွေကို ဝေမျှပေးသွားပါမယ်။ Product Roadmap မှာ အတွေ့အများဆုံးက Quarterly Roadmap (Q1,