Skip to main content

Process Flowchart တစ်ခုဘယ်လိုဆွဲမလဲ

Process Flowchart က လူတိုင်းနဲ့ ရင်းနှီးပြီးသားဖြစ်နိုင်ပါတယ်။ ကျွန်တော်တို့လို Product Manager တွေအတွက်တေ့ာ Developers တွေနဲ့ဖြစ်စေ၊ Business ဘက်နဲ့ဖြစ်စေ ပြောဆိုဆက်ဆံရတဲ့အခါ မရှိမဖြစ် အသုံးပြုကြပါတယ်။ Background အမျိုးမျိုးကသူတွေနဲ့ Communicate လုပ်ရာမှာ ရှင်းရှင်းလင်းလင်း နားလည်လွယ်အောင် အထောက်အကူပြုပေးနိုင်တဲ့ Tool ဖြစ်လို့ပါ။ Meeting ထဲမှာ စကားနဲ့ Process ကို ရှင်းပြနေတာထက် ပုံနဲ့ဆွဲပြီးရှင်းပြတာက ပိုမိုထိရောက်ပါတယ်။ တခါတလေ Flowchart ပြရုံနဲ့ Process တစ်ခုလုံးသဘောပေါက်သွားပြီး အသေးစိတ်ရှင်းပြဖို့ မလိုအပ်လောက်အောင်ထိပါ အကျိုးရှိတတ်ပါတယ်။



Process Flowchart က ရင်းနှီးပြီးသားဖြစ်ကြပေမယ့် မြင်နေကြဖြစ်ရုံနဲ့ ကိုယ်တိုင်လက်တန်းဆွဲဖို့က ထင်သလောက် မလွယ်ကူပါဘူး။ Product Manager တစ်ယောက်အနေနဲ့ ကိုယ်ကိုယ်တိုင် PRD (Product Requriements Document) တွေရေး Process Flowchart တွေဆွဲဖို့ လိုလာပြီဆိုရင် လွယ်လွယ်ကူကူဆွဲနိုင်ဖို့ အခြေခံသိသင့်တဲ့ အချက်တွေကို ဝေမျှသွားပါမယ်။

Process ဆိုတာ အလုပ်တစ်ခု ပြီးမြောက်ဖို့ တစ်ဆင့်ပြီးတစ်ဆင့် ဆောင်ရွက်ရတဲ့ လုပ်ငန်းစဥ် ဖြစ်ပါတယ်။ Process Flowchart ကတော့ အဲဒီ Process တစ်ခုကို ပိုမိုမြင်သာဖို့ ပုံကားချပ်ပုံစံ ရေးဆွဲပြခြင်းဖြစ်ပါတယ်။

ဒါဆို ဘာလို့ Process Flowchart ဆွဲကြတာလဲ။
  1. Process တွေကို Documents ပြင်ဆင်ဖို့ (Documentation)
  2. Process တွေကို ပိုမိုမြင်သာစေဖို့ (Visualization)
  3. Process ထဲက ကွာဟချက်နဲ့ အပိုအဆင့်များကို ဖယ်ရှားဖို့ (Identify Gaps and Inefficiencies) ရေးဆွဲကြခြင်းဖြစ်ပါတယ်။
ဆက်ပြီးတော့ Process Flowchart တစ်ခုဆွဲရာမှာ အသုံးများလေ့ရှိတဲ့ နည်းလမ်းတွေကို ‌ဝေမျှသွားမှာဖြစ်ပါတယ်။
ပထမဆုံး Process Flowchart တစ်ခုဆွဲရာမှာ လိုအပ်တဲ့ သင်္ကေတ(Symbol) ကို အရင်လေ့လာကြည့်ရအောင်။

Symbols
၁။ Start and End Symbol
Process Flowchart တစ်ခုမှာ အမြဲတမ်း Start နဲ့ End symbol ရှိရပါတယ်။ ဒီ symbol နှစ်ခုက Process တစ်ခု ဘယ်က”စ”လဲ နဲ့၊ ဘယ်မှာ”ဆုံး”လဲကို ရှင်းလင်းပြခြင်းဖြစ်ပါတယ်။ ဘဲဥပုံ စက်ဝိုင်းပုံစံ ရေးဆွဲကြပြီးတော့ အထဲမှာ Start ဒါမှမဟုတ် End လို့ရေးသားကြပါတယ်။ Start ကိုတော့ အထင်ရှားဆုံးမြင်ရဖို့ Flowchart ရဲ့ ဘယ်ဘက် ထိပ်ဆုံးမှာဆွဲရပါတယ်။ End ကိုတော့ ဖြစ်နိုင်ရင် ညာဘက်အောက်ဆုံးမှာ ဆွဲကြပါတယ်။ ပိုမိုမြင်သာစေဖို့ ရည်ရွယ်လို့ပါ။



၂။ Process Symbol
Task တခုချင်းဆီကို Process Symbol တစ်ခုချင်းဆီနဲ့ ကိုယ်စားပြုပါတယ်။ ပုံစံအားဖြင့် လေးထောင့်ပုံ ထိပ်ဝိုင်းဝိုင်းရှိတတ်ကြပါတယ်။ Symbol ထဲမှာ Verb (ကြိယာ) ပုံစံ နဲ့ စပြီး Noun (နာမ်) နဲ့ အဆုံးသတ်ပါတယ်။ ဥပမာ...Write a Blog။
Best Practice ကတော့ တိုတိုနဲ့ လိုရင်းကို ရေးသားခြင်းဖြစ်ပါတယ်။ ကျွန်တော်တို့ အမှတ်ရနေရမှာက Process Flowchart ဆိုတာ သူများနဲ့ ပြောဆိုရာမှာ လွယ်ကူမြင်သာစေရန် အသုံးပြုခြင်းဖြစ်ပါတယ်။ ဒါကြောင့် ရိုးရှင်းပြီး မြင်သာတဲ့ စာသားများကို အသုံးပြုတာပိုကောင်းပါတယ်။


၃။ Sequence (သို့) Flow Direction
Process Symbol များ တစ်ခုနဲ့တစ်ခု ချိတ်ဆက်ဖို့ Direction Symbol ကို သုံးရပါတယ်။ ပထမ Process ပြီးရင် နောက် Process သွားတယ်ဆိုတဲ့ လမ်းညွှန် တစ်ခုဖြစ်ပြီး Arrow ပုံစံ ဆွဲတတ်ကြပါတယ်။ Process Direction က Process တစ်ခုကနေ နှစ်ခု၊သုံးခု ခွာ မထွက်သင့်ပါဘူး။ ဖြစ်နိုင်ရင် Arrow အချင်းချင်းလဲ မထပ်သင့်ပါဘူး။

၄။ Decision Symbol
တချို့ Process Task တွေက တစ်ခုနဲ့တစ်ခုကြားမှာ Condition တွေရှိတတ်ပါတယ်။ ဆိုလိုချင်တာက ဒီ Process A ပြီးသွားရင် Condition တစ်ခုပေါ်မူတည်ပြီး Process B လုပ်မယ် / မလုပ်ဖူး ဆိုတာမျိုး ဆုံးဖြတ်ရတာ ရှိတတ်ပါတယ်။ အဲ့အခါမှာ Decision Symbol ကအသုံးဝင်ပါတယ်။ Symbol ကို Diamond ပုံစံဆွဲတတ်ကြပါတယ်။ Decision Symbol ကိုထည့်ဆွဲရာမှာ Decision တစ်ခုထွက်ဖို့ Condition ကို ကိုယ်စားပြုတဲ့ မေးခွန်းရှိရပါတယ်။ အဲ့ဒါကြောင့် Decision Symbol ထဲက စာသားမှာ မေးခွန်းများဖြစ်ပြီး Arrow ပေါ်မှာ Decision ရဲ့ Yes (or) No ကို ထည့်ပေးပါတယ်။


၅။ Input and Output Symbol
Input နဲ့ Output Symbol တွေကိုတော့ parallelogram နဲ့ဆွဲကြပြီးပါတယ်။ Process တစ်ခုထဲ Information တစ်ခုဝင်တာပဲဖြစ်ဖြစ်၊ Process တစ်ခုထဲက Information တစ်ခုပြန်ထွက်တာပဲဖြစ်ဖြစ် Input/ Output Symbol ကိုသုံးပါတယ်။ ဒီ Symbol နှစ်ခုကတော့ Flowchart ထဲသိပ်ထည့်မဆွဲတတ်ဘဲ အဲ့ဒီအစား Process Symbol နဲ့ ဆွဲလေ့ရှိပါတယ်။ Flowchart ရဲ့ အဓိက ရည်ရွယ်ချက်က ကြည့်တဲ့လူ လွယ်လွယ်ကူကူ မြင်သာဖို့ဆိုတော့ Input/ Output Symbol တွေသုံးမလား၊ Process Symbol ပဲသုံးမလားဆိုတာကတော့ မိမိကိုယ်တိုင်ဆုံးဖြတ် ကြည့်ပါ။


Swim-lanes
Process Flowchart မှာ ပါတဲ့ Symbol တွေအကြောင်းသိပြီးတော့ နောက်ထပ် Flowchart မှာ ပိုမို မြင်သာစေဖို့ထည့်ဆွဲတတ်ကျတဲ့ Swimlanes တွေအကြောင်း လေ့လာကြည့်ရအောင်။ Swimlane ရဲ့ အဓိက ရည်ရွယ်ချက်ကတော့ Process တွေကို Cateogrize လုပ်ဖို့ပါ။ Swimlane ကို ဘယ်လို အခြေအနေမှာ သုံးဖို့လိုအပ်လဲဆိုတော့ Process မှာ ပါဝင်တဲ့ User / Group / Department တွေများတာ၊ Application Area တွေမတူတာ စသဖြင့် ပုံမှန်ထပ် ပိုရှုပ်ထွေးတဲ့ Process တွေမှာ ရှင်းရှင်းလင်းလင်း မြင်သာဖို့ သုံးကြပါတယ်။

Swimlane တွေကို အလျားလိုက် (သို့) ဒေါင်လိုက် ထားနိုင်ပြီး Swimlane တစ်ခုချင်းက မိမိ Category ခွဲမယ့် User, Group, Application Area စတာတွေကို ကိုယ်စားပြုပါတယ်။ ခွဲလိုက်တဲ့ Category နဲ့ဆိုင်တဲ့ Process တွေ၊ Decision တွေအားလုံးကို သက်ဆိုင်ရာ Swimlane ထဲမှာ ထည့်ဆွဲပေးခြင်းဖြင့် Flowchart က ဘယ်အပိုင်းတွေက ဘယ်သူတွေနဲ့ သက်ဆိုင်တယ်ဆိုတာမျိုး ပိုမိုနားလည်လွယ်စေတာပါ။ Swimlane တွေ တစ်ခုနဲ့တစ်ခု မြင်သာဖို့ မတူတဲ့ Background Color တွေနဲ့ ထားတတ်ကြပါတယ်။ 
--------
Symbol တွေ Swimlane တွေအကြောင်းသိပြီဆိုရင် ပိုမို မြင်သာတဲ့ Process Flowchart တွေ ဆွဲဖို့ အဆင်သင့်ဖြစ်ပါပြီ။ မိမိ Process Flowchart မှာ Information တွေပိုထည့်ချင်သေးရင်တော့ နောက်တစ်ပတ် ရေးမယ့် Advanced Symbol တွေကို ဆက်ဖတ်ရှုဖို့ အကြံပြုပါတယ်။ နောက်ထပ် ဖတ်ချင်တဲ့ Topic တွေရှိရင်လည်း ဒီ Google Form ကနေတဆင့် အကြံပေးနိုင်ပါတယ်။

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

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 ကို ပြင်ဆင်ကြ