Antara perkara yang paling demotivated bagi saya apabila terlibat dalam proses pembangunan software adalah bila banyak masa terbuang dalam dalam mesyuarat progress update migguan dengan department yang lain dalam satu-satu tim itu. Jika anda seorang developer ataupun designer yang terlibat dalam projek terbabit, mesti anda boleh relate tentang apa yang saya ingin kongsi ini.

Sales & Biz Department akan ada idea mereka tersendiri dan selalunya berbeza setiap minggu, Management pula akan sentiasa bertanya bilakah kita akan ready untuk peluncuran? dan setiap orang dalam bilik meeting itu pula akan ada idea baru tentang bagaimana UI dropdown itu harus di design. Ini belum pengarah jabatan turun meeting untuk review progress. Pasti ada saja idea baru.

Developer yang betul-betul akan kod fungsi bagi software itu pula akan terkejar-kejar di antara logic mana yang perlu dibangunkan. Sebab dalam meeting tidak ada kata putus yang definitif. Hanya feature request (eyh, belum luncurkan lagi sudah ada FR?)

Masa, resources dan tenaga yang terbuang dalam meeting ini selalunya akan drag timeline projek menjadi lebih panjang sebulan dua dan akhirnya hasil akhir Software yang ingin dibangunkan akan menjadi bloated, mediocre dan sering kali bersifat asal-ada dan cukup syarat bajet projek sahaja.

Kali ini saya nak share 5 tips yang boleh bantu anda mempercepatkan pembangunan software berdasarkan pengamatan saya sebagai seorang Produk Designer yang dah dekat 4 -5 tahun jugak berkecimpung dalam bidang ini.

# Kenal pasti jumlah konklusif man-hour yang diperlukan untuk membangunkan fungsi sofware.

Di sebabkan simen konkrit yang datang dari Batching Plant akan keras sempurna dalam masa 21 hari. Kaedah Gantt Chart adalah antara metode yang sering digunakan oleh Project Manager untuk merancang tempoh masa mula dan habis kerja dalam project Building Construction. Disebabkan ada tempoh masa konklusif, dari situlah bos besar boleh lihat berapa banyak resources yang perlu disediakan untuk menyiapkan projek.

Kalau hari hujan, pekerja kontrak tak boleh tuang konkrit

Lain pula halnya dengan projek Software Development. Tak kisahlah sama ada ianya projek Mobile App, Web App mahupun software in-house. Agak sukar untuk kenal pasti jumlah akhir man-hour yang diperlukan. Selalunya anggaran tak tepat akan datang daripada feature request yang jarang diminta orang, ataupun kita sendiri tidak pernah membangunkannya. Sebab masa nak R&D dan belajar perkara baru itu mengambil masa!

Salah satu cara yang saya kerap guna untuk dapatkan semaksimum tepat man-hour yang diperlukan adalah dengan kaedah Guesstimate (Anggaran Agak-Agak).

Lain padang lain belalang. Lain team, lain estimationnya. Ikut pengalaman saya lah

Berapakah jumlah man-hour yang sesuai bagi setiap feature dan user story? Ini anda kena tanya team anda sendiri. Dapatkan purata bagi setiap satu dengan cara seperti rajah di atas.

Seterusnya, terpulang pada anda sama ada nak gunakan Gantt Chart atau kaedah yang lain seperti Agile-Scrum dan Kanban. Ikut keselesaan.

# Lakukan ekplorasi produk sehabis baik jika produk anda baru dalam pasaran.

Ini quote daripada founder Bukalapak — Achmad Zaky. Tapi dalam gambar tu adalah Steve Jobs masa muda.

Nak kata idea, semua orang ada idea. Tapi hendak execute idea tu yang paling susah. Tambahan pula idea anda itu adalah unik dan baru dalam pasaran lokal, lagilah mencabar untuk tembusi pasaran.

Tak kira sama ada anda Product Owner mahupun developer yang bekerja dalam projek terbabit. Anda kena ada rasa tanggungjawab untuk gesa semua ahli tim untuk lakukan ekplorasi produk sampai semua pihak puas hati.

Dalam soal Software Development, anda perlu keluarkan segala macam user stories yang anda hendak bangunkan dalam versi pertama software ini. Jangan terus tulis kod dahulu! Buat simulasi dengan pelbagai user story yang sudah dicatatkan. Bila betul-betul pasti, barulah tulis kod.

Ikutkan akal logikal, kalau tiada senarai user stories masakan dapat anda lukis user flow, system flow chart, bilangan man-hour dan juga anggaran harga akhir. Gagal dalam salah satu langkah ini, projek software anda sama ada akan rugi, penat dan anda akan rasa macam menghabiskan beras sahaja.

Contoh rajah userflow yang betul; sesuai untuk rujukan semua.

Ramai yang silap bila mereka hanya panggil semua orang dalam office untuk meeting, conteng-conteng sikit dekat papan putih rajah flowchart dengan harapan semua akan faham. Realitinya, developer yang akan pening kepala di kemudian hari (betul kan?)

Ada bermacam macam cara untuk kita buat eksplorasi produk ini. Antaranya adalah; Google Design Sprint, Kanvas Market Fit, Kanvas Business Model dan sebagainya. Nanti kalau ada masa kita bincangkan topik ini pula.

# Rancang dan Persetujui Cara Bekerja diantara tim.

Jikalau tim anda hanyalah diri anda dan juga kawan anda. Ini tidak lah menjadi suatu yang sukar, sebab setiap pagi sebelum mula kerja pasti anda berdua akan pekena roti canai banjir di Mamak dulu.

Tapi, kalau ada lebih dari 4–5 orang dan ada pula melibatkan pihak yang lain seperti Marketing Department ataupun orang ketiga dari syarikat yang lain. Anda perlu segera rancang dan persetujui cara bekerja.

Sebagai contoh, senaraikan siapa PIC (Person in Charge) untuk UAT, untuk Bursari/Payment dan juga untuk perolehan aset grafik (Gambar, Video). Yang paling penting, siapa pula yang perlu menjadi Gatekeeper untuk semua ini? Selalunya perlulah dilantik seorang Project Manager dari salah seorang anggota tim masing-masing.

Project Manager inilah yang akan kawal selia keluar masuk task, feature mengikut jadual kerja yang telah kita tetapkan seperti di atas tadi. Kalau pakai Gantt Chart, perlulah follow chart tersebut dengan penuh tertib. Kalau Agile-Scrum lain pula kaedahnya.

Boleh gunakan Trello untuk monitor proses kerja anda.

Walaupun dalam satu satu projek itu sudah ada Project Manager. Antara isu yang sering jadi masalah di kemudian hari apabila ada pihak ketiga yang sering kali buat FR (Feature Request). Seringkali FR ini datang daripada C-level executive macam CEO, CFO ataupun dari Uncle Venture Capitalist yang memberi modal untuk projek kita.

Di sini, kepandaian seorang Project Manager itu bersilat amat penting bagi memastikan projek berjalan mengikut garisan landasan yang betul.

# Bincang Secara Jujur Segitiga Masa-Kualiti-Kos.

Jika anda sedang membangunkan software in-house untuk syarikat anda sendiri, mungkin tips ini sudah anda sudah hadamkan sebab anda yang punya duit. Namun kalau projek itu datang daripada Client atau anda adalah seorang kontraktor, anda perlu tekankan pemahaman segitiga Masa-Kualiti-Kos ini.

Selalunya client akan mintak semua benda dengan cepat, semua nak cepat. Benda nak semalam, tapi bagitahu hari ini. Itu semua perkara biasa, kerana Client bukan seorang developer. Jadi mereka sedikit gusar sama ada anda bekerja ataupun main Twitter. Boleh jadi juga Client kurang faham effort yang perlu diolah gerak bagi membangunkan sesuatu feature itu (mereka tak tau Stack Overflow tu apa).

Untuk memudahkan pemahaman Client, anda sebagai kontraktor harus sedaya upaya menerangkan segala aspek ini dengan jujur dan tanpa ayat pemanis bibir. Selalunya saya akan keluar minum dengan Client dan bincangkan perkara ini di sana. Ia lebih mudah dan santai.

Apabila Client faham apa yang anda cuba lakukan, mudahlah anda untuk buat sebut harga yang kompetitif.

# Tetapkan expectation semua yang terlibat seawal projek bermula.

Bukan Pied Piper dalam siri HBO tu. Inilah cerita asalnya.

Paling baik, individu yang ambil inisiatif untuk tetapkan expectation adalah Product Owner itu sendiri. Selalunya Taukeh syarikat. Konflik seringkali timbul apabila Product Owner tidak tetap pendirian, sekejap nak begitu, sekejap hendak begini. Sedar sedar sudah sebulan berlalu.

Bagaimana nak tetapkan expectation untuk semua yang terlibat dalam projek ini? Jawapannya adalah dengan berterus terang dalam setiap perbincangan awal. Apa sahaja idea yang timbul harus dikongsi dengan semua anggota tim semasa awal-awal projek bermula.

Software yang terbaik adalah hasil daripada kod yang ditulis dengan ikhlas dan penuh attachment oleh seseorang developer itu. Sehinggakan kalau developer itu bersungguh-sungguh menulis kod, bila tengok codebase dah semacam tahap artisan dah. Elegan!

Begitu juga dengan design UI/UX nya. Kita boleh nampak hasil produk itu sama ada direka dengan penuh kesungguhan atau sekadar melepaskan bato’ di tangga sahaja. Cukup bulan dapat gaji. Sudahnya macam mana nak bersaing dengan inVision, Automattic, AirBnb dan Grab?

Saya fikir kita di sini kita sudah ada practice yang baik dalam proses membangunkan Software, ada banyak produk digital dalam pasaran yang piawaiannya sama taraf dengan produk antarabangsa seperti Runcloud, Supahands, HelloGold, Katsana dan Grab. Cuma, ia masih tidak equally distributed lagi. Ada rompong di sana sini.

Semoga sedikit tulisan ini dapat mengiyakan apa yang ada dalam benak fikiran anda, dan membantu anda mengorak langkah untuk bawa standard Software kita ke suatu tahap yang lebih baik.

Apa lagi, tepuk tangan sikit. Baru ada motivasi untuk menulis lagi!