Sistem Bisnes Tak Pernah Betul-Betul Siap
Published:
Updated:
Ada satu perkara yang saya semakin sedar selepas beberapa kali membina custom system untuk business.
System yang dah siap bukan bermaksud system itu akan kekal sama selama-lamanya.
Malah, kalau system itu digunakan dengan betul, biasanya akan berlaku benda yang lebih menarik.
Lepas beberapa bulan, owner mula datang dengan benda-benda macam:
"Faiz, boleh tak buat macam ni?"
"Sebelum ni kita tak pernah buat macam ni."
"Sekarang customer dah mula minta benda ni."
"Staff ada process baru."
"Kita nak tambah satu lagi jenis package."
"Boleh tak customer yang lama masuk balik dan buat pembelian baru?"
Dan kadang-kadang akan keluar soalan yang agak mencabar:
"Kenapa system tak boleh buat?"
Ini soalan yang menarik.
Sebab jawapan sebenarnya sangat mudah.
Sebab masa system itu dibuat, requirement tersebut memang tak wujud.
Dan ini bukan semestinya kesalahan developer.
Kita selalu anggap requirement boleh diramal dari awal
Bila nak buat system, biasanya kita akan buat requirement gathering.
Tanya business owner:
- Apa process sekarang?
- Siapa yang guna system?
- Apa yang perlu direkod?
- Apa report yang diperlukan?
- Apa flow pembelian?
- Apa flow approval?
- Apa yang berlaku selepas payment?
- Apa yang staff perlu buat?
Kemudian developer akan design database, UI, workflow dan business logic berdasarkan jawapan tersebut.
Contohnya, katakan kita buat system untuk sebuah pusat latihan.
Business model mereka mudah.
Customer beli kursus.
Selepas payment:
Customer
↓
Buy Course
↓
Course Registration
↓
Attend Course
↓
Certificate
Semua orang happy.
System siap.
Test.
Deploy.
Training staff.
Go live.
Setahun kemudian, business berkembang.
Tiba-tiba mereka mula buat corporate training.
Sekarang seorang company boleh daftar 20 orang sekaligus.
Flow yang dulu:
Customer → Course
sekarang jadi:
Company
↓
Purchase Course
↓
Register 20 Employees
↓
Each Employee
↓
Attend
↓
Certificate
Kemudian datang pula requirement baru:
"Company yang sama kadang-kadang beli course lain."
Sekarang kita perlukan:
Company
├── Order #001
│ └── Course A
│
├── Order #002
│ └── Course B
│
└── Order #003
└── Course C
System asal mungkin langsung tak direka macam ini.
Dan itu normal.
Sebab pada masa system dibina, business itu sendiri belum melalui pengalaman tersebut.
Developer bukan boleh nampak masa depan
Ini perkara yang saya rasa perlu difahami oleh kedua-dua pihak.
Developer memang sepatutnya bertanya soalan.
Developer patut cuba faham business.
Developer patut challenge requirement.
Developer patut fikir edge case.
Tetapi developer tak boleh membaca masa depan business.
Kalau owner sendiri belum pernah fikir tentang sesuatu scenario, agak tidak realistik untuk mengharapkan developer dapat teka scenario tu.
Contohnya:
"Customer mungkin akan membeli semula selepas setahun."
Mungkin ya.
Mungkin tidak.
Mungkin business owner sendiri yakin customer hanya akan beli sekali.
Kemudian selepas setahun, behaviour customer berubah.
Itu bukan bug.
Itu business discovery.
Software sebenarnya membantu kita teroka business process
Ini bahagian yang paling menarik.
Sebelum ada system, banyak business sebenarnya berjalan berdasarkan:
- pengalaman staff
- Excel
- Google Sheets
- kertas
- dalam ingatan
- "nanti saya check"
- "biasanya kita buat macam ni"
Banyak process tidak pernah benar-benar di-formalisasikan.
Bila kita bina software, kita terpaksa translate semua benda itu menjadi rules.
Contohnya:
"Customer beli package."
Okay.
Apa maksud package?
Berapa lama valid?
Boleh beli sekali sahaja?
Boleh beli dua kali?
Boleh transfer?
Boleh refund?
Boleh upgrade?
Boleh tambah item?
Boleh digunakan oleh orang lain?
Apa jadi kalau package expired?
Apa jadi kalau staff tersalah redeem?
Apa jadi kalau customer datang semula tahun depan?
Bila semua ini ditanya, baru kita nampak sesuatu.
Business process sebenarnya jauh lebih kompleks daripada apa yang kita sangka.
Dan kita hanya nampak complexity tersebut apabila system mula digunakan.
Sebab itu saya tak percaya kepada idea "system mesti perfect dari awal"
Secara teori, memang sedap bunyinya.
Kita buat requirement lengkap.
Design semua.
Build semua.
Test semua.
Launch.
Siap.
Tetapi realitinya jarang begitu.
Business sentiasa berubah.
Customer berubah.
Staff berubah.
Product berubah.
Pricing berubah.
Marketing berubah.
Cara business operate berubah.
Dan kadang-kadang business berkembang sampai muncul scenario yang sebelum ini memang tidak pernah berlaku.
Kalau system tidak berubah bersama business, system akan mula menjadi bottleneck.
V1 bukan produk terakhir
Saya lebih suka melihat custom system macam ini:
Idea
↓
V1
↓
Real users
↓
Real problems
↓
New discoveries
↓
Enhancement
↓
V2
↓
More usage
↓
More discoveries
↓
V3
↓
Repeat
Bukan:
Requirement
↓
Build
↓
Launch
↓
FINISH
Yang kedua itu lebih sesuai untuk projek yang skopnya memang fixed. contohnya Landing Page
Tetapi business system biasanya bukan macam itu.
System tersebut hidup bersama business.
Pengguna sebenar adalah sebahagian daripada proses development
Ini sebab saya suka bila system boleh digunakan secepat mungkin.
Kita boleh duduk dalam meeting selama tiga bulan dan bincang semua kemungkinan.
Tetapi kadang-kadang satu minggu penggunaan sebenar boleh memberikan lebih banyak info daripada semua meeting tu.
Contohnya staff tiba-tiba cakap:
"Eh, kami selalu buat macam ni sebenarnya."
Owner pula:
"Oh, saya tak tahu staff buat macam tu."
Developer:
"..."
Ini bukan sesuatu yang pelik.
Sebab meeting biasanya membincangkan expected process.
Tetapi system akan expose actual process.
Dan kedua-duanya tidak semestinya sama.
Ada beza antara bug dan requirement baru
Ini perkara yang sangat penting.
Bila client request sesuatu selepas system launch, jangan terus anggap semuanya sebagai "change request".
Kita kena bezakan sekurang-kurangnya tiga perkara.
1. Bug
System tidak buat sesuatu yang memang sudah dipersetujui.
Contohnya requirement:
Invoice perlu auto-generate selepas payment.
Tetapi system tidak generate invoice.
Itu bug.
Developer patut fix.
2. Requirement yang terlepas
Requirement sebenarnya sudah ada atau tersirat dalam business process, tetapi tidak dibina dengan betul.
Contohnya:
System sepatutnya membenarkan customer mempunyai banyak order.
Tetapi database design hanya membenarkan satu order.
Ini boleh jadi isu requirement atau architecture bergantung kepada apa yang telah dipersetujui.
3. Business scenario baru
Ini yang paling biasa berlaku selepas system digunakan.
Contohnya:
"Sekarang kami nak customer lama beli product baru."
Atau:
"Sekarang kami ada reseller."
Atau:
"Sekarang company boleh beli untuk 20 staff."
Atau:
"Sekarang kami nak buat membership."
Kalau benda tersebut memang tidak wujud dalam requirement asal, ia adalah new functionality.
Bukan bug.
Dan new functionality memang sepatutnya ada kos development.
"Tapi kenapa system tak boleh buat?"
Ini sebenarnya soalan yang valid.
Dan saya rasa developer tak patut jawab dengan defensive.
Jangan terus cakap:
"Sebab benda ni tak ada dalam requirement."
Walaupun technically betul.
Jawapan yang lebih baik ialah:
"Flow sekarang memang tak support scenario tersebut sebab masa system direka, prosesnya hanya untuk satu pembelian bagi customer. Kita boleh support scenario baru ini, tetapi ia memerlukan perubahan pada flow dan database."
Kemudian tunjukkan apa yang perlu diubah.
Contohnya:
Current:
Customer
↓
Order
↓
Product
New:
Customer
↓
├── Order #1
│ └── Product A
│
├── Order #2
│ └── Product B
│
└── Order #3
└── Product C
Bila client nampak perubahan tersebut, conversation terus berubah.
Ia bukan lagi:
"Kenapa developer tak buat?"
Tetapi:
"Oh, rupanya kita kena ubah structure."
Itu conversation yang lebih sihat.
Jangan cuba bina semua kemungkinan dari awal
Ada satu lagi perangkap.
Bila kita sedar business mungkin berubah, kita boleh pergi terlalu jauh.
Kita mula fikir:
"Okay, kita kena support semua kemungkinan."
Customer boleh beli banyak kali.
Boleh transfer.
Boleh refund.
Boleh upgrade.
Boleh downgrade.
Boleh merge.
Boleh split.
Boleh gift.
Boleh share.
Boleh pause.
Boleh resume.
Boleh tukar owner.
Boleh...
Akhirnya V1 yang sepatutnya boleh siap dalam dua bulan menjadi enam bulan.
Dan yang lebih teruk:
mungkin 80% functionality tersebut tak pernah digunakan.
Ini juga satu bentuk pembaziran.
Software development ada kos.
Setiap abstraction yang kita tambah mempunyai complexity.
Setiap "future-proofing" mempunyai harga.
Dan kadang-kadang kita membayar hari ini untuk masalah yang mungkin tidak pernah berlaku.
Jadi apa pendekatan yang lebih baik?
Saya lebih suka prinsip:
Build for today's business. Design with tomorrow in mind.
Bukan:
Build everything for tomorrow.
Maksudnya, kita tetap perlu bina architecture yang reasonable.
Database jangan dibuat secara bodoh semata-mata sebab requirement sekarang simple.
Tetapi jangan pula membina sistem enterprise yang kompleks untuk business yang baru mempunyai 50 customer.
Kita cari balance.
Contohnya, kalau sekarang customer hanya membeli sekali, kita masih boleh design database dengan konsep:
Customer
↓
Orders
bukan:
Customer
↓
OneOrder
Walaupun UI sekarang hanya perlukan satu purchase.
Itu contoh designing for extensibility.
Tetapi kita tidak perlu membina UI untuk 17 jenis repeat-purchase scenario yang belum wujud.
Saya rasa model yang lebih sihat ialah "system evolution"
Untuk custom software, saya rasa relationship sepatutnya bukan:
Client → Developer → Project → Handover → Goodbye
Tetapi:
Client → Developer → V1 → Usage → Feedback → Enhancement → Improvement
Ini lebih dekat dengan realiti.
Selepas V1 launch, client boleh maintain satu backlog.
Contohnya:
| Request | Status |
|---|---|
| Repeat customer | New |
| Export report | Planned |
| New payment method | Planned |
| Fix invoice calculation | Bug |
| New membership type | New |
| Dashboard improvement | Backlog |
Setiap bulan atau setiap quarter, backlog boleh review.
Mana yang penting, buat dahulu.
Mana yang tak penting, simpan.
Mana yang sebenarnya bukan masalah, buang.
Ini juga mengubah cara kita charge client
Kalau kita dari awal menjual:
"RM30,000 untuk system."
Client mungkin mempunyai mentaliti:
"Saya bayar RM30,000. Jadi system ini sepatutnya buat semua benda yang saya perlukan."
Lebih baik kalau expectation dari awal ialah:
"RM30,000 untuk membangunkan Version 1 berdasarkan scope yang dipersetujui."
Kemudian:
Bug dalam scope → fix.
New requirement → enhancement.
New business process → enhancement.
Major new module → project baru.
Ini jauh lebih jelas.
Malah, saya rasa developer patut menjual "evolution", bukan sekadar development
Ini mungkin nampak macam perbezaan kecil.
Tapi dari sudut business, ia besar.
Kalau kita hanya menjual development, revenue kita datang daripada:
Build
↓
Handover
↓
Done
Kita sentiasa kena cari client baru.
Tetapi kalau kita menjual system evolution:
Build
↓
Support
↓
Observe
↓
Improve
↓
Enhance
↓
Maintain
↓
Improve lagi
Client lama boleh terus menjadi customer.
Dan bagi client pula, mereka dapat partner yang faham system dan business mereka.
Win-win.
Tetapi owner business juga ada tanggungjawab
Dalam masa yang sama, saya rasa kita tak boleh letakkan semua expectation kepada developer.
Developer tahu software.
Owner tahu business.
Owner tahu:
- siapa customer mereka
- bagaimana customer membeli
- apa yang customer selalu tanya
- bagaimana staff bekerja
- apa yang berlaku di luar happy path
- bagaimana business mungkin berkembang
- apa jenis transaction yang biasa berlaku
Developer boleh bantu uncover semua itu.
Tetapi developer bukan pengganti business owner.
Kalau owner sendiri belum pernah terfikir sesuatu scenario, kita tak boleh expect developer tahu secara automatik.
Sebab itu requirements gathering perlu menjadi collaboration, bukan soal jawab semata-mata.
Soalan yang saya sekarang lebih suka tanya
Selain:
"Apa system perlu buat?"
Saya akan cuba tanya:
"Apa yang berlaku kalau customer buat benda yang sama untuk kali kedua?"
"Apa yang berlaku kalau customer cancel?"
"Apa yang berlaku kalau staff tersilap?"
"Apa yang berlaku kalau payment gagal?"
"Apa yang berlaku kalau customer datang semula?"
"Apa yang berlaku kalau business mula jual product baru?"
"Apa yang berlaku kalau satu company mempunyai ramai users?"
"Apa yang berlaku kalau satu transaction perlu diubah selepas beberapa bulan?"
Soalan-soalan macam ini lebih banyak uncover state dan behaviour.
Tetapi sekali lagi, kita tidak akan dapat semua jawapan.
Dan itu okay.
Real-world usage adalah sebahagian daripada discovery
Saya rasa ini mindset yang paling penting.
Jangan fikir:
Discovery berlaku sebelum development sahaja.
Discovery sebenarnya berlaku sepanjang hayat system.
Sebelum development:
"Ini yang kita rasa business perlukan."
Selepas launch:
"Ini yang sebenarnya berlaku."
Selepas beberapa bulan:
"Ini cara customer sebenarnya behave."
Selepas setahun:
"Oh, business dah berubah."
Dan software perlu mengikuti perubahan itu.
System yang matang bukan system yang mempunyai paling banyak feature
Ini pun penting.
Kadang-kadang kita nampak system yang mempunyai 100 feature dan kita fikir:
"Wah, mature."
Tak semestinya.
System yang matang ialah system yang betul-betul represent operation business dengan baik.
Kalau business hanya perlukan 20 feature, maka 20 feature yang betul mungkin jauh lebih baik daripada 100 feature yang separuh digunakan.
Maturity bukan tentang jumlah feature/fungsi.
Maturity ialah tentang:
How well the system fits the actual business.
Jadi, adakah V1 itu gagal kalau selepas setahun kita perlu ubah banyak benda?
Pada saya, tidak.
Malah kadang-kadang itu petanda system sedang berjaya.
Sebab perubahan itu mungkin berlaku kerana:
- customer bertambah
- business mendapat product baru
- staff bertambah
- operation menjadi lebih kompleks
- business menemukan revenue stream baru
- customer behaviour berubah
Masalah sebenar bukan:
"System berubah."
Masalah sebenar ialah apabila business berubah tetapi system tidak boleh berubah.
Software yang baik sepatutnya boleh berkembang
Ini yang saya rasa patut menjadi salah satu objektif ketika membina custom system.
Bukan cuba meramal semua future requirements.
Tetapi memastikan apabila requirement baru muncul, kita tidak perlu buang semuanya dan bina semula dari kosong.
Kita mahu architecture yang membolehkan:
V1
↓
V1.1
↓
V1.2
↓
V2
↓
V2.1
bukan:
V1
↓
New requirement
↓
"Tak boleh"
↓
Buang system
↓
Build V2 from scratch
Itulah beza antara system yang sekadar berfungsi dengan system yang boleh berkembang bersama business.
Akhirnya, jangan takut dengan requirement baru
Saya rasa ini perkara yang paling penting.
Bila selepas enam bulan client datang dan berkata:
"Sekarang kami nak buat benda lain."
Jangan terus melihatnya sebagai masalah.
Tanya dulu:
Kenapa business sekarang perlukan benda baru tu?
Kadang-kadang jawapannya ialah:
"Sebab customer semakin ramai."
Atau:
"Sebab kami baru buka branch kedua."
Atau:
"Sebab product baru ni laku."
Atau:
"Sebab customer lama mula datang balik."
Itu sebenarnya berita baik.
Business sedang berubah.
Dan software perlu berubah bersama-sama.
Kesimpulan
Saya sekarang melihat custom software bukan sebagai projek yang perlu "siap perfect".
Saya melihatnya sebagai satu proses.
Kita bina Version 1 berdasarkan apa yang kita tahu hari ini.
Kemudian business menggunakan system tersebut.
Daripada penggunaan sebenar, kita discover perkara yang sebelum ini tidak diketahui.
Kemudian kita improve.
Dan cycle itu berulang.
Build
↓
Use
↓
Learn
↓
Improve
↓
Build
↓
Use
↓
Learn
↓
Improve
↓
Repeat
Sebab itu saya rasa expectation yang lebih sihat ialah:
V1 tidak perlu sempurna. V1 perlu cukup baik untuk digunakan dan cukup fleksibel untuk berkembang.
Developer pula perlu bertanggungjawab memastikan system dibina dengan architecture yang masuk akal.
Business owner pula perlu faham bahawa business requirements boleh berubah.
Dan kedua-dua pihak perlu faham satu perkara:
Requirement baru bukan semestinya tanda seseorang gagal buat kerja.
Kadang-kadang requirement baru itu muncul kerana business baru belajar sesuatu yang mereka tidak tahu sebelum ini.
Dan sebenarnya, itulah tujuan sebenar software.
Bukan sekadar automate apa yang business buat hari ini.
Tetapi menjadi infrastructure yang boleh berkembang apabila business itu sendiri berkembang.
