ဆော့ဝဲ ပရောဂျက် တစ်ခုမှာ လူဘယ်နှစ်ယောက်ပါလဲ?
ဆော့ဝဲ ပရောဂျက် တစ်ခုမှာ လူဘယ်နှစ်ယောက်ပါပြီး ဘာတွေတာဝန်ယူကြလဲ?
ကုမ္မဏီအပေါ်မူတည်ပြီး အမျိုးမျိုး ကွဲပြားနိုင်တာ ဖြစ်လို့ ကျွန်တော်တို့ အဖွဲ့ရဲ့ တာဝန်ခွဲဝေပုံကိုပဲ အကြမ်းဖျဉ်း မျှဝေပေးပါမယ်။
စစချင်းကတော့ Client နဲ့ ကျွန်တော် နဲ့ နှစ်ယောက်ပဲ ပါတယ်။
Client က သူလိုချင်တဲ့ Product အကြောင်းပြောတယ်။ စျေးအရောင်းစာရင်းမှတ်တဲ့ ဖုန်းဆော့ဝဲလေးတစ်ခု ရေးပေးပါဉီးတို့ Facebook မှာ စျေးရောင်းတာအပြင် website လေးနဲ့ပါ ရောင်းချင်ပါတယ်လို့ ဒီလို လာအပ်တယ်။
သူတို့ပြောတာကလည်း ရှင်းရှင်းလေး ကိုယ်လုပ်ရတဲ့အလုပ်ကလည်း ရိုးရိုးရှင်းရှင်း CRUD Module (စာရင်းဇယား) သုံးလေးခုကို ပိုင်ရှင်တစ်ယောက်တည်းကပဲ အထုတ်အသွင်းလုပ်မှာ ဆိုတော့ ပြဿနာ မရှိဘူး။ Website ပဲဖြစ်ဖြစ်၊ Mobile App ပဲဖြစ်ဖြစ် အစအဆုံး တစ်ယောက်တည်း ရေးသွားလို့ရတယ်ပေ့ါဗျာ။ ဒါက အစောပိုင်း ကာလမှာ အဆင်ပြေခဲ့တဲ့ ပုံစံ။
နောက်ပိုင်းတော့ ဆော့ဝဲလာအပ်တဲ့သူက တစ်ယောက်တည်း မဟုတ်တော့ဘူး။ ဆိုလိုတာက လူအရေအတွက်ကို ပြောတာ မဟုတ်ဘူး။ လုပ်ငန်းတစ်ခု အနေနဲ့ လာအပ်တာ။ ဉပမာ ဒိုဘီ(အဝတ်လျှော်) လုပ်ငန်းတစ်ခုက သူတို့ရဲ့ ဒိုဘီကောက်တဲ့ လုပ်ငန်းစဉ် ကို Mobile App ကနေ အစအဆုံး လုပ်ချင်တယ်ဆိုပြီး လာအပ်တယ်။
ဒီစနစ်ကတော့ အရင်က ပြောခဲ့တဲ့ ပရောဂျက်တွေလို စာရင်းဇယားကလည်း သုံးလေးခု မကတော့ဘူး။ နောက် ဒီ စာရင်းဇယားတွေကိုလည်း လူပေါင်းစုံက အထုတ်အသွင်းလုပ်နေကြမှာ။
အရင် Manual လုပ်နေတဲ့စနစ်က ဒီလိုမျိုးသွားတယ်။
- ဖောက်သည်က ဒိုဘီဆိုင်ကို ဖုန်း / viber ကနေ အဝတ်လျှော်အပ်ချင်တဲ့ အကြောင်းလှမ်းပြောတယ်
- ဆိုင်ဘက် ဝန်ထမ်းက စာရင်းစာအုပ်ထဲမှာ မှတ်ပြီး မနက်ဖြန် ဘယ်ချိန် လာယူပါမယ်ဆိုပြီး အတည်ပြုပေးတယ်
- နောက်ရက် အဝတ်လိုက်ကောက်တဲ့ ဝန်ထမ်းက အိမ်တွေကို အဝတ်လိုက်ကောက်တယ်
- ဆိုင်မှာ လျှော်ဖွတ် မီးပူတိုက်ပြီးရင် နောက်တစ်ရက်မှာ ပြန်သွားပို့ပေးရင်း ပိုက်ဆံကောက်တယ်။
ပုံမှန်အတိုင်း အဆင်ပြေပေမယ့် ဒီလိုပြဿနာတွေ ကြုံရတယ်
- ဆိုင်က ဝန်ထမ်းက ဖောက်သည်တစ်ယောက်ရဲ့ ဖုန်းတစ်လုံးကို ဖြေနေတုန်း အခြား ဖောက်သည်တွေဆက်ရင် ဖုန်းမအားသေးပါဆိုပြီး ဆက်မရတော့ ဖောက်သည်တွေ ဆုံးရှုံးရတယ်။ Customer Experience လည်း မကောင်းဘူးပေါ့။
- ထည့်ပေးလိုက်တဲ့ အဝတ်တွေ နဲ့ ပြန်လာပို့တဲ့ အဝတ်တွေက အရေအတွက် မတူတာတွေ / အထည် မတူတာတွေ ဖြစ်တယ်။
- ဖောက်သည်တွေက အပ်လိုက်တဲ့ အဝတ်တွေ ဘယ်ချိန် ပြန်ရမလဲဆိုတာကို ဖုန်းဆက်ပြီး မေးရတယ်။
- အဝတ်ပြန်သွားပို့တဲ့အချိန် ဖောက်သည်မရှိလို့ လိုက်ပို့တဲ့ ဝန်ထမ်းက ပြန်သယ်လာရတာမျိုးတွေလည်း ဖြစ်တယ်။
ဆိုရရင် အဝတ်လျှော်ဖို့ လာကောက်တဲ့အချိန်က စပြီး ပြန်ပို့ပေးတဲ့အချိန်ထိ ဘယ်ချိန်မှာ ဘာဖြစ်နေပါပြီဆိုပြီး အချိန်နဲ့တပြေးညီ ပွင်းလင်းမြင်သာ ပြနိုင်မယ်ဆိုရင် ဒီပြဿနာ တွေ ပြေလည်မယ်လို့ ယူဆပြီး ဒီလုပ်ငန်း ပိုင်ရှင်က ဆော့ဝဲလာအပ်တယ်။
ဒီ ပရောဂျက်မှာ ဒါတွေပါလာမယ်
- ဖောက်သည်တွေ သုံးမယ့် မိုဘိုင်းအက်ပ် (Android, iOS)
- ဆိုင်က ဝန်ထမ်းတွေ သုံးမယ့် Admin Panel (Website)
- အဝတ်လိုက်ကောက် / လိုက်ပို့မယ့် ဝန်ထမ်းတွေသုံးမယ့် မိုဘိုင်းအက်ပ် (Android)
ဝန်ထမ်းက (၁၀၀) ဝန်းကျင်ရှိပြီး ဖောက်သည်က (၅၀၀၀)ဝန်းကျင်ရှိတယ်။
ဒီပရောဂျက်ကိုရေးဖို့ တစ်ယောက်တည်းနဲ့ အဆင်မပြေတော့ဘူး။ ဒီလူတွေ လိုလာပြီ။
- Client
- Product Owner
- Project Manager
- Designer
- Developer
- Tester
- DevOps
- System Administrator
Client
ဒါကတော့ အလုပ်လာအပ်တဲ့သူ / လုပ်ငန်း အုပ်စု က တာဝန်ခံ ကိုဆိုလိုတာ။
Product Owner
ဒီလူကတော့ ဘယ် ဆော့ဝဲမှာ ဘာ Feature တွေပါမယ်၊ Requirement က ဘာတွေ အစရှိသဖြင့် လိုချင်တာတွေ ထိုင်ပြောနေမယ့်သူပေ့ါ။ ဉပမာ ။ ဖောက်သည်တွေ သုံးမယ့် App မှာ
- register လုပ်ရင် ဖုန်းနံပါတ်နဲ့ လုပ်ပြီး OTP နဲ့ verification လုပ်မယ်
- login ဝင်ရင် ဖုန်းနံပါတ် နဲ့ စကားဝှတ် နဲ့ ဝင်ရမယ်။
အဝတ်လိုက်ကောက် / ပို့ တဲ့ Rider သုံးမယ့် App မှာ
- မြေပုံပါမယ်။
- မြေပုံပေါ်မှာ ဖောက်သည်တွေရဲ့ အိမ်ကို ကြည့်လို့ရမယ်။
အစရှိသဖြင့် လိုချင်တာတွေ ဖြစ်ချင်တာတွေကို ထိုင်ပြောနေမယ့်သူ။ ထိုင်ပြောနေရုံတော့ မဟုတ်ဘူးပေါ့ဗျာ။ User Story နဲ့ Product Backlog တွေဘာတွေလည်း ရေးပေးလိမ့်မယ်။
Project Manager
ဒီလူကတော့ လူတကာကို အလုပ်ပေးမယ့်သူလို့ ပြောလို့ရတယ်။ ဘယ်သူ ဘယ်ချိန်မှာ ဘာကို အပြီးလုပ် ဆိုပြီး ပရောဂျက်တစ်ခုလုံးကို Deadline အမှီပြီးအောင် မောင်းနေမှာ။ အထူးသဖြင့် Product Owner ဘက်က ပေးလိုက်တဲ့ User Story တွေကို ခွဲခြမ်းစိတ်ဖြာပြီး Task သေးသေးလေးတွေ ထုတ်ပေးရတာများတယ်။ တစ်ခါတစ်လေလည်း မဖြစ်နိုင်တဲ့ Features တွေ Budget နဲ့ မကိုက်တဲ့ Timeline တွေအတွက် Product Owner နဲ့ ရန်တွေဖြစ်ပေ့ါ။
Designer
အပေါ်ကလူ နှစ်ယောက်နဲ့ ခေါင်းချင်းဆိုင်ပြီး Client နဲ့ End User တွေ တကယ်မြင်ရမယ့် Mobile App နဲ့ Web Admin Panel တွေကို ပုံစွဲပြတဲ့သူ။ သူဆွဲပြတဲ့ပုံကို ကိုင်ပြီး Client နဲ့လည်း စကားပြောရတယ်။ Mobile App ကို ဖွင့်ဖွင့်ချင်း ဒီလိုလေး မြင်ရပါမယ် ၊ Client ရဲ့ Brand အရောင်နဲ့ တွဲစပ်မိအောင်လည်း ဒီလူက တာဝန်ယူရတယ်။ Wireframe တို့ Prototype တို့က စပြီး နောက်ဆုံး UI/UX အထိ တဆင့်ပြီးတဆင့် ငြင်းလိုက် ခုန်လိုက်နဲ့ ဆွဲကြတာမျိုး။
Developer
ဒါကတော့ တကယ် ကုတ်မယ့် အဖွဲ့တွေ။ တစ်ရက်တစ်ရက် Project Manager က assign လုပ်ထားတဲ့ task နဲ့ UI/UX Designer က ဆွဲပေးထားတဲ့ ပုံကို ကြည့်ပြီး ကုတ်ရတာမျိုး။ ဒီအဖွဲ့ကတော့ လူအတော်စုံတယ်။ Backend API ရေးတဲ့အဖွဲ့ရှိတယ်။ Frontend Website တို့ Mobile App တို့ စတာတွေ ရေးတဲ့အဖွဲ့တွေလည်း ရှိတယ်။ UI/UX ဘက်က client နဲ့ အတည်ပြုထားပြီးတဲ့ Design တွေကို ကွန်ပျူတာ ကုတ်နဲ့ မတူတူအောင် လုပ်ရေးရတာမျိုးဆိုတော့ တစ်ခါတစ်လေတော့လည်း အတော်ရွာလည်ကြတဲ့ အဖွဲ့လို့ ပြောရမယ်။
Tester
ကုတ်တဲ့သူတွေက သူတို့ကုတ်ပြီးပါပြီ အလုပ်ပြီးပါပြီဆိုတာနဲ့ မရဘူး။ သူတို့ကုတ်ထားတာက ရေးထားတဲ့ User Story တွေနဲ့ ကိုက်ညီမှု ရှိလားဆိုပြီး စစ်ရတဲ့အဖွဲ့။ Developer (၃) ယောက် Tester (၁) ယောက် တွဲပေးထားတာမျိုးလည်း ရှိရဲ့။ လူနဲ့ မစစ်ပဲ Program နဲ့ပဲ စစ်လည်း စစ်ကြရဲ့။ စစ်လို့ မှန်းထားတဲ့အတိုင်း အလုပ်မလုပ်ရင် Developer တွေစီကို Bug ဆိုပြီး ပြန်တင်ပေးပေါ့။ ဟိုဘက်က Developer တွေက Bug လိုက်ရှာပြီး ပြန်ရှင်းကြ နဲ့ လည်ပတ်။
Dev Ops
Tester တွေဘက်ကနေ အာမခံပြီးတဲ့အချိန် ပရောဂျက်ကို တကယ့် Production Server တွေပေါ်တင်ပေးမယ့် သူတွေ။ Develpment ကာလာအတွင်း Test Server တွေအပေါ်တင်ပေးရတာလည်း ရှိတယ်။ CI/CD လိုမျိုး Deployment Pipeline တွေ ဆင်ပေးရတာမျိုးလည်း ရှိတယ်။
System Administrator
ပရောဂျက်က လိုအပ်တဲ့ Server / Infrastructure တွေကို configure လုပ်ပေးမယ့်သူတွေ။
ဒါက အကြမ်းဖျဉ်းလိုတဲ့ လူအုပ်စုပေါ့။ ဒီ Role တစ်ခုချင်းစီက Professional တစ်ခုစီ ဖြစ်နေတာဆိုတော့ ဆွေးနွေးရရင် အကျယ်ကြီးပဲ။
ကျွန်တော်တို့လို့ လူလေးငါးယောက်ပဲ ရှိတဲ့ အဖွဲ့တွေ ကြတော့ လူတစ်ယောက်က Role နှစ်ခု သုံးခုကို တာဝန်ယူကြရတယ်။
- Product Owner + Project Manager
- Desinger + Tester
- Developer
- Dev Ops + System Administrator
ဒါလည်း Role အရ ပေါင်းထားပေမယ့် လူမရှိတော့ Product Owner တာဝန်ယူထားတဲ့သူကလည်း ဝင်ကုတ်ကောင်း ကုတ်ရမယ်။ Developer ဆိုပေမယ့်လည်း ကိုယ့်ဘာသာကိုယ် Server ပေါ်တင်ရတာမျိုးလည်း ရှိမယ်။
ဒါကတော့ ကျွန်တော်တို့ လုပ်နေတဲ့ Software Development Project တစ်ခုမှာ ပါလေ့ရှိတဲ့ Role and Responsibilites တွေအကြောင်းပဲဖြစ်ပါတယ်။ ကုမ္မဏီ အမျိုးမျိုးမှာ Role and Responsibilites အမျိုးမျိုးရှိနိုင်တာမို့ လှေနံဓားထစ်မှတ်ထားလို့တော့မရနိုင်ပါဘူး။ အခြား လိုအပ်တဲ့ Role and Responsibilites တွေရှိရင်လည်း မျှဝေခဲ့ကြပါဉီး။
ဆော့ဝဲပရောဂျက် တစ်ခုမှာ ဘယ်သူတွေပါရမယ်၊ ဘာတွေ တာဝန်ယူရမယ်ဆိုပြီး ဖွဲ့စည်းတာက ပါတဲ့ သူတွေနဲ့ သူတို့ရဲ့ တာဝန်ခွဲဝေမှုက ကုမ္မဏီအပေါ်မူတည်ပြီး အမျိုးမျိုး ကွဲပြားနိုင်ပါတယ်။
ဆိုတော့ကာ ဆော့ဝဲပရောဂျက် တစ်ခု စပြီဟေ့ဆိုရင် သူ့ဘက်ကိုယ့်ဘက် အဖွဲ့အင်အားနဲ့ လုပ်ရမယ့် အလုပ်ကို သေချာ ဆွေးနွေးပြီးမှ စသင့်တယ်။ မဟုတ်ရင် ကုတ်ရေးရင် ပရောဂျက်ပြီးတာပဲဆိုတဲ့ mind set နဲ့ တိုင်ပတ်သွားနိုင်ပါကြောင်း။
Specification တွေကို စီစဉ်ပေးရတဲ့သူ။ Ubuntu 20 LTS ကို RAM 32 GB နဲ့ နှစ်လုံးလိုချင်တယ်။
တစ်ခါတစ်လေ website တစ်ခု တစ်ခါတစ်လေတော့ မိုဘိုင်းအက်ပ် တစ်ခု
Software တစ်ခု စရေးရင် လူဘယ်နှစ်ယောက် ပါလဲ?
အနည်းဆုံး တစ်ယောက်ပေါ့။
ကိုယ့် Idea ကိုယ့်ဘာသာကို ကုတ်။
နောက် အလုပ်လာအပ်တဲ့ Client နဲ့ ကုတ် ရေးပေးတဲ့ ပရိုဂရမ်မာ ဒါမျိုး ရှိမယ်။
ထားတော့ ဒါတွေက Informal တွေ။
တင်း ရည် လုပ် အုပ် ဆက်
ပြောချင်တဲ့ သတင်းက Software တစ်ခု ရေးပြီးဆိုရင် ဘယ်လိုလူတွေ လိုလဲ?
Title : Software Development Team Structure: Roles & Responsibilities Statement : Audience :
မြေဆန်တဲ့ အသုံးအနှုန်း လိုတယ်။
Software Development Team Structure: Roles & Responsibilities
ဒါတွေကို Junior Programmer တွေနဲ့ အပြင်က အလုပ်အပ်မယ့်သူတွေ သိစေဖို့
တာဝန်နဲ့ လူစာရင်း ရှင်းပြမယ်။ ဘယ်သူက ဘာတာဝန်ကို ယူတယ် ဘာကြောင့် ဘယ်လို ယူတယ် မရှိရင် ဖြစ်ချင်တိုင်း ဖြစ်မယ့် အကြောင်း။
** Development Process ** မှာ Client ကို ဘယ်အခြေအနေအထိ ဝင်ခိုင်းမှာလဲ ဒါလည်း ပြောစရာတစ်ခု။
ကိုယ့် Team ကို ဆက်သွယ်လို့ရတယ်ပေါ့။ ဒါက နောက်တစ်ပိုင်း။
အင်္ဂါမစုံတဲ့ Team တွေက ဘယ်လို ဖွဲ့စည်းပုံ ပျက်တဲ့အကြောင်း source : ကိုယ်တိုင်။
- Product Owner
- Project Manager
- Developer
- Tester
- Dev Ops
- System Administrator
–
Programming is not a field but it is an ideology and concept. Most developers in Burma are weak in Programming. What most developers know is only Web Development and Mobile Development. They don’t even know the meaning of “Front-end” and “Back-end”. You can pick one developer from the crowd and ask him what the Front-end and Back-end mean. Most of them will answer like Front-end is JavaScript, React,… and Back-end is PHP, SpringBoot,… That’s the most stupid answer ever.
Front-end/Back-end is a theory and it exists everywhere. Front-end is something that has to be interactive with the end-user (does not exactly describe that it has to be the Web). For ex: The phone and computer you are using has Front-end part (button, camera, body, color, OS) and Backend (CPU, Memory, battery).
Those JavaScript, React are so-called Front-end Web Development Languages/Framework.
Not every developer can be a programmer. Programming is a concept as I mentioned and Programming Language is a human-readable, compilable language that is used to implement that Programming Concept.
There are many types of Programming, most developer in Burma do not know. Imperative Programming, Competitive Programming, Functional Programming, Parallel Programming, Object-Oriented Programming, etc…
Those Programming style are also a theory/concept.
Most developers in Burma do not even know Maintainability, Scalability, Efficiency of the program. There are many design patterns of programming to improve Maintainability, Scalability and Efficiency. (Here, it comes Software Engineering)
Sidenote: every engineer can be a programmer/developer but not every developer/programmer cannot be an engineer.
To conclude this question, I would kindly ask to learn what programming means and then review this question again and study those so-called Design Patterns. Those “React, Laravel, JavaScript, etc..” are “အတတ်ပညာ” and those Programming Theory and Engineering are “အသိပညာ”.
A developer who does not have “အသိပညာ” will not be different from those ……..
Please share this article in Burmese Language if you find this is useful.
Best Regards, Software Engineer