---

layout: post title: Spylnx - Fiber Management System —

Spylnx - Fiber Management System

Workflow

• Lead generation
• Convert lead to customer
• Installation equipment
• Bill to customer
• Open Ticket by customer
• Review and assign ticket to specific team
• Update / close ticket after resolve ticket

Entity List

• Lead
• Customer
• Packages
• Order
• Survey
• Installation
• Bill
• Ticket
• Team
• Employee

Simplified မလုပ်ခင်မှာ ထားမယ့် Entity စာရင်း။ ဒါက Main Entity စာရင်းလို့ ပြောရမယ်။ Supplymentry Entity စာရင်းလည်း ရှိမယ်။

Usecase

• Lead တစ်ယောက်ရဲ့ အချက်အလက်တွေကို ထည့်မယ် (Customer ကိုယ်တိုင်လည်း ဖြစ်နိုင်မယ်၊ Staff တစ်ယောက်လည်း ဖြစ်နိုင်မယ်။)
• Lead ကို ဆက်သွယ်ပြီး quotation ပို့ဖို့ Team တစ်ခုကို assign လုပ်မယ်။
• Assign လုပ်ခံရတဲ့ Team က Lead ကို ဆက်သွယ်ပြီး ဘာလိုချင်လဲမေး၊ အခြား network နဲ့ ပတ်သက်ပြီး ဘာ package တွေရှိတယ်
• Operation တစ်ခုခု လုပ်တိုင်းမှာ လုပ်ဆောင်ချက် အသစ်တွေ (log ) ထည့်မယ်၊ နောက် status တွေလည်း ပြောင်းမယ်။ ဒါတွေကိုလည်း မှတ်ထားရမယ်။
• Lead က Product တစ်ခုယူမယ်လို့ အတည်ပြုလိုက်ပြီ။ Customer အနေနဲ့ ပြောင်းမယ်။
• Newly Customer ကို သူယူထားတဲ့ Product ပေးဖို့ installation task schedule ဆွဲပေးမယ်
• Installation Team က သူတို့ကို assign လုပ်ထားတဲ့ task တွေကို ကြည့်ပြီး လိုက် install လုပ်မယ်။ ဒီ task နဲ့ ပတ်သက်ပြီး လိုတာတွေ မေးမယ်။
• Network Team က Installation က ပို့ပေးတဲ့ အချက်အလက်တွေကို စီစစ်ပြီး Installation Complete ဖြစ်မဖြစ် ဆုံးဖြတ်မယ်။
• Installation Complete ဖြစ်သွားရင် Bill ကောက်မယ်။ ဒီတစ်လစာ ၊ ဒါမှ မဟုတ် (၃) လစာ။ စသည်ဖြင့်။
• Customer Potal ကို ဝင်ဖို့ account ပေးခဲ့ပြီး Customer က သူ့အချက်အလက်သူ ဝင်ကြည့်လို့ရမယ်။
• အင်တာနက် မရတာ၊ လိုင်းနှေးသွားတာ၊ ဝိုင်ဖိုင်ပျက်တာ စတဲ့ Issues တွေကြုံလာရတဲ့အခါ ဖုန်း / app ကနေ Ticket ဖွင့်မယ်။
• Network Team ကနေ တက်လာတဲ့ Issues တွေကို အမျိုးအစားခွဲပြီး ပိတ်သင့်တာပိတ်၊ service ပေးသင့်တာရှိရင် service ပေးနိုင်ဖို့ schedule team ကို လွှဲမယ်။
• Service လိုတဲ့ ticket တွေအတွက် Service Team တွေကို assign လုပ်မယ်။ (task)
• Service Team က သူတို့ကို assign လုပ်လာတဲ့ Tasks တွေကို လိုက်ပြင်မယ်။
• Service တစ်ခု ဖြေရှင်းပြီး ဖြစ်မဖြစ်ကို Network Team ကပဲ ဆုံးဖြတ်ပေးမယ်။
• Bill ကောက်ရမယ့် စာရင်း ကြည့်ပြီး Bill ပေးဖို့ ကျန်နေရင် Remind လုပ်မယ်
• User တွေက kpay က တဆင့် bill ဆောင်မယ်။
• Inventroy -> ဝယ်ယူရေး -> ပစ္စည်းတွေထည့်မယ်
• Installation / Service Team -> ပစ္စည်းလာထုတ်မယ်

• Infrasturcture -> ဘယ် ပစ္စည်းတွေ ဘယ်နေရာမှာ သုံးထားတယ်။ GIS

• What’s our problem?

ဘာလို့ ပရောဂျက်တွေ မပြီးလဲ (သို့မဟုတ်) ကိုယ့်ပေါင်ကိုယ်လှန်ထောင်းခြင်း

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

ဇာက်လမ်းက ဒီလိုစတယ်။ Client က “o”လုံးလောက် ရေးတက်ရင် ရပါပြီဆိုပြီး သူ့ရဲ့ requirement ကို ဆွေးနွေးတယ်။ ဒါနဲ့ Developer ဘက်က “ထ” ဆင်ထူး ရော မပါဘူးလားလို့ မေးရင် ဟာ ပါရမှာပေါ့လို့ ပြောတယ်။ အိုကေပေါ့ ဒါနဲ့ (၂) ဉီးနှစ်ဘက် အကျေအလည်ဆွေးနွေးပြီး တစ်ဘက်ကို တစ်ဘက် နားလည်မှု ရပြီလို့ ထင်လိုက်ကြတယ်။

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

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

ဒါနဲ့ သတ်မှတ်တိုင်း အချိန်ပြည့်လို့ Working Demo ထွက်လာတယ်။ အဲ့ဒီမှာ “ထ”ဆင်ထူးက “ထ”ဆင်ထူးနဲ့ မတူပဲ “တ” လိုမျိုး ဖြစ်နေတယ်။ ဒါပေမယ့်လည်း Client က လက်ခံတယ်။ တစ်ခုပဲ တောင်းဆိုတယ်။ “တ”ဝင်းပူတောင် ရသေးတာပဲ။ “က”ကြီးရော ရနိုင်မလားပေါ့။ Client အနေနဲ့ နဂိုကတည်းက “က”ကြီးကနေ “အ”အထိ လိုချင်တာလည်း ဖြစ်နိုင်တယ်။ ဒါမှ မဟုတ် အခု Demo ကိုကြည့်ပြီးမှ အမြင်တွေရလာပြီး ထပ်လိုချင်တာလည်း ဖြစ်နိုင်တယ်။ ဒီအထိလည်း နှစ်ဉီးနှစ်ဘက် အဆင်ပြေသေးတယ်။ အကုန်လုံးက ဆင်တူရိုးမှားတွေကိုး။ အဲ့မှာ “ဝ”လုံးကစလိုက်တာ “ထ”ဆင်ထူး၊ “တ”ဝင်းပူ၊ “က”ကြီး အထိ ရောက်လာတယ်။ ဒါနဲ့ အဆင်ပြေသွားပြီလားဆိုတော့ မပြေသေးဘူး။ တကယ့်လက်တွေ့မှာ ဒီစကားလုံးလောက်နဲ့ သုံးလို့မရသေးဘူး။ ဒီတော့ ခင်ဗျားတို့ ‌ပေးတဲ့ ဟာတွေက သုံးစားမရဘူးဆိုပြီး feedback တွေစရလာတယ်။ Developer တွေဘက်ကလည်း ခင်ဗျားပြောတဲ့အတိုင်း အကုန်ရေးပေးထားတာပဲ ဘာကိစ္စသုံးမရတာလဲပေါ့။ နောက်ထပ် ဗျည်းတွေလိုချင်ရင် အချိန်နဲ့ငွေ ထပ်ပေးမှရမယ်ဆိုပြီး စတောင်းဆိုလာတယ်။ Client ဘက်ကလည်း သူက “ဝ” လုံးရရင် ဗျည်း(၃၃) လုံးလုံး ရမယ်ထင်လို့ ရေးခိုင်းတာပေါ့ အခုတော့ နောက်ထပ် သုံးလေးလုံးပဲ ရေးရသေးတယ် အလုပ်က မဖြစ်ချင်တော့ဘူး ပိုက်ဆံလည်းထပ်မပေးနိုင်ဘူး အချိန်လည်း ထပ်မပေးနိုင်ဘး ဘာညာသာရကာဆိုပြီး တကယ်ကို နှစ်ဘက်ကြားမှာ Bad Blood ဖြစ်လာတယ်။

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

Bad Blood ဆိုတာနဲ့ ဒီအခြေအနေတွေထဲက တစ်ခု ဖြစ်လာတယ်။ တစ်ချို့ Client တွေက refund ပြန်တောင်းတယ်။ တစ်ချို့ Client တွေက ဒီဘဝ ဒီအမျှပဲ ရှိပါစေတော့ ဆိုပြီး Project ကို ရပ်ခိုင်းလိုက်တယ်။ Developer တွေဘက်ကလည်း အကြောင်းမပြန်တော့ပဲ အဲ့ Project ကို ပစ်ထားလိုက်ကြတာမျိုး။ ဒါမှ မဟုတ် (၂) ဉီး (၂) ဘက် တစ်လ နေမှ တစ်ခါလောက် စကားပြောပြီး ဘာ Progress မှ မရှိတော့တဲ့ ပရောဂျက်ကို မြွေမသေ တုတ်မကျိုး ထားလိုက်ကြတာမျိုး။

ဘာပဲဖြစ်ဖြစ် တစ်ခုမှ မကောင်းပါဘူး။

လူ အချင်းချင်းကြားမှာ အဖွဲ့အစည်း (၂) ခုကြားမှာ ဒါမျိုး ဆက်ဆံရေးမကောင်းတာတွေ ဖြစ်တာက အဘက်ဘက်က နစ်နာပါတယ်။ Client ဘက်ကလည်း ရှင်းပြပြောပြ၊ ငွေကြေးစိုက်ထုတ်ရ နဲ့ နောက်ဆုံး သုံးစားမရတဲ့ စနစ်ကြီးတစ်ခု ရလာပြီး အချိန်ကုန် လူပန်း စိတ်ဆင်းရဲပေါ့။ Developer တွေဘက်ကလည်း မီတင်တွေအကြိမ်ကြိမ်လုပ်၊ Team ထဲမှာ ငြင်းကြခုန်ကြ အချိန်နဲ့ ကာယ ဉာဏ်ဏ စိုက်ထုတ်မှုတွေ Professional Skill Set တွေ သုံးခဲ့ကြပေမယ့် နောက်ဆုံးတော့ လက်တွေ့ လုပ်ငန်းခွင်မှာ သုံးမရပါဘူး ဆိုတဲ့ feedback တစ်ခွန်းနဲ့ Refund ပြန်လုပ်ပြီး လုပ်ခဲ့သမျှ သဲထဲရေသွန်။

ဒီလို ကိစ္စမျိုးက တစ်ခါလည်း မဟုတ်၊ နှစ်ခါလည်း မဟုတ်။ ကျွန်တော် တို့ Developer အနေနဲ့ စပြီးအလုပ်လုပ်လာတဲ့ (၃) နှစ်အတွင်းမှာ 90 ရာခိုင်နှုန်းသော Client တွေနဲ့ ဒါမျိုးတွေချည်း ကြုံရတယ်။ ဒီတော့ ဒါဟာ Client အမှားမဟုတ်ဘဲ ကိုယ့်ဘက်က အမှားဆိုတာ သိသာလာတယ်။ ဒါနဲ့ ဒီလို ကိစ္စမျိုးကို ဘယ်လို ကာကွယ်ကြမလဲ။ အလုပ်တစ်ခုကို ပြီးမြောက်အောင် လုပ်နိုင်ဖို့ ဘာတွေလိုမလဲ? ဒီမေးခွန်းကို ကိုထိန်လင်းရွှေ(SaturnGod)၊ ဆရာအိမောင် စတဲ့ ဒီနယ်ပယ်ထဲက ဆရာသမားတွေရဲ့ talk တွေ လိုက်နားထောင်၊ ရေးထားတဲ့ စာတွေဖတ်၊ လူကိုယ်တိုယ်သွားမေး စတာတွေလုပ်ပြီး အဖြေရှာရတယ်။ ဒါတွေကိုတော့ နောက်တစ်ပိုင်းမှာ ဆက်ရေးပါဉီးမယ်။

ဘာလို့ ပရောဂျက်တွေ မပြီးလဲ (သို့မဟုတ်) ကိုယ့်ပေါင်ကိုယ်လှန်ထောင်းခြင်း

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

ဒီတော့ အလုပ်တစ်ခု ပြီးမြောက်အောင်လုပ်နိုင်ဖို့ဆိုရင် ဘာတွေလိုမလဲ? ဒါကို မြတ်စွာဘုရားဟောထားတာ ရှိတယ်။ ဆိုရင်ရင် ဗုဒ္ဓအလိုကျ ပရောဂျက်ပြီးအောင် ရေးနည်းပေါ့။

မြတ်စွာဘုရားဟောထားတယ်။ ဒီအောက်က အချက်(၅) ချက်ရှိနေရင် ဘယ်အလုပ်မှ မပြီးဘူးပေါ့။

၁။ လုပ်နိုင်လိမ့်မယ်လို့ ယုံကြည်မှု မရှိတာ

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

ကျန်းမာရေးမကောင်းတာ

လူက ရှုနာရှိုက်ကုန်းဖြစ်နေမယ်ဆိုရင် ကွန်ပျူတာရှေ့မှာ နာရီပေါင်းများစွာထိုင်ပြီး ကုတ်နေနိုင်မှာမဟုတ်ဘူး။ တရားထဲမှာတော့ လူရဲ့ ကျန်းမာရေးကိုပဲ အဓိကထား ဟောထားပေမယ့် ကျွန်‌တော်ကတော့ လူအပြင် ကျန်တဲ့ ကိုယ့်ရဲ့ Infrastructure ခေါ်မလား အခြေခံ အဆောက်အဉီး၊ ကွန်ပျူတာ၊ လျှပ်စစ်၊ အင်တာနက် စတာတွေလည်း အားကောင်းဖို့ လိုတယ်လို့ ယူဆတယ်။ လူကဘယ်လိုပဲ ကျန်းမာသန်စွမ်းနေပါစေ မီးပျက်နေရင် အလုပ်လုပ်လို့မရ (စာအုပ်တော့ ဖတ်လို့ရတာပေါ့၊ ဒါက ခြွင်းချက်)။ နောက် အင်တာနက် ကွန်နက်ရှင် မကောင်းတာမျိုး။ ကိုယ်သုံးနေရတဲ့ ကွန်ပျူတာက low specification, ကိုယ်ရေးနေရတဲ့ ပရောဂျက်က Android Studio , Xampp , Emualtor နဲ့ Chorome မှာ tab ပေါင်း သောင်းခြောက်ထောင် ဖွင့်ထားရတာမျိုးဆိုရင်လည်း ဘယ်လိုမှ အလုပ်လုပ်ရတာ အဆင်ပြေမှာ မဟုတ်ဘူး။ နောက်တစ်ခုက ရေးတာကတော့ iOS , Mac တော့ မရှိဘူးဆိုရင်လည်း အလုပ်ဖြစ်မှာ မဟုတ်။ ဆိုတော့ ကျန်းမာအောင်နေ သန်စွမ်းအောင် Gym သွား ကွန်ပျူတာနဲ့ ဆက်စပ်ပစ္စည်းကို အရည်အသွေးကောင်းတာတွေဝယ်။

ဂျင်းထည့်မယ်ပဲ ကြံနေတာ

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

ကြိုးစားအားထုတ်မှု မရှိ ( အလုပ်တစ်ခုလို သတ်သတ်မှတ်မှတ်မလုပ်ပဲ လမ်းကြုံမှ ထလုပ်တာမျိုး)

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

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

အရှေ့က လေးချက်ကို ဖြေရှင်းနိုင်တယ်ဆိုရင်တောင်မှ ဒီ အရည်အချင်းဆိုတဲ့ ကိစ္စမှာ ပြဿနာတက်နိုင်တယ်။ ပရောဂျက်တိုင်းက unique ဖြစ်တဲ့ requirement တွေနဲ့ လာကြတယ်။ ဒီတော့ အမြဲလိုလို ကိုယ့်ရဲ့ skill set နဲ့ ရှင်းနိုင်ချင်မှပဲ ရှင်းနိုင်မယ်။ ဒီလိုအခြေအနေမျိုးမှာ နောက်ထပ် အသစ်အသစ်သော skill တွေကို သင်ယူနိုင်ဖို့လိုတယ်။ အမြဲလိုလို CRUD ပဲ လာနေမှာ မဟုတ်ဘူးဆိုပါတော့။ ဒီလိုအခြေအနေမျိုးမှာ တစ်ခြားသူတွေ ဘယ်လို ဖြေရှင်းကြလဲ ဆိုတဲ့ နည်းလမ်းကို ရှာနိုင်ရမယ်။ နည်းလမ်းတွေ့လာတဲ့အခါမှာလည်း ဒီနည်းလမ်းကို သုံးနိုင်ရမယ်။ မဟုတ်ရင်တော့ ပရောဂျက်ရဲ့ တစ်ကွေ့မဟုတ် တစ်ကွေ့မှာ ကိုယ်မရှင်းနိုင်တဲ့ Issues တစ်ခုတွေ့ပြီး ရပ်သွားမှာပဲ။

လုပ်နိုင်လိမ့်မယ်လို့ ယုံကြည်မှု မရှိတာ

ကျန်းမာရေးမကောင်းတာ ( လူရော infrastructure ရောပါတယ်။)

ဂျင်းထည့်မယ်ပဲ ကြံနေတာ ( နည်းနည်းလုပ်ပြီး အများကြီးရချင်တာမျိုး )

ကြိုးစားအားထုတ်မှု မရှိ ( အလုပ်တစ်ခုလို သတ်သတ်မှတ်မှတ်မလုပ်ပဲ လမ်းကြုံမှ ထလုပ်တာမျိုး)

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

User Requirements ကို နားမလည်တာ

Skillful မဖြစ်တာ

စိတ်ဓာတ်မကောင်းတာ

အလုပ်တစ်ခုကို ပြီးမြောက်အောင် လုပ်နိုင်စွမ်း မရှိတာ

ရႈပ ေထ ်ားတတဲ့ ကိစၥရပ တစ ခုကို တစ ေယဗက ေယဗက နတ႔ ဆက သ ယ ေျပဗၾကဗ်ားဖို႔ ႀကိ ်ားစဗ်ားတတဲ့အခ္ိန မ ဗ အတဲ့ဒီအေၾကဗင ်ားအရဗကို ခင ္ဗ်ားက အေတဗ ေလ်ားကို ုႏ ံ႔ုႏ ံ႔စပ စပ သိထဗ်ားၿပီ်ား တစ ဖက လ က လံု်ားဝသိမထဗ်ားဘ ်ားဆိုရင သ ႔ဦ်ားေဏ ဗက နတ႔ ခင ္ဗ်ားဦ်ားေဏ ဗက အၾကဗ်ား က ်ားလ ်ားဆက ုႏ ယ တတဲ့ေနရဗမ ဗ အခက အခတ ရ ိုႏိုင တယ ဆိုတဗကိုဂရုျပ ပါ။ သ ႔ကိုအတဲ့ဒီကိစၥရ င ်ားျပရတဗက ေတဗ ေတဗ ေလ်ား လက ေပါက ကပ ေနပါလိမ ဲ့မယ ။ သ ႔ဖက က အမ ဗ်ားေၾကဗင ဲ့မဟုတ ပါဘ ်ား။ ခင ္ဗ်ားက ခင ္ဗ်ားသိသလို သ လည ်ားသိလိမ ဲ့မယ ၊ ခင ္ဗ်ားစိတ ထတက သိေနတဗကို သ လည ်ားသိေနလိမ ဲ့မယ လို႔ ထင ျမင ယ ဆေနၿပီ်ား သ ကအတဲ့သလို သိမေနတဗေၾကဗင ဲ့ ျဖစ ပါတယ ။ အတဲ့သလိုသိမေနလို႔လည ်ား သ ႔ကိုထင သေလဗက စမတ ျဖစ မေနတတဲ့သ တစ ေယဗက လို႔ေျပဗလို႔မရပါဘ ်ား။ ခင ္ဗ်ား ေဒါသထ က ရံု၊ စိတ လႈပ ရ ဗ်ားရံု နတ႔တယ လီပသီအစ မ ်ားေတ ရလဗမ ဗမဟုတ ပါဘ ်ား။ စိတ ကို ေအ်ားေအ်ားထဗ်ားၿပီ်ား သ နဗ်ားလည ုႏိုင ေလဗက တတဲ့အဆင ဲ့အထိေလ ္ဗဲ့ခ္ၿပီ်ား ရ င ်ားျပလိုက ပါ