Kapan boleh mengorbankan "kerapian" desain untuk menyelesaikan proyek?

Ketika mengerjakan suatu produk yang perlu dilakukan segera dan bekerja dengan baik, kapan bisa mengorbankan pemeliharaan dan "kerapian" desain untuk menyelesaikan pekerjaan dan keluar dari pintu dengan cepat? Dan sampai sejauh mana itu baik-baik saja, terutama ketika teknik yang digunakan untuk membuatnya "rapi" adalah hal baru bagi saya?

Ingatlah bahwa Anda dipekerjakan untuk mendukung bisnis. Dalam beberapa hal, perangkat lunak Anda memengaruhi garis bawah bisnis. Anda perlu menemukan keseimbangan antara solusi yang sempurna secara teknis, dan waktu untuk memasarkan produk Anda dan seberapa besar manfaat bisnis yang akan diperoleh darinya.

Dalam pengalaman saya, pengembang sering terpaku pada kekhawatiran tentang kesempurnaan teknis. Tetapi ada alasan yang sangat valid untuk mengorbankan atribut kualitas seperti pemeliharaan atau kinerja agar produk keluar lebih cepat. Itu tergantung pada bisnis dan produk. Tapi "selalu berusaha untuk desain yang sempurna" adalah pendekatan yang terlalu sederhana.

Pada akhirnya, satu-satunya hal yang penting adalah nilai bagi bisnis. Cari tahu bagaimana memaksimalkannya dalam jangka pendek dan panjang dan bertujuan untuk target itu.

Istilah "utang teknis" sangat berguna untuk membantu menginformasikan keputusan bisnis seperti ini. Pekerjaan apa pun yang tidak Anda lakukan sekarang akan menyebabkan sejumlah pekerjaan nanti. Sama seperti dengan keuangan, mengambil utang itu berisiko tetapi mungkin layak untuk dimanfaatkan jika Anda akan dapat membayar utang nanti.

Karena itu, utang teknis bukan rasio 1: 1 pada saat pengembalian. Bug lebih mahal untuk diperbaiki setelah rilis, dan dampaknya pada produktivitas di masa depan ketika berkembang dari sistem warisan yang berantakan bisa sangat memalukan. Anda bisa melihat menghabiskan dua kali lipat waktu untuk memperbaiki kesalahan Anda, atau mungkin 1.000 kali lebih banyak dari jam kerja dan sumber daya.

Tugas Anda dalam keputusan ini adalah untuk memahami konsekuensi dari potongan sudut tertentu yang Anda pertimbangkan, dan kemudian mengomunikasikan konsekuensi tersebut kepada orang-orang yang membuat keputusan bisnis. Keterampilan estimasi khusus ini mungkin membutuhkan banyak penelitian dan bekerja pada bagian Anda untuk berkembang dengan baik sekarang, tetapi itu akan sangat berharga selama karir Anda.

Ketika diterima dan konsekuensinya dipahami oleh pemilik / klien / pengguna.

Seorang tukang ledeng harus mengambil tempat pembuangan sampah untuk diperbaiki. Saya ingin menggunakan wastafel untuk sementara waktu, tetapi dia harus menagih saya untuk waktu dan bahan untuk dimasukkan ke dalam pipa sementara menggunakan selotip yang bisa pecah. Ini juga akan menunda membawa pembuangan kembali ke bengkel. Jika saya menerima tagihan tambahan dengan pengertian bahwa saya berisiko tersumbat. Butuh satu hari lebih lama untuk memperbaiki pembuangan dan penundaan yang lebih lama sebelum dia bisa mengembalikannya, itu bisa diterima.

Anda bisa tepat waktu dan sesuai anggaran sekarang, tetapi mengorbankan / mengambil risiko biaya yang lebih tinggi dalam jangka panjang. Ini bisa sulit untuk membuat orang-orang non-teknis mengerti, tetapi itulah gunanya staf penjualan.

Banyak orang menyerah dengan cara cepat ketika mempelajari sesuatu yang baru dan hanya melakukannya dengan cara yang selalu mereka lakukan. Jika ini adalah pola, kode Anda tidak hanya akan terganggu, tetapi keterampilan Anda sebagai programmer juga akan tetap terbatas.

Namun, pada akhirnya, satu-satunya perangkat lunak yang berhasil adalah yang dikirimkan.

Setelah batas waktu lunak berlalu. Dan bahkan itu adalah tingkat "OK" yang sangat rendah. Setelah tenggat waktu yang keras berlalu, tentu saja, bisa diperdebatkan. Karena itulah sifat tenggat waktu yang sulit.

Selanjutnya, ini menimbulkan hutang teknis. Untuk setiap jam / hari yang Anda habiskan untuk mengambil jalan pintas dalam mentalitas git-er-done, Anda akan dikenakan biaya kira-kira dua kali lebih banyak waktu ketika berikutnya Anda harus menyentuh proyek ini. Jika Anda harus maka yang terbaik adalah bergegas, mengirim, dan kemudian segera mulai memperbaiki semua pita bebek Anda. Kembali ke proyek mata yang diretas bertahun-tahun kemudian adalah mimpi buruk. Jika Anda tidak akan pernah menyentuhnya lagi, biarlah, tidak ada yang akan peduli. Tapi satu-satunya waktu saya meninggalkan proyek berbohong selamanya adalah ketika saya berganti pekerjaan.

Ingat juga, mengatur waktu hal-hal ini adalah pekerjaan manajer proyek. Jika Anda tergesa-gesa memenuhi tenggat waktu, itu adalah kesalahan PM. Lakukan dengan benar, lakukan sekali, dan lakukan dengan tenang dan benar. Hidup ini terlalu singkat untuk hal lain.

Semua jawaban lain yang diposting di sini bagus. Saya ingin menambahkan bahwa meskipun sebagai pengembang pada proyek ini, Anda adalah pelayan (pelindung) desain.

Jika Anda tidak membela solusi teknis yang tepat maka tidak ada orang lain yang akan saya janjikan. Anda harus selalu berdebat untuk melakukan hal-hal dengan cara yang benar untuk bos Anda dan PM harus selalu berdebat untuk tenggat waktu.

Semoga jika Anda berada di organisasi yang masuk akal kompromi akan tercapai yang membantu memenuhi tenggat waktu dan juga tidak menyimpang terlalu jauh dari desain pada saat yang sama.

Dengan itu, jangan berasumsi bahwa jika tenggat waktu PM tidak tercapai, dunia akan berakhir dan proyek akan gagal. Biasanya tidak hitam dan putih dan sebagian besar waktu tenggat waktu PM lembut dan memiliki ruang untuk penyesuaian.

Hampir setiap tenggat waktu yang pernah saya ikuti dalam jadwal PM sebagian besar adalah buatan. Mereka akan mempertahankannya dengan gigih dan berpura-pura namun karena jika PM mendorong batas waktu maka PM TERLIHAT BURUK!

Hanya karena PM terlihat buruk bukan berarti proyek telah gagal. Jika Anda memahami hal ini, Anda akan terkejut betapa banyak Anda bisa mendapatkan PM untuk ditekuk.

Mengutip klien untuk desain yang rapi. Jika kutipan itu tidak dapat diterima oleh mereka, maka masuklah ke rincian berapa biaya setiap komponen (biasanya biaya == waktu pengembangan). Biarkan mereka mengambil barang dari "a la carte" jika mereka mau. Banyak yang akan melompati waktu untuk hal-hal yang "tidak berguna" seperti pengujian dan desain. Jelaskan risiko dari pendekatan ini, tetapi jika mereka menerima risiko, maka lanjutkan seperti yang diarahkan. Jika saya hanya punya cukup uang untuk mobil clunker, maka saya akan membeli mobil clunker, bahkan jika saya tahu itu mungkin akan rusak dalam 8 bulan. Klien Anda memiliki tanggung jawab untuk menimbang risiko ini dan menerima konsekuensinya.

Satu hal yang tidak ingin Anda lakukan adalah memberi tahu klien bahwa mereka memiliki perangkat lunak yang dirancang dengan indah, ketika mereka hanya membayar (dan menerima) sepotong sampah yang belum diuji. Jika terjadi kesalahan (yang kemungkinan akan terjadi), dalam skenario pertama mereka akan terlihat buruk, tetapi dalam skenario kedua Anda akan terlihat buruk.

Tidak pernah apa - apa, tetapi kadang-kadang Anda harus berkompromi demi menyelesaikan suatu proyek. Kenyataan yang menyedihkan adalah bahwa kebanyakan pebisnis benar-benar bodoh dan lebih dari rela mengorbankan pemeliharaan untuk sesuatu saat ini. Kuncinya adalah mengetahui bagaimana mencapai keseimbangan; mungkin proyeknya tidak akan serapi mungkin, tetapi selama itu bukan kandang babi, itu adalah kompromi yang layak.

Itu sepenuhnya tergantung pada pertanyaan "Apakah Anda atau orang lain mungkin ingin mengubahnya nanti?" Jika ya, Anda harus mencoba memiliki desain "rapi", jika tidak, Anda berisiko harus membuang semuanya dan mulai lagi 6 bulan kemudian.

Tentu saja, Anda bisa mengambil kerapian terlalu jauh, tetapi umumnya sedikit kerapian akan menghemat kerja Anda nanti.