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 အဆင့်နဲ့ စတင်ပြီး လက်တွေ့စမ်းသပ်တာမျိုး လုပ်ကြည့်သင့်ပါတယ်။
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 အဆင့်နဲ့ စတင်ပြီး လက်တွေ့စမ်းသပ်တာမျိုး လုပ်ကြည့်သင့်ပါတယ်။
- Scaling Agile @ Spotify
- Spotify Engineering Culture (Part 1)
- Spotify Engineering Culture (Part 2)
- Spotify’s Failed #SquadGoals
- You can do better than the Spotify Model
----
နောက်ထပ် ဖတ်ချင်တဲ့ 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