အမှားတွေကို ရင်ဆိုင်ဖို့ အကောင်းဆုံး နည်းယာမကတော့ ပထမဆုံး အဲဒီအမှားတွေကို မလုပ်မိဖို့နဲ့ ရှောင်နိုင်ဖို့ပါပဲ။ အခုပြောပြမယ့်ဟာကတော့ ယေဘူယျအားဖြင့် ကြုံတတ်တဲ့ အချက်အချို့ကိုပါ။
သင်ကြားဖူးပြီးသားဖြစ်မှာပါ ”Be proactive, not reactive” ဆိုတဲ့ စကားကိုပါ။ ဒီစကားစုဟာ အမှားတွေကို ရင်ဆိုင်ဖို့ အကောင်းဆုံး စကားစု တစ်ခုပါပဲ။ စဉ်းစားပုံကတော့ အမှားတွေကို မကြုံတွေ့ခင် ကြိုတင် ကာကွယ်တာပါပဲ။ ကာကွယ်ခြင်းဟာ ကုသခြင်းထက်ကောင်းတယ်လို့ ဆိုတယ်မဟုတ်ပါလား။
ဒါပေမယ့် အဲဒါတွေကို ဘယ်လိုလုပ်ရမလဲ။ ဘယ်လို ကာကွယ်ရမလဲ။ ဆိုတဲ့ မေးခွန်းတွေ မေးလာနိုင်ပါတယ်။ ဒီ စာမျက်နှာကနေ လက်တွေ့ လောကမှာ project တွေ ထုတ်လုပ်တဲ့ နေရာမှာ ကြုံတွေ့တတ်တဲ့ အမှားတွေကနေ ရှောင်နည်း၊ ကာကွယ်နည်း 10 ချက်ကိုရေးသားဖော်ပြပေးပါမယ်။ အခုရေးသားမယ့် အကြောင်းအရာတွေက Developers တွေကို အဓိကရည်ရ့ွယ်ပြီး ရေးသားထားပေမယ့် အခြား IT roles ကလူတွေလည်း ဒီစာမျက်နှာတွေကနေ အကျိုးကျေးဇူးရနိုင်မယ်လို့ မျှော်လင့်ပါတယ်။
(၁) အခြားသူတွေရဲ့အမှားတွေကနေ သင်ယူပါ
ကိုယ်လုပ်ခဲ့တဲ့ အမှားတွေကို မျှဝေချင်တဲ့ သူတွေကို ရှာဖွေကြည့်ပါ။ ကိုယ်ကိုတိုင်ကလည်း မျှဝေပေးပြီး သူတို့တွေ ပြောပြတဲ့ အတွေ့အကြုံတွေကိုလည်း နားထောင်ပေးပါ။
(၂)သုတေသနကို အရင်လုပ်ပါ
သိထားတာတွေ ဘယ်လောက်ပဲ များများ၊ နေ့စဉ်လုပ်ဆောင်မှုတွေမှာ စိန်ခေါ်မှု အသစ်တွေ တွေ့နေရဦးမှာပါ။ စိန်ခေါ်မှု တိုင်းမှာ အသစ်အသစ်သော သင်ကြားလေ့လာဖို့ လိုအပ်မှုတွေ ရှိနေပါတယ်။ ပြဿနာတွေ၊ စိန်ခေါ်မှုတွေကို မရင်ဆိုင်ခင်မှာ အရင်ဆုံး စူးစမ်းလေ့လာမှု၊ သုတေသနကို အရင်လုပ်ကြည့်သင့်ပါတယ်။
”Trial-and-error” လို့ ခေါ်တဲ့ စမ်းသပ် သင်ကြားမှု နည်းလမ်းဟာ နှစ်ပေါင်းများစွာကတည်းက လက်ခံကျင့်သုံးလာတဲ့ နည်းလမ်း တစ်ခုပါပဲ။ ဒါပေမယ့် အင်တာနက်မှာ ရရှိနိုင်တဲ့ သယံဇာတ အရင်းအမြစ်ကြီးရှိနေမှတော့ ကြိုတင် ပြင်ဆင် သုတေသန၊ ရှာဖွေစူးစမ်းမှုကို ကြိုတင်ပြင်ဆင် ပြုလုပ်မထားတာကတော့ ကြီးမားတဲ့ အမှားတစ်ခုပါပဲ။ ဒါ့ကြောင့် သင့်တော်တဲ့ စူးစမ်းရှာဖွေ သုတေသနပြုမှုကို ကြိုတင်ပြီး လုပ်ဆောင်သင့်ပါတယ်။
(၃) ကြံစည်မှု Plan ရှိပါစေ
သွားရမယ့် လမ်းကြောင်းပြမြေပုံ Roadmap သာမရှိရင် လမ်းဆုံးပန်းတိုင်ကို ဘယ်လို သွားရမယ်ဆိုတာ မသိနိုင်ပါဘူး။ Project Development မှာတော့ အဲဒီ Roadmap ကို project plan လို့ ခေါ်ပါတယ်။ formally ပဲဖြစ်ဖြစ် informally ပဲဖြစ်ဖြစ်၊ အလုပ်တစ်ခုကို လုပ်တော့မယ်ဆိုရင် သွားမယ့်နေရာကို ဘယ်လို ရောက်အောင်သွားမယ် ဆိုတာကို သိထားသင့်ပါတယ်။
မှားယွင်းတဲ့လမ်းကြောင်းကို လျောက်မိမယ် ဆိုရင် ရက်တွေ ဒါမှမဟုတ် ရက်သတ္တပတ်အထိတောင် programming ရေးတဲ့ အချိန်တွေ ကုန်ဆုံးသွားနိုင်ပါတယ်။ အသေအချာသာပြင်ဆင်ထားမယ်ဆိုရင် 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 တွေသုံးတာပါပဲ။ ဥပမာ subversion, CVSNT, sourcesafe စသဖြင့်ပေါ့။
ဆက်သွယ်မှုနဲ့ ပူးပေါင်းဆောင်ရွက်မှု plan တစ်ခုချမှတ်ပြီး stakeholders အားလုံး ပါဝင်နိုင်အောင် လုပ်ဆောင်ထားမယ်ဆိုရင် တော့ အကောင်းဆုံးပါပဲ။
Free communication plan template
(၆) အချိန် အလုံအလောက်ပေးပါ
အဆိုးဆုံးကို လိုချင်ရင် အဆိုးဆုံးရမှာပဲ ဆိုတာ တကယ်ကို မှန်ပါတယ်။ အမြဲတော့ မဖြစ်တတ်ပေမယ့် ဖြစ်နေတတ်တာကတော့ ကိုယ်ရေးမယ့် product က အရမ်းကို အလျင်လိုနေပြီး ထုတ်လုပ်တဲ့ အဆင့်တွေမှာလည်း မြန်မြန်လုပ်၊ စစ်ဆေးမှုတွေ နည်းပါး အဆိုးဆုံးတွေ ကြုံတွေ့ နိုင်ပါတယ်။
Project ကို အစိတ်အပိုင်းလေးတွေပိုင်း water fall လိုမျိုး လုပ်ပြီး လုပ်ဆောင်ကြပါတယ်။ ဒါပေမယ့် အပိုင်း တစ်ခုချင်းစီကို အချိန် အလုံအလောက်မပေးမိတာကနေပြီ လိုအပ်ချက်တွေ ကျန်နေခဲ့တာ မတိကျတဲ့ analysis တွေ၊ ညံဖျင်းတဲ့ design တွေ၊ မြန်မြန်ရေးထားတဲ့ programming တွေ၊ သေချာ စစ်မထားတဲ့ testingတွေ၊ မပြည့်စုံတဲ့ documentation တွေကို ရရှိလာတတ်ကြပါတယ်။ ရရှိချက် result အနေနဲ့ လိုအပ်ချက်တွေ မပြည့်စုံတဲ့ key areas တစ်ခု ဒါမှမဟုတ် တစ်ခုထက်မကတဲ့ fail ဖြစ်မှုတွေ ပြည့်နေတဲ့ system တစ်ခုကို ရရှိနိုင်ပါတယ်။
ဒါပေမယ့် project development တစ်ခုရဲ့ အစိတ်အပိုင်း တစ်ခုချင်းစီကို ပြီးဆုံးဖို့ အတွက် ဘယ်လောက်အချိန်ယူရမလဲ ဆိုတာကို တွက်ချက်ရတာ အတော်လေးကို ခက်ခဲပါတယ်။
Tips on creating realistic schedules
(၇) ရေးပြီးသား 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 လုပ်လိုက်တာဟာ ကိုယ့်ကုမ္ပဏီရဲ့ ပုံရိပ်ကို နှစ်များစွာ ထိခိုက်စေနိုင်ပါတယ်။
နောက်ဆုံးအနေနဲ့
သေချာတာကတော့ အမှားတွေကို တစ်ယောက်ယောက်က အမှားလို့ မသိမချင်း အမှားကို အမှားလို့ မထင်ပါပဲ။ ဒါအရေးကြီးပါတယ်၊ မမြင်ရတဲ့ မမြင်နိုင်တဲ့ အမှားတွေ ကိုယ့်အတွင်းထဲမှာ ဘယ်လောက် များနေပြီလည်း။ ကိုယ်က ကြီးမားတဲ့ အမှားတွေ လုပ်ခဲ့မိတယ်ဆိုတာကို ပြောတာတစ်ခုတည်းကတော့ ဘာမှ အကျိုးကျေးဇူးရလာစရာမရှိပါဘူး။ မတော်ရင် ကိုယ်မှာပဲ အကျိုးယုတ်နိုင်တာ မဟုတ်လား။
ဒီစာမျက်နှာကနေ အမှားတွေကို ဘယ်လိုရှောင်ရမလဲ ဆိုတဲ့ နည်းလမ်းအချို့ကို ရနိုင်မယ်လို့ မျှော်လင့်ပါတယ်။ ကျွန်တော်လည်း များသောအားဖြင့် အမှားတွေကနေ တဆင့် အမြဲ သင်ယူနေရ ပါတယ်။ ဒါပေမယ့် အမှားတွေကို အရင် မလုပ်မိအောင်တော့ အမြဲသတိပေးချင်တယ်။
Other References
Mini-glossary: Project management terms you should know
Build a foundation for project success with this definition template
Project planning template for project managers
Top project management resources: Best of Tom Mochal
10 things you should do to successfully manage your workplan
10 techniques for gathering requirements
10 tips for meeting IT project deadlines
10 things you should do near the end of a project
I credited that this articles is referenced and translated from
Date: February 22nd, 2010
Author: Alan Norton
http://blogs.techrepublic.com.com/10things/?p=1360&tag=nl.e053