“Aplikasi Anda akan selesai pada hari Selasa.” - hari Selasa yang mana ?!

10 alasan mengapa proyek Pengembangan Perangkat Lunak gagal

Jika Anda mencari tren pengembangan perangkat lunak secara daring, Anda akan menemukan persediaan informasi yang tak ada habisnya mengenai teknologi yang sedang booming dan bagaimana teknologi akan memengaruhi setiap sektor pada tahun 2020. Kami mendengar tentang semua perubahan luar biasa yang akan membuat teknologi baru mengalami mual, tetapi saya ' Saya di sini untuk mempertanyakan bagian terakhir dari kalimat sebelumnya.

"Pada tahun 2020". Bagi Anda yang tidak berbicara "insinyur perangkat lunak", itu berarti 2040.

Sebagai satu-satunya pria di Crane.ai yang tidak menulis kode, saya telah terganggu oleh masalah ini untuk waktu yang lama. Tentu saja, non-coders juga merupakan bagian dari masalah; posting ini awalnya akan menjadi sekitar 5 alasan mengapa proyek pengembangan perangkat lunak gagal, tetapi secara penuh klien saya mengubah spesifikasi di tengah proyek dan jadi sekarang akan ada sekitar 10 alasan mengapa proyek pengembangan perangkat lunak gagal.

1. Hasil yang tidak jelas (atau, insya Allah, tidak terdefinisi!)

“Aplikasi seluler? Kami membangun jembatan, apakah itu berhasil? "

Salah satu masalah terbesar yang mengganggu proyek pengembangan perangkat lunak adalah hasil yang tidak jelas. Tanpa definisi yang tepat tentang apa "produk akhir" seharusnya, sebuah proyek dijamin gagal.

Ini sangat penting sehingga sangat mungkin mengubah arah proyek itu sendiri (itulah sebabnya itu # 1 di daftar saya!). Saya sangat merekomendasikan membangun lembar spesifikasi untuk mengidentifikasi dengan lebih baik seperti apa produk itu, apa yang akan dilakukan, dan bagaimana itu akan melakukannya. Lebih lanjut tentang ini di bawah komunikasi dan harapan!

2. Memecahkan masalah yang salah.

“Kami membangun jembatan kayu baru yang terlihat jauh lebih cantik dari yang lama. Mobil? Oh, tidak, itu tidak bisa mendukung mobil. Cukup banyak yang lebih berat daripada seekor burung yang akan melanggarnya. ”

Masalah umum lainnya adalah memecahkan masalah yang salah. Ini terletak di sepanjang garis yang sama dengan hasil yang tidak didefinisikan dengan baik, namun cakupannya jauh lebih luas. Meskipun Anda dapat mengidentifikasi produk akhir Anda dengan baik dan menyelesaikan masalah lain yang dibahas di sini, jika solusi Anda tidak mengatasi masalah dengan benar maka Anda tidak berhasil dalam proyek ini.

Salah satu cara untuk mengatasi ini adalah dengan ide tambahan. Identifikasi masalah inti Anda, langkah apa yang bisa diambil untuk menyelesaikannya, dan solusi yang memungkinkan. Selanjutnya, teruskan iterasi produk melalui dengan pengguna akhir Anda - pertahankan proses peninjauan terus-menerus untuk memastikan proyek memenuhi kebutuhan pengguna Anda dengan benar, dan tetap menjadi solusi untuk masalah inti Anda.

3. Tidak cukup komunikasi.

"Kami membangun setengah jembatan, mereka membangun setengah terowongan."

Masuk pada # 3 adalah masalah inti yang melanda hampir setiap proyek, industri, dan komunikasi bisnis. Komunikasi sangat penting di setiap tingkat proyek pengembangan perangkat lunak.

Di tingkat internal, pengembang Anda perlu berkomunikasi secara efektif untuk memastikan mereka membangun alat dan saluran pipa yang terkoordinasi dan kompatibel dengan baik. Solusi umum di sini adalah menyusun spesifikasi sebelumnya untuk desain, API, dan segala rekayasa lain yang diperlukan dalam proyek Anda. Ini penting untuk menghemat ratusan jam waktu yang dapat terbuang sia-sia dalam refactoring dan restrukturisasi.

Di tingkat yang lebih tinggi, penting juga untuk berkomunikasi dengan baik dengan tim lain. Tim pemasaran, misalnya, perlu tahu apa yang layak secara teknologi sebelum menjual konsep tersebut.

Kegagalan untuk berkomunikasi pada tingkat ini dapat menyebabkan masalah yang menghancurkan proyek; produk tersebut dapat menjadi sangat terlepas dari apa yang dijual, dijanjikan, dibangun, dan dibutuhkan.

4. Tidak ada rencana atau garis waktu.

"Ya ... itu akan selesai seperti ... mungkin beberapa minggu? Tidak yakin apa yang akan kita lakukan setelah itu ... "

Terlepas dari apakah garis waktu dan rencana dipatuhi, penting untuk memilikinya. Ini memberi proyek Anda rasa struktur dan memberi Anda perkiraan kapan dan bagaimana tugas akan diselesaikan.

Tentu saja, rencana yang baik menjangkau lebih jauh. Rencana atau garis waktu yang baik juga dapat berfungsi sebagai perbatasan bersama untuk tim besar, yang memungkinkan mereka untuk beroperasi dengan cepat dan efisien dalam sprint. Jika suatu fitur gagal atau memerlukan lebih banyak waktu, maka rencana / waktu dapat disesuaikan dengan cepat, dan anggaran disesuaikan.

5. Kurangnya akuntabilitas.

"Uang berhenti ... di sana, sampai jumpa!" - Harry Truman, mungkin

Ketika kotoran mengenai kipas angin, seseorang harus siap dengan kain pel. Jika sebuah fitur gagal, harus jelas siapa yang bertanggung jawab dan langkah apa yang harus diambil untuk mencegah hal ini di masa depan.

Kedengarannya kekanak-kanakan tapi kejadian umum dalam industri pengembangan perangkat lunak adalah "menunjuk jari." Para insinyur backend akan menyalahkan insinyur frontend akan menyalahkan tim penjualan akan menyalahkan tim pemasaran akan menyalahkan kantor legal akan menyalahkan manajemen akan menyalahkan ... Proses ini adalah tidak hanya menghabiskan waktu dan menghancurkan moral, tetapi juga meninggalkan pertanyaan inti - “apa yang salah?” - terbuka dan tidak terjawab.

6. Memindahkan tiang gawang terlalu sering.

"Oke, tapi sekarang jembatan perlu juga berfungsi sebagai landasan pacu, punya 10 jalur lagi, dan bagaimana dengan taman di tengahnya?"

Sangat penting untuk melacak tujuan proyek dan memastikan mereka terpenuhi secara tepat waktu. Meskipun ada kemungkinan bahwa suatu proyek perlu diperluas atau persyaratannya telah berubah, membuat modifikasi yang sering pada "tujuan akhir" tidak hanya dapat menghancurkan moral, tetapi membuat proyek itu menjadi mustahil. Seringkali, perubahan tidak direncanakan dan memerlukan refactoring yang luas; seiring waktu, ini menyebabkan sejumlah besar waktu terbuang, dan akhirnya proyek gagal.

Apa yang tampak seperti perubahan kecil pada awalnya bisa berakhir menjadi proyek pembangunan jangka panjang.

7. Dokumentasi dan pelacakan yang tidak memadai.

"Instruksi untuk menjinakkan bom ini mengatakan untuk menarik kabel merah setelah listrik terputus, tetapi semua kabel berwarna merah dan kekuatannya seharusnya terputus 10 menit yang lalu!" - James Bond, pada apa yang akan menjadi akhir dari karirnya

Sangat bagus untuk mengikuti metodologi yang gesit dan bergerak cepat, tetapi dokumentasi selalu penting. Kode yang tidak berdokumen dapat menyebabkan hutang teknis selama bertahun-tahun dan dapat menyebabkan masalah luar biasa - "apa fungsi ini lakukan?"

Sama pentingnya untuk mendokumentasikan produk. Setiap langkah proses dari ideasi ke desain hingga pelaksanaan harus didokumentasikan dengan baik untuk memastikan bahwa proyek mudah dinavigasi untuk orang lain dan tetap di jalur. Dokumentasi yang baik dapat memudahkan pelacakan proyek - dalam sistem yang gesit, cobalah papan kanban atau sejenisnya untuk melacak tugas!

8. Persyaratan sistem yang tidak jelas.

"Apa maksudmu hanya ada 5 roti dan 2 ikan untuk 5000 orang dari kita semua ?!"

Persyaratan teknis suatu proyek mungkin sulit untuk diukur, tetapi sangat penting bagi Anda untuk melakukannya. Apa yang tampak seperti tambahan kecil dapat berubah menjadi turducken masalah, melibatkan alokasi infrastruktur tambahan dan mendefinisikan ulang seluruh sistem untuk memperkenalkan dukungan.

9. Persiapan yang buruk.

"Kami masih menerbangkan setengah kapal."

Seringkali suatu proyek menarik dan mudah dilompati; Namun, sangat penting untuk keberhasilannya untuk persiapan yang tepat untuk terjadi. Spesifikasi perlu dibuat, desain harus disusun, garis waktu harus disepakati, dan sumber daya harus dialokasikan.

Metode yang populer untuk mengelola ini pada tingkat teknis adalah Pengembangan Berbasis Tes. Sebelum menulis satu baris kode menuju proyek, rencanakan arsitektur dan apa yang perlu dicapai setiap bagian. Selanjutnya, tulis tes untuk menegaskan bahwa masing-masing bagian benar-benar melakukan apa yang dimaksudkan. Dengan cara ini, Anda memiliki kerangka kerja yang siap dengan sasaran yang ditetapkan dan dapat mengukur kemajuan pengembangan produk Anda.

10. Harapan yang tidak realistis.

"Oke, aplikasinya terlihat bagus - tetapi mengapa skema warna tidak secara otomatis berubah agar sesuai dengan kotak telepon pengguna?"

Sangat penting untuk mengelola harapan. Sering kali, klien meminta fitur yang tidak masuk akal, tidak praktis, atau mustahil. Praktik umum adalah membatasi jumlah perubahan yang dapat dibuat untuk spesifikasi dan untuk menghadirkan insinyur selama diskusi untuk menentukan apakah fitur yang diusulkan layak secara teknologi.

Mudah-mudahan, dengan menghindari 10 jebakan ini, proyek pengembangan perangkat lunak Anda berikutnya akan sukses luar biasa! Masalah apa yang Anda hadapi dalam proyek perangkat lunak Anda?

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 ketika saya berbagi cerita tentang seperti apa pengembangan perangkat lunak dan wirausaha dalam kehidupan nyata.