အမွားေတြကို ရင္ဆိုင္ဖို႔ အေကာင္းဆံုး နည္းယာမကေတာ့ ပထမဆံုး အဲဒီအမွားေတြကို
မလုပ္မိဖို႔နဲ႔ ေရွာင္ႏိုင္ဖို႔ပါပဲ။ အခုေျပာျပမယ့္ဟာကေတာ့ ေယဘူယ်အားျဖင့္
ၾကံဳတတ္တဲ့ အခ်က္အခ်ိဳ ႔ကိုပါ။
သင္ၾကားဖူးျပီးသားျဖစ္မွာပါ "Be proactive, not reactive" ဆိုတဲ့ စကားကိုပါ။
ဒီစကားစုဟာ အမွားေတြကို ရင္ဆိုင္ဖို႔ အေကာင္းဆံုး စကားစု တစ္ခုပါပဲ။
စဥ္းစားပံုကေတာ့ အမွားေတြကို မၾကံဳေတြ႔ခင္ ၾကိဳတင္ ကာကြယ္တာပါပဲ။ ကာကြယ္ျခင္းဟာ
ကုသျခင္းထက္ေကာင္းတယ္လို႔ ဆိုတယ္မဟုတ္ပါလား။
ဒါေပမယ့္ အဲဒါေတြကို ဘယ္လိုလုပ္ရမလဲ။ ဘယ္လို ကာကြယ္ရမလဲ။ ဆိုတဲ့ ေမးခြန္းေတြ
ေမးလာႏိုင္ပါတယ္။ ဒီ စာမ်က္ႏွာကေန လက္ေတြ႔ ေလာကမွာ project ေတြ ထုတ္လုပ္တဲ့
ေနရာမွာ ၾကံဳေတြ႔တတ္တဲ့ အမွားေတြကေန ေရွာင္နည္း၊ ကာကြယ္နည္း 10
ခ်က္ကိုေရးသားေဖာ္ျပေပးပါမယ္။ အခုေရးသားမယ့္ အေၾကာင္းအရာေတြက Developers ေတြကို
အဓိကရည္ရ႔ြယ္ျပီး ေရးသားထားေပမယ့္ အျခား IT roles ကလူေတြလည္း ဒီစာမ်က္ႏွာေတြကေန
အက်ိဳးေက်းဇူးရႏိုင္မယ္လို႔ ေမွ်ာ္လင့္ပါတယ္။
*(၁) အျခားသူေတြရဲ ႔အမွားေတြကေန သင္ယူပါ*
ကိုယ္လုပ္ခဲ့တဲ့ အမွားေတြကို မွ်ေ၀ခ်င္တဲ့ သူေတြကို ရွာေဖြၾကည္႔ပါ။
ကိုယ္ကိုတိုင္ကလည္း မွ်ေ၀ေပးျပီး သူတို႔ေတြ ေျပာျပတဲ့ အေတြ႔အၾကံဳေတြကုိလည္း
နားေထာင္ေပးပါ။
*(၂)သုေတသနကို အရင္လုပ္ပါ*
သိထားတာေတြ ဘယ္ေလာက္ပဲ မ်ားမ်ား၊ ေန႔စဥ္လုပ္ေဆာင္မႈေတြမွာ စိန္ေခၚမႈ အသစ္ေတြ
ေတြ႔ေနရဦးမွာပါ။ စိန္ေခၚမႈ တိုင္းမွာ အသစ္အသစ္ေသာ သင္ၾကားေလ့လာဖို႔
လုိအပ္မႈေတြ ရွိေနပါတယ္။ ျပႆနာေတြ၊ စိန္ေခၚမႈေတြကို မရင္ဆိုင္ခင္မွာ အရင္ဆံုး
စူးစမ္းေလ့လာမႈ၊ သုေတသနကို အရင္လုပ္ၾကည္႔သင့္ပါတယ္။
"Trial-and-error" လို႔ ေခၚတဲ့ စမ္းသပ္ သင္ၾကားမႈ နည္းလမ္းဟာ
ႏွစ္ေပါင္းမ်ားစြာကတည္းက လက္ခံက်င့္သံုးလာတဲ့ နည္းလမ္း တစ္ခုပါပဲ။ ဒါေပမယ့္
အင္တာနက္မွာ ရရွိႏိုင္တဲ့ သယံဇာတ အရင္းအျမစ္ၾကီးရွိေနမွေတာ့ ၾကိဳတင္ ျပင္ဆင္
သုေတသန၊ ရွာေဖြစူးစမ္းမႈကို ၾကိဳတင္ျပင္ဆင္ ျပဳလုပ္မထားတာကေတာ့ ၾကီးမားတဲ့
အမွားတစ္ခုပါပဲ။ ဒါ့ေၾကာင့္ သင့္ေတာ္တဲ့ စူးစမ္းရွာေဖြ သုေတသနျပဳမႈကို
ၾကိဳတင္ျပီး လုပ္ေဆာင္သင့္ပါတယ္။
*(၃) ၾကံစည္မႈ Plan ရွိပါေစ*
သြားရမယ့္ လမ္းေၾကာင္းျပေျမပံု Roadmap သာမရွိရင္ လမ္းဆံုးပန္းတုိင္ကို ဘယ္လို
သြားရမယ္ဆိုတာ မသိႏိုင္ပါဘူး။ Project Development မွာေတာ့ အဲဒီ Roadmap ကို
project plan လို႔ ေခၚပါတယ္။ formally ပဲျဖစ္ျဖစ္ informally ပဲျဖစ္ျဖစ္၊
အလုပ္တစ္ခုကို လုပ္ေတာ့မယ္ဆိုရင္ သြားမယ့္ေနရာကို ဘယ္လို ေရာက္ေအာင္သြားမယ္
ဆိုတာကို သိထားသင့္ပါတယ္။
မွားယြင္းတဲ့လမ္းေၾကာင္းကို ေလ်ာက္မိမယ္ ဆိုရင္ ရက္ေတြ ဒါမွမဟုတ္
ရက္သတၱပတ္အထိေတာင္ programming ေရးတဲ့ အခ်ိန္ေတြ ကုန္ဆံုးသြားႏိုင္ပါတယ္။
အေသအခ်ာသာျပင္ဆင္ထားမယ္ဆိုရင္ project
plan<http://en.wikipedia.org/wiki/Project_plan>က
လမ္းေၾကာင္းေသြဖယ္သြားမႈကို ထိန္းညိွေပးႏိုင္ပါတယ္။
*(၄) စနစ္ Standards ေတြကို လိုက္နာျပီး Template ေတြကို သံုးပါ*
အေတြ႔အၾကံဳရင့္တဲ့ professionals ေတြက အခ်ိန္ယူျပီး စက္႐ံုနဲ႔ ကုမၸဏီသံုး စနစ္
standards ေတြကို ျပဳလုပ္ ေဖာ္ထုတ္ၾကသလဲဆိုတာ အေကာင္းဆံုး အေၾကာင္းျပခ်က္ေတြ
ရွိပါတယ္။ စနစ္ standards ေတြဟာ အေကာင္းဆံုး လုပ္ေဆာင္မႈ best practices ေတြကို
အေသးစိတ္လုပ္ထားျပီး၊ ႏွစ္ေပါင္းမ်ားစြား trial-and-error နည္းနဲ႔ သိရွိခဲ့တဲ့
လုပ္ေဆာင္မႈေတြ ပါရွိေနလို႔ပါပဲ။
Templates လို႔ေခၚတဲ့ ၾကိဳတင္ျပင္ဆင္ပံုဆံထုတ္ထားတဲ့ ပံုစံ forms ေတြဟာ
အလြန္ကို အသံုး၀င္ပါတယ္။ ဘာလို႔လဲဆိုရင္ အလုပ္ေတြအားလံုးဟာ စံသက္မွတ္ထားတဲ့
ပံုစံအတိုင္း ျဖစ္လာမွာ ျဖစ္တဲ့ အတြက္ျဖစ္ပါတယ္။ ဒါ့ေၾကာင့္ ကိုယ့္ရဲ
႔ကိုယ္ပိုင္ standard စံစနစ္နဲ႔ template ပံုစံေတြကို ၾကိဳတင္ျပင္ဆင္
ျပဳလုပ္ထားသင့္ပါတယ္။ အျခား ခ်မွတ္ျပီး သား standard စံစနစ္ေတြနဲ႔ template
ပံုစံေတြကိုလည္း ယူျပီး သံုးစြဲသင့္ပါတယ္။
*(၅) အျခားသူေတြနဲ႔ ဆက္သြယ္၊ ပူးေပါင္းေဆာင္ရြက္ပါ*
အသင္း၀င္တစ္ေယာက္ ျဖစ္တယ္ဆိုရင္၊ အျခား အသင္း၀င္ေတြနဲ႔ ဆက္သြယ္ ဆက္ဆံေရးဟာ
အလြန္ပဲ လိုအပ္ပါတယ္။ ဒါမွ အလုပ္ထပ္မႈေတြ၊ မတူညီမႈေတြနဲ႔ နားလည္မႈလြဲမႈေတြကို
ေျဖရွင္းႏိုင္ျပီး ပူးေပါင္းေဆာင္ရြက္ႏိုင္မွာပါ။
Emails, instant messages, project status reports နဲ႔ teleconferences
စတာေတြအားလံုးဟာ အသင္း၀င္ေတြ ၾကားမွာ ဆက္သြယ္ေရးနဲ႔ ပူးေပါင္းေဆာင္ရြက္မႈကို
ေဆာင္ရြက္ေပးႏိုင္တဲ့ နည္းလမ္းေတြပဲ ျဖစ္ပါတယ္။ ဒါေပမယ့္ အဲဒီတစ္ခုခ်င္းစီက
လံုး၀အေကာင္းမြန္ဆံုးေတြေတာ့ မဟုတ္ပါဘူး။
ေန႔တစ္ေန႔ရဲ ႔ အလုပ္လုပ္ဖို႔ အေကာင္းဆံုး အခ်ိန္ေတြ coding ေရးခ်င္တဲ့
အခ်ိန္ေတြကို emails ေရးတာ၊ ဖတ္တာ၊ conference calls, meeting ေတြမွာ ပါ၀င္ရတာ၊
instant message ေတြပို႔ေနရတာနဲ႔ပဲ အခ်ိန္ေတြ ကုန္ေနႏိုင္ပါတယ္။ ဒါေပမယ့္
ဒီလိုအရာေတြက project development process မွာ အလြန္ကို လိုအပ္တဲ့ အရာေတြ
ျဖစ္ပါတယ္။ အေကာင္းဆံုးလို႔ ေျပာလို႔ရမယ့္ ဆက္သြယ္ေရးနဲ႔ ပူးေပါင္းေဆာင္ရြက္ေရး
tool က မေပၚေသးဘူးလို႔ ဆုိႏိုင္ပါတယ္။ အားနည္းခ်က္ေတြကေတာ့ ရွိေနဦးမွာပါ။
Code ေတြကို share လုပ္ဖို႔ အတြက္ အေကာင္းဆံုးနည္းကေတာ့ revision control
software <http://en.wikipedia.org/wiki/Revision_control> ေတြသံုးတာပါပဲ။ ဥပမာ
subversion, CVSNT, sourcesafe စသျဖင့္ေပါ့။
ဆက္သြယ္မႈနဲ႔ ပူးေပါင္းေဆာင္ရြက္မႈ plan တစ္ခုခ်မွတ္ျပီး stakeholders အားလံုး
ပါ၀င္ႏိုင္ေအာင္ လုပ္ေဆာင္ထားမယ္ဆိုရင္ ေတာ့ အေကာင္းဆံုးပါပဲ။
Free communication plan template
<http://downloads.techrepublic.com.com/abstract.aspx?docid=173819>
*(၆) အခ်ိန္ အလံုအေလာက္ေပးပါ*
အဆိုးဆံုးကို လိုခ်င္ရင္ အဆိုးဆံုးရမွာပဲ ဆိုတာ တကယ္ကို မွန္ပါတယ္။ အျမဲေတာ့
မျဖစ္တတ္ေပမယ့္ ျဖစ္ေနတတ္တာကေတာ့ ကိုယ္ေရးမယ့္ product က အရမ္းကို
အလ်င္လိုေနျပီး ထုတ္လုပ္တဲ့ အဆင့္ေတြမွာလည္း ျမန္ျမန္လုပ္၊ စစ္ေဆးမႈေတြ နည္းပါး
အဆိုးဆံုးေတြ ၾကံဳေတြ႔ ႏိုင္ပါတယ္။
Project ကို အစိတ္အပိုင္းေလးေတြပိုင္း water fall လိုမ်ိဳး လုပ္ျပီး
လုပ္ေဆာင္ၾကပါတယ္။ ဒါေပမယ့္ အပိုင္း တစ္ခုခ်င္းစီကို အခ်ိန္
အလံုအေလာက္မေပးမိတာကေနျပီ လိုအပ္ခ်က္ေတြ က်န္ေနခဲ့တာ မတိက်တဲ့ analysis ေတြ၊
ညံဖ်င္းတဲ့ design ေတြ၊ ျမန္ျမန္ေရးထားတဲ့ programming ေတြ၊ ေသခ်ာ စစ္မထားတဲ့
testingေတြ၊ မျပည္႔စံုတဲ့ documentation ေတြကို ရရွိလာတတ္ၾကပါတယ္။ ရရွိခ်က္
result အေနနဲ႔ လိုအပ္ခ်က္ေတြ မျပည္႔စံုတဲ့ key areas တစ္ခု ဒါမွမဟုတ္
တစ္ခုထက္မကတဲ့ fail ျဖစ္မႈေတြ ျပည္႔ေနတဲ့ system တစ္ခုကို ရရွိႏိုင္ပါတယ္။
ဒါေပမယ့္ project development တစ္ခုရဲ ႔ အစိတ္အပိုင္း တစ္ခုခ်င္းစီကို
ျပီးဆံုးဖို႔ အတြက္ ဘယ္ေလာက္အခ်ိန္ယူရမလဲ ဆိုတာကို တြက္ခ်က္ရတာ အေတာ္ေလးကို
ခက္ခဲပါတယ္။
Tips on creating realistic
schedules<http://articles.techrepublic.com.com/5100-10878_11-6160572.html>
*(၇) ေရးျပီးသား proven code ေတြ ျပန္သံုးပါ*
အေတြ႔အၾကံဳရွိတဲ့ developer တစ္ေယာက္သာဆိုရင္၊ ႏွစ္မ်ားစြာေရးလာခဲ့တဲ့ code ေတြ
အမ်ားၾကီး ရွိမွာပါ။ အဲဒီ proven code ေတြကို ျဖစ္ႏိုင္သမွ် ျပန္ျပန္သံုးေပးပါ။
အသစ္ေရးတဲ့ စနစ္အတြက္ လိုအပ္ခ်က္ေတြကို ထပ္ျပီး ျဖည္႔ေကာင္းျဖည္႔ဖို႔
လိုအပ္ပါလိမ့္မယ္၊ ဒါေပမယ့္ proven code ေတြကေတာ့ တကယ့္ကို ေကာင္းမြန္တဲ့
အေျခခံတစ္ခု အေနနဲ႔ ျပန္လည္ သံုးစြဲသင့္ပါတယ္။
ဒီလို လုပ္ျခင္းအားျဖင့္ အသစ္ bugs ေတြေတြ႔တာေလ်ာ့သြားႏိုင္သလို တူညီတဲ့ code
ေတြ test ေတြ လုပ္ရတာ သက္သာသြားႏိုင္ပါတယ္။ အျခားသူေတြနဲ႔လည္း ကိုယ့္ code
ေတြကို share လုပ္ေပးပါ။ proven code ေတြကို plug-i ဒါမွမဟုတ္ libraries
ပံုစံေတြနဲ႔ share လုပ္ႏိုင္ပါတယ္။ အျခားေသာ ျပင္ပ source code ေတြလည္း
အင္တာနက္ကေန အခမဲ့ ရယူ သံုးစြဲႏိုင္ပါေသးတယ္။
*(၈) စစ္ေဆးတဲ့ စာရင္း Checklists ေတြ သံုးပါ*
Checklistေတြကို project development အဆင့္တိုင္းမွာ အသံုးျပဳႏိုင္ပါတယ္။ ဒီ
checklists ေတြက systems အၾကီးၾကီးေတြ၊ လူတစ္ေယာက္ထဲက အလုပ္ေတြအမ်ားၾကီးကို
တာ၀န္ယူရတဲ့ အခါေတြမွာ အရမ္း အသံုး၀င္ပါတယ္။ အလုပ္႐ႈပ္ေနတဲ့ developers ေတြ
အေနနဲ႔ အေရးၾကီးတဲ့ အခ်က္ေတြကို အျမင္ေက်ာ္ျပီး လစ္ဟာသြားတတ္ပါတယ္။ ဒါ့ေၾကာင့္
ကိုယ္လုပ္တဲ့ အလုပ္ေတြမွာ checklists ေတြကို အသံုးျပဳျပီး စစ္ေဆးတာကေတာ့
အေကာင္းဆံုး စစ္ေဆးနည္း တစ္ခုပါပဲ။
*(၉) စစ္ေဆးပါ၊ test လုပ္ပါ၊ အလုပ္ကို ေသေသခ်ာခ်ာ ျပန္လည္သံုးသပ္ review လုပ္ပါ
*
ျဖစ္ႏိုင္ရင္ ျဖစ္ႏိုင္သေလာက္ test ကို ေစာေစာ လုပ္ပါ။ code ေတြထဲမွာ ေတြ႔တဲ့
errors ေတြဟာ dev process ျပီးဆံုးခါနီးမွသာ ေတြ႔မယ္ဆိုရင္ အေတာ္ေလးကို
ခက္ခဲတဲ့ အလုပ္တစ္ခုျဖစ္သြားပါမယ္။ တစ္လေလာက္ကတည္းက သိရမယ့္ အမွားတစ္ခု bug
တစ္ခုကို တစ္လေလာက္ကတည္းက သိျပီး ျပင္ႏိုင္တာက အေကာင္းဆံုးပါပဲ။
ဒါ့ေၾကာင့္ ေသေသခ်ာခ်ာ၊ အေသးစိတ္ testing လုပ္ျပီး users ေတြ မေတြ႔ခင္ကတည္းက
ေတြ႔ႏိုင္ေအာင္ လုပ္သင့္ပါတယ္။ ႏွစ္ၾကိမ္၊ သံုးၾကိမ္ အလုပ္ေတြကို ျပန္စစ္ေဆးပါ။
test data နဲ႔ plan ေတြကို ခ်မွတ္ျပီး လုပ္ေဆာင္ပါ။
လုပ္ေဆာင္မႈ functionality ေတြအားလံုးနဲ႔ အေၾကာင္းအရာ scenario ေတြ တစ္ခုမက်န္
ေသခ်ာစစ္ေဆးပါ။ ဒီေနရာမွာ checklist ကို သံုးဖို႔ အေကာင္းဆံုးပါပဲ။ PCL
(program check list) စတဲ့ checklist ေတြကို သံုးျပီး စစ္ေဆးမႈေတြကို
အၾကိမ္ၾကိမ္ လုပ္သင့္ပါတယ္။
*(၁၀) တတိယအဖြဲ႔အစည္း Third Paryt နဲ႔ ထပ္ျပီး စစ္ေဆးပါ၊ Test လုပ္ပါ*
အနည္းဆံုး အေတြ႔အၾကံဳရွိတဲ့ beta testing လုပ္ဖို႔ သင့္ေတာ္တဲ့
လူတစ္ေယာက္ရွာျပီး စစ္ခုိင္းပါ။ ကိုယ္ကလံုး၀ ေတြးမထားတဲ့ နည္းလမ္းေတြနဲ႔
စစ္ေဆးျပီး ကိုယ္ထင္မထားတဲ့ အမွားေတြ bugs ေတြကို ေတြ႔ႏိုင္မွာ လံုး၀
မမွားပါဘူး။ ဒါ့ေၾကာင့္ ဒီအဆင့္ကို လံုး၀ အလ်င္မလိုသင့္ပါဘူး။ ေနာက္ဆံုး
အခြင့္အေရးလို႔ လည္း ဆိုႏိုင္ပါတယ္။ ဘာလို႔လည္းဆိုရင္ မေကာင္းတဲ့
အမွားေတြအမ်ားၾကီးပါတဲ့ system တစ္ခုကို released လုပ္လိုက္တာဟာ ကိုယ့္ကုမၸဏီရဲ
႔ ပံုရိပ္ကို ႏွစ္မ်ားစြာ ထိခိုက္ေစႏိုင္ပါတယ္။
*ေနာက္ဆံုးအေနနဲ႔*
ေသခ်ာတာကေတာ့ အမွားေတြကုိ တစ္ေယာက္ေယာက္က အမွားလို႔ မသိမခ်င္း အမွားကို
အမွားလို႔ မထင္ပါပဲ။ ဒါအေရးၾကီးပါတယ္၊ မျမင္ရတဲ့ မျမင္ႏိုင္တဲ့ အမွားေတြ
ကိုယ့္အတြင္းထဲမွာ ဘယ္ေလာက္ မ်ားေနျပီလည္း။ ကိုယ္က ၾကီးမားတဲ့ အမွားေတြ
လုပ္ခဲ့မိတယ္ဆိုတာကို ေျပာတာတစ္ခုတည္းကေတာ့ ဘာမွ အက်ိဳးေက်းဇူးရလာစရာမရွိပါဘူး။
မေတာ္ရင္ ကိုယ္မွာပဲ အက်ိဳးယုတ္ႏိုင္တာ မဟုတ္လား။
ဒီစာမ်က္ႏွာကေန အမွားေတြကို ဘယ္လိုေရွာင္ရမလဲ ဆိုတဲ့ နည္းလမ္းအခ်ိဳ ႔ကို
ရႏို္င္မယ္လို႔ ေမွ်ာ္လင့္ပါတယ္။ ကၽြန္ေတာ္လည္း မ်ားေသာအားျဖင့္ အမွားေတြကေန
တဆင့္ အျမဲ သင္ယူေနရ ပါတယ္။ ဒါေပမယ့္ အမွားေတြကို အရင္ မလုပ္မိေအာင္ေတာ့
အျမဲသတိေပးခ်င္တယ္။
ျမန္မာ သကၠရာဇ္ ၁၃၇၂ ခုႏွစ္ ကဆုန္ လဆန္း ၁၃ ရက္
Posts
