အခန်း ၉ :: Project မစတင်ခင်

Project မစတင်ခင်မှာ လုပ်စရာ အလုပ်တွေ အရမ်းများပါတယ်။ လုပ်ရမယ့် အဆင့်တွေကတော့

၁။ Proposal ၂။​ Requirement ၃။ Quotation ၄။ Contract ၅။ Wireframe ၆။ UI/UX ၇။ Human Resources

ဒီအဆင့်တွေက project manager , business development စသည် တို့ အတွက်လို့ ထင်ရပေမယ့် freelance လုပ်မည့် developer တွေအနေနဲ့လည်း အထက်ပါ အဆင့်တွေကို ကိုယ်တိုင် လုပ်ရပါမယ်။

Product development လုပ်သည့် အခါမှာ အထက်ပါ အဆင့်တွေ လိုအပ်မှ လိုအပ်ပါလိမ့်မယ်။ သို့ပေမယ့် product owner နှင့်တော့ အချို့အဆင့်တွေ သဘောတူညီမှု ရှိဖို့ လိုပါတယ်။

Proposal

Project မစတင်မှာ project proposal ရေးသားရပါတယ်။​ Project proposal မှာ အဓိက အားဖြင့် လက်ရှိ project နဲ့ ပတ်သက်ပြီး ဘယ်လို အတွေ့အကြုံတွေ ရှိခဲ့တယ် နောက်ပြီး ဘယ်လို project တွေကို အောင်မြင်စွာ launch လုပ်ခဲ့ပြီး ဖြစ်သည့်အတွက် အခု project ကိုလည်း လုပ်နိုင်မည် ဖြစ်ကြောင်းကို ရေးသားဖော်ပြခြင်းဖြစ်ပါတယ်။

Proposal မှာ email နဲ့ တင် ရခြင်း ရှိသလို presentation ပြရသည့် အပိုင်းတွေလည်း ရှိပါတယ်။ Email နဲ့ ပို့ရသည့် အခါမှာ PDF format သည် အကောင်းဆုံး ဖြစ်ပါသည်။

ပါဝင်ရမည့် အချက်တွေကတော့

  • About Company
  • Summary
    • Objective/Problem
    • Portfolio
    • Solution
  • Phases
  • Estimate Cost
  • Terms Of Payment
  • Commencement
  • Withdrawal of project
  • Responsibilities

စသည့် အချက်အလက်ပါဝင်ပြီး ရေးသားထားဖို့ လိုပါတယ်။​

Document အကုန်လုံးမှာ Company Letter Head နဲ့ ရေးသားဖို့ လိုပါတယ်။

အကယ်၍ presentation ပြရမည် ဆိုရင် အထက်အပါ အချက်အလက်တွေ ကို အတိုချုံးပြီး ပြသဖို့ လိုပါတယ်။ Guy Kawasaki ရဲ့ 10/20/30 rule က အသုံးဝင်ပါလိမ့်မယ်။

10 slide , 20 minutes , 13 point font size ပါ။​ တတ်နိုင်သမျှ slide 10 ခု ထက် မပိုရန်။​ မိနစ် ၂၀ အတွင်း အပြီးပြောပါ။​ font size ကို 13 လောက် အနည်းဆုံးထားပေးပါ။

Requirement

Project က ဘယ်လို project လဲ ဆိုတာ အရေးကြီးတယ်။ In House Development လား ၊ Client project လား။ In House Development နှင့် Client project ကွာခြားချက်ကတော့ requirement changes ပါပဲ။

Client Project တွေက requirement က project စသည့် အချိန်ကတည်းက သတ်မှတ်ထားပါတယ်။ Changes တွေ အတွက် charges တွေ ရှိတယ်။ ဒါကြောင့် မလိုအပ်ရင် အသစ် ထပ်ဖြည့်တာမျိုး မလုပ်ပါဘူး။ ဒါကြောင့် Project size ပေါ်မှာ မူတည်ပြီး ၃ လ ကနေ ၁ နှစ် လောက် ကြာတတ်ပါတယ်။

In House Development တွေကတော့ company ပေါ်မှာ မူတည်တယ်။ stable ဖြစ်သည့် product တွေဆိုရင် timeline နဲ့ သွားတတ်ပေမယ့် development အဆင့်မှာ တော့ မျိုးစုံ ပြောင်းလဲ တတ်တယ်။ ပြီးသွားသည့် အခါမှာ Directors တွေ review feedback တွေ ပြန်လာရင် ပြန်ပြင် ရတာတွေ ရှိမယ်။ CEO feedback တွေ ပြန်လာရင် ပြန်ပြင်ရတာ ရှိမယ်။ Launch တစ်ခု ဖြစ်ဖို့ အဆင့်ဆင့် approval တွေ ယူရတာမျိုး ရှိတတ်ပါတယ်။ Project တစ်ခု ထွက်ဖို့ ၆ လ ကနေ ၂ နှစ်လောက် အချိန်ကြာတတ်တယ်။

ဘယ်လို project ဖြစ်ဖြစ် developer အနေနဲ့ ကိုယ်လုပ်ရမယ့် tasks list တွေကို timeline နဲ့ သေချာမှတ်ထားဖို့ လိုတယ်။ Changes တွေ ရှိလာခဲ့ရင် အချိန် ပို ယူ ဖို့ အတွက် နောက်ကျ နိုင်ကြောင်း ပြသ ဖို့ အတွက် သက်သေ ပြဖို့ လိုတယ်။

Quotation

Quotation က requirement တွေ ရပြီးပြီ။ proposal လည်း approve ဖြစ်ပြီ ဆိုရင် quotation ကို ပို့ဖို့ လိုပါတယ်။ Invoice လိုပါပဲ။​ ကျသင့်ငွေ အသေးစိတ်ကို invoice အတိုင်း ဖော်ပြပေးဖို့ပါ။​ quotation ကို approve ရမှသာ project အတွက် စတင်ရပါမယ်။ Quotation approval မရခင်မှာ project ရပြီလို့ သတ်မှတ်ထားလို့ မရပါဘူး။

Business Requirement Specification (BRS)

Project မစခင်မှာ အကြမ်းအားဖြင့် ဆွေးနွေးပြီးသွားရင် BRS ကို client ဖြစ်ဖြစ် product owner ဆီက ဖြစ်ဖြစ် တောင်းဖို့ လိုတယ်။ Project Manager ဟာ BRS ထဲမှာ ပါသည့် အချက်အလက်တွေ နဲ့ ဆွေးနွေးထားသည့် requirement အချက်အလက်တွေ ကွာနေလား ဆိုတာကို စစ်ဖို့ လိုတယ်။ BRS က ပုံမှန် အားဖြင့် product owner ဆီ က နေ ရ ပါတယ်။

BRS ဟာ contract မတိုင်ခင်မှာ နှစ်ဖက်ညှိထားသည့် requirement တွေ Business ဘက်က လိုအပ်ချက်တွေ ပါဝင်ပါတယ်။

BRS တစ်ခုမှာ

  • Project Name
  • Business Project Owner
  • Author
  • Contributors
  • Project Manager

စသည် တို့ ကနေ စတင်ပြီး ပါဝင်ပါတယ်။

ပြီးလျှင် Revision History ကို မဖြစ်မနေ ထည့်သွင်းဖို့လိုပါတယ်။ ဒါမှသာ Vendor ဘက်က သဘောတူထားသည့် Revision number က ဘယ် number ၊ Vendor မသိသေးသည့် Revision number က ဘယ် number ဆိုပြီး ခွဲသိနိုင်ပါလိမ့်မယ်။ ကိုယ့်ဘက် က complain တက်လာရင်လည်း BRS revision number xxx အတိုင်း develop လုပ်ထားပြီး နောက်ထပ် revision number yyy ကို လက်ခံမရရှိကြောင်း ငြင်းလို့ ရမှာပါ။

BRS မှာ ထပ်မံ ပါဝင်သည့် အရာတွေကတော့

  • Business Objective
  • Current Problems and Limitation
  • General Business Requirement
  • Business Requirement

စသည့် အချက်အလက်တွေ ပါဝင်ပါတယ်။

BRS က client ရဲ့ company ပေါ်မှာ မူတည်ပြီး ကွဲပြားတတ်ပါတယ်။

Contract

Developer နဲ့ မဆိုင်ပေမယ့် Project တစ်ခုမှာ contract ဟာ အရမ်းအရေးပါတယ်။ တချို့ project တွေက contract မတိုင်ခင်မှာ စပြီး လုပ်နေရင်းနဲ့ contract မချုပ် မိတာ တွေ ရှိပါတယ်။ Project Manager , Business development managers တို့ရဲ့ ဆုံးဖြတ် ချက်တွေက အရမ်းကို အရေးပါပါတယ်။ contract ပြီးမှ project စမယ် ဆိုရင်လည်း အရမ်းကို နောက်ကျ သွားတာတွေ ရှိတတ်တယ်။ Project owner နဲ့ သဘောတူထားတာကတော့ ၃ လ ပဲ ကြာမယ်။ သို့ပေမယ့် contract အဆင့်မှာတင် ၃ လ လောက် ကြာသွားတာ ရှိတတ်တယ်။ နားလည်မှု ၊​ ယုံကြည်မှုတွေ နဲ့ လုပ်ရပေမယ့် အကောင်းဆုံးကတော့ contract ပြီးမှသာ လုပ်ဆောင်ခြင်းဟာ အကောင်းဆုံးပါပဲ။ Contract တစ်ခု ကို ပြင်ဆင်ရတာဟာလည်း ၁ ပတ်လောက် ကြာတတ်ပါတယ်။ Contract မပြီးသေးခင် လုပ်ရသည့် အလုပ်ဟာ ပြဿနာဖြစ်ခဲ့ရင် အချက်နဲ့အလက် နဲ့ ပြောဖို့ အတော့်ကို ခက်ပါတယ်။ ဥပမာ Contract ထဲမှာ မပါသည့် Features ကို စကားနဲ့ ပြောထားတယ်။​ ကိုယ့်ဘက်ကလည်း develop လုပ်ထားလိုက်တယ်။​ တဖက်က ကျွန်တော် ပြောထားပြီးသားလေ။​ ပြောထားသည့် စျေးထဲမှာ အဲဒီ feature အပါလို့ ထင်တာ။​ စသည် ဖြင့် ညှိနှိုင်းရတာ အလုပ်ရှုပ်ကုန်ပါတယ်။ ဒါကြောင့် contract က အရေးကြီးပါတယ်။ contract မထိုးနိုင်ရင်တောင် BRS ကို ရယူထားမှ ဖြစ်ပါလိမ့်မယ်။

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

Wireframe

Team တစ်ခု ကို ရှင်းပြဖို့ client ဘက်က product owner ကို ရှင်းပြဖို့ အတွက် ဖြစ်စေ နောင်တချိန် project document အတွက် project မစချိန်မှာ အကြမ်းအားဖြင့် project အတွင်းပါဝင် ပတ်သက်သူတွေ နားလည် ရှင်းလင်းဖို့ အတွက် wireframe ကို ရေးဆွဲပါတယ်။

wireframe ရေးဆွဲသည့် software တွေ အများကြီး ရှိပါတယ်။ လက်ရှိ ကျွန်တော်ကတော့ https://whimsical.com ကို အသုံးပြုပါတယ်။ အခြား နှစ်သက်ရာ wireframe tool ကို အသုံးပြုနိုင်သလို အလွယ်ကူဆုံးကတော့ လက်နဲ့ပဲ​ ရေးဆွဲတာတွေလည်း ရှိပါတယ်။

wireframe ကို အခြား UI/UX tool တွေဖြစ်သည့်

  • Sketch
  • Adobe XD
  • Penpot

စသည်တို့မှာ ရေးဆွဲထားရင်တော့ final UI/UX ပြောင်းသည့် အခါမှာ ပိုမိုမြန်ဆန် လွယ်ကူပါတယ်။

Wireframe ဟာ project ရဲ့ size ပေါ်မှာ မူတည်ပြီး ကြာမြင့်နိုင်ပါတယ်။​

Wireframe မှာ product တစ်ခုလုံးကို ခြုံပြီး pageတိုင်းပါဖို့လိုပါတယ်။ Page တိုင်းမပါနိုင်ရင်တောင် product owner နဲ့ သဘောတူညီထားသည့် page တွေပါဝင်ထားဖို့ လိုပါတယ်။

Wireframe သေချာသွားမှသာ UI/UX ကို စသင့်ပါတယ်။ ပုံမှန် အားဖြင့် page တစ်ခု ခြင်းစီ ကို confirm လုပ်ပြီး ပြီးသွားသည့် page တွေကို UI/UX အပိုင်း စသင့်ပါတယ်။ Wireframe ကို အချိန်ပေးပြီး လုပ်ဖို့ လိုပါတယ်။ Project timeline နည်းတယ် Project က သေးတယ် ဆိုပြီး wirframe မပါပဲ​ development လုပ်သည့် အခါမှာ နောက်ပိုင်း ပြဿနာတက်နိုင်ပါတယ်။

Wireframe မှာ project owner ကိုယ်တိုင် စမ်းလို့ရသည့် prototype အဆင့်ထိ ပါ လုပ်ပေးနိုင်ရင် ပိုကောင်းပါမယ်။​ ဒါမှသာ ဘာမှ မစခင်မှာ project owner လိုချင်တာ ဘာလဲ ဆိုတာကို သိသာရှင်းလင်းစေပါလိမ့်မယ်။ Project တစ်ခု စတင်သည့် အခါမှာ စမ်းတဝါးဝါး နဲ့ စိတ်ထင်သည့် ပုံစံ ကို စတတ်ကြပေမယ့် wireframe အဆင့်မှာ ဘာလိုချင်လဲ ဘာဖြစ်ချင်လဲ ဆိုတာကို ပိုပြီး မြင်သာလာပါတယ်။

Wireframe ပြီးသွားရင် project owner နဲ့ သဘောတူညီမှု လက်မှတ် ဖြစ်ဖြစ် ထိုးထားခြင်း ဖြစ်စေ email ကနေ တဆင့် သဘောတူညီကြောင်း ဖြစ်စေ ရယူထားဖို့ လိုအပ်ပါတယ်။​ နောက်ပိုင်း changes တွေ ရှိလာခဲ့ရင် new fatures , bug ငြင်းနေသည့် အခါမှာ wireframe ပေါ်မှာ သဘောတူညီ ထားချက်ကို ပြန်လည် ကြည့်ရှုဖို့ လိုပါတယ်။​

UI/UX

Wireframe မပြီးခင်မှာ UI/UX ကို စတင်ဖို့ အကြံ မပေးချင်ပါဘူး။​ Wiframe က ခဏ ခဏ ပြောင်းလဲ တတ်ပါတယ်။​ လိုအပ်ချက်တွေက အမြဲ ပြောင်းလဲတတ်ပါတယ်။ Wireframe မှာ confirm ထားပေမယ့် UI/UX ရောက်သည့် အချိန်မှ ပြန်ပြီး ပြောင်းတာတွေလည်း ရှိနိုင်ပါတယ်။

UI/UX ကို အများအားဖြင့်

  • Sketch
  • Adobe XD
  • Figma
  • Penpot

စသည့် tool များ ဖြင့် ရေးဆွဲကြပါတယ်။ Designer တွေက ပုံမှန်အားဖြင့် ပုံတွေက export မထုတ်ပဲ developer တွေ ကိုယ်တိုင် လိုအပ်သည့် icons တွေ images တွေကို export ထုတ်ရတာ တွေရှိပါတယ်။ ဒါကြောင့် Developer တွေ အနေနဲ့ ကိုယ်တိုင် export လုပ်နိုင်အောင် tool တွေ ကို သုံးတတ်ဖို့ လိုပါတယ်။ အကုန်လုံးကတော့ အခြေခံတွေ တူညီ ကြသည့် အတွက် လေ့လာရတာ ခက်ခဲမှုတော့ မရှိပါဘူး။

Human Resources

Project Contract စကတည်းက project မှာ resources ဘယ်လောက်ပါမလဲ ဆိုတာ ဆုံးဖြတ်ထားပြီးသားပါ။ အများအားဖြင့် Resources တွေက အခြား project မပြီးသေးသည့် အခါ ဒါမှမဟုတ် bugs fix လုပ်ဖို့ လိုသည့် အခါတွေ မှာ သတ်မှတ်ထားသည့် ရက်မှာ သတ်မှတ်ထားသည့် tasks တွေ လုပ်ဖို့ နောက်ကျ သွားတာ တွေ ရှိပါတယ်။ ဒါကြောင့် အဲဒီလိုမျိုး issue တွေ အတွက် timeline မှာ အချိန် ပိုယူထားဖို့ လိုအပ်ပါတယ်။ Project တစ်ခု ဟာ ပြီးဆုံးသွားပေမယ့် အမြဲတန်း bugs တွေ features အသေးလေးတွေ ပြန်လာတတ်ပါတယ်။ အဲဒီ အခါမှာတော့ project ကို လုပ်ထားသည့် developer ကိုယ်တိုင် လုပ်ဆောင်ရတာ များပါတယ်။ ဒါကြောင့် project timeline တော်တော်များများမှာ developer တစ်ယောက် ဟာ အချိန်ပြည့် ၁၀၀% လုပ်ဆောင်နိုင်မယ်လို့ တွက်ထားလို့ မရပါဘူး။ ပြဿနာ နောက်တစ်ခုက လက်ရှိ developer မအား လို့ အခြား developer တစ်ယောက်က လွှဲယူရသည့် အခါမှာ တွက်ထားသည့် timeline ထက် ပိုမို ကြာမြင့်နိုင်ပါတယ်။ Project Manager အနေနဲ့ timeline ချ သည့် အခါမှာ Developer တွေရဲ့ timeline ကို လက်ရှိ လုပ်နေဆဲ ကိုင်ထားသည့် project အခြေအနေ ပေါ်ကြည့်ပြီး ရေးဆွဲဖို့ လိုပါတယ်။