5 Red Flags Developer Sistem Yang Buat Projek Gagal Sebelum Mula

Ramai orang ingat projek software gagal sebab developer tak pandai coding.

Sebenarnya, kebanyakan projek gagal jauh lebih awal daripada itu.

Ia bermula semasa proses memilih developer.

Masalahnya, ramai pemilik bisnes tak datang daripada latar belakang teknikal. Jadi mereka terpaksa bergantung kepada apa yang developer cakap. Bila developer nampak yakin, guna istilah teknikal yang hebat-hebat, terus nampak macam pakar.

Malangnya, keyakinan bukan kompetensi.

Selepas beberapa tahun membina sistem custom untuk pelbagai jenis bisnes, aku perasan ada beberapa red flags yang hampir selalu muncul dalam projek yang akhirnya bermasalah.

Kalau kau nampak tanda-tanda ni semasa peringkat awal perbincangan, hati-hati.

1. "Boleh Je, Senang" Untuk Semua Benda

Kau cadangkan satu feature.

"Ya boleh."

Kau tambah lagi lima feature.

"Ya boleh."

Kau ubah keseluruhan workflow.

"Ya boleh."

Semua benda nampak mudah.

Pada pandangan pertama, ini nampak macam servis yang bagus.

Hakikatnya, ini salah satu red flag paling besar.

Developer yang betul-betul faham apa yang dia buat akan bagi pushback bila perlu.

Dia akan tanya soalan.

Dia akan cabar assumption.

Dia akan beritahu risiko.

Kadang-kadang dia akan terus cakap:

"Cara tu boleh buat, tapi nanti data susah nak maintain. Saya cadangkan kita buat macam ni."

Atau:

"Kalau ikut flow ni, nanti proses approval akan jadi bottleneck bila jumlah pengguna bertambah."

Developer yang sentiasa setuju dengan semua benda biasanya berada dalam salah satu kategori:

• Mereka tak faham complexity sebenar
• Mereka tak kisah tentang outcome projek

Developer yang bagus bukan sekadar menerima arahan.

Mereka membantu membentuk penyelesaian.

Signal kompetensi: Mereka berani berhujah tentang cara yang betul, bukan sekadar mengangguk setuju.

2. Tak Boleh Terangkan Sistem Dalam Bahasa Bisnes

Ada developer yang setiap kali bercakap, penuh dengan jargon teknikal.

Microservices.

Event-driven architecture.

Message queue.

Redis.

Containerization.

CQRS.

Semua bunyi hebat.

Tapi selepas 30 minit meeting, kau masih tak faham macam mana semua benda tu membantu bisnes kau.

Itu masalah.

Sebagai pemilik bisnes, kau tak beli teknologi.

Kau beli penyelesaian kepada masalah.

Developer yang benar-benar faham sesuatu perkara biasanya boleh menerangkannya dalam bahasa yang mudah.

Contohnya:

Daripada cakap:

"Kita implement queue worker supaya asynchronous processing lebih scalable."

Mereka akan cakap:

"Bila customer submit order, sistem tak perlu tunggu proses invoice siap dulu. Jadi website kekal laju walaupun ramai pengguna serentak."

Nampak beza?

Konsep yang sama.

Bahasa yang berbeza.

Kalau seseorang tak boleh menerangkan perkara kompleks dengan bahasa yang mudah, ada kemungkinan mereka sendiri tidak memahami perkara itu sedalam yang mereka sangkakan.

Signal kompetensi: Mereka boleh terjemahkan teknologi kepada impak bisnes.

3. "Template Developer" Bukan Software Engineer

Ini antara perangkap yang paling kerap berlaku.

Developer tunjuk portfolio yang cantik.

Banyak website.

Banyak projek.

Semua nampak kemas.

Kemudian bila kau perlukan workflow yang unik sikit, masalah mula muncul.

Mereka tahu install WordPress.

Mereka tahu pasang theme.

Mereka tahu configure/setting plugin.

Mereka tahu guna no-code tools.

Tetapi bila proses bisnes kau tak sama seperti template yang di-"beli", mereka mula tersekat.

Akhirnya apa yang berlaku?

Bukan sistem yang mengikut bisnes.

Sebaliknya bisnes dipaksa mengikut sistem.

Bila ada edge case?

Jawapan biasa:

"Plugin tu tak support."

Atau:

"Kalau nak macam tu kena cari plugin lain."

Software yang baik sepatutnya dibina mengikut cara operasi bisnes, bukan memaksa bisnes mengikut limit template.

Signal kompetensi: Mereka banyak bertanya tentang workflow (flow perjalanan) sebenar syarikat kau sebelum bercakap tentang teknologi yang akan digunakan.

4. Tiada Scope Bertulis — "Nanti Kita Adjust"

Ini nampak kecil.

Tapi kesannya boleh jadi sangat mahal.

Ramai developer suka bermula dengan ayat:

"Kita bincang dulu. Nanti jalan-jalan kita adjust."

Bunyinya fleksibel.

Realitinya, ia membuka pintu kepada satu masalah yang dipanggil scope creep.

Tanpa skop bertulis:

• Tiada siapa tahu apa yang dijanjikan
• Tiada siapa tahu apa yang tidak dijanjikan
• Timeline sentiasa berubah
• Kos sentiasa berubah

Apabila berlaku pertikaian, kedua-dua pihak akan merujuk kepada memori masing-masing.

Dan memori manusia sangat tidak boleh dipercayai.

Developer profesional biasanya akan menyediakan dokumen yang menerangkan:

• Feature yang termasuk
• Feature yang tidak termasuk
• Andaian projek
• Timeline pembangunan
• Bilangan revision
• Tanggungjawab setiap pihak

Dokumen ini bukan untuk menyusahkan proses.

Ia untuk melindungi kedua-dua pihak.

Signal kompetensi: Mereka menyediakan proposal bertulis yang jelas sebelum projek bermula.

5. Tak Pernah Bincang Security, Edge Cases Dan Failure Scenario

Ramai developer suka bercakap tentang feature.

Tak ramai suka bercakap tentang kegagalan.

Padahal sistem sebenar diuji semasa sesuatu perkara gagal berlaku.

Developer yang berpengalaman biasanya akan bertanya soalan yang kadang-kadang membuatkan pelanggan tertanya-tanya kenapa benda itu perlu difikirkan.

Contohnya:

• Apa jadi kalau pembayaran gagal separuh jalan?
• Apa jadi kalau pengguna tekan butang dua kali?
• Apa jadi kalau dua agent claim komisen untuk jualan yang sama?
• Apa jadi kalau server down semasa transaksi sedang diproses?
• Apa jadi kalau pelanggan refresh browser ketika checkout?

Soalan-soalan ini biasanya lahir daripada pengalaman.

Daripada bug.

Daripada projek yang pernah rosak.

Daripada kesilapan yang pernah berlaku.

Developer yang tidak pernah membincangkan failure scenario selalunya belum pernah melalui situasi tersebut.

Dan itu bermaksud pelanggan berpotensi menjadi eksperimen pertama mereka.

Signal kompetensi: Mereka bercakap tentang data integrity, race condition, rollback strategy dan recovery plan sebelum kau sempat bertanya.

Penutup

Memilih developer bukan sekadar mencari orang yang boleh menulis kod.

Ia tentang mencari orang yang boleh memahami operasi bisnes, mengenal pasti risiko, dan membantu membina sistem yang boleh digunakan untuk jangka panjang.

Kalau developer sentiasa setuju dengan semua benda, tak boleh bercakap dalam bahasa bisnes, bergantung sepenuhnya pada template, tiada skop bertulis, dan langsung tidak membincangkan kegagalan sistem...

Itu bukan warning sign kecil.

Itu siren kecemasan.

Kerana kos paling mahal dalam projek software bukan harga pembangunan.

Tetapi masa, peluang, dan momentum bisnes yang hilang apabila projek gagal.