Langsung ke konten utama

Pembuatan Software Pasti Mengalami Keterlambatan!!!




Yes, Anda tidak salah membaca judul atau mendengar. Saya yakin ketika Anda membuat project secara pribadi ataupun untuk orang lain, client, dan team internal pasti mengalami keterlambatan.


Selama menjadi software engineer, saya masih mencari tau alasan mengapa pembuatan software menjadi terlambat. 


Oh mungkin karena teamnya kurang kompeten, 

Oh munkin timelinenya kurang panjang, 

Oh mungkin permintaan yang berubah-rubah di tengah jalan, 

Oh mungkin standarisasinya yang kurang baik di terapkan, 

Oh mungkin dari awal permintaannya kurang jelas, 

dan masih banyak lagi...

Sebab musabab diatas hanyalah sedikit dari banyak sebab yang sering saya dengar atau bahkan yang saya ikut terjun didalamnnya. Tapi apakah pembuatan software ngak bisa ontime? jawabannya Bisa, ujar seorang software engineer yang di anggap senior, dan di kenyataannya tidak sesimple kalimat Bisa.


Kalimat Bisa sering saya dapatkan ketika client yang minta dan software engineer yang jawab atau jika tim sales yang bilang dan team PM yang mengamini. 


Oke, tapikan base codenya sudah ada?


Ya, monggo fakta di lapangan meski ada base code tetap saja anda harus melakukan penyesuaian sesuai permintaan user, faktannya tetap saja implmentasinya tidak mudah perlu training end user, faktanya tetap saja harus menjawab issue bug fix dari base code yang sudah ada. Dan masih banyak fakta lainnya.


Sampai akhirnya saya menemukan Hofstadter’s Law, 



 It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Pembuatan aplikasi atau software adalah pekerjaan yang kompleks dan penuh ketidak pastian, dan manusia sulit memperkirakan (estimasi) waktu yang dibutuhkan untuk mengerjakan hal yang tidak pasti bahkan ketika sudah di tambahkan ekstra waktu sekalipun. 


Jadi kalo begitu pendekan saja waktunya? Jika semuanya sudah pasti telat. Jawabanya tidak semudah itu. Memendekan waktu hanya berakibat burnoutnya team Anda. Dan Anda sendiri tidak mau kehilangan tim Anda di banding software yang akan Anda bangun.


Jika tidak bisa bagaimana jika nambah tim? Menambah tim hanya memperkeruh suasana menambah tim akan menambah kompleksitas managerial. Anda tidak ingin membuang waktu berharga anda hanya untuk membagi tugas ke banyak team. Anda juga tidak ingin mendengar alasan "Saya butuh mereview kembali code basenya, saya butuh mereview kembali dokumentasi dan seterusnya."


Jika memang tidak bisa juga kita MVP aja deh, MVP yang Anda maksud adalah mengerjakan seluruh fitur kecuali fitur yang masih negosiasikan? problemnya tidak semua fitur bisa di negosiasikan. Problemnya tech stack yang Anda minta microservices. Problemnya Anda tidak mau end user memiliki pengalaman jelek karena pake webview, dan lain-lain




Hukum Hofstadter mengajarkan kerendahan hati dalam perencanaan (untuk anda PM, PO, Tech Lead, Client atau Project personal Anda, dan lain-lain). Kita tidak bisa memprediksi masa depan dengan sempurna. Fokuslah pada memecah masalah, menggunakan data, membangun buffer, bekerja secara iteratif, berkomunikasi secara terbuka, dan terus belajar dari pengalaman untuk mengelola ketidakpastian tersebut sebaik mungkin.

Saya mempunyai ide, dengan pengelolaan tim yang baik dan standarisasi pembuatan software yang di patuhi akan meminimalisir keterlambatan. Bayangkan jika software yang Anda bangun adalah sebuah rumah yang memiliki konstrusi bangunan yang unik. Saking uniknya Anda sendiri mempersiapkan dengan matang segala proses dan standarisasi bangunannya, sehingga hilir mudik seseorang dapat dengan mudah dilakukan dan setiap orang terpantau progressnya secara realtime. 


Terus bedanya dengan nambah tim apa? perbedaannya Anda tidak punya beban dengan tim yang mengerjakan. Anda sudah tau takaran dari masing-masing pekerjaan, pemantauan secara realtime membuat anda dapat mengambil keputusan.


Terus ditambah dengan AI, Anda bisa memanfaatkannya untuk tim Anda untuk memecahkan masalah kompleks tersebut. Jangan pelit-pelit sama tim :), Anda sudah tau software yang dibangun kompleks tapi minta harga murah :P




 

Label:

Komentar

Posting Komentar

Postingan populer dari blog ini

Factory Method: Problem -> Solution -> Results 🚀

  Factory Method: Problem -> Solution -> Results 🚀 Alright, let's dive into this pattern.   The Problem 🤔 Imagine you're building an app, maybe a game where players can choose different types of characters (like Warriors, Mages, Archers). At first, you might just create them directly wherever you need them, like: // Somewhere in your game logic... Character player1 = new Warrior(); Character player2 = new Mage(); This works fine for a small game. But what happens when you add tons of character types? Or maybe the way you create characters gets super complex, needing specific stats or items? Your main code gets cluttered with all this character creation logic. Even worse, if you decide to change how a Warrior is created (maybe they need a specific starting weapon now), you have to hunt down every single place you created a Warrior and change it. Major headache! 😩 It makes your code rigid and hard to update. You're basically locked into the specific classes you...
Posting Komentar
Baca selengkapnya

Laravel Best Practices: The Pragmatic Guide

  Laravel Best Practices: The Pragmatic Guide Mengapa Best Practices Penting dalam Pengembangan Laravel? Dalam dunia pengembangan web yang serba cepat, kita sebagai developer Laravel sering terjebak dalam siklus "yang penting jadi". Aplikasi berjalan? Check. Fitur berfungsi? Check. Tapi tunggu dulu—bagaimana dengan kualitas kode, maintainability, dan skalabilitas jangka panjang? Laravel memang menawarkan ekosistem yang elegan, tetapi tanpa penerapan best practices, kita bisa berakhir dengan "utang teknis" yang menumpuk. Mari kita bahas panduan pragmatis yang akan mengubah cara Anda mengembangkan aplikasi Laravel. Prinsip Single Responsibility Salah satu kesalahan umum yang sering terjadi adalah membuat "Fat Controller"—controller yang melakukan terlalu banyak hal. Controller seharusnya hanya bertanggung jawab untuk mengkoordinasikan permintaan , bukan menangani logika bisnis. Bandingkan kode berikut: // Cara yang kurang baik public function store(Re...
Posting Komentar
Baca selengkapnya