Saya berpartisipasi dalam tiga proyek yang jelas-jelas gagal. Ini sangat menyakitkan tetapi melihat ke belakang, dua dari tiga tidak memiliki konsekuensi negatif pada karir saya, dan bahkan yang ketiga bukanlah akhir dunia.
Berikut adalah beberapa pengamatan yang saya ingat.
Pengembang di posisi junior ("kode per spek", "perbaiki bug", hal-hal seperti itu) tidak terlalu terpengaruh, kecuali jika mereka mengendur karena semangat kerja tim yang lebih rendah. Pada posisi seperti ini, strategi bertahan hidup yang masuk akal dan bahkan kadang-kadang bisa saja melakukan yang terbaik yang Anda bisa.
- Sebagai contoh, salah satu kegagalan yang saya alami telah diatasi dengan perbaikan metodis dari lebih dari seratus bug yang diketahui (ditambah dengan pendekatan yang sangat pintar dalam mempromosikan kemajuan ini oleh pimpinan teknologi) akhirnya membuat manajemen puncak mengambil keputusan untuk memulihkan proyek dan memberikan Ini kesempatan lain dengan rilis baru, yang pada gilirannya membuat kesuksesan yang masuk akal.
Programmer di posisi yang lebih senior dan berpengaruh akan lebih siap untuk berbagi konsekuensi negatif dari kegagalan proyek. Seorang arsitek, pemimpin teknologi, pengembang senior biasanya diharapkan membuat dampak yang cukup besar untuk dianggap bertanggung jawab atas keberhasilan atau kegagalan proyek.
Pada posisi senior, seseorang akan lebih siap untuk memperoleh keuntungan dari kegagalan "secara tidak langsung", dengan menganalisis apa yang salah dan apa yang bisa dilakukan dengan lebih baik.
Ini sedikit pengetahuan, pelajaran post-mortem mungkin sangat berharga jika dipelajari dengan benar, karir yang sangat sukses di posisi senior mungkin tergantung pada seberapa baik ini dipelajari, seperti dijelaskan dalam jawaban yang brilian di WP :
Penghakiman tidak datang dari kesuksesan, tetapi dari kegagalan. Sebagian besar perusahaan ingin merekrut orang yang kegagalannya dibayar oleh perusahaan sebelumnya ...
Pada catatan yang lebih praktis, seseorang dapat mempertimbangkan pendekatan "rilis berikutnya / perbarui" sebagai jalan keluar dari kegagalan. Secara kebetulan atau tidak (saya pikir tidak ), tetapi kedua kegagalan yang tidak merusak karier saya berjalan dengan skenario yang sangat mirip: rilis N
adalah bencana total, rilis N+1
dapat ditoleransi, rilis N+2
dan kemudian sukses biasa.
Berjalan di sepatu Anda, saya kemungkinan besar akan berusaha menyiapkan / mempromosikan ide "rilis berikutnya". Buat (dan komunikasikan !) Sesuatu seperti daftar sementara masalah-masalah yang diketahui yang ingin Anda perbaiki setelah rilis yang direncanakan. Buat konsep peta jalan informal dan kasar untuk rilis berikutnya.
Pikirkan bagaimana Anda dapat mengkomunikasikan ide-ide ini kepada orang-orang di sekitar Anda, bagaimana Anda dapat memengaruhi manajemen untuk mempertimbangkan rencana ini. Jika proyek memiliki seseorang dengan keterampilan pemasaran yang baik, cobalah untuk melibatkan mereka dalam mengamortisasi kerusakan akibat kegagalan dengan membungkus rilis yang akan datang menjadi lebih lancar, seperti "akses awal", "beta", "pratinjau pelanggan", "rilis pengantar", hal-hal seperti bahwa.
Pikirkan rencana cadangan untuk berjaga-jaga jika atasan akan tampak tuli terhadap ide ini. Ingat cerita di atas tentang "memperbaiki lebih dari seratus bug yang dikenal"? ada kesempatan untuk berubah, sungguh.
Manajemen mungkin tampak tuli terhadap ide-ide rilis berikutnya sekarang, tetapi ada peluang bagus bagi mereka untuk mempertimbangkan kembali di hadapan bukti kuat yang meyakinkan tentang kemajuan kualitas proyek.
- Sangat mungkin bahwa akan ada waktu yang agak lama antara kode pembekuan untuk rilis yang direncanakan dan keputusan manajemen untuk membatalkannya sepenuhnya. Waktu itu adalah kesempatan Anda: jika Anda memfokuskan upaya untuk memperbaiki masalah yang diketahui dan benar "menginjili" kemajuan, ini bisa membuat perbedaan (seperti yang pernah terjadi pada saya).