AI Driven Development ၏ လက်ရှိအခြေအနေ - Software Engineering သမိုင်းမှ သင်ခန်းစာများ

■ ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေး သမိုင်းကြောင်းသည် 'ရှုပ်ထွေးမှု (Chaos) နှင့် အင်ဂျင်နီယာပညာရပ် (Engineering)' တို့အကြား လွန်ဆွဲပွဲ ဖြစ်ခဲ့သည်။

ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေး စတင်ပေါ်ပေါက်ခါစ ကာလတွင် ရေးထားသော ကုဒ် (Code) သည်သာ လုပ်ငန်းသတ်မှတ်ချက် ဖြစ်ခဲ့ပြီး၊ လူအနည်းငယ်၏ သိနားလည်မှု (Tacit knowledge) ဖြင့်သာ လုပ်ငန်းများကို လည်ပတ်ခဲ့ကြသည်။ စနစ်က သေးငယ်ပြီး လူနည်းစဉ်တွင် ဤနည်းလမ်းက အဆင်ပြေခဲ့သည်။ သို့သော် စနစ်ကြီးမားလာပြီး လူဦးရေများပြားလာသောအခါ ထိုသိနားလည်မှုများမှာ ပျက်ပြားသွားခဲ့သည်။ ပရောဂျက်များ ကြန့်ကြာခြင်း、အရည်အသွေးကျဆင်းခြင်းနှင့် ဆက်သွယ်ရေး အဆင်မပြေခြင်းများ ဖြစ်ပေါ်လာပြီး “Software Crisis (ဆော့ဖ်ဝဲလ်အကျပ်အတည်း)” ဟုခေါ်သော ပြဿနာကြီးနှင့် ရင်ဆိုင်ခဲ့ရသည်။ စနစ်တကျ ဖြစ်စေရန် ကြိုးပမ်းမှုများနှင့် ပြောင်းလဲလာပုံ ထိုအကျပ်အတည်းမှတစ်ဆင့် ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေးကို စနစ်တကျ အင်ဂျင်နီယာပညာရပ်ဆန်ဆန် လုပ်ဆောင်သည့် Waterfall (ရေတံခွန်ပုံစံလုပ်ငန်းစဉ်) များ ပေါ်ပေါက်လာခဲ့သည်။ ၎င်းသည် ဝေဝါးမှုများကို လျှော့ချရန် လုပ်ငန်းအဆင့်ဆင့် ခွဲခြားခြင်း၊ ပြန်လည်စစ်ဆေးခြင်း (Review) နှင့် အရည်အသွေးထိန်းချုပ်ခြင်း (Quality control) တို့ကို မိတ်ဆက်ပေးခဲ့သည်။ နောက်ပိုင်းတွင် ထိုစနစ်၏ စာရွက်စာတမ်း အလွန်အကျွံ အသားပေးမှုကို ဆန့်ကျင်ပြီး ပေါ့ပါးသွက်လက်သော Agile (အဂျိုင်းလ်လုပ်ငန်းစဉ်) ပေါ်ပေါက်လာခဲ့သည်။ 🎯 အဓိကသော့ချက် - ဤနေရာတွင် Waterfall နှင့် Agile မည်သည့်အရာက ပိုမှန်သလဲဆိုသည်က အရေးမကြီးပါ။ သမိုင်းတစ်လျှောက်လုံးတွင် အဓိက စိန်ခေါ်မှုမှာ 'ကြီးမားရှုပ်ထွေးလှသော ဆော့ဖ်ဝဲလ်စနစ်များကို စနစ်တကျနှင့် အစီအစဉ်တကျဖြစ်အောင် (Order) မည်သို့ ထิန်းချုပ်မလဲ' ဆိုသည့်အချက်သာ ဖြစ်သည်။

■ Agile (အဂျိုင်းလ်) အောင်မြင်ခဲ့ခြင်းသည် လုပ်ငန်းသတ်မှတ်ချက်များ (Specifications) မလိုအပ်တော့ဟု မဆိုလိုပါ။

Agile လုပ်ငန်းစဉ်ကို 'စာရွက်စာတမ်းများ (Documentation) မလိုတော့ပါ' ဟု အယူအဆ မှားလေ့ရှိကြသည်။ သို့သော် အမှန်တကယ်တွင်မူ Agile သည် စဉ်ဆက်မပြတ် အလှည့်အပြောင်းလုပ်နိုင်သော၊ တန်ဖိုးကို ဦးစားပေးသော၊ ပေါ့ပါးသော်လည်း အဓိပ္ပာယ်ပြည့်ဝသော လုပ်ငန်းသတ်မှတ်ချက်များကို အလေးထားသည့် အတွေးအခေါ်တစ်ခုသာ ဖြစ်သည်။ သို့ရာတွင် အချို့သော လုပ်ငန်းခွင်များတွင် လုပ်ငန်းသတ်မှတ်ချက်များကို လျစ်လျူရှုပြီး လူအချင်းချင်း စကားပြောဆိုမှုအပေါ်၌သာ အလွန်အကျွံ မှီခိုလာကြသည်။ ထို့ကြောင့် ရေးထားသော ကုဒ် (Source code) တစ်ခုတည်းသာလျှင် တစ်ခုတည်းသော အမှန်တရား (Sole truth) ဖြစ်နေသည့် အခြေအနေမျိုးအထိ ဖြစ်ပွားခဲ့သည်။

■ AI သည် အတိတ်က 'ကုဒ် = လုပ်ငန်းသတ်မှတ်ချက်' ဆိုသည့် ခေတ်ကို ပြန်ခေါ်လာလိမ့်မည်။

AI Agent များသည် ကုဒ်ကို အလွန်မြန်ဆန်စွာ ရေးပေးနိုင်သော်လည်း၊ ၎င်းသည် လူသားတို့၏ နားလည်နိုင်စွမ်းနှင့် သဘောတူညီမှု ရယူနိုင်စွမ်းထက် များစွာမြန်နေသဖြင့် အဆက်အစပ် ပြတ်တောက်မှုကို ဖြစ်စေသည်။ လူက အပြည့်အဝ နားမလည်ဘဲ AI ရေးလိုက်သော စနစ်သည် အပေါ်ယံတွင် အလုပ်လုပ်နေသလို ထင်ရသဖြင့် ၁９၆၀ ပြည့်လွန်နှစ်များက 'ကုဒ်သည်သာ သတ်မှတ်ချက်ဖြစ်သည်' ဟူသော ရှုပ်ထွေးပရမ်းပတာခေတ်ကို ပိုမိုမြန်ဆန်စွာ ပြန်လည်ရောက်ရှိစေမည် ဖြစ်သည်။ မူလက ဆော့ဖ်ဝဲလ်အင်ဂျင်နီယာပညာရပ်သည် စနစ်တစ်ခုကို 'ဘာကြောင့် တည်ဆောက်ရသလဲ'၊ 'ဘယ်လို စစ်ဆေးခဲ့သလဲ' နှင့် 'ဘယ်သူ့မှာ တာဝန်ရှိသလဲ'ဆိုသည်ကို ရှင်းလင်းရန် ပေါ်ပေါက်လာခြင်း ဖြစ်သည်။ AI ခေတ်တွင် ဤလုပ်ငန်းစဉ်များက ပို၍ပင် အရေးကြီးလာသည်။ ဤနေရာတွင် ပေါ်လာမည့် ပြဿနာများသည် နည်းပညာအကြွေး (Technical debt) တင်ရုံတင်မကဘဲ လူတစ်ဦးတည်းအပေါ် မှီခိုရခြင်း၊ ပုံတူကူးချ၍ မရခြင်း၊ စစ်ဆေးရန် (Audit) ခက်ခဲခြင်း၊ အရည်အသွေး ပျက်ပြားခြင်းနှင့် ထိန်းသိမ်းစရိတ် တက်လာခြင်းတို့ ဖြစ်သည်။ ၎င်းတို့သည် ကုမ္ပဏီ၏ အမြတ်အစွန်းနှင့် စီးပွားရေး ရေရှည်ရပ်တည်မှုကို တိုက်ရိုက် ထိခိုက်စေနိုင်ပါသည်။

■ SDD သည် AI ခေတ်တွင် ပြန်လည်ဆန်းသစ်လာသော 'အင်ဂျင်နီယာပညာရပ်၏ Reboot' ဖြစ်သည်။

သတ်မှတ်ချက်အခြေပြု ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေး (SDD) သည် AI ခေတ်မှ ရုတ်တရက် ပေါ်လာသော အယူအဆ မဟုတ်ပါ။ Agile စနစ်များ ပြန့်နှံ့လာစဉ်က လျစ်လျူရှုခံခဲ့ရသော 'လုပ်ငန်းသတ်မှတ်ချက်များ၏ တန်ဖိုး' ကို AI ခေတ်တွင် ပြန်လည်အကဲဖြတ်လာကြခြင်း ဖြစ်သည်။ အဓိကအချက်မှာ အတိတ်ကကဲ့သို့ လေးလံထုထည်ကြီးမားသော စာရွက်စာတမ်းဝါဒဆီသို့ ပြန်သွားရန် မဟုတ်ပါ။ လုပ်ငန်းလိုအပ်ချက်များ၊ ကန့်သတ်ချက်များ၊ လက်ခံနိုင်မည့် အခြေအနေများနှင့် ဒီဇိုင်းရည်ရွယ်ချက်များကို AI ထံ လွှဲအပ်နိုင်ရန်အတွက် အစဉ်အမြဲ အပေါ်ဒိတ်ဖြစ်ပြီး အကောင်အထည်ဖော်နိုင်မည့် ပုံစံမျိုး ပြုလုပ်ထားရန် ဖြစ်သည်။ ၎င်းသည် လုပ်ငန်းခွင်သုံး ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေး (Enterprise development) တွင် အလွန်ပင် ကျိုးကြောင်းဆီလျော်မှု ရှိသည်။ လုပ်ငန်းသတ်မှတ်ချက်များ စနစ်တကျ ရှိနေသောအခါ AI သည် ပိုမိုလွယ်ကူစွာ လည်ပတ်နိုင်ပြီး၊ ကုဒ်စစ်ဆေးမှု (Review) များ အလွယ်တကူ အောင်မြင်နိုင်ကာ၊ လူအများအပြားနှင့် လုပ်ငန်းခွင်နေရာအသီးသီးအကြား နားလည်မှုများကို ညှိနှိုင်းရန် ပိုမိုလွယ်ကူစေသည်။ ရလဒ်အနေဖြင့် ပြန်လည်ပြင်ဆင်ရမှုနှုန်း (Rework rate) လျော့ကျခြင်း၊ ရေရှည်ထိန်းသိမ်းရလွယ်ကူခြင်းနှင့် ဝန်ထမ်းအသစ်လေ့ကျင့်ရေးစရိတ်များ လျော့နည်းခြင်းတို့ဆီသို့ ဦးတည်စေပါသည်။

■ AI ခေတ်၏ ပြိုင်ဆိုင်မှုစွမ်းရည်သည် ကုဒ်ထုတ်လုပ်နိုင်သည့် ပမာဏအပေါ်တွင် မဟုတ်ဘဲ ဒီဇိုင်းဆွဲနိုင်စွမ်းအပေါ်တွင်သာ မူတည်လိမ့်မည်။

အနာဂတ်တွင် AI ကို မည်သူမဆို အသုံးပြုနိုင်မည်ဖြစ်သောကြောင့် ရိုးရှင်းသော အကောင်အထည်ဖော်မှု မြန်နှုန်း (Implementation speed) ကွာဟချက်များကို အလွယ်တကူ ကျော်လွှားနိုင်မည် ဖြစ်သည်။ အဓိက ကွာခြားချက်မှာ လုပ်ငန်းသတ်မှတ်ချက်များကို မည်မျှ ကောင်းမွန်စွာ ရေးသားနိုင်သလဲ၊ ကန့်သတ်ဘောင်များ (Guardrails) ကို မည်မျှ စနစ်တကျ ပုံစံထုတ်နိုင်သလဲနှင့် စစ်ဆေးအတည်ပြုခြင်း (Verification) များကို မည်မျှ ထိရောက်စွာ ထည့်သွင်းနိုင်သလဲ ဆိုသည့်အချက်များအပေါ်တွင်သာ မူတည်လာမည်။ တစ်နည်းအားဖြင့် ပြိုင်ဆိုင်မှုဆိုင်ရာ အားသာချက်များ၏ အခြေခံအရင်းအမြစ်သည် ကုဒ်ရေးသားနိုင်စွမ်း (Coding ability) ၏ အစိတ်အပိုင်းတစ်ခုမှသည် လုပ်ငန်းစဉ်များကို ပုံစံထုတ်ခြင်း (Design)၊ ထိန်းချုပ်ခြင်း (Control) နှင့် အရည်အသွေး သေချာစေခြင်း (Quality assurance) တို့ဆီသို့ လုံးဝရွေ့လျား ပြောင်းလဲသွားမည် ဖြစ်သည်။

■ AI သည် မြန်ဆန်လွန်းသောကြောင့် လုပ်ငန်းသတ်မှတ်ချက်များကို ကြိုတင်သတ်မှတ်ထားရမည်။

ဝေဝါးသော ညွှန်ကြားချက်များပေးလျှင်ပင် AI သည် အတိုင်းအတာတစ်ခုအထိ စံချိန်မီသော ကုဒ်များကို ပြန်ထုတ်ပေးလိမ့်မည်။ ဤကဲ့သို့ 'ဟုတ်တုတ်တုတ်' ဖြစ်နေခြင်းသည် AI အသုံးပြုခြင်း၏ အကြီးမားဆုံး ဆွဲဆောင်မှုဖြစ်သလို၊ တစ်ချိန်တည်းမှာပင် အကြီးမားဆုံး ထောင်ချောက်လည်း ဖြစ်သည်။ လူသားများသည် မရေရာသော လိုအပ်ချက်များနှင့် ကြုံတွေ့ရပါက လုပ်ငန်းကို ခေတ္တရပ်ဆိုင်းပြီး ရှင်းလင်းချက်တောင်းခံလေ့ရှိသော်လည်း၊ AI ကမူ ရပ်တန့်မသွားဘဲ ဆက်လက်လုပ်ဆောင်နေမည် ဖြစ်သည်။ ထို့ကြောင့် AI ကိုအသုံးပြုသော ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေးတွင် လိုအပ်ချက်များ၊ ကန့်သတ်ချက်များ၊ ဒီဇိုင်းရည်ရွယ်ချက်များနှင့် လက်ခံနိုင်မည့် အခြေအနေများကို ကြိုတင်သတ်မှတ်ထားရန် အရေးကြီးသည်။ ဘာကို တည်ဆောက်ရမည်နည်း ဟူရုံတင်မကဘဲ ဘာကို မလုပ်ရဘူးလဲနှင့် မည်သည့်အရာက လက်ခံနိုင်သော ဘောင်အတွင်းရှိသလဲ ဆိုသည်ကိုပါ AI ကိုင်တွယ်နိုင်မည့် ပုံစံမျိုးဖြင့် ရှင်းလင်းပြတ်သားစွာ သတ်မှတ်ပေးရန် လိုအပ်သည်။ ဤနေရာတွင် ဖော်ပြထားသော လုပ်ငန်းသတ်မှတ်ချက် (Specifications) ဆိုသည်မှာ လေးလံထုထည်ကြီးမားသော စာရွက်စာတမ်းများကို ဆိုလိုခြင်းမဟုတ်ပါ။ ၎င်းတို့သည် အမြဲတစေ ပြုပြင်ပြောင်းလဲနိုင်ပြီး အကောင်အထည်ဖော်ခြင်းနှင့် စစ်ဆေးအတည်ပြုခြင်းတို့ဆီသို့ တိုက်ရိုက်ဦးတည်နိုင်မည့် အသက်ဝင်နေသော သတ်မှတ်ချက်များ (Living specs) ဖြစ်သည်။ ၎င်းတို့ ရှိနေခြင်းဖြင့် AI ကို ပိုမိုတည်ငြိမ်စွာ လည်ပတ်စေနိုင်မည် ဖြစ်သည်။

■ AI ထံပေးသော ညွှန်ကြားချက်များ၏ အရည်အသွေးသည် ရလဒ်ထွက်ကုန်များ၏ အရည်အသွေးအဖြစ် တိုက်ရိုက် ပြောင်းလဲသွားသည်။

AI ခေတ်၏ ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေးတွင် ပရုံးစကေး (Prompt skill) ကောင်းရုံတင်မကဘဲ၊ လုပ်ငန်းလိုအပ်ချက် သတ်မှတ်ချက်များ၏ ရှင်းလင်းပြတ်သားမှု၊ ဒီဇိုင်း၏ အသေးစိတ်ကျမှုနှင့် လက်ခံနိုင်မည့် အခြေအနေများ (Acceptance conditions) ကပါ ရလဒ်ထွက်ကုန်များအပေါ် အားကောင်းကောင်းဖြင့် တိုက်ရိုက် သက်ရောက်လာမည် ဖြစ်သည်။ တစ်နည်းအားဖြင့်ဆိုရသော် ဝေဝါးသော အဖွဲ့အစည်းတစ်ခုသည် ဝေဝါးသော ရလဒ်များကိုသာ ထုတ်လုပ်နိုင်လိမ့်မည်။ ဤရှုထောင့်မှကြည့်လျှင် SDD (သတ်မှတ်ချက်အခြေပြု ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေး) သည် AI ကို ထိရောက်စွာ အသုံးပြုနိုင်ရန်အတွက် မရှိမဖြစ် လိုအပ်သော ကြိုတင်ပြင်ဆင်မှု စွမ်းရည်တစ်ခု ဖြစ်သည်ဟု ဆိုနိုင်ပါသည်။

■ CI/CD နှင့် Quality Gates များသည် AI ခေတ်၏ 'အလိုအလျောက် ဘရိတ်စနစ်' များ ဖြစ်သည်။

AI က ထုတ်လုပ်ပေးသော ကုဒ်များကို လက်တွေ့လုပ်ငန်းခွင် (Production) တွင် အသုံးပြုသည့်အခါ အလိုအလျောက် စစ်ဆေးအတည်ပြုသည့်စနစ် (Automated verification) သည် မရှိမဖြစ် လိုအပ်သည်။ CI/CD ဆိုသည်မှာ အလိုအလျောက် လုပ်ဆောင်ပေးသော ပိုက်လိုင်း (Pipeline) တစ်ခုမျှသာ မဟုတ်ဘဲ၊ AI က ထုတ်ပေးလိုက်သော ရလဒ်များကို စစ်ထုတ်ပေးသည့် အရည်အသွေးစစ်ဆေးရေးဂိတ် (Quality gate) တစ်ခု ဖြစ်သည်။ Testing၊ Linting၊ လုံခြုံရေးအားနည်းချက် စစ်ဆေးခြင်း၊ ကုဒ်ရေးထုံးစံနှုန်း (Convention) စစ်ဆေးခြင်းနှင့် Dependency စစ်ဆေးခြင်းတို့မှတစ်ဆင့် AI ၏ ရလဒ်သည် စံချိန်စံညွှန်းများနှင့် ကိုက်ညီမှု ရှိမရှိကို စက်ပစ္စည်းယန္တရားဖြင့် တိတိကျကျ ဆုံးဖြတ်ပေးနိုင်သည်။ ဤနေရာတွင် အရေးကြီးသည်မှာ AI ၏ စေတနာ သို့မဟုတ် ၎င်း၏ 'ထက်မြက်မှု' အပေါ်တွင် လုံးဝ မမှီခိုရန် ဖြစ်သည်။ AI သည် စွမ်းဆောင်ရည်မြင့်မားသော အကောင်အထည်ဖော်သူ (Implementation entity) မျှသာဖြစ်ပြီး၊ တာဝန်ခံရမည့် အဖွဲ့အစည်း မဟုတ်ပါ။ စံနှုန်းများကို မလိုက်နာသော ကုဒ်များကို အလိုအလျောက် ရပ်တန့်ပေးမည့် ယန္တရားရှိနေသောကြောင့်သာ ဖွံ့ဖြိုးရေးမြန်နှုန်း တိုးတက်လာသော်လည်း အရည်အသွေး ကျဆင်းမသွားခြင်း ဖြစ်သည်။ စီမံခန့်ခွဲမှု ရှုထောင့်မှကြည့်လျှင် ဤစနစ်သည် အရည်အသွေးပိုင်းဆိုင်ရာ မတော်တဆမှုများကို ကာကွယ်ပေးရုံတင်မကဘဲ ကုဒ်စစ်ဆေးရသည့် အလုပ်ဝန်ထုပ်ဝန်ပိုးကို မျှတစေခြင်း၊ တစ်ဦးချင်းစီ၏ စိတ်ခံစားချက်အပေါ်မူတည်၍ ဆုံးဖြတ်မှုများကို လျှော့ချပေးခြင်းနှင့် လုပ်ငန်းခွင်နေရာအသီးသီးအကြား အရည်အသွေး ကွာဟချက်များကို ထိန်းချုပ်ပေးခြင်းတို့ဆီသို့ ဦးတည်စေပါသည်။

■ AI ကို ယုံကြည်မည့်အစား ကျော်ဖြတ်ရမည့် အရည်အသွေး ကန့်သတ်ချက် (Hurdles) များကိုသာ ယုံကြည်ပါ။

AI ကို လက်တွေ့အသုံးပြုပြီး ရင့်ကျက်အောင်မြင်လာသော အဖွဲ့အစည်းများသည် 'AI ကို ဘယ်လောက်အထိ ယုံကြည်ရမလဲ' ဆိုသည်ကို ဆွေးနွေးငြင်းခုံခြင်း မပြုကြတော့ပါ။ ၎င်းအစား 'သတ်မှတ်ထားတဲ့ စံချိန်စံညွှန်း ကိုက်ညီတဲ့ ရလဒ်ထွက်ကုန်တွေကိုပဲ ထုတ်လုပ်ခွင့်ပြုမယ်' ဆိုပြီးသာ တိတိကျကျ သတ်မှတ်ကြသည်။ ဤသည်မှာ အလွန်အရေးကြီးသော အတွေးအခေါ်အပြောင်းအလဲ ဖြစ်သည်။ တစ်ဦးချင်းစီ၏ အတွေ့အကြုံနှင့် စိတ်ထင်မြင်ချက် (Intuition) အပေါ်တွင် မှီခိုမည့်အစား၊ သတ်မှတ်ထားသော စည်းမျဉ်းများနှင့် ကိုက်ညီသည့်အရာများကိုသာ ထုတ်လွှတ်ခွင့်ပြုခြင်း ဖြစ်သည်။ ဤနည်းလမ်းအားဖြင့်သာ ထပ်ခါတလဲလဲ လုပ်ဆောင်သော်လည်း တသမတ်တည်းဖြစ်သော ရလဒ်ကောင်းများ ထွက်ပေါ်လာခြင်း (Reproducibility) ကို ဖန်တီးပေးနိုင်မည် ဖြစ်သည်။

■ နောက်ဆုံးတွင် တာဝန်ယူမှု၊ တာဝန်ခံမှုသည် လူသားများအပေါ်၌သာ တည်ရှိသည်။

AI က အကောင်အထည်ဖော်မှုအပိုင်းကို တာဝန်ယူထားစေကာမူ ၎င်းသည် တာဝန်ခံမှုကိုမူ လွှဲပြောင်းရယူသွားမည် မဟုတ်ပါ။ နောက်ဆုံးတွင် ရလဒ်ထွက်ကုန်များကို အတည်ပြုခြင်း၊ ထုတ်လွှတ်ခြင်း (Release) နှင့် အသုံးပြုသူများအပေါ် တာဝန်ခံခြင်းတို့ကို ပြုလုပ်ရမည်မှာ လူသားများသာ ဖြစ်သည်။ ဤအခြေခံအချက်သည် AI ခေတ်ကြီးတွင်လည်း ပြောင်းလဲသွားမည် မဟုတ်ပါ။ ထို့ကြောင့် အင်ဂျင်နီယာများ၏ အခန်းကဏ္ဍသည် လျော့နည်းသွားမည်မဟုတ်ဘဲ ပိုမိုမြင့်မားဆန်းသစ်လာမည် ဖြစ်သည်။ ရိုးရှင်းသော လုပ်ငန်းလုပ်ဆောင်သူများ၏ တန်ဖိုးကို AI က အတိုင်းအတာတစ်ခုအထိ အစားထိုးနိုင်သော်လည်း၊ ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေး လုပ်ငန်းစဉ်တစ်ခုလုံးကို ကြီးကြပ်နိုင်ခြင်း၊ ပုံစံထုတ်ခြင်း၊ စစ်ဆေးခြင်းနှင့် အရည်အသွေးနှင့် ဘေးကင်းလုံခြုံမှုကို သေချာစေနိုင်ခြင်းတို့ လုပ်ဆောင်နိုင်သည့် ဝန်ထမ်းများ၏ အရေးပါမှုမှာ ပိုမိုမြင့်မားလာမည် ဖြစ်သည်။ PM များ၊ PL များ၊ Tech Lead များ၊ Architect များ၊ QA များနှင့် IT စနစ်မန်နေဂျာများအတွက်မူ ယခုအချိန်သည် မိမိတို့၏ အခန်းကဏ္ဍကို 'စီမံခန့်ခွဲမှု (Management)' အဖြစ်မဟုတ်ဘဲ 'ထိန်းချုပ်မှုစနစ် ပုံစံထုတ်ခြင်း (Control design)' အဖြစ် ပြန်လည်အဓိပ္ပာယ်ဖွင့်ရမည့် အချိန် ဖြစ်သည်။ လက်တွေ့လုပ်ငန်းခွင်မှ အင်ဂျင်နီယာများအတွက်မူ ကုဒ်ရေးသားနိုင်စွမ်းအပြင် လုပ်ငန်းသတ်မှတ်ချက်များကို စနစ်တကျ ဖွဲ့စည်းတည်ဆောက်နိုင်စွမ်း၊ ကုဒ်စစ်ဆေးမှုဆိုင်ရာ ရှုထောင့်အမျိုးမျိုး ရှိနေနိုင်စွမ်းနှင့် တိုးတက်မှုအလှည့်အပြောင်း (Improvement cycles) များကို မောင်းနှင်နိုင်စွမ်းတို့သည် နောင်အနာဂတ် စျေးကွက်တွင် မိမိတို့၏ တန်ဖိုး (Market value) ဖြစ်လာပါလိမ့်မည်။