Skip to main content

Spotify ရဲ့ နာမည်ကြီး Product Squad Model

Digital Product လောကမှာ Popular ဖြစ်ပြီး တော်တော်များများလည်း သဘောကျကြတဲ့ Product Team Model တစ်ခုအကြောင်းကို ဝေမျှချင်ပါတယ်။ အဲဒါကတော့ Spotify ရဲ့ နာမည်ကြီးတဲ့ Product Squad ဆိုတဲ့ Product Team Model ပဲ ဖြစ်ပါတယ်။

Spotify က ၂၀၁၂ ခုနှစ်မှာ သူတို့ Engineering Team ရဲ့ Agile နဲ့ အလုပ်လုပ်နေတဲ့ပုံစံကနေ ပိုကောင်းအောင်ပြင်ဆင်ပြောင်းလဲခဲ့ပြီး လူအများကိုလည်း သူတို့အသုံးပြုနေတဲ့ “Spitify Engineering Culture” အကြောင်းကို မိတ်ဆက်ခဲ့ပါတယ်။ ဒါက အခုပြောမယ့် Product Squad ဖြစ်လာပုံပါ။ အောင်မြင်တဲ့ Product Team တွေ ဘယ်လိုအလုပ်လုပ်ကြလဲဆိုတာ သိလေ၊ ကိုယ်နဲ့ကိုက်ညီပြီး ကောင်းမွန်တဲ့ Method တွေကို လက်ခံကျင့်သုံးကြည့်နိုင်ဖို့ အခွင့်အလမ်းများလေဆိုတော့ သင်လည်း Product Squad က သင့် Product Team နဲ့ ကိုက်ညီမလားဆိုတာကို စိတ်ဝင်စားမှာ အသေအချာပါပဲ။


Spotify ရဲ့ Product Squad က Cross-functional Team ပုံစံကိုအခြေခံပါတယ်။ Team တစ်ခုစီမှာ Product Owner တစ်ယောက်စီ နဲ့ Developers တွေ စုစုပေါင်း ၈ယောက်ပါဝင်ပြီး Squad လို့ သုံးနှုန်းပါတယ်။ Squad တစ်ခုစီက Product တွေရဲ့ သတ်မှတ်ထားတဲ့ အပိုင်းတစ်ခုစီကို တာဝန်ယူ ဖြေရှင်းကြပါတယ်။ Function အပိုင်းတစ်ခု၊ Area တစ်ခုကို ပိုင်ပိုင်နိုင်နိုင် ကျွမ်းကျွမ်းကျင်ကျင်ရှိပြီး Product တွေမှာ အဲဒီ Fuction ပိုင်းပါလာရင် သူတို့ Team က တာဝန်ယူလုပ်ဆောင်ပါတယ်။ ဥပမာ – App ထဲက သီချင်းရှာဖွေတဲ့ Search အပိုင်း ဆိုပါစို့။ Search ကို တာဝန်ယူတဲ့ Squad က App တစ်ခု (သို့မဟုတ်) Company မှာရှိတဲ့ App တွေထဲမှာ Search နဲ့ဆိုင်တဲ့ အပိုင်းတွေဆို သူတို့က Develop လုပ်ပါတယ်။ ဘယ်လိုပုံစံနဲ့ User တွေကို အသင့်တော်ဆုံး၊ အကောင်းဆုံး Search Result နဲ့ Experience ကိုပေးမလဲဆိုတာကို အဲ့ Squad ကပဲ Research လုပ်ပြီး Optimize လုပ်ပါတယ်။



Squad တစ်ခုမှာ Design ကနေ Product ထွက်တဲ့အထိ၊ Frontend, Backend ကျွမ်းကျင်သူအသီးသီးပါဝင်ကြလို့ Product Area တစ်ခုကို အစ-အဆုံး တာဝန်ယူ၊ Ownership ယူနိုင်ကြပါတယ်။ အဲဒါကြောင့် Squad က Startup အသေးလေးနဲ့တောင် တူတယ်လို့ ပြောကြပါတယ်။ Squad ရဲ့ အဓိက mission က Product ထဲမှာရှိတဲ့ Challenge တစ်ခုခုကို ဖြေရှင်းဖို့၊ ပိုကောင်းလာအောင်လုပ်ဖို့ပဲ ဖြစ်ပေမယ့် Product ရဲ့ Overall Mission နဲ့ လွဲတဲ့ Solution တွေတော့ လုပ်လို့ မရဘူးပေါ့။

Product Squad Model က ကိုယ့် Product အမျိုးအစားနဲ့ Organization ပေါ်မူတည်ပြီး အားသာချက် / အားနည်းချက်တွေ ရှိနိုင်ပါတယ်။ ကောင်းတဲ့အချက်တွေက Squad တစ်ခုဆီက Product Area တစ်ခုဆီကို ကောင်းကောင်းပိုင်ပိုင်နိုင်နိုင်ရှိတာကြောင့် Function တစ်ခုဆီ နဲ့ပတ်သက်ရင် ဘာလာလာ ဒေါင်းတယ်ဆိုတဲ့ Team တွေ ရှိလာတာပါပဲ။ Squad တွေကို လုပ်ပိုင်ခွင့် (Autonomy) လည်း ပေးထားတာကြောင့် Development နဲ့ Optimization တွေမှာ ပိုမိုကောင်းမွန်တဲ့ Idea တွေကို မြန်မြန်အကောင်အထည်ဖော်နိုင်၊ Release လုပ်နိုင်ပါတယ်။ အားနည်းချက်အနေနဲ့ Squad တွေက အပိုင်းတစ်ပိုင်းကိုပဲ ကောင်းကောင်းသိပြီး Product ကိုခြုံငုံပြီး မသိတာတွေလည်းဖြစ်လာနိုင်ပါတယ်။ ဒါ့အပြင် Squad တွေကို လုပ်ပိုင်ခွင့်အများကြီး ပေးထားခြင်းကလည်း Product Vision နဲ့ Squad တွေ Align လုပ်တဲ့နေရာမှာ လွတ်သွားတာတွေ ရှိနိုင်ပါတယ်။ ပိုအရေးကြီးတာက ကိုယ့် Product က အဲ့လို သီးသန့် Function Expert တွေရှိဖို့မလိုတာမျိုးမှာ အတင်း Product Squad ကို Adapt လုပ်နေတာ အကျိုးမရှိဖြစ်နိုင်ပါတယ်။

Product Squad က အစမှာတင် မိတ်ဆက်ရှင်းပြတဲ့ Video က ပေါက်သွားခဲ့ပြီး တော်တော်များများသဘောကျခဲ့သလို Company တွေကလည်း မိမိတို့ Product Team တွေမှာ Apply လိုက်လုပ်ကြည့်ခဲ့ကြတာတွေ တွေ့ရပါတယ်။ Spotify ကိုယ်တိုင်က စမိတ်ဆက်တည်းက သူတို့က Product Squad ကို အကောင်းဆုံးရလဒ်ရအောင် လိုအပ်တဲ့အပြောင်းအလဲတွေလုပ်ရင်း ကြိုးစားနေတုန်းအဆင့်လို ထည့်ပြောခဲ့ပါတယ်။ အချို့က အဲ့ဒါကို သတိမမူဘဲ ဒီ Structure အတိုင်း မရရအောင် တစ်ထပ်တည်း Copy လိုက်ကူးပြီးလုပ်ကြရင်း အဆင်မပြေတာတွေလည်း ရှိခဲ့ကြပါတယ်။




ဒီပုံက Product Squad Model ကို အသေးစိတ်ရှင်းပြတဲ့ Video ထဲက Product Squad တွေ အလုပ်လုပ်ပုံ Workflow တစ်ခုလုံးကို ရေးဆွဲထားတဲ့ပုံပါ။ Mission တွေနဲ့ အလုပ်လုပ်ပုံ အသေးစိတ်ကိုတော့ စိတ်ဝင်စားရင် ကြည့်လို့ရအောင် Spotify ရဲ့ Product Squad Intro Video link နဲ့ အခြားရှုထောင့်တွေက ရေးထားကြတဲ့ link တွေကိုပါ အောက်ဆုံးမှာ ထည့်ပေးထားပါတယ်။

“ကိုယ့် လက်ရှိ Product Team ကိုရော Product Squad ကို ပြောင်းကြည့်သင့်လား၊ သို့မဟုတ် အခြား Team ပုံစံတွေရော စမ်းကြည့်သင့်လား”

Product Team မှာက Agile Mindset အတိုင်း လိုအပ်ရင် လိုအပ်သလို အပြောင်းအလဲ လုပ်တာကောင်းပါတယ်။ တစ်ကြိမ်တည်းနဲ့ အကောင်းဆုံးကို ရဖို့ထပ်၊ ထပ်တလဲလဲ ပိုကောင်းအောင် ပြုပြင်ပြီး လိုချင်တဲ့ ရလဒ်ဆီရောက်အောင်သွားရမှာပါ။ Product Team ကို မိမိတို့နဲ့ကိုက်ညီတဲ့ Team Structure ရအောင် တဖြည်းဖြည်းချင်း အပြောင်းအလဲလုပ်သွားနိုင်ပါတယ်။

သို့သော် ကျွန်တော်တို့ သတိထားရမှာက ကိုယ်လိုချင်တာကို သိဖို့ပါ။ လုပ်လိုက်တဲ့ အပြောင်းအလဲ ကိုယ့်ဆီမှာလက်ရှိဖြစ်နေတဲ့ ပြဿနာကိုဖြေရှင်းပေးနိုင်မှာလား၊ ပိုကောင်းသွားစေမှာလား ဆိုတာကိုသုံးသပ်ဖို့ ပိုအရေးကြီးပါတယ်။ Company A က Method A ကိုသုံးတာ အောင်မြင်လို့၊ ငါတို့ Team တစ်ခုလုံးကိုလည်း Method A လိုက်ပြောင်းမယ် ဆိုတာမျိုး မြန်မြန်ဆန်ဆန် ဆုံးဖြတ်ချက်ချတာက Product Team ကို မလိုအပ်ဘဲ ဝန်ပိစေနိုင်သလို၊ ကိုယ်နဲ့မကိုက်ရင် Failure ဖြစ်နိုင်ချေလည်း များပါတယ်။ နည်းလမ်းတစ်ခုခုက ကိုယ်နဲ့ကိုက်ညီတယ်ထင်ရင်တော့ Team အသေးလေးဖွဲ့ပြီး Pilot အဆင့်နဲ့ စတင်ပြီး လက်တွေ့စမ်းသပ်တာမျိုး လုပ်ကြည့်သင့်ပါတယ်။

----

နောက်ထပ် ဖတ်ချင်တဲ့ 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 ကို အပြည

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 တွေက