Tips & Tricks for Distributed Remote Collaboration

အပေါ်ယံလောက်ကြည့်ရင်တော့ ဒါဟာ Co-located team တွေလောက် အလုပ်မတွင်ဘူးထင်ရပေမဲ့ တကယ်ထိရောက်အောင်အလုပ်လုပ်တတ်ရင် Distributed Team ကလည်း သူ့ဟာနဲ့သူ သာတဲ့အချက်တွေရှိတယ်။ ဒီတော့...

Tips & Tricks for Distributed Remote Collaboration
Photo by Austin Distel / Unsplash

ကျွန်တော် ဒီဇင်ဘာ ၂၀၂၁ လောက်က စင်ကာပူ ကုမ္မဏ္ဏီတစ်ခုအတွက် Remote အလုပ်စလုပ်ဘူးတယ်။ (အဲတာမတိုင်ခင်ကတော့ Covid ကာလတုန်းက အိမ်ကလုပ်ဘူးပေမဲ့ တစ်ဖွဲ့လုံးက စံတော်ချိန်တူတူပဲဆိုတော့ Remote ရယ်တော့မဟုတ်ဘူး၊ Work from home လို့ပဲပြောလို့ရတယ်။) အဲတုန်းက မြန်မာအချိန်နဲ့ စင်ကာပူအချိန်နှစ်ခုပဲဆိုတော့ လုပ်ရတာ အဲလောက်ခက်တယ်ဆိုပြီးမရှိဘူး။ အဲလိုနဲ့ ထိုင်းရောက်တော့ Thoughtworks မှာ စလုပ်ခဲ့ရတဲ့ ပထမ ပရောဂျက်မှာ မလေး၊ ဖိလစ်ပိုင်၊ သြော်ဇီ၊ အင်ဒိုနီးရှား၊ ထိုင်း၊ အိန္ဒိယက သူတွေနဲ့ တစ်ဖွဲ့တည်းလုပ်ရတယ်။ အဲတော့မှ တကယ့် "Distributed Team" အတွေ့အကြုံကို ရခဲ့တယ်။ အဲလိုမျိုး စံတော်ချိန်တွေ၊ ယဉ်ကျေးမှု Culture တွေမတူညီတဲ့ သူတွေနဲ့ တွဲလုပ်တဲ့အခါမှာ ဘယ်လိုမျိုး အလုပ်တွင်အောင်လုပ်ရလဲဆိုတဲ့ လက်တွေ့ကျကျ လေ့လာခဲ့ရတယ်။

ရှေးရိုးစွဲ ကုမ္မဏ္ဏီတွေမှာဆို အလုပ်တွဲလုပ်ရတဲ့သူတွေက ရုံးခန်းတစ်ခုထဲမှာ တူတူရှိတာဖြစ်တော့ တစ်ခုခုစကားပြောစရာလိုတယ်ဆိုရင် ပုခုံးပုတ် အားလားမေးရုံပဲ။ နေရာအနှံ့ကနေလုပ်နေကြတဲ့ Distributed Team တွေမှာကျတော့ ဒီလိုမေးလို့မရဘူး။ ဒီတော့ Asynchronous Communication လို့ခေါ်တဲ့ ချက်ချင်းမေး၊ချက်ချင်းဖြေ မဟုတ်တဲ့ ဆက်သွယ်နည်းကို သုံးရတယ်။

Reference: Slack

အပေါ်ယံလောက်ကြည့်ရင်တော့ ဒါဟာ Co-located team တွေလောက် အလုပ်မတွင်ဘူးထင်ရပေမဲ့ တကယ်ထိရောက်အောင်အလုပ်လုပ်တတ်ရင် Distributed Team ကလည်း သူ့ဟာနဲ့သူ သာတဲ့အချက်တွေရှိတယ်။ ဒီတော့ ကျွန်တော့်လိုမျိုး အဝေးကနေအလုပ်လုပ်နေတဲ့ သူတွေအဖ်ို့ အထောက်အကူဖြစ်အောင် ကျွန်တော်ကိုယ်တိုင် ကျင့်သုံးနေတဲ့ သိုင်းလေးတွေ ချပြပေးမယ်။

Don't just say Hi

စာပို့စနစ်တွေမှာ စကားစရင် ဘယ်တော့မှ "Hi" "Hello" နဲ့ပဲမရပ်ထားနဲ့။ "Hi" ဆိုပြီး တစ်ဖက်လူ စကားပြန်ပြောတာကို စောင့်နေတာက မလိုအပ်ပဲ အချိန်တွေကုန်စေတယ်။ နောက်ပြီး "Hi" တစ်လုံးတည်းနဲ့ အခုချက်ချင်း စကားပြန်ရမဲ့ အရေးကြီးတဲ့ အကြောင်းအရာ ဟုတ်လား၊ မဟုတ်လား မကွဲပြားတာကြောင့် တစ်ဖက်လူက စကားပြန်ချင်မှ ပြန်လိမ့်မယ်။ ဒီတော့ "Hi" ဆိုပြီး စိမ်းသွားတာ ထိုင်မစောင့်ပဲ၊​ လိုချင်တာကို တစ်ခါတည်းတွဲမေး၊ တွဲပြောပါ။ ဥပမာ​- "Hi, just wanted to ask about XXX" ဆိုပြီး တကယ်လိုတာကို ရှင်းရှင်းလင်းလင်း ပြည့်ပြည့်စုံစုံမေးပါ။ "Hi" တင်မဟုတ်ဘူး၊ "အချိန်ရလား"တို့၊ "ပြောစရာရှိလို့ အားရင်ပြောဦး" တို့လည်း မလုပ်နဲ့။ လိုတာကို တိုက်ရိုက်ပြော။ ဒါဆိုတစ်ဖက်နဲ့တစ်ဖက် အချိန်တွေမလိုအပ်ပဲ မကုန်တော့ဘူး။ မရှင်းရင် NoHello ကိုဖတ်ကြည့်၊​ တစ်ဖက်ကအဲလို "hi" လာလုပ်ရင်လည်း အဲ့ NoHello link သာ ပြန်ပို့ပေးလိုက်၊ နောက်မလုပ်တော့အောင်လို့ 😆။​​ ဒီနည်းက အလုပ်ထဲမှာမဟုတ်ဘူး၊ ဘယ် စာတိုပိုတဲ့ App မှာမဆို လိုက်နာသင့်တဲ့ ကျင့်ဝတ်ပဲ။

Context is important

အပေါ်က တစ်ချက်မှာ ပြောထားတဲ့ "ရှင်းရှင်းလင်းလင်း ပြည့်ပြည့်စုံစုံ" ဆိုတဲ့နေရာမှာ ကိုယ့်အနေနဲ့ "Context" ကိုထည့်ပြောပေးဖို့လိုတယ်။ ရှေ့ကဘာတွေဖြစ်ထားတယ်၊ ဘယ်သူနဲ့ဘယ်လိုတွေ ဆွေးနွေးထားပြီးပြီလဲ အစရှိသဖြင့် ကိုယ်က သိပေမဲ့ တစ်ဖက်လူတွေက သိချင်မှာသိမယ်။​​​ ဒီတော့ တတ်နိုင်သလောက် ကိုယ်သိထားတဲ့ကိုပြောပေးဖို့လိုတယ်။ ဥပမာ Developer တွေရှိတဲ့ Group Chat ထဲမှာ မေးခွန်းမေးမယ်ဆို​ "ငါ ဒါကိုဘယ်လိုလုပ်ရမလဲ" ဆိုတာထက်​ "ငါက ဘယ်ပြဿနာကို ဘယ်လိုကြုံနေရလို့​ ဒီလိုရှင်းချင်တယ်။ အဲဒါဘယ်လိုလုပ်ရမလဲ" ဆိုပြီး ပြည့်ပြည့်စုံစုံပြောပေးရမယ်။ ဒါကို "XY Problem" လိုလည်းခေါ်ဝေါ်ကြတယ်။ "Y" ဆိုတဲ့ ဖြစ်နေတဲ့ပြဿနာကို မပြောပဲ​ ကိုယ်ထင်တဲ့အဖြေ "X" ကိုဘယ်လိုလုပ်ရမလဲမေးတဲ့အခါမှာ "X" ကိုတော့ရသွားပေမဲ့ ပြဿနာအရင်းအမြစ် "Y" ကို မပြေလည်စေတာမျိုးသော်လည်းကောင်း၊​ ပြေလည်ပေမဲ့ ထိရောက်တဲ့ နည်းလမ်း မဟုတ်တာသော်လည်းကောင်း ဖြစ်စေတတ်တယ်။

Source: https://sketchplanations.com/the-xy-problem

ဒီလို XY Problem မျိုးမဖြစ်စေဖို့ Remote အလုပ်လုပ်တဲ့အခါမှာ စာတိုတွေထက် အချက်အလက်ပြည့်ဝတဲ့ စာရှည်တွေကို ပိုပြီးသုံးသင့်ပါတယ်။ တကယ်လို့ ကိုယ်ရေးရမှာများတယ်ဆိုရင် အရေးကြီးတဲ့အကြောင်းအရာလောက်ပဲ အကျဉ်းချုပ်ပဲရေးပေးပြီး အသေးစိတ်သိချင်ရင် ဒီမှာဖတ်ပါဆိုပြီးတော့ Documentation Link တွေကိုတွဲပေးလို့ရပါတယ်။

Emoji are your friends 😤

အပြင်မှာဖြစ်ဖြစ်၊ Zoom မှာဖြစ်ဖြစ် စကားပြောရင် လူတစ်ယောက်ရဲ့ မျက်နှာအမူအရာ၊ ခန္ဓာကိုယ် အနေအထား (Body Language)၊ စကားလုံးတွေရဲ့ အသံအနိမ့်အမြင့် (tone) တွေကို ကြည့်ပြီး ဒီလူက စိတ်ဆိုးပြီးပြောတာလား၊ ရွဲ့နေတာလား၊ စနေတာလား အစရှိသဖြင့် ခွဲခြားလို့ရတယ်။ ဒါပေမဲ့ Slack တို့လို စာပို့စနစ်တွေမှာ စကားပြောတဲ့အခါကျတော့ ဒီလိုခွဲခြားရခက်တယ်။ ကိုယ်ပြောလိုက်တာက တစ်မျိုးဆိုပေမဲ့ တစ်ဖက်လူက တစ်မျိုးထင်သွားနိုင်တယ်။ ဥပမာ အနေနဲ့ "I guess it's my responsibility" (ပြောချင်တာ ငါ့တာဝန်ပေါ့) ဆိုပြီး ပြောတာမျိုးဆိုရင် ဒီလူက ရွဲ့နေတာလားဟ ဆိုပြီး ထင်နိုင်စရာရှိ်တယ်။​ ဒါပေမဲ့ "I guess it's my responsibility 🤣" ဆိုပြီး ပြောတာမျိုးကျတော့ ဒီလူ လာစနေတာပဲ ဆိုပြီး ဖြစ်သွားတယ်။ ကိုယ်နဲ့တွဲလုပ်နေတဲ့သူတွေက မတူညီတဲ့ယဉ်ကျေးမှုတွေကလာကြတာဖြစ်တဲ့အတွက်ကြောင့် စကားပြောတဲ့အခါမှာ အဓိပ္ပာယ်ကောက်မမှားဖို့ ဂရုစိုက်ဖို့လိုတယ်။ Emoji တွေက ဘာသာစကားတွေထက် ကိုယ်ရဲ့ စိတ်နေစိတ်ထားနဲ့ ဆိုလိုရင်းကို ဖော်ပြပေးတဲ့နေရာမှာ ပိုပြီးထိရောက်တယ်။ EmojiPasta လိုမျိုးရှုပ်ပွနေအောင် မသုံးနဲ့ပေါ့။ လုပ်ငန်းခွင်ထဲမှာ Emoji တွေသုံးပြီးပြောကြတာက အလုပ်ကို အလေးအနက်မထားဘူးဆိုတဲ့ အတွေးကိုဖျောက်ပြီး စာပို့စနစ်တွေမှာ Emoji သုံးဖို့ကို လက်မတွန့်ပါနဲ့။

Don't @ everyone

Remote Team တွေမှာနောက်လူတိုင်းလိုက်နာရမဲ့ အကျင့်က @ သုံးပြီး mention ခေါ်တဲ့အကျင့်ပဲ။​ Group Chat တွေထဲမှာ လူအများကြီးရှိတယ်ဆို အကုန်လုံးစီ မလိုအပ်တဲ့ အရေးမပါတဲ့စာတွေ (Stupid Pointless Annoying Message SPAM) မပိုမိအောင်@channel တို့၊ @everyone တို့လိုမျိုး အသုံးတွေ လျှောင်ရမယ်။ Mention ခေါ်ခါနီးတိုင်း ဒီလူက ဒါကို ချက်ချင်း သိဖို့ လိုမလား စဥ်းစားရမယ်၊ မလိုဘူး နောက်မှသိလည်းဖြစ်တယ်ဆိုရင် mention မခေါ်နဲ့။​​ ဒီတိုင်းပဲ သက်ဆိုင်ရာ channel မှာပဲစာပို့ထားလိုက်၊ နောက်သူအားရင် ဝင်ဖတ်လိမ့်မယ်။ တစ်ခုရှိတာက စကားဝိုင်းတစ်ခုမှာ ဘယ်သူလိုတယ်သိဖို့ ဆိုတာကလည်း ကိုယ်က ကိုယ့်လုပ်ကိုင်တဲ့ အဖွဲ့အစည်းအပေါ် အသိအမြင် (Organizational Awareness) တစ်ခုတော့ရှိရမယ်။

Keep your virtual workspace tidy

ရုံးတွေမှာ ကိုယ်အလုပ်လုပ်တဲ့နေရာဝန်းကျင်ကို ကိုယ်စိတ်တိုင်းကျ productive ဖြစ်အောင်ထားသလိုပဲ ကိုယ့် virtual workspace ကိုလည်း ဒီလိုပြင်ဆင်တတ်ရမယ်။ Slack သုံးတယ်ဆိုရင် Slack မှာ notification settings တွေကို ကိုယ်နဲ့ကိုက်အောင်ထားတာမျိုး၊ အရေးကြီးတဲ့ channel တွေကို စာအသစ်မှန်သမျှ noti ပို့ခိုင်းပြီး သိပ်အရေးမကြီးရင် mention ခေါ်မှ noti ပို့တာမျိုး ထိန်းညှိတတ်ရမယ်။ နောက် Sidebar မှာလည်းပွထနေအောင်မထားပဲ Starred Channel တွေ လုပ်ထားတာမျိုး၊ အမျိုးအစားခွဲပြီး ခေါင်းစဥ်လေးတွေအောက်မှာစုထားတာမျိုး၊​ စကားခဏခဏ သွားပြောရတဲ့သူဆိုရင်လည်း Pin လုပ်ထားတာမျိုး၊ ညနေအားမှ ကြည့်ရမဲ့ဟာကို မနက်တွေ့ကတည်းက Reminder သတ်မှတ်ထားတာမျိုး တွေနဲ့ ကိုယ့်ရဲ့ tool တွေကို သပ်ရပ်နေအောင်၊ အလုပ်လုပ်ရလွယ်အောင် ပြင်စင်တတ်ရမယ်။ ကိုယ်က Slack မကလို့ ဘာပဲသုံးသုံး Power features တွေနဲ့ ရင်းနှီးအောင် သင်ထားဖို့လိုတယ်။

Organizing Channel

Organize with Threads

Slack မှာ ဖြစ်ဖြစ်၊ Google Workspace ဖြစ်ဖြစ် ခုခေတ် စာပို့စနစ်တွေက Thread လို့ခေါ်တဲ့ (App မဟုတ်ဘူးနော် 😆) channel ထဲမှာ မပေါ်ပဲ ဆိုင်ရာစာအောက်မှာပဲ အစုလိုက်ပေါ်နေတဲ့ Feature တွေပါလာပြီ။

Slack Threads

တကယ်လို့ကိုယ်ပြောမဲ့ဟာက channel ထဲကလူတွေအကုန်သိစရာမလိုဘူး၊​ ဒီ topic အောက်မှာပဲဆို Threads ကိုသုံးပြီး ပြောလို့ရတယ်။ ဘာကောင်းလဲဆိုတော့ ဆိုင်ရာလေးတွေစုသွားတော့ နောင်တစ်ချိန်မှာကိုယ်က အကြောင်းအရာတစ်ခုကို ပြန်ရှာရမယ်ဆိုရင် သူနဲ့ဆိုင်တဲ့ သမိုင်းတစ်ခုလုံးကို အဲ့ Thread ထဲမှာဖတ်လို့ရတယ်။ Commit Message တွေမှာလည်း "သေချာသိချင်ရင် ဒီ Thread မှာသွားကြည့်ပါ" ဆိုပြီး Commit စာကိုယ်မှာ link ထည့်ပေးလိုက်လို့ရတယ်။

Align your meeting hours

စံတော်ချိန်မတူတဲ့သူတွေနဲ့လုပ်ရတဲ့အခါ အစည်းအဝေးတစ်ခု ချိန်းဖို့ တစ်အားခက်တယ်။ ဒါကို လွယ်ကူအောင်လို့ အားလုံးသတ်မှတ်ထားတဲ့ "Meeting hours" တစ်ခုရှိရမယ်။​ ဥပမာ သြော်ဇီတွေနဲ့တွဲလုပ်မယ်ဆိုရင် ကိုယ့်ရဲ့ ရန်ကုန်စံတော်ချိန် မနက် ၉ ကနေ နေ့လည် ၁ နာရီလောက်ထိက ဟိုမှာအလုပ်ချိန်အတွင်း ဖြစ်နေသေးတယ်။ ဆိုတော့ နှစ်ဘက်လုံး အလုပ်ချိန်ထပ်နေတဲ့ အချိန်တွေကို အစည်းအဝေးလုပ်ဖို့ အချိန်ဆိုပြီး သတ်မှတ်ရမယ်။ မတူညီတဲ့နိုင်ငံတွေများလာလေလေ (စံတော်ချိန်တွေများလာလေ) ဒီထပ်နေတဲ့အချိန်က နည်းသထက်နည်းလာတာမလို့ မလိုလားအပ်တဲ့ အချိန်ကုန်တဲ့ အစည်းအဝေးတွေကို လျှောင်ဖို့လည်းလိုအပ်တယ်။ တစ်ခုအသုံးဝင်တဲ့နည်းက အစည်းအဝေး booking လုပ်မယ်ဆို ကိုယ့် အဖွဲ့တစ်ခုလုံးပါတဲ့ Group Calendar တစ်ခုထားထား၊ ပြီးရင် အဲ့ Group Calendar နဲ့ ကိုယ့် Group ထဲကလူကိုပဲ Invite လုပ်ပေးရမယ်။ Invite တဲ့အခါမှာလည်း လိုအပ်တဲ့သူတွေကို ခေါ်ရမယ်။ ဒီလိုလုပ်တာဘာကောင်းလဲဆိုတော့

  1. ဘယ်သူတွေ ဘာလုပ်နေတယ်၊ ဘာတွေတော့ အဖွဲ့ထဲမှာ အရေးတကြီးပြောနေကြလဲဆိုတာကို မြင်ရတော့ ပွင့်လင်းတဲ့ Transparent Culture တစ်ခုကို တည်ဆောက်လို့ရမယ်။
  2. ကိုယ်နဲ့မဆိုင်တဲ့သူက Group calendar filter ကို ပိတ်လိုက်မယ်ဆိုရင် ကိုယ်နဲ့ ဆိုင်တဲ့ အစည်းအဝေးတွေကိုပဲ မြင်ရမယ်။
  3. ဒါပေမဲ့ ကိုယ်က နေ့လည်စာစားနေတုန်းဖြစ်ဖြစ်၊ အားနေတုန်းဖြစ်ဖြစ်၊ အစည်းအဝေးထဲမှာ ပြောနေကြတဲ့ အကြောင်းအရာကိုပဲ ဖြစ်ဖြစ် စိတ်ဝင်စားတယ်ဆိုရင် ကိုယ်ဝင်နားထောင်လို့ရမယ်။ (ကျင့်ဝတ်အရတော့ မိုက်ကရိုဖုန်းနဲ့ ဗီဒီယိုကိုတော့ ပိတ်ထားပေါ့ )

Don't wait to talk

တစ်ခုရှိတာက Meeting Hours ရှိတယ်ဆိုပြီး အဲ့အချိန်ရောက်မှ ပြောမယ်ဆိုပြီးမလုပ်ပါနဲ့။ ပြောစရာရှိတာကို အချိန်မဆွဲပဲ ပြည့်ပြည့်စုံစုံ ကြိုပြောထားပါ။ ဥပမာ ကျွန်တော်ဆိုရင် သြော်ဇီတွေနဲ့ တွဲလုပ်ပြီဆို ကိုယ့်အချိန်ညနေဘက် PR Review ပေးပြီဆိုရင် ပြည့်စုံအောင်ရေးပေးထားတယ်။ သူတို့မနက်ဘက် (ကိုယ်တွေထက်သူတို့က ရုံးတက်တာ ၃ နာရီလောက်စောတယ်) ရုံးတက်ပြီဆိုရင် ကျွန်တော်နိုးတဲ့အချိန်ကို စောင့်စရာမလိုပဲ ပြင်စရာရှိတာ ကြိုပြင်ထားလို့ရတယ်။ ကျွန်တော် အလုပ်တက်ချိန်ဆို သူတို့မှာ နေလည်ထမင်းစားနားချိန်။ အဲတော့ကျွန်တော်က သူတို့ပြင်ထားတာကို အရင်ဆုံး ဝင်ကြည့်ပေးတယ်။​ ဒါမှသူတို့ နေ့လည်ထမင်းစားပြီး ပြန်လာရင် ထပ်ပြင်စရာရှိတာပြင်ပြီး ကျွန်တော့်ကိုပြန်ပြောဖို့အချိန်ရမယ်။​ ဒီလိုမဟုတ်ပဲ တူတူအလုပ်လုပ်တဲ့အချိန်ကိုပဲ စောင့်ပြီး ပြောစရာရှိတာပြောမယ်ဆိုရင် နှစ်ဘက်လုံး အလုပ်မတွင်ပဲနေမယ်။

Feature Boundaries

Async လုပ်ကြတဲ့ ကုမ္မဏ္ဏီတွေမှာ အသင်းအဖွဲ့တစ်ခုနဲ့ နောက်တစ်ခု အချင်းချင်းပြောရတဲ့ "Cross-team communication" ကိုလျှော့လေ့ရှိကြတယ်။ ရုတ်တရက်ဆိုရင် "ဟင် မင်းတို့က ကုမ္မဏ္ဏီတစ်ခုတည်းကို အချင်းချင်းတွေ စကားမပြောကြဘူးလား" လို့မေးနိုင်ပေမဲ့ ကုမ္မဏ္ဏီအကြီးတွေမှာ တကယ်ကို cross-team စကားပြောရတာတွေ အများကြီးမရှိဘူး။ Feature-Aligned Team လို့ခေါ်တဲ့ Features ကိုင်တဲ့ အဖွဲ့တွေမှာ ကိုယ့် Feature ကဘယ်ကနေ ဘယ်ထိ ပိုင်တယ်ဆိုပြီး သေချာသတ်မှတ်ထားတာရှိရတယ်။ ကိုယ်ပိုင်တဲ့ Feature ကို ကိုယ်ကြိုက်တာပြင်၊ ဘယ်အဖွဲ့မှ လာတားလို့မရဘူး။ ဒီလို "Feature Boundary"လို့ခေါ်တဲ့ တစ်ဖွဲ့နဲ့တစ်ဖွဲ့ ပိုင်ဆင်မှုအပြည့်ပေးထားပြီဆိုနောက်ကနေပြီး ကိုယ်ပိုင်လုပ်ကိုင်ခွင့် (Autonomy)နဲ့ အတူ တာဝန်ယူမှု (Responsibility) တွေလည်းရှိလာတယ်။​ ဥပမာ တစ်ပတ်တစ်ခါ Release လုပ်မယ်ဆိုရင် ကိုယ့်အဖွဲ့အနေနဲ့ Software တစ်ခုလုံးသုံးမရအောင် ဖြစ်စေနိုင်တဲ့ Bug ပါတဲ့ Code တွေမတင်မိဖို့ ဂရုစိုက်ရတယ်။​​ ဒီလို ဂရုစိုက်ရတော့ Test တွေရေးရမယ်၊ Feature Toggle တွေသုံးရတယ် အစရှိသဖြင့် သေချာလုပ်ရတယ်။ Bug ဖြစ်ပြီဆိုလည်း ပါတဲ့ Feature ကဘာလဲဆိုတာသိတာနဲ့ ဘယ်အဖွဲ့က တာဝန်ရှိတာလဲဆိုတာ ချက်ချင်းသိနိုင်ပြီး တစ်ယောက်နဲ့တစ်ယောက် ဘော်လီဘော်ပုတ်ပြီး အငြင်းပွားနေစရာမလိုတော့ဘူး။ ပြောရရင် ပိုအလုပ်တွင်တယ်ပေါ့ဗျာ။ တစ်ချို့ကတော့ တည်နေရာအလိုက် Feature Team တွေခွဲတယ်။​ ဥပမာ ထိုင်းရုံးခန်းက A ကိုကိုင်၊ မလေးက B ကိုကိုင်ဆိုရင် တည်နေရာတစ်ခုတည်းကသူတွေအနေနဲ့ အချိန်တူတူလုပ်ရတော့ အလုပ်ပိုတွင်စေနိုင်တယ်။​ ဒီတော့ အဖွဲ့ကြီးလာပြီဆိုရင် Feature Boundary သတ်မှတ်ဖို့လည်းလိုတယ်။

💡
Feature Aligned Team တွေက တစ်ဖွဲ့နဲ့တစ်ဖွဲ့ အမြဲစကားမပြောကြတာတော့မဟုတ်ဘူး။ တွဲလုပ်ဖို့လိုပြီဆို Feature Ambassador တစ်ယောက်ထားပြီး Integration ကိုအရင်လုပ်ကြရတယ်၊​ ဒါမှမဟုတ်ရင် Enabling Team လေး ခေတ္တဖွဲ့ပြီးတွဲလုပ်ကြတယ်။ အသေးစိတ်သိချင်ရင် Team Topology ဆိုတဲ့စာအုပ် ဖတ်ကြည့်ပါ။

Always On Zoom

ရုံးမှာဆိုရင် ကောင်းတာတစ်ခုက တစ်ယောက်ယောက် အားနေတယ်ဆိုရင် သွားစကားပြော၊ မသိတာရှိ ပုခုံးပုတ်မေးလို့ရတယ်။ Remote Work မှာကျဒီလိုလုပ်ရတာကခက်တယ်။ အဲလိုမဖြစ်အောင် သုံးတဲ့နောက်တစ်နည်းက Always On Zoom ဆိုတဲ့ နည်းကိုသုံးတယ်။ ကြိုက်တဲ့အချိန် အဝင်အထွက်လုပ်လို့ရအောင် 24 နာရီ ဖွင့်ထားတဲ့ Zoom Call တစ်ခုပါပဲ။​ အထဲမှာ Breakout room လေးတွေ လိုသလောက် အများကြီးခွဲထားတယ်။​ (ပျော်တတ်ကြရင် တစ်ပတ်တစ်ခါ တစ်ယောက်တစ်လှည့်စီ အခန်း နာမည်လေးတွေပေးခိုင်း 😆) ကိုယ်က Always On ထဲက Breakout room တစ်ခုခုထဲမှာ ဝင်နေပြီး အလုပ်လုပ်နေရုံပဲ။ ကိုယ့်လိုတဲ့သူက ကိုယ်ရှိနေတဲ့အခန်းကို ကြည့်ပြီးဝင်လာလိမ့်မယ်။ အလုပ်တစ်အားများလို့ focus လိုတဲ့ဆိုရင် Zoom က ထွက်ထား၊ မဟုတ်ရင်လည်း Zoom ထဲမှာ "Be Right Back" ဆိုပြီး ထားထားလို့ရတယ်။ ဒါဆိုရင် ရုံးခန်းထဲမှာ ပခုံးပုတ်မေးသလိုပဲ အလုပ်တွင်စေတယ်။ ကျွန်တော်တို့ဆို ညနေ အလုပ်ဆင်းခါးနီးအားပြီဆို အကုန်လုံးတစ်ခန်းထဲမှာ ပြုံသွားပြီး အာလာဘ၊ သလာဘ ပြောကြရင်းနဲ့ မိတ်ဖွဲ့ဖြစ်တယ်။ တစ်ချို့တွေကြတော့လည်း Kumospace လိုမျိုးနဲ့ Virtual Workspace ထားတာတွေ့ရတယ်။​ အဲလိုတော့မလုပ်ကြည့်ဘူးသေးဘူးတော့ ဘယ်လိုနေလဲမပြောတတ်ဘူး။

Single Team Remote Wall

Thoughtworks က ကျွန်တော်လုပ်ခဲ့တဲ့ Team ကနေ နာမည်တွင်ခဲ့တဲ့နည်းလမ်းတစ်ခုဖြစ်တယ်။ Project Wall လို့ခေါ်တဲ့ နည်းလမ်းကိုပဲ Remote Team အတွက် လုပ်ထားပေးတာဖြစ်တယ်။ ရင့်ကျက်လာတဲ့ ကုမ္မဏ္ဏီတွေရဲ့ ပြဿနာတစ်ခုက သုံးရတဲ့ Tool တွေတအားများတယ်။ Error Log တွေကြည့်ဖို့ Datadog, Splunk၊ စကားပြောဖို့ကြတော့ Slack, အလုပ်တွေဘာကျန်သေးလဲကြည့်တာကြတော့ Jira, Documentation တွေက Confluence, Backstage အစရှိသဖြင့် ပွတထနေတာပဲ။ ဒီတော့ Project ရဲ့ အဓိက အချက်အလက်တွေကို တစ်နေရာတည်းစုထားဖို့ ရုံးထဲမှာ LED Screen တွေနဲ့ Project Wall ထားလေ့ရှိတယ်။ Remote Team တွေမှာလည်း ဒီလို အလွယ်တကူ လာကြည့်လို့ရတဲ့ နေရာတစ်ခုလိုတယ်။​ ကျွန်တော်တို့တုန်းကတော့ Miro ကိုသုံးပြီး Remote Wall တစ်ခုဖန်းတီးထားတယ်၊ အထဲမှာ Jira အတိုင်း Status Table တစ်ခုဆောက်တယ်၊ Miro ထဲကနေပဲ Jira Card တွေကို လှမ်း update လုပ်တယ်၊ assign ချတယ်။ Always On Zoom Link တွေပါတယ်။ RAID Radar တွေရှိတယ်၊ Retro Action တွေပါမယ်၊ System Dashboard တွေပါတယ် အစရှိသဖြင့် တစ်နေရာထဲကနေအကုန် ကြည့်လို့ရအောင်လုပ်ထားပေးတယ်။ ဒါရှိနေခြင်းအားဖြင့် အလုပ်လုပ်ဖို့ Chrome Tab အခု ၂၀ လောက်ဖွင့်စရာမလိုတော့ဘူး။

Miro Remote Wall

ဒီလို နည်းပညာအကြောင်းတွေကို သဘောကျတယ်ဆိုရင် တစ်လ Baht 1၀၀ နဲ့ အားပေးလို့ရနေပြီနော်။ Supporter တွေအနေနဲ့ Comment မှာလည်း သိချင်တာတွေရှိရင်မေးလို့ရပါတယ်။ ကျွန်တော်အကုန်လုံးကို ဖြေပေးသွားပါမယ်။