Poka-Yoke (ပိုကာယိုကေ)

Poka-Yoke ဆိုတာ ဂျပန်စကားဖြစ်ပြီး အမှားဖြစ်နိုင်ခြေကို ကြိုတင် ကာကွယ်တဲ့ နည်းစနစ်တစ်ခုပါ။ Poka-Yoke နည်းစနစ်ကို 1960 ဝန်းကျင်လောက်က ဂျပန်နိုင်ငံမှ Shigeo Shingo က Toyota Production System (TPS) ရဲ့ အစိတ်အပိုင်း တစ်ခုအနေနဲ့ တီထွင်ခဲ့တာဖြစ်ပါတယ်။

အနှစ်ချုပ် -

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

Poka-Yoki နည်းစနစ်ကို ဆော့ဖ်ဝဲ ထုတ်ကုန်တွေ ဖန်တီးတဲ့ နေရာမှာ - ဘယ်လိုသုံးလို့ရမလဲ? ဘယ်လိုသုံးနေလဲ?

1) Input Validation & Error Messages
* Server မှာ Data တွေမသိမ်းခင်မှာ User Input အနေနဲ့ အမှားရှိ မရှိ စစ်ဆေးခြင်း နဲ့ အချက်အလက်တွေ မှန်အောင်ထည့်သွင်းဖို့ သတိပေးခြင်း။ ဥပမာ - Google Email Account ဖွင့်တဲ့ အချိန်မှာ သုံးထားတဲ့ ပုံစံကိုကြည့်ပါ။

ဒါက နမူနာ အနေနဲ့ပါ ဒီထက် ပိုကောင်းအောင် ထပ်စဉ်းစားလို့ရပါတယ်။ နမူနာအနေနဲ့ Mobile phone input box မှာ number တွေပဲ ထည့်လို့ရပြီး number ကလွဲရင် တစ်ခြား letter or symbol တွေ လုံးဝ ရိုက်လို့မရအောင် input event မှာဖမ်းပြီး ကြိုကာကွယ်ထားတာမျိုး။

2) Automatic Save
data ထည့်သွင်းပြီး မ သိမ်းမိလိုက်တာမျိုးကို data တွေ အလိုအလျောက် သိမ်းဆည်းပေး (Save) တဲ့ နည်းစနစ်မျိုး။ User က data တွေထည့်သွင်းပြီး Save ဖို့ မေ့သွားတာမျိုး၊ မထင်မှတ်တဲ့အကြောင်းတစ်ခုခုကြောင့် သုံးနေတဲ့ Device ပျက်သွားတာမျိုး စတာတွေကြောင့် Data တွေမဆုံးရှုံး ရအောင် ကြိုတင်ကာကွယ် ဖို့အတွက် ရည်ရွယ်ပါတယ်။ ဥပမာ - Google Docs တွေသုံးရင် User အလုပ်လုပ်နေချိန်တိုင်း Data ကို အလိုအလျောက် Save လုပ်ပေးတာမျိုး။

3) Version Control Systems
အမှားရှိမရှိစစ်စစ်ပြီး မိမိ လုပ်ထားတာတွေ (Code) ကို မရှုပ်အောင်၊ အခြားသူတွေ လုပ်ထားတာတွေ (Code) တွေ နဲ့ ရှင်းရှင်းလင်းလင်း ပေါင်းစပ်နိုင်အောင် လုပ်ပေးတဲ့ နည်းစနစ်မျိုး။ ဥပမာ - Git, Apache Subversion (SVN)

4) Unit Testing
Code ရဲ့ Functionality တွေကို စစ်ဆေးပြီး အမှားမရှိအောင် ကြိုကာကွယ်ပေးတယ်။ Unit Test တွေရေးထားပြီး run ချလိုက်ရင် အရင်ရေးထားတာတွေ အသစ်ထပ်ရေးတာတွေ ပေါင်းအလုပ်လုပ်တဲ့အခါ အမှားတွေရှိရင် error message အလိုအလျောက် ပေါ်လာလိုက်မယ်။ Deploy မလုပ်ခင် QA မစစ်ရသေးခင် ကြိုပြင်လို့ရတာပေါ့။ Deploy လုပ် QA စစ်ပြီးမှ error ပေါ်လို့လာလို့ ပြန်ပြင်ရရင် အချိန်တွေပိုကုန်ပါတယ်။

5) Continuous Integration/Continuous Deployment (CI/CD)
တစ်ခါ release လုပ်ရင် manual တစ်ခါ deploy လုပ်တဲ့အခါ Dependencies, Versions, Runtime Environments, ... စသဖြင့် မှားနိုင်ခြေတွေ ရှိပါတယ်။ CI/CD နည်းစနစ်ကို သုံးလိုက်ရင် တစ်ကြိမ်သာ အစီအစဉ်တွေ ကြိုသတ်မှတ်ထားပြီး Code ကို အလိုအလျောက် Build, Test, Deploy လုပ်ပေးနိုင်တယ်။ အဲ့တော့ အမှားနည်းသွားပြီး အချိန်ကုန်သက်သာ ပါတယ်။

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

Aung Kyaw Minn

Founder @ Tally Sale