Feedbacks : We Don't Know What We Don't Know

ကျွန်တော်ကြီးပြင်းလာတဲ့ Social Culture မှာကော Work Culture မှာကော Feedback (အပြုသဘောဆောင်တဲ့ ဝေဖန်မှုမျိုး) ပေးတာ၊ လက်ခံတာမျိုး သိပ်အများကြီးမကြုံခဲ့ရဘူး။ အားနာတတ်တာသော်လည်းကောင်း၊​ မပြေပြတတ်တာ သော်လည်းကောင်း အကြောင်းအမျိုးမျိုးကြောင့် Feedback ပေးတဲ့ အတတ်ပညာကို ထဲထဲဝင်ဝင် မသင်ယူခဲ့ရဘူး။ Thoughtworks ရောက်တော့မှ Feedback Culture နဲ့ ရင်းနှီးလာပြီး Feedback အတတ်ပညာကိုလေ့လာသင်ယူခဲ့ရတယ်။

Feedback ပေးနည်း

Feedback ပေးတယ်ဆိုတာလည်း မလွယ်ဘူး။​ ကျွန်တော့်အတွက်က Thoughtworks ရောက်ပြီး ပထမ ၂ နှစ်မှာ တော်တော်ကျင့်ယူခဲ့ရတဲ့ အတတ်ပညာတစ်ခုပဲ။ မှတ်မှတ်ရရ ကျွန်တော် စလုပ်ပြီး ၆ လလောက်နေတာ့ အသစ်ဝင်လာတဲ့ Tech Lead နဲ့ နှစ်ပတ်တစ်ခါ One-on-One စကားပြောရတယ်။ တစ်ရက်ကျတော့ အဲလိုပဲ one-one-one ပြောကြရင်းသူက "တစ်ခြားသူတွေကို မင်းပေးထားတဲ့ Feedback ကတော်တော်ဆိုးတယ်၊ ပြောရရင် တစ်ဖက်သူအတွက် လုံးဝ အသုံးမဝင်ဘူး။ မင်းကိုယ်မင်း သတိထားမိလား" ဆိုပြီး မေးလာတယ်။ ရုတ်တရက်ဆိုတော့ ကျွန်တော် ဘာပြန်ပြောရမလဲ မသိဘူး။ အလုပ်ထဲမှာ အဲလိုပွင့်ပွင့်လင်းလင်းပြောတာမျိုး အဲတော့မှာ ကြုံဘူးတော့ Culture Shock လည်း တော်တော်လေး ရသွားတယ်။ နောက်တော့ သတိဝင်တော့မှ "အဲလို မတွေးမိဘူး၊ ပြောပြပါဦး" ဆိုပြီးပြောတော့ သူကကျွန်တော့်ကို Feedback ပေးနည်း၊ယူနည်း အတတ်ပညာကို သင်ပေးခဲ့တယ်။

Mindset

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
- Retrospective Prime Directive by Norm Kerth

Feedback တစ်ခုမပေးခင်မှာ အရေးကြီးဆုံးအချက်က ကိုယ့်စိတ်နေစိတ်ထားအရေးကြီးတယ်။ ကိုယ်က တစ်ဖက်လူကို အပြစ်တင်ချင်လို့၊​ ကြည့်မရလို့မဟုတ်ပဲ တကယ်ကောင်းစေချင်တဲ့ စိတ်နဲ့ပြောပြတာဖြစ်ရမယ်။ တစ်ဖက်လူရဲ့ အခြေအနေကိုလည်း စာနာတတ်ရမယ်။ ဥပမာ တစ်ယောက်က meeting နောက်ကျတာကို သူဘာလို့နောက်ကျတာလဲဆိုတဲ့ အဖြေကိုမသိပဲ မင်းနောက်မကျနဲ့ပြောတာက အဆင်မပြေဘူး။ လမ်းမှာ Accident ဖြစ်လို့၊ အိမ်ကလူတစ်ယောက် နေမကောင်းဖြစ်နေလို့ ဂရုစိုက်နေရလို့ အစရှိသဖြင့် ဖြေရှင်းရခက်တဲ့ ပြဿနာတွေဖြစ်နေနိုင်တယ်။​ စာနာစိတ်ထားပြီး တကယ်ကောင်းစေချင်တဲ့ စိတ်နဲ့ဖြစ်ရမယ်။​ ဒီတော့ ကိစ္စတစ်ခုကို Feedback မပေးချင် ခဏ စိတ်အေးအောင်အရင်ထားဖို့ လိုအပ်တယ်။

Timeliness

ပထမတစ်ခု အရေးကြီးတာက Feedback တစ်ခုက အချိန်မှီပေးနိုင်ဖို့အရေးကြီးတယ်။ ခင်ဗျားတို့တော့မသိဘူး၊​ ကျွန်တော်ဆို အရင် Sprint ရေးခဲ့တဲ့ Code တောင် မမှတ်မိဘူး။​​ ဆိုလိုတာက လွန်ခဲ့တဲ့ သုံးလလောက်က ကိစ္စကို အခုမှလာပြောရင် ဘာဖြစ်ခဲ့လဲ့ မှတ်မှိမှာမဟုတ်ဘူး။​​ ဒီတော့ တတ်နိုင်သလောက် အချိန်မှီပေးဖို့အရေးကြီးတယ်။ အချိန်မှီဖို့ဆိုပြီး ချက်ချင်းကြီးလည်း ပြောစရာမလိုဘူး။ တစ်ချို့ကိစ္စတွေက ခုလေးတင် အသည်းအသန်ဖြစ်ထားပြီး ထူပူနေတဲ့အချိန်မှာဆို မပြောတာကောင်းတယ်။ နှစ်ဖက်လုံး ပြောဖို့၊လက်ခံဖို့ အခြေအနေရောက်ပြီဆိုတော့မှ Feedback ကိုစပြောရမယ်။​ ဒီလို အချိန်ကောင်းကို ရှာတတ်တာကလည်း ကျင့်ယူရမဲ့ အတတ်ပညာတစ်ခုပဲ။

Relevancy

ကိုယ်ပေးမဲ့ Feedback က တစ်ဖက်လူအတွက်နဲ့လည်း ကိုက်ဖို့အရေးကြီးတယ်။​​ သူအတွက် မလိုအပ်တဲ့၊ အရေးမကြီးတဲ့ အရာတစ်ခုကို Feedback ပေးဖို့မလိုဘူး။ iOS ကို ဒီနှစ်ထဲလေ့လာတဲ့ သူတစ်ယောက်ကို "မင်း Web ကိုသင်ပါလား" ဆိုပြီး ပြောတာမျိုးက မလိုအပ်ဘူး။ အသုံးလည်းမဝင်ဘူး။ တစ်ဖက်လူနဲ့ သက်ဆိုင်တဲ့ Feedback ပေးဖို့ဆိုတာကလည်း ကိုယ်ကသူနဲ့ထိတွေ့ပြီး သူဘာတွေလုပ်ချင်တာရှိလဲ၊ ငါ့ Team ထဲမှာကော ဘာကိုလိုအပ်နေတာလဲကို ကိုယ့်အနေနဲ့ ဝေဖန်ပိုင်းခြားတတ်ဖို့ လိုတယ်။ ဒါမှ သူ့အတွက်ကော ကိုယ့်အတွက်ကော တကယ်လိုနေတဲ့ အကြာင်းအရာတစ်ခုကို ကိုယ်ကကူပေးလို့ရမယ်။

Facts, not stories

Feedback တစ်ခုက Facts (မှန်ကန်တဲ့ အချက်အလက်) တစ်ခုကို အခြေခံတဲ့အရာဖြစ်ရမယ်။ Stories တစ်ခုမဟုတ်ရဘူး။ Fact နဲ့ Story ဘယ်လိုကွာလဲဆိုတာ မြင်ဖို့ ဥပမာတစ်ခုပြောပြမယ်။

Client နဲ့ဆွေးနွေးနေတုန်း Team ထဲကတစ်ယောက်က Technical ကိစ္စတစ်ခုကို မှားပြောလိုက်တယ်ဆိုပါတော့၊ တစ်ဖက် Client ထဲက Tech အကြောင်းနားလည်တဲ့သူတစ်ယောက်က မျက်မှောင်ကြုတ်သွားတာကို ခင်ဗျားက သိတိထားမိလိုက်တယ်။ အဲဒီအခြေအနေမှာဆိုရင် Fact က သူမှားပြောတာဖြစ်တယ်။ Client တစ်ယောက် စိတ်ထင့်သွားတာက Story ဖြစ်တယ်။ Client ကိုယ်တိုင်က "စိတ်ထင့်သွားပါတယ်" လို့မပြောမချင်း ဒီအချက်က သူတုံ့ပြန်တဲ့အမူအရာကိုကြည့်ပြီး ခင်ဗျားစိတ်ထဲက ကောက်ချက်ချလိုက်တဲ့ Story သာဖြစ်တယ်။

​ဒီနှစ်ခုကို ကွဲကွဲပြားပြားသိဖို့လိုတယ်။ ကိုယ်ပေးတဲ့ Feedback က Fact ကိုအခြေခံပြီးပြောတာဖြစ်ဖို့ အရေးကြီးတယ်။ Fact ဆိုတာက verifiable (စစ်ဆေးကြည့်) လို့ရတယ်၊ Story ဆိုတာက စစ်ဆေးရခက်တယ်။ ဒီမှာဆို "မင်းပြောလိုက်လို့ Client စိတ်ထင့်သွားတယ်" လို့မပြောပဲ "မင်း လွန်ခဲ့တဲ့ သုံးရက်လောက်က Backlog Refinement Meeting မှာ Server Scaling လုပ်ဖို့ပြောနေတုန်း မင်းမှားပြောလိုက်မိတာကို ငါသတိထားမိလိုက်တယ်" ​ဆိုပြီး Verify လုပ်လို့ရတဲ့ အချိန်၊​နေရာ၊ အဖြစ်အပျက်ကို သေချာပြောပြဖို့လိုတယ်။ Fact ကိုပြောပြီးတော့မှ "ငါ့အမြင်မှာတော့ Client ဘက်က Tech နားလည်တဲ့သူပါတော့ ငါတို့ team အပေါ် Confidence နည်းသွားနိုင်တယ်" ဆိုပြီး နောက်ကနေ Story ကလိုက်ရမယ်။

Actionable

Feedback တစ်ခုပေးပြီးရင် ဒါနဲ့ပတ်သက်ပြီး အဆင်ပြေအောင် ဘာလုပ်လို့ရမလဲဆိုတာကို ထည့်စဥ်းစားပေးရမယ်။​ "မင်း Code Quality ကောင်းအောင်လုပ်ဦး" ဆိုတာထက်စာရင် "မင်း Code Quality အပိုင်းမှာ ငါသတိထားမိတာ မင်းရေးတဲ့ Code တွေက Test တွေမပါဘူး။​ Code မရေးခင် Test ရေးတာနဲ့စကြည့်ပါလား။ ဒီ TDD စာအုပ်ထဲက အတိုင်း လိုက်လုပ်ကြည့်လို့ရတယ်.."​အစရှိသဖြင့် Actionable တကယ်လိုက်လုပ်လို့ရတဲ့ နည်းလမ်းတွေ ပြောပြပေးရမယ်။ ဒီလို Actionable ဖြစ်ဖို့ကလည်း ကိုယ့်ပေးတဲ့ Feedback က အသေးစိတ်ဖြစ်ဖို့လိုအပ်တယ်။ အသေးစိတ်သိပြီဆိုရင် နောက်ကဘာလုပ်လို့မရလဲဆိုပြီး စဥ်းစားရတာလွယ်သွားလိမ့်မယ်။

နောက်ဆုံးတစ်ခုအနေနဲ့ Feedback ဆိုတာ လွယ်လွယ်ကူကူ ရော့အင့်ဆိုပြီးလုပ်လို့ရတဲ့ အရာမဟုတ်ဘူး။​ ကိုယ့် Team ကို တကယ်တိုးတက်စေချင်တယ်ဆိုရင် ကိုယ်ဘက်ကလည်း အချိန်ကော၊ ကြိုးစားအားထုတ်မှုကော လိုက်ရမယ်။ နေ့စဥ်လုပ်နေတဲ့ အလုပ်မှာကိုယ့် Team က ဘယ်လိုအခြေအနေရှိနေလဲဆိုတာကို အကဲခတ်တတ်အောင်လုပ်ရမယ်။ ဒီအတတ်ပညာကို စကျင့်လို့ရတဲ့ နည်းလမ်းတစ်ခုက Team Meeting တွေ၊ Pair Programming အချိန်တွေ၊ PR Review အစရှိသဖြင့် တစ်ဖက်လူတွေနဲ့ ထိတွေ့ရတဲ့ နေရာတိုင်းမှာ ကိုယ်က Awareness လေးထားပြီး တစ်ဖက်လူက ဘယ်အပိုင်းမှာလိုနေတယ်ဆိုတာမျိုး တွေးပေးဖို့လိုတယ်။ Meeting မှာ စကားပြောတာ မရှင်းတာမျိုးလား၊ PR Review တွေမှာ nitpick တွေများနေတာမျိုးလား အစရှိသဖြင့်ပေါ့။ ကိုယ့်အလုပ်တစ်ခုပြီးအောင်ပဲလုပ်တာမျိုးမဟုတ်ပဲ ဒီထက်တစ်ဆင့်တက်ရမယ်။ ကျွန်တော့်အတွက်အလုပ်ဖြစ်တဲ့ နည်းတစ်ခုကတော့ ကျွန်တော်အလုပ်ခုံမှာ မှတ်စုစာအုပ် လေးတစ်ခုအမြဲထားထားတယ်။ တစ်ခုခုသတိထားမိတယ်ဆိုရင် ချက်ချင်း အချိန်နေ့စွဲနဲ့တွဲပြီး မှတ်ထားလိုက်တယ်။ နောက် Feedback ပြန်ပေးတဲ့အချိန်ကျရင် ဒီ မှတ်စုလေးတွေက တော်တော်အသုံးဝင်တယ်။ မဟုတ်ရင် ဒီနေ့ခေါင်းထဲမှာတွေး၊ နောက်နေ့မေ့သွားကောဖြစ်တတ်တယ်။

Feedback ယူနည်း

ကျွန်တော်ကြီးပြင်းလာတဲ့ Culture မှာ အပြုသဘောဆောင်တဲ့ ဝေဖန်မှုတွေမကြုံခံရတော့ Feedback သွားတောင်းဖို့ကို စစကတော်တော်ကြောက်တယ်။ "Ignorant mind is so peaceful" ဆိုသလိုပဲ သွားတောင်းလိုက်လို့ ကိုယ်လိုတာတွေသိရမှ စိတ်ညစ်နေရမယ်ဆိုပြီး အစကတော့ တောင်းလေ့မရှိဘူး။ တောင်းရင်း၊ တောင်းရင်းနဲ့ပဲ နောက်တော့တော်တော်လေးအသားကျလာတယ်။ အဓိက ကတော့ ခေါင်းထဲမှာ တွေးရမှာက "ငါ့ကို သူ Feedback ပေးလို့ လွယ်အောင် ငါဘာလုပ်ပေးလို့ရမလဲ" ဆိုတာပဲ။​ ဒီတော့ ကိုယ့်ဘက်ကနေပြီး လုပ်ပေးလို့ရတာက

Be Specific

ယေဘူယျမေးခွန်းတွေဖြစ်တဲ့ "ငါဘာတွေထပ်လုပ်ရမလဲ"၊ "ငါဘာတွေ အဆင်မပြေဘူးလဲ" ဆိုတဲ့မေးခွန်းတွေအပြင် တိကျတဲ့ အကြောင်းအရာတွေကိုလည်း မေးတတ်ရမယ်။ မကြာသေးခင်က ဘာတွေရှိထားလဲ၊​ ဥပမာ "UX Meeting" မှာကိုယ်က ဦးဆောင်ထားတာဆိုရင် "လွန်ခဲ့တဲ့ တစ်ပတ်က လုပ်ခဲ့တဲ့ UX Meeting မှာငါပြင်ထားတဲ့ UX Design တွေက အချက်အလက်တွေဆုံရဲ့လား၊ ငါရှင်းပြတာကော နားလည်လွယ်ရလား" အစရှိသဖြင့် မေးလို့ရတယ်။ ဒါဆို တစ်ဖက်လူအနေနဲ့လည်း အဲဒီအကြောင်းအရာတစ်ခုထဲကို အာရုံစိုက်ပြီး အကြံဉာဏ်ပေးလို့ရတယ်။ Focused Feedback တွေက ကိုယ့်အတွက်လည်း ပိုအသုံးဝင်တယ်။

Context

တစ်ဖက်လူက သူဘာလို့ ဒါကိုမေးတာလဲဆိုတာမျိုးမဖြစ်ဖို့ နောက်ကွယ်က Context တွေကို ပြောပြထားဖို့လိုတယ်။ ဥပမာ ကျွန်တော့် ဒီနှစ် Goal က Tech Lead ဖြစ်ဖို့ဆိုပါတော့၊​ "ငါ Tech leadership ပိုင်းကို ကျင့်နေလို့၊​ ငါ Meeting တွေမှာ ငါဝင်ပြောနေတော့ မင်းတို့ပြောချင်တာ ပြောဖို့ကော space ငါပေးနေရဲ့လား။ မင်းတို့ကော ငါအခု ဦးဆောင်နေတဲ့ Feature တွေကအဆင်ပြေလား" အစရှိသဖြင့် ကိုယ်နဲ့အခုချိန်မှာ ပိုအသုံးဝင်နိုင်တဲ့ အကြောင်းအရာတွေက ဘာဆိုတာကို တစ်ဖက်လူကိုပြောပြထားလို့ရတယ်။​ ဒီမှာဆို တောင်းတဲ့သူက "Leadership" အပိုင်းကို ဦးစားပေးတောင်းထားတာကို မြင်နိုင်မယ်။

Don't take it personal

Culture မတူတဲ့သူတွေနဲ့လုပ်ရတဲ့အခါမှာ တစ်ခါတစ်ရံ တစ်ဖက်လူကပြောလိုက်တဲ့ Feedback က ကိုယ့်နားထဲ ကန့်လန့်ကြီး​ဝင်လာတာတွေရှိတတ်တယ်။​ ဒီလိုအချိန်မှာဆို ချက်ချင်း မတုံ့ပြန်ပဲ Objective အမြင်ကနေပြီး "သူဘာလို့ ငါ့ကို ဒီလိုပြောတာလဲ" ဆိုပြီး အတွေးထားတတ်ဖို့လိုတယ်။ ကိုယ်ကသေချာမသိသေးတဲ့ အချိန်မှာ "Story" တွေခေါင်းထဲမှာမတွေးပဲ​ "မင်းပြောတဲ့ အကြောင်းကို ငါပိုသိချင်တယ်။​​ ဒီထက်ပိုပြီး အသေးစိတ်ပြောပြလို့ရမလား"​ ဆိုပြီးပြန်မေးရင်းနဲ့ Fact တွေအရင်စုံအောင်လုပ်ရမယ်။

တကယ်လို့အဲမှာ သူပေးတဲ့ Feedback ကမမှန်ကန်ဘူးဆိုတာ ကိုယ်ကသေချာသိတယ်ဆိုပါတော့​။​ အဲလိုဆိုရင်ကိုယ်က မဟုတ်ကြောင်းကိုလည်း အချက်အလက်ကျကျနဲ့ ပြန်ရှင်းပြတတ်ဖို့လိုတယ်။ "မင်းပြောတာ ငါ့ Code မှာ Bug တွေခဏခဏတွေ့တယ်ဆိုလို့ ငါအရင် sprint နှစ်ခုသုံးခုလောက်ပြန်ကြည့်ကြည့်တာ ငါ့ Code က Bug မထွက်ဘူး။ ငါ မဖြစ်အောင်လို့လဲ Test တွေဒီလိုရေးတယ်" ဆိုပြီး ပြန်ပြောပြတာမျိုး လုပ်တတ်ရမယ်။ တစ်ခါတစ်ရံကျ ကျွန်တော်တို့ရဲ့ Confirmation Bias တွေကြောင့် စိတ်ထဲမှာထင်နေပေမဲ့ အမှန်ဖြစ်ချင်မှဖြစ်တဲ့ အရာလေးတွေရှိတတ်တာကြောင့် ဘာလို့ သူ့အနေနဲ့ ဒီလိုတွေးနေလဲဆိုတာကို ပြန်ရှာတတ်ရမယ်။​ သူဘက်ကလုံးဝကို အမှတ်မှားပြီး ပြောတာဖြစ်နိုင်တယ်၊​​ ဒါမှမဟုတ် အပေါ်က ဥပမာမှာဆို Team မှာပဲ Bug အမြဲတမ်းလိုလိုတက်နေတဲ့ ကိစ္စအရင်းအမြစ်ကို အပြောမတတ်တာမျိုးလည်းဖြစ်နိုင်တယ်။ ဒုတိယကိစ္စမှာဆိုရင်တော့ ကိုယ်က လက်တွဲပြီး ဖြေရှင်းဖို့ ကမ်းလှမ်းလို့ရမယ်။

Show Commitment

တစ်ဖက်လူက ကိုယ့်ကို သေချာ Feedback ပေးလာပြီဆိုရင် သူပြောတာကို ကိုယ်က အလေးထားကြောင်းပြပေးရမယ်။ ဒီလိုပြဖို့အကောင်းဆုံးနည်းက ငါမင်းပြောတာကို တကယ်လိုက်လုပ်နေပါတယ်ဆိုပြီး ပြနိုင်ဖို့ပဲ။ သူပြောထားတာကို ပိုကောင်းအောင်လုပ်ဖို့ ငါဘာ Action တွေလုပ်ဖို့ လိုမလဲဆိုတာကို စဥ်းစား၊ ပြီးရင် ငါဘာတွေစလုပ်မယ်ဟေ့ဆိုပြီး ပြန်သွားပြောပြတာမျိုးလည်း လုပ်လို့ရတယ်။​ (ဒီ Action တွေက SMART Action ဖြစ်ဖို့တော့လိုတယ်။) နောက်အချိန်တစ်ခုကြာရင် ကိုယ်ဘက်ကနေစပြီး ဒီကိစ္စနဲ့ပတ်သက်ပြီး တိုးတက်လာတယ်ထင်လားဆိုပြီး Feedback သွားတောင်းရမယ်။ ဘယ်သူမဆို ကိုယ်ပြောတာကို အလေးထားပြီး လိုက်လုပ်တယ်ဆိုရင် နောက်လည်းကိုယ့်ကို ပိုကူပေးချင်လိ်မ့်မယ်။ ဆိုတော့ Feedback တောင်း၊ ရပြီဆိုရင် ပစ်မထားပဲ နောက်ကနေ သေချာလိုက်လုပ်ဖို့ လိုအပ်ပါတယ်။

Feedback ယူတတ်အောင်ကျင့်တဲ့အခါ ကိုယ့် Team ရဲ့အကူအညီကလည်း တော်တော်လိုအပ်တယ်။​ သူတို့ပေးတဲ့ Feedback Quality တွေကကောင်းနေတဲ့အခါကျမှ ကိုယ်ကလည်း ဆက်တောင်းချင်မယ်။​ တစ်ခါလာလည်း သုံးမရတဲ့ အရာတွေလာပြောနေတာများလာရင် ကိုယ်ကလည်း မတောင်းချင်တော့ဘူး။ ဒီတော့ တကယ်လို့ ကိုယ့် Team Culture မှာ ဒီလို Feedback Culture ခိုင်ခိုင်မာမာ မရှိသေးဘူးဆိုရင် ကိုယ်က ပျိုးထောင်ပေးဖို့လိုအပ်တယ်။

Speedback

Feedback Culture ကောင်းကောင်းမရှိသေးတဲ့အချိန်မှာ Formal feedback ကိုတန်းမသွားပဲ ပေါ့ပေါ့ပါးပါးနဲ့ စတာပိုကောင်းတယ်။ အဲဒီအတွက် ကျွန်တော်ကတော့ Speedback နည်းလမ်းကို အားပေးတယ်။

Speedback ဆိုတဲ့ နည်းလမ်းက Google မှာ People Development VP အနေနဲ့လုပ်နေနဲ့ Karen May ဆိုတဲ့ အမျိုးသမီးတစ်ဦးက ထွင်ခဲ့တဲ့နည်းလမ်းဖြစ်တယ်။ Speed Dating နဲ့ Feedback ကိုပေါင်းထားလို့ "Speed-back" ဆိုပြီးခေါ်တာဖြစ်တယ်။ ဒီနည်းလမ်းကိုလုပ်ဖို့ ဘာလိုလဲဆိုရင်

• အားလုံးအားတဲ့ အချိန် ၁နာရီ
• ဘောပင်နဲ့ post-it note
• Physical လုပ်မှာဆိုရင် ထိုင်ခုံတွေချဖို့ နေရာလိုတယ်၊ Online ဆိုရင် Breakout room လေးတွေ ခွဲထားရမယ်။
• Timer

ဒါတွေရပြီဆိုစလို့ရပြီ

• Speedback ကဘယ်လိုဆိုတာရှင်းပြပေးပြီး ပါဝင်တဲ့သူတိုင်းက ကိုယ်လိုချင်တဲ့ feedback အကြောင်းအရာက ဘာ၊​ သူများကို ပေးချင်တဲ့ Feedback ကဘာ ဆိုတာတွေကို ချရေးထားရမယ်။​​ တကယ်လို့ Plan ဖို့ အချိန်ပိုရတယ်ဆို တစ်ပတ်လောက် အချိန်ပေးထားပြီး Whiteboard/Digital board မှာ Feedback လိုချင်တဲ့ အကြောင်းအရာ လေးတွေကို နာမည်နဲ့တွဲပြီး Note လေးတွေကပ်ခိုင်းထားလို့ရတယ်။ တစ်ခြားလူတွေကလည်း ဒီ board ကိုလာကြည့်ပြီး ပြောချင်တဲ့ အရာလေးတွေကို ပြင်ထားရမယ်။ ဒီလိုအချိန်ပေးနိုင်ရင် ပိုထိရောက်တဲ့ Feedback တွေရမယ်။

• အားလုံးနားလည်ပြီဆိုရင် နှစ်ယောက်တစ်တွဲစီတွဲမယ်။​
• အတွဲတွေရပြီဆိုရင် Timer ကို ၃ - ၅ မိနစ် သတ်မှတ်ပြီး စလို့ရပြီ။
• Timer စတာနဲ့ အတွဲတွေက တစ်ယောက်နဲ့တစ်ယောက် Feedback စပေးရမယ်။ Feedback ပေးဖို့ တစ်ယောက်ကို သတ်မှတ်ထားတဲ့အချိန်တစ်ဝက်စီရမယ်​။ ဥပမာ ၃ မိနစ်ဆိုရင် ပထမ ၁ မိနစ်ခွဲမှာ A က B ကိုပေးပြီး၊​ ကျန်တဲ့ ၁ မိနစ်ခွဲမှာဆို B က A ကိုပြန်ပေးမယ်။
• ပြောထားတာလေးတွေကို မှတ်စုလေးတွေ (gist) ချရေးထားဖို့လိုတယ်။
• အချိန်ပြည့်တာနဲ့ (ကျွန်တော်တို့ဆို ကြေးစည်တီးတယ် 🤣) ပြောနေတာချက်ချင်းရပ်ပြီး နောက်တစ်ယောက်နဲ့ထပ်တွဲရမယ်။
• အဲလို ပတ်နေရင်းနဲ့ အကုန်လုံး တစ်ယောက်တစ်လှည့်စီ တွဲပြီး၊ ပြောပြီး ပြီဆိုရင် ရပ်လို့ရပြီ။
• တကယ်လို့ ပြောသွားတဲ့အထဲမှာ အသေးစိတ်သိချင်သေးတဲ့ အရာရှိတယ်ဆိုရင် အဲလူနဲ့ သပ်သပ်အချိန်တစ်ခုယူပြီး ဆက်ဆွေးနွေးလို့ရမယ်။

ဒီလိုလုပ်ခြင်းအားဖြင့် Formal မဆန်တော့ပဲ Game သဏ္ဍာန်ဖြစ်သွားတဲ့အတွက်ကြောင့် ပေါ့ပေါ့ပါးပါးနဲ့ လွတ်လွတ်လပ်လပ်ပြောလို့ရတယ်။ နောက်တစ်ခုက အချိန်သတ်မှတ်ထားတာကြောင့် Formality တွေလုပ်စရာမလိုပဲ လိုရင်းကို အမြန်ပြောလို့ရတယ်။

ကိုယ့်အလုပ်မှာ စမ်းကြည့်ဖို့ အောက်ကပုံလေးတွေကို အလွယ်တကူသုံးလို့ရအောင် ဆွဲပေးထားပါတယ်။

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