Poin Paling Penting Tidak Ada yang Memberitahu Anda Sebelum Anda Mulai Membangun Aplikasi Itu

Selama hampir 50 tahun - sejak Frederick Brooks menerbitkan klasik "The Mythical Man-Month" - tim pengembangan perangkat lunak telah berjuang dengan cara membangun proyek tepat waktu dan sesuai dengan spesifikasi. Ini bukan tugas yang mudah. Inilah yang mereka lupa untuk memberi tahu Anda sebelum Anda mulai membangun aplikasi baru itu ...

Produk akhir tidak akan terlihat seperti spesifikasi aslinya

Membangun aplikasi harus cukup sederhana. Anda duduk beberapa orang di sebuah ruangan, menyetujui beberapa spesifikasi, dan kemudian membiarkan orang-orang terpintar di ruangan itu pergi bekerja mengkode apa yang baru saja Anda diskusikan. Cukup mudah bukan? Salah. Ada kemungkinan yang sangat tinggi bahwa produk akhir tidak akan terlihat seperti spesifikasi aslinya. Ada sejumlah alasan yang sangat bagus untuk ini, dan itu tidak ada hubungannya dengan "ketidakmampuan" tim pengembangan perangkat lunak. Tenggat waktu berubah. Rencana berubah. Dalam beberapa kasus, bahkan masalah awal yang Anda coba selesaikan adalah perubahan. Faktanya, itu adalah keajaiban apa pun yang benar-benar dibangun pada akhirnya.

Semakin banyak pemangku kepentingan yang Anda miliki dalam suatu proyek, semakin berantakan hasil akhirnya

Di permukaan, ini tampaknya masuk akal untuk membatasi jumlah koki di dapur, namun Anda akan terkejut betapa banyak orang yang masuk akal mengabaikan ini. Alih-alih, ada desakan untuk melibatkan tidak hanya tim pengembangan, tetapi juga tim penjualan, tim pemasaran, dan mungkin bahkan orang di ujung lorong yang memiliki gelar yang funky dan dibuat-buat pada kartu namanya. Dan apa yang terjadi selanjutnya adalah seperti permainan telepon kuno, di mana setiap orang yang mendengar percakapan mengulanginya sedikit berbeda dengan orang berikutnya dalam rantai. Menurut apa yang sekarang dikenal sebagai Hukum Brooks (untuk menghormati Frederick Brooks), "menambahkan tenaga kerja ke proyek perangkat lunak yang terlambat membuatnya nanti."

Akan selalu ada satu bagian dari produk jadi yang tidak ada yang tahu persis apa fungsinya

Dalam skenario kasus terbaik, akan selalu ada pemetaan satu-ke-satu langsung antara semua fitur yang semula dibuat oleh tim pengembangan perangkat lunak, dan fitur-fitur terakhir yang muncul dalam aplikasi atau perangkat lunak. Tetapi inilah masalahnya - sebagian besar tim pengembangan perangkat lunak berada di bawah tekanan yang sangat besar untuk mengeluarkan proyek sehingga mereka akan berhemat pada dokumentasi tentang apa yang seharusnya dilakukan setiap baris kode. Ulangi ini cukup kali, dan itu pasti mengarah ke "fitur" yang tidak ada yang benar-benar tahu apa yang dilakukannya, atau bagaimana itu bahkan muncul di tempat pertama. (Dan apa pun yang Anda lakukan, jangan menyebutnya "bug" - itu selalu merupakan "fitur"!)

Satu orang di tim Anda akan bertugas memindahkan tiang gawang

Seperti halnya orang suka berbicara tentang "berada dalam keselarasan" (atau apa pun jargon MBA 101 terbaru), orang jarang selaras. Itu yang membuat kita menjadi manusia, bukan mesin. Dan salah satu dari orang-orang itu akan (tidak resmi, tentu saja) menunjuk dirinya sendiri sebagai orang yang bertanggung jawab memindahkan tiang gawang. Anda tahu, orang yang muncul pada pertemuan Senin pagi dan mengumumkan entah dari mana bahwa batas waktu proyek telah naik beberapa minggu, atau bahwa fitur yang lama terlupakan sekarang "kritis misi" dan harus ditambahkan segera .

**

Kesimpulan

Jadi pada saat Anda duduk bersama tim Anda dan mulai menentukan tenggat waktu dan spesifikasi untuk proyek perangkat lunak Anda berikutnya, ingatlah poin-poin ini. Mungkin hanya menghemat banyak darah, keringat, dan air mata.

Hei! Saya Tomer, seorang pengusaha, dan pembuat. Anda mungkin mengenal saya dari Mevee, Crane, Shots, Slides, dan sekarang investorintelligence.io di antara produk lain yang telah saya luncurkan! Artikel ini adalah bagian dari seri yang lebih luas yang saya tulis sebagian besar berdasarkan pengalaman saya dan terutama dibuat dari pendapat saya dan tim saya.

Saya harap ini membantu Anda untuk menghindari kesalahan yang sama yang saya lakukan, dan ingat untuk tetap mengirim!

Silakan bertepuk tangan jika Anda menemukan ini berharga, dan ikuti saya untuk lebih banyak menulis seperti ini saat saya berbagi cerita tentang seperti apa pengembangan perangkat lunak dan wirausaha dalam kehidupan nyata.