On Healthy Developer Habits

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

On Healthy Developer Habits

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

အချိန်မလောက်တဲ့ ပြဿနာ

Project တစ်ခု Feature တစ်ခုစပြီဆိုရင် အချိန်လုံလောက်အောင် ယူဖို့က စပြီး Planning ချကတည်းက လုပ်ခဲ့ရမဲ့အရာဖြစ်တယ်။ Plan လုပ်တဲ့အချိန်မှာ ပါဝင်တဲ့သူတွေက ကြာရင် ကြာနိုင်ကြောင်း ပွင့်ပွင့်လင်းလင်းပြောရဲရမယ်။ ဒါမှ အချိန်ကို တတ်နိုင်သလောက် လုံလောက်အောင်ယူနိုင်မယ်။ တစ်ခုတော့ရှိတာပေါ့ Hofstadter's law အရ

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

ဘယ်လိုဖြစ်ဖြစ် ယူထားတဲ့အချိန်ထက်တော့ အမြဲနောက်ကျမှာပါပဲ။ ဒါပေမဲ့ နောက်ကျတာကို လက်မခံပဲ အရမ်းဖိအားပေးလို့ကလည်း မရပြန်ဘူး။ ကျွန်တော်ကြုံဖူးတယ်၊ client က ဘာမှကြိုလည်းမပြော၊ နက်ဖြန်လုပ်ပေးရမလားဆိုပြီး ချက်ချင်းကြီး တောင်းတာမျိုး၊ planning အချိန်မှာပဲ ကိုယ့်အထက်က လူက client ကျေနပ်အောင် အချိန်တွေ လျှော့ယူခိုင်းတာမျိုး၊ target မှီအောင် မြန်မြန်လုပ်ခိုင်းတာမျိုး၊ requirements ကသေချာမရှိဘူး timeline က estimate နေပြီ၊ အစစဖြင့်စုံနေတာပဲ။ ကိုယ်တွေက "အားနာလို့" လျော့ယူလိုက်ဆိုရင် ပြဿနာက ဒီမှာမပြီးသွားဘူး။ ကိုယ့်အတွက်ကိုယ်ပဲကြည့်ကြည့်ရအောင်။ ခင်ဗျား အရင်ကထက် အားသွန်ခွန်စိုက်လုပ်လိုက်မယ်၊ ညဘက်တွေပါ ရေးလိုက်မယ်၊ ဒါကို သူတို့မသိဘူးဆိုရင် နောက်တစ်ချိန် ဒီလိုထပ်ကြုံလာရရင်ကော ခင်ဗျားအပေါ်ရှိတဲ့ ထင်မြင်ချက်က "ဒီလူကဒါကို ၃ ရက်လောက်နဲ့ပြီးတယ်" ပေါ့၊ နောင်တစ်ချိန်မှာ ခင်ဗျား ညဘက်တွေ ထပ်မရေးခဲ့ရင် ဘာဖြစ်သွားမလဲ။ သူတို့ထင်တားတဲ့ ထင်မြင်ချက်ကို ပြီးအောင်မလုပ်နိုင်တော့ ခင်ဗျားပဲ performance ထိမယ်။ ကုမ္မဏီဘက်က ကြည့်မယ်ဆိုရင်လည်း ဒီလို deadline နီးတဲ့ထိ အသေကုန်လုပ်နေရတဲ့ "culture" က ပျောက်သွားမှာ မဟုတ်တော့ဘူး။ ကြာတော့ လူတွေပင်ပန်းလာမယ်၊ ပင်ပန်းလာတော့ ထွက်ကုန်ကျမယ်။ "အားနာ" ပြီး ရပါတယ် ပြောလိုက်တဲ့ အရာတစ်ခုက နောက်ဆက်တွဲ ပြဿနာတွေ ရှိတယ်။ ဒီတော့ ဘာလုပ်ရမလဲ? အမှန်တိုင်း ဘယ်လောက်ကြာမယ်ဆိုတာ ရအောင်ပြော၊ တကယ်လို့ကိုယ့်အနေနဲ့ တွက်ပေးဖို့ လိုတာကို မရသေးဘူးဆိုလည်း အရင်ရအောင် တောင်းဖို့ အရေးကြီးတယ်။ တစ်ခုတော့ရှိတယ်၊ တစ်ဖက်သားကို  နားဝင်အောင်တော့ ပြောပေါ့ (ဒါကတော့ Soft Skill ဖြစ်သွားပြီ၊ ဒါကလည်း လိုအပ်တယ်နော်) ။ Healthy Software Developer က တော့ဘယ်လိုပြောသင့်လဲဆိုတာ ဒီလိုလေးပြောထားတယ်။

တစ်ခုလုံးကြည့်ကြည့် တော်တော်ကောင်းတဲ့ Video
"ဒီမှာ၊ ကျွန်တော်က ဒါကိုရေးရမဲ့လူ၊ ခင်ဗျားတို့က မြန်အောင်လုပ်ပေးမယ် ဆိုပြီး client ဆီမှာ မျက်နှာကောင်းအောင်လုပ်ခဲ့တာ ကိစ္စမရှိဘူး။ တကယ်တမ်း ရေးတော့ ကျွန်တော်ရေးရမှာ ကျွန်တော်ဘယ်လောက်ကြာမယ်ဆိုတာ သိတယ်၊ ဒီတော့  ကျွန်တော့် မပြီးရင် ခင်ဗျားတို့လည်း မျက်နှာပျက်မယ်။ ကျွန်တော်ကတော့ ခင်ဗျားတို့ကိုလည်း မျက်နှာမပျက်စေချင်ဘူး။"

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

Cutting corners

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

သူများက ပိုက်ဆံပေးပြီး ဒါလုပ်ဆိုတိုင်း လုပ်တဲ့သူ မဖြစ်ချင်ဘူး။ ကျွန်တော်ကတော့ ကျွန်တော့် profession က ဒီထက်ပိုတယ်လို့ထင်တယ်။

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

Digital Well-being

ကျွန်တော်တို့ရဲ့ အလုပ်တွေက အရင်ကလို ရုံးမှာပဲ ပြောကြဆိုကြတာမဟုတ်ပဲ အွန်လိုင်းပေါ်ရောက်လာတဲ့အချိန်မှာ Digital Well-being က အရေးကြီးလာတယ်။  နည်းပညာတွေကနေ အနားယူတတ်ခြင်းလို့ပဲ ပြောမလား။ ကျွန်တော့်အနေနဲ့ကတော့ ကျင့်ဝတ်အနေနဲ့ အလုပ်ချိန်ပြင်ပမှာ တတ်နိုင်ရင် စာတိုမပို့ပါဘူး။ အရေးမကြီးရင် ရုံးဖွင့်ချိန်ကိုပဲ စာပို့တယ်။ ကိုယ်စာပို့မဲ့သူအနေနဲ့လည်း သူခွင့်ယူထားလို့၊ ရုံးချိန်ပြင်ပမလို့ စကား ပြန်မပြောရင် ဒါကို ကျွန်တော် အပြစ်မမြင်ဘူး။ ရုံးချိန်တွင်းတောင် ချက်ချင်းမပြန်လည်း ဘာမှမဖြစ်ဘူး။ (Async Communication ကိုဦးစားပေးတယ်) ဒီတော့ Digital Well-being ရအောင် ရုံးချိန်ပြင်ပဆိုတာနဲ့ အလုပ်နဲ့ပတ်သက်တဲ့ Notification အကုန်ပိတ်၊။ Leave ယူထားရင်လည်း Leave ယူထားကြောင်း Status ရေးထားပေးတယ်၊ ပြီးရင် Noti အကုန်ပိတ်ထားသင့်တယ်။ အရမ်းအရမ်းကို အရေးကြီးရင် ဖုန်းဆက်လိမ့်မယ်၊ စာတိုဆိုတာက Priority အရ အောက်ဆုံးမှာပဲရှိတယ်။ ဒီတော့ စာတိုတွေက သင့်ရဲ့ အနားယူချိန်ကို လာမနှောက်ဖို့ အရေးကြီးတယ်။ တစ်ဖက်လူက ခင်ဗျားအချိန်ကို မလေးစားဘူးဆိုရင်တောင် ကိုယ်က Noti ပိတ်ထားရင် သူကြိုက်သလိုပို့ပဲ။

Overworking

ရုံးချိန်ပြင်ပဆို နောက်တစ်ခုက ရုံးချိန်ပြင်ပအလုပ်လုပ်ခိုင်းတဲ့ ကိစ္စပေါ့။ "ဒါလေး အလျှင်လိုနေလို့လုပ်ပေးပါ" ဆိုပြီး ပြီးစလွယ်ပြောလိုက်တာ၊ တစ်ဖက်ကလူအနေနဲ့ "ငါ မလုပ်ပေးလိုက်ရင် ငါ့ကို တစ်မျိုးထင်သွားမလား၊ ငါအလုပ်မကြိုးစားဘူးထင်မလား" ဆိုတဲ့ အတွေးတွေဝင်တယ်ဗျ။ ဒီမှာ ပြောချင်တာက ရုံးချိန်ပြင်ပ လုပ်ပေးဖို့ ခင်ဗျားမှာ လုံးဝ တာဝန်မရှိပါဘူး ဆိုတာ သိဖို့လိုတယ်။ ဒီလိုခိုင်းလို့ သင့်အနေနဲ့မလုပ်ပေးနိုင်ဘူးဆိုတကို  ညာစရာလည်းမလိုဘူး၊ "ရုံ:ချိန်ပြင်ပမလို့ မလုပ်ပေးနိုင်ပါဘူး။ ရုံးပြန်ဖွင့်တာနဲ့ အစောဆုံးလုပ်ပေးပါမယ်" ဆိုပြီး ငြင်းခွင့်ရှိပါတယ်။ ငြင်းလိုက်ရတာကိုလည်း အပြစ်လို့ မြင်စရာမလိုဘူး။ ခင်ဗျားမှာ ငြင်းပိုင်ခွင့်ရှိတယ်ဆိုတာ သိဖို့လိုတယ်။ တစ်ခုပေါ့ တကယ်အရေးကြီးလို့ဆိုရင်တော့ တန်ရာတန်ကြေး ပြန်ရအောင်တောင်းပါ။ ကျွန်တော်တို့ Developer တွေမှာ ကျွန်တော်ကိုယ်တိုင်လည်း ထင်ခဲ့တာ ညဘက်တွေထိ bug ကိုမရမက ပြင်ပေးတဲ့ကောင်က တကယ်ကြိုးစားတယ်ပေါ့၊  နောက်တော့သိလာရတာက ဒီလိုညဘက်လုပ်နေရတယ်ဆိုတာက အချိန်ကို လောက်လောက်ငငမယူထားလို့ရယ်၊ နောက်ကျရင် ဘာလုပ်ကြမယ်ဆိုတဲ့ အစီအစဉ်မရှိလို့ရယ်ဆိုတာကို သိလာရတယ်။ တကယ်က Sprint တိုင်း OT အမြဲလိုလိုယူရပြီဆိုရင် ခင်ဗျားတို့ planning မှာကတည်းက အကြီးကြီးလွဲနေခဲ့လို့ဆိုတာသိဖို့လိုတယ်။

Too much meetings

နောက်ထပ်ကြုံရတဲ့ပြဿနာတစ်ခုက အစည်းအဝေးတွေများပြီး ကိုယ်အလုပ်လုပ်ဖို့ အချိန်မလောက်တာ။ သင်နဲ့တွဲလုပ်နေတဲ့ အဖွဲ့တွေက မလိုအပ်ရင် အစည်းအဝေးမခေါ်ဖို့ကို ဦးစားပေးလုပ်ရမယ်။ ဉပမာ အီးမေးလ်နဲ့ ပြီးသွားမဲ့ ကိစ္စကို ရှိသမျှလူအကုန်ခေါ်ပြီး အစည်းအဝေးကြီးထိုင်တာမျိုးကို ရှောင်ရမယ်။ အစည်းအဝေးတွေက "Synchronous communication" လို့ခေါ်တဲ့ တစ်ယောက်နဲ့တစ်ယောက်အလုပ်အမျိုးအစားချင်းမတူပေမဲ့ တစချိန်တည်း အားနေမယ်ဆိုတဲ့ လိုအပ်ချက်ရှိနေတယ်။ ဒီတော့ အလုပ်မများတဲ့သူက အလုပ်များတဲ့သူ အားတာကို စောင့်နေရတယ်။ ဒီလိုမဖြစ်ရအောင် အကြောင်းအရာတစ်ခုကို အီးမေးလ်နဲ့ စာလေးသေချာရေး၊ အချိန်တစ်ခုပေးထားပြီး အကြောင်းပြန်ပေးဖို့ပြော။ တစ်ဖက်ကလည်း သူအနေနဲ့ ဒီအကြောင်းအရာကို သေချာလေး စဉ်းစားပေးဖို့ အချိန်ရသွားမယ်။ အီးမေးလ်က အပြန်အလှန် ဆွေးနွေးကြပြီးပြီဆိုမှ အချောသတ်လောက်ကိုပဲ ၁၀ မိနစ် ၁၅ မိနစ်လောက် အချိန်ပေးပြီး အားလုံးတစ်ပြေးညီ ဖြစ်အောင်လုပ်တာက ပိုပြီး အလုပ်ကို သေသပ်စေတယ်။ နောက်တစ်ခုက Calendar မှာ အစည်းအဝေးလုပ်ဖို့ ချိန်းကတည်းက လိုအပ်တဲ့/သက်ဆိုင်တဲ့ Document တွေကို "Description" လိုနေရာမျိုးမှာ ထည့်ထားပေးဖို့လည်းလိုအပ်တယ်။ ဒါမှ ပါဝင်တဲ့သူတွေက အစည်းအဝေးမစခင် ကြိုပြင်ဆင်ချိန်ရပြီး အားလုံးအချိန်သက်သာစေမယ်ဖြစ်တယ်။

အပေါ်ကလိုမျိုး မလုပ်ကြတဲ့နေရာမျိုးမှာဆိုရင် ကိုယ့်အနေနဲ့ ဘာလုပ်လို့ရမလဲ။ အကောင်းဆုံးက Calendar မှာ ကိုယ်က "ကုဒ်ရေးရန်အချိန်" ဆိုပြီး တစ်နေ့ ဘယ်လောက်ဆိုပြီး block ထားလိုက်ပါ။ ဒီ block ထားတဲ့အချိန်ကို လိုချင်တယ်ဆိုရင် တော်တော်အသည်းအသန် အရေးတကြီးဖြစ်မှရမယ်ဆိုတာ သိအောင်လုပ်ထားပေးပါ။ မဟုတ်ရင်ဘာဖြစ်လဲဆိုတော့ အစည်းအဝေးတွေနဲ့အချိန်ကုန်သွားတယ်၊ ကိုယ့်အလုပ်တွေနောက်ကျတယ်။ နောက်မကျအောင် ညဘက်တွေပါလုပ်ရတယ်။ ကြာတော့ ပင်ပန်းလာမယ်။ နောက်တစ်နည်းက ပြောင်းပြန်အနေနဲ့ Book လို့ရတဲ့အချိန်က ဘယ်ရက် ဘယ်ကနေ ဘယ်နာရီဆိုပြီး ထားထားပေးလည်း ကိုယ့်အချိန်ကို လိုချင်တဲ့သူအနေနဲ့ ဘယ်အချိန် အဆင်ပြေတယ်ဆိုတာ တန်းသိနိုင်မယ်။ ဒါကလည်း လွယ်ချင်ရင်တော့ Online tool တွေဝယ်သုံးပေါ့ဗျာ။

အလုပ်အချိန်နဲ့ ကိုယ်ရေးကိုယ်တာအချိန်တွေ မျှတာအောင် ချိန်ညှိတတ်ပြီး အလုပ်မှာလည်းပျော်၊ နားချိန်မှာလည်းပျော်တဲ့သူတွေ ဖြစ်လာကြပါစေ။

Read more

Platform Engineering: Developers for Developers

Platform Engineering: Developers for Developers

Software Development Team တွေကို ချဲ့ထွင်တဲ့အခါမှာ အတားအဆီးမရှိအောင် Process တွေ၊​ စံနှုန်းတွေ၊ Automation အစရှိတွေကို တာဝန်ယူတဲ့ အဖွဲ့တစ်ဖွဲ့ သီးသန့်ထားလေ့ရှိတယ်။ ဒီ Team ကို Platform Engineering လိုခေါ်တွင်တယ်။

lock-1 By Aung Kyaw Paing
Spikes: Making Unknowns Known

Spikes: Making Unknowns Known

ဒီထက်ပိုပြဿနာရှိတာက သေချာမသိပဲလုပ်မယ်ဆိုရင် တစ်ဝက်လောက်ရောက်မှ ဆက်လုပ်ဖို့ အဆင်မပြေတာသော်လည်းကောင်း၊ သွားချင်တဲ့လမ်းကြောင်း မမှန်တာသော်လည်းကောင်းဆိုရင် လုပ်ထားသမျှ သဲထဲရေသွန်ဖြစ်မယ်။ ဒီတော့မသိသေးတဲ့အကြောင်းအရာ တစ်ခုကို နည်းနည်းပါးပါးလောက် နားလည်ဖို့လိုအပ်လာတဲ့အခါမှာ...

By Aung Kyaw Paing
Tips & Tricks for Distributed Remote Collaboration

Tips & Tricks for Distributed Remote Collaboration

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

By Aung Kyaw Paing
ссс