PM တွေကို သိစေချင်

Enhancing Communication Between Developers and PM

နိဒါန်း

ဒီလောကထဲမှာ ပြောကြတာက PM နဲ့ Developer ဆိုတာက မတည့်အတူနေ ကြောင်နဲ့ကြွက်လိုပဲပေါ့။ PM ကလည်း assign ပေါင်းစုံချပြီး developer ဆီက မရမက ညှစ်ထုတ်မယ်၊ developers တွေကလည်း task updates, timelines တွေနဲ့ ပတ်သတ်ပြီး လိုသလိုလှည့်ပတ်မယ် စသည်ပေါ့။

တကယ်လို့ သင်တို့စိတ်ထဲမှာ PM ဆိုတာ ငါ့တို့ကို assign ချပြီး နေ့တိုင်း status ကောက်မယ်၊ customer နဲ့ ဖုန်းပြောပြီး report တင်ရုံကလွဲလို့ ဘာမှအလုပ်မရှိဘူးလို့ မြင်နေရင်တော့ တကယ်ကောင်းတဲ့ PM မျိုးနဲ့ အလုပ်မလုပ်ဖူးသေးလို့ပါ လို့ပဲ ပြောချင်ပါတယ်။

ဒီဆောင်းပါးမှာတော့ PM တွေကို ဘာဖြစ်လို့ လိုအပ်လဲဆိုတာနဲ့ သူတို့နဲ့ ဆယ်စုနှစ် ၁ခုကျော်တွဲလုပ်လာတဲ့ developer တစ်ယောက်အနေနဲ့ ဖြစ်စေချင်တာလေးတွေကို အကြံပေးချင်လို့ ရေးရခြင်းဖြစ်ပါတယ်။

PM ဆိုတာ Load Balancer

အဓိကတော့ web server ရှေ့မှာ load balancer ၁လုံး ခံလိုက်သလိုမျိုး developer တွေကို လက်ရှိ project နဲ့ ပတ်သတ်တဲ့ requests (သို့) တစ်ခြားကိစ္စပေါင်းစုံနဲ့ အကူအညီလာတောင်းတဲ့ဟာတွေကို သက်ဆိုင်ရာ PM ဆီကို အရင်ပို့စေချင်တာပါ။ အဲဒါမှ PM အနေနဲ့ လက်ရှိ timeline နဲ့ချိန်ပြီး ငြင်းသင့်တာငြင်း၊ တစ်ခြား availiable resources ကို လွဲသင့်တာလွဲ၊​ လက်ခံရင်လည်း priority ခွဲပြီး assign ပြန်ချပေးတာမျိုး လုပ်လို့ရမှာပါ။

Dev တွေအနေနဲ့လည်း tasks သီးသန့် အာရုံစိုက်လို့ရရုံမက အဲဒိလို ticket ဖွင့်လို့မရတဲ့ဟာတွေအတွက် အချိန်တွေသုံးလိုက်ရတာကိုလည်း ကာကွယ်ပြီးသားဖြစ်ပါလိမ့်မယ်။ ကိုယ်က daily meeting မှာ report ပြန်တင်ရင်တောင် လုပ်ရတဲ့အနည်းအများကို PM က ခန့်မှန်းဖို့ ခက်တာ စတာမျိုး ဖြစ်တက်ပါတယ်။ ဒါကတော့ company policy နဲ့ လည်း ဆိုင်ပါတယ်၊ အဓိကတော့ resource တစ်ခုကိုယူသုံးမယ်ဆို သက်ဆိုင်ရာ PM ဆီမှာ အရင်ခွင့်တောင်းစေချင်တာပါ။

PM ဆိုတာ Process Manger

PM ရှိရခြင်းရဲ့ အကျိုးကျေးဇူးက သီးသန့်ဖြစ်နေတဲ့ resources တွေကို Motherboard လိုမျိုး သူ့လက်အောက်မှာ အတူတူအလုပ်လုပ်စေတာပါ။ အဲဒိနေရာမှာလည်း ဘယ်လိုချိတ်ဆက်မလဲဆိုတဲ့ procedures တွေကို သေချာသတ်မှတ်ပြီး အလုပ်ဖြစ်လား ကြည့်ပေးနိုင်ရင်ကို လုံးဝအဆင်ပြေတယ်။

ဥပမာ client ဆီက new feature တစ်ခုလာတိုင်း dev တွေကို ရော့အင့်ဆိုပြီး ထိုးပေးလိုက်တာက actual coding ပေါ်မှာ design ရော business logic ပါ ခဏခဏပြောင်းနိုင်တာမို့ အထိနာလိမ့်မယ် (အထူးသဖြင့် backend သမားတွေ)။ ဒါကိုဖြေရှင်းဖို့ product designer အရင်ခံပြီး Figma မှာ စိတ်ကြိုက် stimulate လုပ်မယ်၊ အကုန်လုံးသေချာပြီဆိုမှ development စလိုက်တာက လူပိုသက်သာပြီး အချိန်ပိုထွက်လာမယ် စသည်ပေါ့။

နောက်ပြီး management style နဲ့ processes တွေကို ပုံသေမထားပဲ​ project nature, client behaviour, development team, timelines စတာတွေ အပေါ်မူတည်ပြီး လိုသလိုချိန်ဆပြီး သွားဖို့ပါ။ ဥပမာ timeline flexible ဖြစ်တဲ့ projects တွေဆို စာသင်ပေးရတာကြိုက်တဲ့ senior ကိုမှ junior/interns တွေနဲ့ တွဲပေးတာမျိုးပေါ့။ ကိုယ်သုံးလိုက်တဲ့ strategy ကောင်းရင် ကောင်းသလို development team ရဲ့ productivty အတွက် အများကြီးအထောက်အကူဖြစ်ပါတယ်။

PM ဆိုတာ Don Corleone

The Godfather ရုပ်ရှင်ကြည့်ဖူးရင် သိမှာပါ၊ Don Corleone နဲ့ အလုပ်တွဲလုပ်တိုင်း သူ တောင်းဆိုတာကိုသာပေးရင် ကိုယ့်ကိုအပြည့်အဝကာကွယ်ပေးတယ်။ PM ဆိုတာလည်း တကယ်တော့ development team ရဲ့ Godfather ပါပဲ။ Tasks တွေကို deadline မတိုင်ခင် quality ကောင်းကောင်းနဲ့ ပြီးစေချင်တယ်မလား၊ အဲအတိုင်းဖြစ်စေရမယ်၊ ဒါပေမယ့် ကိုယ့်ကိုတော့ ကာကွယ်ပေးစေချင်တယ်။

• Client ဘက်ကနေ requirement changes တွေ ခဏခဏလုပ်တာ၊​ out of scope features တွေကို ညာတာပါတေးနဲ့ တောင်းတာ
• Dev team က feature release ပြီးတော့မှ designer ဘက်က ပိုလှအောင်ဆိုပြီး update ခဏခဏလုပ်တာ၊ timeline နဲ့ မကိုက်တဲ့ဟာတွေ အတင်းထည့်တာမျိုး
• တစ်ခြား teams ကနေ resource ယူသုံးတာ ခံရတာမျိုး

အဲလိုအခြေအနေတွေမှာ သူတို့ဖြစ်ချင်တာလုပ်ပေးလိုက်၊ ဒါပေမယ့် ငါတော့ timeline မတိုးပေးနိုင်ဘူးဆိုတာမျိုးက tech team ကို stress အရမ်းပိစေပါတယ်။ အလုပ်သဘောအရ အမြဲငြင်းလို့မရဘူးဆိုပေမယ့် အတက်နိုင်ဆုံးတော့ ကိုယ့်လူတွေဘက်က ရပ်တည်ပြီး team ကို ကာကွယ်ပေးစေချင်တာပါ။ (Project bonus တွေရှိခဲ့ရင်လည််း အတက်နိုင်ဆုံး များများတောင်းပေးစေချင်တာပေါ့)

PM နဲ့ Meeting

Developers တွေက အနည်းနဲ့ အများဆိုသလို meeting trauma ရှိကြပါတယ်။ စကားအများကြီးပြောနေကျ career မဟုတ်တော့ social anxiety ကြောင့်လည်းပါသလို အဓိကတော့ ဒီအချက်တွေကြာင့်ပါ။

• တစ်ခါပါသွားပြီဟေ့ဆိုရင် အနည်းဆုံး နာရီဝက် ၁နာရီကြာပါတယ်
• Meeting က ပြန်ထွက်လာရင်လည်း တော်တော်နဲ့ အာရုံပြန်စိုက်လို့ မရတာပါ
• Dev တွေက ပြဿနာတစ်ခုကို deep analysis လုပ်ပြီး ချိတ်ဆက်စဥ်းစားတက်တဲ့ type မျိုးမို့ meeting လို အကြောင်းအရာပေါင်းစုံကို တစ်ထိုင်တည်းပြောသွားတာမျိုးက information overload ဖြစ်ပြီး စိတ်ရှုပ်စေပါတယ်
• Development စမှ မေးခွန်းတွေပေါ်လာရင်လည်း meeting တုန်းက ဒါတွေဘာလို့မမေးခဲ့တာလည်းဆိုပြီး အပြစ်တင်ခံရတာလည်း ကြုံဖူးကြလို့ပါ
• Daily standup နဲ့ training ကလွဲလို့ ကျန် meeting အများစုမှာက Is it technically possible? ဆိုတာကိုပဲ “Yes” or “No” ဖြေစရာရှိတာမို့ motivation ကျသလို မဆိုင်တာဝင်ပါရတယ်ဆိုပြီး ခံစားရလို့ပါ

Dev တွေရဲ့ သဘောက project စတာနဲ့ သူတို့လိုချင်တာ (diagrams, design prototypes, user stories, etc.) အကုန်ပေးထားရင် သူတို့ဘာသာ ခေါင်းထဲမှာ အကုန်လုံးကို ဆက်စပ်ချိတ်ဆက်ပြီး စဥ်းစားမယ်၊ system design တစ်ခုဆောက်မယ်၊ အလုပ်လုပ်နေတာကို မြင်ယောင်မယ်၊ real world scenrions တွေ ထည့်စဥ်းစားမယ်၊ ပြီးရင် လိုချင်တာသိချင်တာတွေကို list down လုပ်ပြီး လာပြောမယ်စတဲ့ အလုပ်လုပ်ပုံ type မျိုးမို့ မလိုအပ်တဲ့ meeting တွေ အတက်နိုင်ဆုံး လျှော့ချပေးနိုင်ရင် အကောင်းဆုံးပါ။

PM နဲ့ Work-Life Balance

ကျွန်တော့် personal အနေနဲ့တော့ ကိုယ့်အလုပ်ချိန်ပြင်ပမှာ slack (သို့)​ phone call နဲ့ အလုပ်အကြောင်းလာပြောတာမျိုးတွေ တော်တော်ကိုမကြိုက်ဘူး (server ကျသွားတာလို urgent case ဆို တစ်မျိုးပေါ့)။ ငါ့အလုပ်ချိန်အတွင်းမှာ လုပ်စရာရှိတာ အာရုံစိုက်ပြီး သေချာလုပ်ပေးပြီးပြီ၊ ဘာလို့ ငါ့ကိုယ်ပိုင်အချိန်ကိုပါ အလွတ်မပေးရတာလဲဆိုပြီး စိတ်ပျက်တာထက် ရင်ထဲမှာမောသွားတယ်။

PM တွေအနေနဲ့ ပိတ်ရက်ပါမကျန် client နဲ့ deal လုပ်ရတယ်ဆိုတာ သိပေမယ့် work nature မတူတဲ့အတွက် ကိုယ့်ရဲ့ dev တွေကိုတော့ ရုံးချိန်ပြင်ပမှာ အပြည့်အဝ အနားပေးသင့်တယ်။

နိဂုံး

PM တွေရဲ့ တာဝန်က အတိုချုပ်ပြောရရင် project တစ်ခုကို timeline မတိုင်ခင် deliver လုပ်ပြီး profit margin များများကျန်အောင် လုပ်ရတာမို့ စောနကပြောတဲ့ဟာတွေ မလုပ်လည်းရတယ်လို့ တွေးလို့ရပါတယ်။​ Dev ဆိုတာကလည်း company hierarchy အရ PM ရဲ့ supervison အောက်မှာရှိတာမို့ ခိုင်းသမျှအကုန်လုပ်ပေးရမယ့် တာဝန်တော့ရှိပါတယ်။

ဒါပေမယ့် unofficial surveys တွေအရ ဝန်ထမ်းတွေ အလုပ်ထွက်ရတဲ့ အကြောင်းအရင်းတွေမှာ supervisor နဲ့ အဆင်မပြေလို့ ဆိုတာက ထိပ်ဆုံးမှာအမြဲရောက်နေကြမို့ အလုပ်သဘောဆက်ဆံရေးအပြင် ကိုယ့်အောက်ကလူတွေ အဆင်ပြေအောင် လုပ်ပေးနိုင်ရင်တော့ စိုင်းထီးဆိုင်သီချင်းလို “မောတော့မောတာပေါ့၊ ဒါပေမယ့် မမောဘူး” ဆိုပြီး ပျော်စရာပတ်ဝန်းကျင်တစ်ခုဖြစ်လာမှာပါ။