Saya seorang pengembang di tim beranggotakan 5 orang dan saya yakin proyek kami menuju bencana. Saya akan menjelaskan mengapa sebentar lagi, tetapi pertanyaan saya adalah: bagaimana saya harus bersikap?

Batas waktu dalam 1,5 bulan, dan saya merasa tidak peduli apa yang kami lakukan, proyek ini akan gagal. Saya berpendapat bahwa kita harus menghentikan proyek dan berhenti membuang-buang waktu, tetapi secara politis saya pikir tidak mungkin bagi manajer kita untuk melakukan itu.

Apa yang harus saya lakukan dalam kasus ini? Haruskah saya berusaha ekstra, atau haruskah saya tenang saja? Dan apa yang harus saya katakan kepada manajer?

Alasan proyek ini menuju kegagalan:

• Dengan tenggat waktu mendekati banyak fitur yang harus dimiliki belum selesai
• Aplikasi tidak stabil dan sangat sulit digunakan
• Sistem sangat berbelit-belit, kode sangat sulit dimengerti, sangat sulit diubah - Model data terlalu didorong oleh database relasional yang kompleks (100+ tabel)
• Kepemimpinan yang tidak jelas; manajer merespons informasi baru dengan perubahan besar
• Hampir tidak ada tes otomatis atau tes unit
• Sangat tergantung pada sistem lain, tetapi belum ada tes integrasi

Sebenarnya, kami benar-benar baru saja mewarisi proyek ini (bersama dengan kekacauan) sekitar 1-2 bulan yang lalu dari tim pengembang lain di bawah manajer yang sama, yang telah mengerjakannya selama beberapa bulan.

Komunikasikan kekhawatiran Anda dengan cara yang paling ringkas dan non-konfrontatif yang mungkin menaiki tangga manajemen. Ringkas risikonya, tetapi jangan memaksakan kesimpulan Anda pada risiko tersebut.

Manajemen harus selalu memiliki pilihan tentang apa yang harus dilakukan, tetapi tugas Anda adalah untuk menilai dan mengomunikasikan situasi. Gunakan email, untuk meninggalkan jejak kertas ketika ada hal-hal ke selatan.

Setelah melakukan itu, terus mengerjakan proyek dengan itikad baik.

Perlu diingat, Anda mungkin tidak tahu semua yang perlu diketahui tentang proyek, pendukungnya, dan keputusan keuangan di belakangnya. Keputusan manajemen yang tampak bodoh bagi Anda mungkin sebenarnya didasarkan pada penalaran cerdas yang tidak terlihat oleh Anda.

Menyimpan jejak kertas (misalnya buku harian, email yang disimpan, dll). Hanya sertakan fakta dan pengamatan objektif . Serahkan semua kesimpulan kepada siapa pun (jika ada) membaca apa yang telah Anda tulis.

Sebagai seorang pengembang, jika Anda tidak dipandang sebagai penghambat proyek Anda kemungkinan besar akan keluar dari masalah ini yang pasti akan terjadi. Manajer Anda mungkin tidak seberuntung itu, tetapi itu tidak relevan di sini.

Hanya pada prinsip-prinsip umum, perbarui resume Anda dan pastikan Anda sesekali bertemu dengan dev lainnya di luar perusahaan Anda. Jika Anda bukan bagian dari grup pengembang lokal, bergabunglah 2 atau 3. Dibutuhkan bertahun-tahun untuk membangun jaringan teman dan kenalan tetapi dalam jangka panjang itu layak dilakukan. Pastikan untuk melihatnya sebagai jalan 2 arah - jika Anda dapat membantu mengisi celah di perusahaan Anda dengan seseorang yang cakap, itu sama baiknya dengan seseorang yang membantu Anda menemukan pekerjaan.

Saya akan merekomendasikan Anda meluangkan sedikit waktu untuk membaca 2 buku.

Death March adalah buku kanonik yang menggambarkan gaya manajemen proyek patologis yang tersebar luas dalam pengembangan perangkat lunak. Karena kompresi jadwal, fitur mengasapi, atau salah urus, banyak proyek berakhir dalam keadaan buruk; akan membantu untuk memahami bahwa Anda tidak sendirian dan proyek Anda bukan satu-satunya jalan kematian. Penulis Edward Yourdon mengategorikan proyek-proyek jalan buntu menjadi 4 kuadran, yang masing-masing memiliki strategi mengatasi yang berbeda. Terkadang satu-satunya strategi mengatasi adalah berjalan pergi. Saya pikir buku ini akan membantu Anda mengetahui kisaran pilihan Anda dan mempersempit apa yang dapat dan tidak bisa Anda lakukan.

Disasterlement Bencana ditulis lebih untuk manajer proyek. Hal ini bertujuan untuk mencari tahu bagaimana melakukan triase terhadap proyek yang rusak: Apa yang perlu dipotong, apa yang dapat dipotong kembali, dan bagaimana cara menyampaikannya kepada pelanggan? Manajemen proyek perangkat lunak "konvensional" membawa kita ke dalam proyek-proyek yang berantakan, dan kita tidak akan luput dari masalah kita dengan menggunakan pemikiran yang sama yang membuat kita terlibat di dalamnya. Buku ini sedikit lebih sulit dibaca daripada Death March , tapi bagusuntuk dibacadi rak buku Anda.

3 strategi sederhana dan sinis untuk mempertahankan karier / kewarasan.

1. Lihat bangkai kereta dalam pembuatan - turun dari kereta: Proyek yang gagal sangat buruk untuk moral dan kecuali Anda memiliki ninja, keterampilan manajemen ke atas akan berdampak negatif pada karier Anda. Lompat sekarang jika Anda dapat melihat pendaratan lunak.

2. Jika itu tidak berhasil, teruskan kepala Anda: Orang-orang akan mulai mencari orang untuk disalahkan - jangan membuatnya mudah bagi mereka! Sementara meningkatkan kekhawatiran di rantai manajemen mungkin merupakan hal yang tepat untuk dilakukan, itu tidak efektif dan juga berisiko. Manajer Anda sendiri sepertinya tidak akan meneruskan kekhawatiran Anda dan mengabaikannya tidak hanya akan membuat Anda berdua terlihat buruk tetapi juga dapat menjadikan Anda sebagai 'pembuat onar' yaitu jenis orang yang dapat disalahkan karena merusak proyek sejak awal, dll. Ini tentu saja juga berarti menjadi profesional, meluangkan waktu Anda tetapi tidak heroik.

3. Rencanakan untuk keluar darurat pada T + 1: berikan diri Anda beberapa opsi dan lakukan dasar untuk potensi transfer internal atau eksternal sekarang. Berbicara dengan orang; tidak ada alasan untuk menunggu orang lain memutuskan apa yang harus dilakukan dengan Anda ketika pendanaan proyek dipotong atau dibanjiri oleh 'penyerbuan' yang tak terhindarkan dari orang yang bermigrasi dalam beberapa bulan.

Mohon maaf jika kedengarannya terlalu sinis tetapi jika Anda telah menyebutnya dengan benar maka tidak ada sisi negatif untuk menderita ketidaknyamanan datang kepada Anda. Menjadi profesional, optimis tetapi selalu realistis.

Apa dampak proyek yang akan segera gagal ini terhadap karier Anda di perusahaan, dan seterusnya? Dalam pengalaman saya, sekadar dikaitkan dengan proyek-proyek yang sukses bukanlah indikator keunggulan pribadi Anda.

Kualitas yang Anda tunjukkan dalam menghadapi kesulitan dan kadang-kadang apa yang tampak sebagai kegagalan tertentu, sering diperhatikan oleh atasan, lebih dari yang Anda pikirkan. Dan saya berbicara di luar manajer langsung Anda.

Saya secara pribadi telah mengalami melihat manajer langsung saya dipecat karena ketidakmampuan, dan kemudian menemukan diri saya dipromosikan ke posisinya pada hari yang sama. Tidak menyenangkan, tetapi itu menunjukkan bahwa orang-orang memperhatikan saya, dan menyukai apa yang saya lakukan.

Seringkali, kekacauan dan disorganisasi yang sama dengan proyek yang gagal, memberi Anda kesempatan untuk bersinar.

Jadi, perhatikan proyeknya seperti ini: peluang apa yang dimiliki oleh proyek yang gagal ini, agar cahaya menyinari semua kekuatan dan kualitas terbaik saya? Pelajaran apa yang saya pelajari dari pengalaman ini, yang akan membuat saya menjadi seorang profesional yang lebih baik dan orang yang lebih baik?

Pada dasarnya, jumlah pengalaman yang diambil dari kegagalan adalah apa yang mendorong kesuksesan sejati.

Catatan: Thomas Owens bertanya, hal spesifik apa yang dapat dilakukan seseorang dalam proyek seperti ini. Saya punya beberapa saran umum, yang saya gunakan sebagai pedoman pribadi dalam situasi ini. Apakah itu akan membantu proyek kesusahan untuk secara ajaib berhasil? Tidak - tetapi saya telah menemukan bahwa itu telah membantu saya untuk menjaga perspektif yang benar tentang berbagai hal, dan menemukan kesuksesan pribadi terlepas dari situasi yang buruk.

1) Fokus pada keunggulan pribadi - berusaha untuk menulis kode yang lebih baik, memenuhi standar kualitas dan fungsionalitas yang lebih tinggi.

2) Fokus pada metrik pribadi - berapa banyak kode yang Anda tulis, yang memunculkan bug selanjutnya? Kurangi rasio itu serendah mungkin. Ketika diminta untuk memberikan perkiraan untuk tugas yang diberikan kepada Anda, apakah Anda secara umum akurat, atau apakah Anda mendapati bahwa Anda terlalu banyak / terlalu banyak menyangga timeline? Ketika benar-benar ditugaskan tugas, apakah Anda memberikan umpan balik yang baik tentang perkembangan pekerjaan, termasuk memberikan pemberitahuan sebelumnya yang baik dan maju tentang masalah waktu pengiriman?

3) Fokus pada metrik tim - Ini hanya beberapa hal di luar kepala saya: Apakah anggota tim lain tertinggal karena ketergantungan pada tugas yang sedang Anda kerjakan? Apakah Anda pandai mendelegasikan atau membagi tugas / subtugas Anda kepada orang lain dalam tim? Apakah Anda merasa sulit untuk berkomunikasi dengan satu atau lebih anggota tim? Semua area yang saya kerjakan untuk memperbaiki secara teratur.

Dalam situasi seperti ini, sebagai anak tangga terendah, hanya ada begitu banyak yang dapat Anda lakukan untuk membantu proyek.

• Pastikan pekerjaan Anda bersih
• membantu mengidentifikasi bidang masalah terbesar
• Cobalah untuk memberikan jawaban, bukan hanya masalah. Sepertinya Anda sedang berusaha memperbaikinya.

Selain itu, Anda benar-benar harus menjaga nomor 1.

• Dokumentasikan semuanya
• simpan semua email, percakapan IM
• Coba dan temukan jalan keluar dari proyek jika semuanya memungkinkan

Proyek yang gagal dapat menjadi racun bagi jiwa, menyebabkan depresi, terlalu banyak bekerja, dan rendah diri.

Itu semua relatif terhadap perspektif.

Saya telah mengerjakan proyek-proyek yang mengerikan sambil duduk di seberang pria lain yang memiliki senyum di wajahnya setiap hari. Oh betapa aku ingin menampar senyum itu dari wajahnya.

Beberapa orang tidak terganggu oleh keadaan saat ini pada suatu proyek. Mereka menikmati kontribusi mereka, tugas-tugas mereka dan bekerja dalam bidang minat mereka. Sementara yang lain, memiliki reaksi negatif yang kuat terhadap keadaan saat ini. Ini semua tentang harapan yang dirasakan kita untuk pekerjaan sehari-hari kita.

Sementara Anda mungkin melakukan beberapa pekerjaan yang Anda sukai. Jelas ada unsur-unsur dalam proyek saat ini yang tidak Anda sukai.

Anda perlu mengidentifikasi apa elemen-elemen masalah itu, dan mengatasinya.

• tekanan tenggat waktu
• kontrol kualitas
• profesionalisme
• bimbingan oleh manajemen

Ada banyak tim dan perusahaan yang tidak menganggap aspek pengembangan di atas penting. Yang saya temukan adalah mereka sering memikirkan hal berikut.

• Tekanan tenggat waktu dirasakan sebagai cara untuk memotivasi orang.
• Kualitas lebih banyak biaya dan batas pengembalian.
• Profesionalisme berlaku untuk bidang bisnis lainnya.
• Manajer adalah pencatat waktu dan bukan orang yang berkontribusi pada pengembangan.

Masalah-masalah ini bukan milikmu. Itu milik mereka, dan Anda tidak boleh membuang-buang energi untuk perilaku mereka. Jika Anda bukan salah satu dari orang-orang yang tersenyum dan menikmati pekerjaannya bahkan ketika menuju ke tebing, maka Anda harus berpikir tentang menemukan tempat like mindedpengembang.

Anda akan jauh lebih bahagia.

Cobalah untuk bersikap proaktif dalam menemukan cara baru untuk mencapai kesuksesan bagi proyek. Pikirkan bagaimana Anda dapat mengusulkan beberapa alternatif. Saat ini bos Anda mungkin sedang dihajar karena proyek itu gagal, bukankah ia akan menghargai seseorang yang datang dengan solusi alih-alih masalah?

Mungkin ada cara untuk membagi fitur menjadi kiriman terhuyung? Seringkali ada tingkat "harus dimiliki", jadi lihat apakah Anda dapat memprioritaskannya dan mengelompokkannya ke dalam tonggak sejarah. Lebih baik memiliki beberapa produk di akhir timeline daripada tidak sama sekali. Atau pertimbangkan untuk membagi tim antara orang yang mengerjakan fungsionalitas baru dan orang lain yang mengerjakan stabilitas, dengan cara ini Anda dapat menunjukkan beberapa kemajuan di kedua sisi.

Jika upaya ini berhasil, Anda akan menunjukkan bahwa Anda adalah anggota tim yang dapat menemukan cara untuk berhasil, jika tidak, Anda masih akan menunjukkan bahwa Anda tidak menyerah dan akan bekerja untuk menemukan solusi.

Kedengarannya seperti kebanyakan proyek yang pernah saya jalani. Namun, ini mungkin tidak akan berakhir seburuk yang Anda kira:

1) Lakukan pekerjaan Anda. Jangan terlalu khawatir tentang keseluruhan proyek selama Anda menyelesaikan tanggung jawab Anda.

2) CYA. Jika proyek gagal dan Anda curiga manajer akan mulai menyalahkan semua orang kecuali dirinya sendiri, pastikan Anda memiliki cukup bukti bahwa Anda melakukan semua yang diminta dari Anda (lihat item 1).

3) Buat beberapa saran sopan untuk perbaikan. Jangan membunyikan lonceng peringatan, jangan menjadi malapetaka dan kesuraman, hanya bersikap sopan dan halus.

Misalnya, jika tim tidak menulis tes unit yang efektif (atau tes apa pun), tulis beberapa tes unit lebih dekat dengan apa yang ingin Anda lihat dan dengan menyebutkan bagaimana melakukannya membantu Anda memecahkan masalah tertentu, atau menghemat waktu Anda.

Apa pun akhirnya jika Anda ingin memengaruhi fokus perubahan pada langkah-langkah positif yang memiliki hasil nyata. Proyek ini mungkin tidak akan pernah menjadi pemenang, tetapi mungkin tim dapat belajar untuk yang berikutnya.

Juga:

4) Refactoring oportunistik adalah teman Anda.

1. Bekerja keras; tetapi tidak dengan mengorbankan keluarga Anda atau kesehatan Anda.
2. Catat semua keputusan desain penting; terutama karena mereka berkaitan dengan pekerjaan Anda.
3. Tetap berjejaring, dan jaga pilihan Anda tetap terbuka jika situasinya menjadi terlalu sulit atau Anda menjadi korban PHK massal.
4. Cobalah untuk tidak menganggap proyek Anda sebagai "proyek gagal". Semua orang menyukai orang yang tetap positif dan berjuang keras dalam menghadapi kesulitan. Jadi untuk selama mungkin, mencoba untuk menjadi yang orang. Pandangan, grit, dan tekad yang positif selalu baik untuk tempat kerja.
5. Jika Anda mengantisipasi proyek yang gagal, maka Anda mengantisipasi pertemuan post-mortem. Pada pertemuan post-mortem, semua orang akan dimintai pertanggungjawaban. Bersiaplah untuk mempertahankan semua kode Anda. [Catatan: Sebagai aturan umum, Anda harus selalu menulis kode bersih sehingga mudah untuk mempertahankannya nanti.] Jika Anda memiliki email atau dokumen desain yang menginspirasi keputusan Anda, maka itu lebih baik.
6. Pada pertemuan post-mortem itu, cobalah untuk tetap positif; dan hanya sajikan bukti email dan dokumen desain Anda jika penilaian, upaya, atau pengerjaan Anda dipertanyakan.

Apa yang saya temukan paling efektif adalah rekomendasi Robert L. Read tentang cara mengatasi tekanan jadwal . Inilah yang tulis Baca:

Kunci dari tekanan jadwal pertempuran adalah dengan mengubahnya menjadi tekanan waktu-ke-pasar. Cara melakukan ini untuk memberikan visibilitas ke dalam hubungan antara tenaga kerja yang tersedia dan produk. Memproduksi jujur, rinci, dan sebagian besar dari semua, dimengerti perkiraan semua tenaga kerja yang terlibat adalah cara terbaik untuk melakukan hal ini. Ini memiliki keuntungan tambahan yang memungkinkan keputusan manajemen yang baik dibuat tentang kemungkinan kompromi fungsionalitas.

Wawasan utama yang harus diperjelas oleh estimasi adalah bahwa persalinan adalah cairan yang hampir tidak dapat diatasi. Anda tidak dapat mengemas lebih banyak dalam rentang waktu lebih lama daripada mengemas lebih banyak air ke dalam wadah di atas dan di atas volume wadah itu. Dalam arti tertentu, seorang programmer tidak boleh mengatakan 'tidak', melainkan mengatakan 'Apa yang akan Anda menyerah untuk mendapatkan hal yang Anda inginkan?' Efek dari menghasilkan estimasi yang jelas adalah untuk meningkatkan rasa hormat terhadap programmer. Ini adalah bagaimana perilaku profesional lainnya. Kerja keras programmer akan terlihat. Menetapkan jadwal yang tidak realistis juga akan sangat jelas bagi semua orang. Pemrogram tidak dapat ditipu. Tidak sopan dan melemahkan semangat untuk meminta mereka melakukan sesuatu yang tidak realistis.

Ketika Anda mengatakan bahwa proyek ini "menuju kegagalan," itu didasarkan pada penilaian Anda tentang tugas-tugas apa yang perlu dilakukan dan berapa banyak upaya masing-masing dari mereka akan membutuhkan. Buat penilaian itu eksplisit , dapat dimengerti , dan terperinci . Pisahkan tugas menjadi bagian-bagian komponennya; jelaskan sedetail mungkin bagaimana waktu pengembangan akan dihabiskan.

Setelah Anda melakukannya, Anda memiliki dasar yang kuat untuk membahas masalah dengan manajemen. Kemungkinan besar, begitu Anda membagi penilaian Anda menjadi semua tugas spesifik yang perlu diselesaikan, Anda akan dapat menunjukkan bahwa pekerjaan itu membutuhkan lebih banyak waktu daripada yang Anda miliki - mungkin jauh, lebih banyak lagi.

Setelah Anda membahas jadwal terperinci ini dengan manajer Anda, bersiaplah untuk bersikap fleksibel. Manajer Anda mungkin mengatakan, "Tugas X tidak akan memakan waktu satu bulan; paling lama seminggu," atau "Tugas Y sama sekali tidak perlu, potong itu dari jadwal." Anda pasti bisa mendiskusikan titik-titik ini, tapi apa yang jauh lebih penting adalah untuk mencapai pemahaman antara Anda dan manajer Anda pada beberapa versi realistis jadwal. Dengan begitu, jika Anda tidak dialokasikan waktu untuk, katakanlah, pengujian, maka Anda memiliki arahan eksplisit untuk tidak menguji, daripada hanya kehabisan waktu "secara tak terduga". Dan sangat mungkin bahwa manajer Anda secara sah bersedia untuk secara eksplisit memotong sudut-sudut tertentu untuk mengirim tepat waktu - ada banyak kasus di mana '

Perkiraan memberi Anda substansi konkret untuk berdebat dan berdiskusi. Ini menempatkan Anda pada halaman yang sama; ini membantu Anda merasa yakin bahwa manajer Anda telah mempertimbangkan masalah Anda. Dan itu membawa Anda ke titik di mana jika manajer Anda dengan jelas meminta hal yang mustahil, itu akan menjadi bukti yang jelas bagi Anda berdua. Jika proyeknya baik dan benar-benar hancur, Anda akan membuatnya menjadi jelas, dan itu tergantung pada manajer Anda untuk memutuskan dengan tepat bagaimana dia ingin Anda menghabiskan waktu Anda.

Karena manajer Anda tahu itu mungkin akan gagal, Anda lebih baik daripada kebanyakan. Saya akan mempertimbangkan bekerja dengan manajer dan melihat apakah ada bagian / fitur aplikasi yang dapat dikecualikan.

Terlalu sering kita berpikir setiap permintaan klien adalah 'pembunuh kesepakatan' dan berusaha keras untuk menjanjikan pengiriman. Sampai seseorang bekerja dengan klien dan menyelidiki lebih dalam, Anda mungkin tidak dapat membuat keputusan ini. Jika Anda tidak dapat melakukan ini, cobalah untuk menyampaikan apa yang menurut Anda paling penting. Terkadang lebih mudah untuk meminta maaf daripada izin.

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 Nadalah bencana total, rilis N+1dapat ditoleransi, rilis N+2dan 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).}

Ada rim saran praktis (dan sebaliknya) di sini, tetapi bagi saya kunci misteri ini adalah dua hal berikut (penekanan saya):

Batas waktu adalah 1,5 bulan

dan

... kami sebenarnya baru saja mewarisi proyek ini (bersama dengan kekacauan) sekitar 1-2 bulan yang lalu dari tim pengembang lain di bawah manajer yang sama ...

Begitu....

Selamat datang di Team Patsy The Avengers

Tim sebelumnya memiliki hal-hal yang lebih baik untuk dilakukan ... daripada gagal. Dan entah bagaimana manajer setuju dengan itu. Mengubah tim yang mendekati tenggat waktu ini bukanlah langkah terbaik manajemen proyek untuk membuat, jadi ... ada apa dengan itu?

Koreksi: Tim sebelumnya diganti, ~ 3 bulan sebelum batas waktu.

-> Cari tahu bagaimana tim dev sebelumnya berhasil melarikan diri, dan lakukan itu. <-

3 bulan hampir tidak cukup waktu untuk mempercepat pada sistem seukuran ini, apalagi memperbaiki arsitekturnya, menambah tes, dan menyelesaikannya. Anda butuh lebih banyak waktu

Dan jika Anda tidak dapat melakukan itu, kecuali jika Anda benar-benar yakin bahwa proyek itu akan diperpanjang tanpa batas waktu, atau dibantu oleh peri sihir atau sesuatu, Anda tidak ingin menjadi orang terakhir yang berdiri di kiri memegang tas.

Keras? Iya. Tetapi sementara perencanaan yang buruk (setidaknya!) Oleh tim / manajer sebelumnya bukan kesalahan Anda, 'kegagalan untuk mewujudkan' akan terjadi .

Tim sebelumnya ditebus . Tim sebelumnya ditendang ke trotoar. Apa artinya itu bagimu? Ini memberitahu saya bahwa Anda adalah tim turnaround ... dan manajer Anda mengandalkan kepahlawanan Anda untuk menyelamatkan hari.

Tim 5-orang, dan 1,5 bulan lagi. Tim baru hanya memiliki proyek selama 1-2 bulan, sehingga tim baru bahkan tidak melebihi kurva belajar . Mengambil tebakan kasar pada ukuran proyek ini, bagi saya sepertinya tidak mungkin tim baru akan melewati kurva belajar bahkan jika proyek tidak memiliki masalah sama sekali.

Jadi, saya (masih) berpikir Anda telah dicurangi.

Jika itu masalahnya - dan hanya Anda yang bisa memutuskan mana yang benar, atau apa yang ingin Anda percayai - Anda tidak perlu memberi penjelasan atau permintaan maaf kepada siapa pun karena tidak terlibat dalam kecelakaan kereta ini. Anda perlu berhati-hati tentang hal itu.

Saya ragu dengan serius bahwa manajer tidak menyadari bahwa proyek ini dalam bahaya, yang berarti bahwa penjelasan yang lembut tidak akan memberi Anda apa pun selain perhatian negatif. Kecuali jika manajer Anda adalah Tuan Rogers , masa depan Anda dalam bahaya.

Tetapi selalu ingat : jangan mengambil nasihat karier dari orang asing di Internet.

Ini adalah kesempatan luar biasa untuk Anda! Mari kita ambil sudut pandang kewirausahaan dalam hal ini.

Dengan asumsi bahwa manajemen ingin proyek ini berhasil, Anda berada dalam posisi yang tepat untuk membantu mereka melakukannya. Alasan realisasi ini sangat penting adalah karena Anda harus mengembangkan keyakinan dan keyakinan bahwa tanda-tanda peringatan yang Anda lihat sebenarnya akan mengarah pada kegagalan proyek ini [1].

Ini adalah kesempatan Anda untuk melatih keterampilan penting dalam pemikiran sistematis dan komunikasi antarpribadi. Memahami dan memvisualisasikan masalah dan peluang potensial yang sedang dilewatkan sehingga Anda dapat mengembangkan strategi untuk mengomunikasikannya sejelas dan sesederhana mungkin.

Kenali peluang Anda di sini untuk meningkatkan keterampilan Anda.

[1] Membatalkan proyek sebenarnya akan berhasil. Kegagalan akan menghabiskan uang baik setelah buruk.

Apa yang bisa kau lakukan

• Perlakukan ini dalam istilah keunggulan diri Anda sendiri, itu adalah proyek "mereka", tetapi juga milik Anda, ambil kepemilikan meskipun Anda tahu itu akan gagal. Mengapa? karena a) Anda mungkin membantunya gagal sedikit, b) pada saat tantangan, di sinilah Anda paling banyak belajar c) Anda harus mengukur diri sendiri melalui metrik keunggulan Anda sendiri, melakukan yang terbaik mungkin tidak menyelamatkan proyek, tetapi Anda mungkin berakhir masih bangga dengan dirimu sendiri

• Berbicaralah dengan sesama pengembang lain dan lihat apa yang mereka pikirkan, Anda mungkin akan menemukan bahwa banyak yang memiliki frustrasi yang sama, jika dilakukan dengan hati-hati (jangan membuat orang berpikir Anda ingin memulai pemberontakan atau sesuatu) maka ini dapat membantu bukan hanya Anda tetapi yang lain juga

• Mengabaikan masalah tidak akan membuatnya hilang, berbicara tentang cara-cara bagaimana, dengan segala rintangan masih bisa menyelesaikannya, misalnya setidaknya mendapatkan beberapa yang layak harus dimiliki, atau kasus penggunaan "faktor faktor" utama yang dilakukan dengan benar, mungkin membuat ini Proyek gagal lebih menyedihkan. Bagaimana cara melakukannya? yah, beberapa ide tentang "ketika menjadi sulit akan sulit" atau "waktu putus asa membenarkan tindakan putus asa" dan klise lainnya, misalnya: penggunaan OSS secara besar-besaran, pemrograman ekstrem / metodologi gesit, hackathon akhir pekan (hanya sukarelawan, tidak memaksa orang untuk akhir pekan kerja). Ini adalah waktu di mana Anda dapat menunjukkan kepemimpinan (hati-hati jika Anda tidak berada di posisi pemimpin tim / senior) tetapi Anda dapat mengambil keuntungan ini dan menjadi mockingjay mereka, hanya membuat orang merasa bahwa mereka mungkin mendapatkan proyek ini hanya sedikit kurang gagal daripada semua orang tahu itu akan.

• Pastikan manajemen Anda tahu, tetapi sangat, sangat hati-hati, jika mereka tahu, mereka akan menghargai Anda mengatakan hal ini dengan cara yang tidak konfrontatif, tenang, jika mereka tidak, mereka akan lebih menghargainya, dan bertanya-tanya mengapa tidak ada yang memberi tahu mereka tentang hal itu sebelumnya. Anda harus memberi tahu mereka ini sebagai layanan, tanpa sisi emosional apa pun, hanya fakta sederhana, dan tanpa agenda. Jika mereka akan bertanya kepada Anda apa yang menurut Anda harus mereka lakukan (yang merupakan pertanda bagus, tetapi jarang) kemudian lihat bagian selanjutnya

Apa yang tidak bisa Anda lakukan, tetapi manajemen Anda mungkin harus melakukannya

• Mereka seharusnya tidak menambahkan lebih banyak orang ke proyek "untuk membantu" melihat ini

• Segera hubungi pelanggan dan beri tahu mereka kabar buruknya. Mengapa ini ide yang bagus? baik, saya akan meninggalkan mengutip manifesto untuk pengembangan perangkat lunak tangkas, tetapi bahkan tanpa itu, bahkan pecinta air terjun membenci kejutan buruk. Jika pelanggan tahu sebelumnya bahwa proyek ini akan gagal, mereka akan tidak bahagia, tetapi akan jauh lebih bahagia bahwa Anda memberi tahu mereka ada masalah sebelum berhembus di wajah mereka, dan bahwa Anda ada di dalamnya, dan melakukan yang terbaik untuk mengakomodasi saya t. Pelanggan dapat melakukan banyak hal tetapi kebanyakan dari mereka tidak lebih buruk daripada mencari tahu di menit-menit terakhir mereka tidak memiliki hasil pengiriman (atau mereka melakukan tetapi kualitasnya tidak dapat digunakan). Pelanggan akan menghargainya karena mereka dapat menunda mempekerjakan staf penguji, staf IT lepas pantai, mengubah rencana pelatihan internal mereka, dan semua hanya karena Anda jujur ​​pada mereka.

• dengan pelanggan, pikirkan cara-cara untuk tetap membuat sesuatu dari proyek, yang paling umum adalah menghilangkan hal-hal. misalnya mungkin ada beberapa fitur yang terlalu sulit untuk mengembangkan cara mereka dirancang, dan jika pelanggan akan menyetujui beberapa modifikasi dan penyederhanaan kecil, maka beberapa fitur akan menjadi lebih sederhana.

• Perbarui manajemen mereka yang lebih tinggi, itu akan membantu mereka menjaga pekerjaan mereka juga ...

Apa yang seharusnya TIDAK Anda lakukan

• Mintalah untuk menambahkan lebih banyak orang ke proyek (lihat ini )

• Berhenti / cari pekerjaan lain (setidaknya belum), ini adalah sesuatu yang dapat Anda pelajari, dan apa yang akan membuat Anda suatu hari menjadi pengembang yang lebih baik atau manajer yang lebih baik. Anda akan belajar menghargai banyak hal dengan lebih baik, mengelola waktu dengan lebih baik, mendesain lebih baik, menulis kode dengan lebih baik, dan bekerja dengan rekan kerja dan manajemen dengan lebih baik. Cari pekerjaan setelah 2 bulan ini selesai jika Anda tidak suka bekerja di sana, bukan karena alasan lain.

• Merengek, mengeluh, atau bersikap negatif tentang proyek, manajemen, desain buruk yang Anda warisi, para pengembang pemula yang Anda selidiki bahwa Anda perlu 3 jam untuk menjelaskan kepada mereka untuk melakukan sesuatu yang membutuhkan waktu 1 jam, bersikap positif sebanyak yang Anda bisa bisa.

• Mengkritik manajemen dan menjadi target sebagai pembuat masalah, mereka berada di kapal yang sama, dan mereka mungkin tahu hal-hal yang tidak Anda lakukan, yang dapat Anda lakukan hanyalah memperbaruinya (selalu perbarui manajer langsung Anda sendiri, jangan pernah mem-bypassnya)

• Menyalahkan orang, (atau diri Anda sendiri), itu tidak membantu, tidak pernah

• Anggap itu terlalu serius, kecuali itu adalah peralatan medis, tidak ada yang akan mati jika Anda melewati tenggat waktu, itu peranti lunak, kami melewatkan tenggat waktu untuk hidup, santai.

Itu hanya dua sen saya, YMMV

Temukan masalah yang dihadapi proyek Anda dan cobalah untuk mengukur dengan jelas sebanyak mungkin secara objektif. Dengan setiap "metrik" yang Anda ukur, pastikan Anda menentukan mengapa Anda percaya bahwa metrik ini penting. Anda ingin memberikan wawasan kepada manajer Anda tentang apa akibatnya jika metrik tertentu tidak berada dalam "rentang yang dapat diterima". Anda perlu memberikan beberapa pedoman untuk setiap metrik untuk menunjukkan nilai mana yang "Baik", "Dapat diterima", "Bermasalah" atau "Buruk". Tetapkan setiap kriteria di depan. Jika memungkinkan, Anda dapat menggambarkan apa yang dibutuhkan minimal untuk sebuah proyek agar berhasil dan membandingkannya dengan proyek saat ini.

• Kualitas Kode Statis dapat dikuantifikasi oleh banyak alat analisis statis. Anda dapat menjaga ini sesederhana atau sedetail yang Anda inginkan. Metrik yang saya sarankan Anda mulai dengan:
  • Kompleksitas Siklomatik
  • Ukuran kode Anda (mis., Nr baris per fungsi / kelas, jumlah file, jumlah tabel ...)
  • Identifikasi modul mana yang terlalu besar
  • Duplikasi.
  • Ketaatan pada gaya kode
• Tingkat cacat
  • per KLOC berdasarkan modul dan atau subsistem (identifikasi bagian-bagian sistem Anda yang bermasalah)
  • Anda dapat menghitung berapa banyak per anggota tim tetapi saya pikir Anda harus menyimpannya sendiri
  • dipecahkan vs ditemukan
  • waktu yang diperlukan untuk menyelesaikan bug (mungkin jika ini cenderung membuat grafik dari ini)
  • mungkin membuat perkiraan berapa banyak waktu yang dibutuhkan jika ini terus berjalan pada tingkat saat ini
• Perencanaan
  • Waktu ekstrapolasi yang digunakan untuk fitur yang dibangun. Mempertimbangkan kompleksitas fitur ini. Ini tidak harus sangat tepat. Apa yang ingin Anda sampaikan adalah di sepanjang garis "Fitur A, B dan C berada di sekitar kompleksitas yang sama dari D, E dan F. Dengan fitur ABC digunakan 170% jika waktu yang direncanakan. Jika tidak ada perubahan, kami mengharapkan yang sama waktu diperlukan untuk DEF "atau sepanjang baris" Fitur rata-rata membutuhkan waktu X% lebih lama dari yang dihitung. Kami tidak memiliki alasan untuk menganggap bahwa sisa fungsionalitas lebih mudah dibangun sehingga kami harus mengkompensasinya dalam perencanaan mendatang. Tidak ada gunanya memiliki perencanaan jika tidak realistis.
  • Cobalah untuk memiliki jadwal rilis bulanan atau lebih disukai bahkan lebih pendek. Kalau saja internal. Ini dapat membantu Anda lebih jauh dengan memperkirakan waktu yang Anda butuhkan untuk proyek tersebut. Ini juga bisa menyelamatkan Anda dari membuat komitmen yang tidak realistis (jika Anda tidak berkomitmen untuk pekerjaan baru sebelum rilis dilakukan). Buat perencanaan untuk setiap silinder dan pastikan fitur baru hanya masuk ke siklus berikutnya (mis. Mereka tidak pernah dapat ditambahkan ke siklus saat ini).
• Cakupan pengujian: jelaskan nilai cakupan pengujian "normal" dan perlihatkan bagaimana cakupan Anda saat ini
• Dokumentasi: Berapa% sebenarnya didokumentasikan? Seberapa bagus
• Modularitas:
  • Berbasis kelas (kopling dan kohesi)
  • Berbasis paket
  • Berbasis subsistem (ada berapa jalur komunikasi?)

Anda harus pergi bekerja dan melakukan apa yang akan Anda lakukan pada proyek apa pun, apakah itu berhasil atau tidak. Anda dibayar untuk melakukan pekerjaan Anda. Lakukan sebaik mungkin sesuai kemampuan Anda. Dengan asumsi Anda bukan manajer / pimpinan proyek, bukan tanggung jawab Anda untuk memutuskan bahwa suatu program harus dibatalkan atau tidak. Anda memutuskan untuk mengendur sama dengan Anda membuat keputusan untuk membatalkan proyek. Itu bukan bagian dari deskripsi pekerjaan Anda.

Namun, dalam gambaran yang lebih besar, itu tidak berarti bahwa Anda harus bekerja 50, 60 jam atau lebih per minggu untuk mencoba dan memenuhi jadwal. Sekali lagi, itulah tugas manajemen untuk mencari tahu bagaimana mencapai tujuan proyek. 50+ jam kerja minggu bukanlah pilihan yang masuk akal kecuali mereka bersedia membayar lembur dan Anda bersedia menunda kehidupan keluarga Anda. Sekali lagi, tugas manajemen adalah menyusun jadwal yang dapat dicapai. Mereka tidak dapat berasumsi bahwa mereka dapat memaksa karyawan untuk mengabaikan kehidupan keluarga mereka untuk memenuhi jadwal yang tidak realistis.

Juga, sementara jadwal mungkin mengatakan 1 1/2 bulan tersisa. Itu mungkin bukan tanggal "drop dead". Beberapa pelanggan mungkin mengambil apa yang Anda miliki pada tanggal itu, bahkan jika itu tidak semua. Beberapa pelanggan mungkin datang dengan dana tambahan, karena mereka sudah menghabiskan banyak uang untuk proyek ini. Terkadang perusahaan itu sendiri dapat mengambil biaya tambahan untuk memastikan pelanggan yang puas. Semua itu di luar kendali Anda. Lakukan pekerjaan Anda dengan kemampuan terbaik Anda. Itu akan memberikan opsi manajemen untuk bekerja dengan yang dapat mengubah proyek bencana menjadi kisah sukses yang hebat. Saya telah melihatnya terjadi berulang kali.

Saya hanya bisa mengulangi apa yang dikatakan orang lain, tetapi saya dengan tegas menekankan: Selalu berusaha untuk pekerjaan terbaik Anda dan menyimpan jejak kertas. untuk alasan CYA dan teknis.

Kerusakan yang terjadi tergantung pada karakter pribadi manajemen; tetapi izinkan saya memberi tahu Anda bahwa berada di ujung penerima manajemen yang tidak kompeten dan berbohong. Tetapi hal terburuk yang akan Anda tinggalkan adalah rasa hormat diri (dan teman sebaya) Anda tetap utuh.

Catat aspek teknis dari Kematian Anda dengan baik. Ketika Anda mendapatkan pertanyaan wawancara yang tak terhindarkan, apakah Anda pernah mengerjakan proyek yang gagal; mengapa itu gagal dan apa yang Anda lakukan untuk mencegahnya? Manajemen Bonehead bukanlah jawaban - bahkan jika itu alasannya.

Mungkin ini jalan keluar yang mudah untuk mengasumsikan bahwa itu adalah kegagalan yang tak terhindarkan dan sepenuhnya dan menyerah pada proyek. Sebagai konsultan, saya sering diundang untuk membantu proyek-proyek yang berada dalam berbagai tahap kemunduran, gagal atau gagal dan bagian dari apa yang saya bayar adalah menghidupkan kembali dan menyelesaikan proyek-proyek tersebut.

Apa yang Anda lihat sebagai kegagalan total, mungkin tidak dianggap oleh semua orang, tergantung pada perspektif. Dalam dunia yang ideal, setiap fitur akan lengkap, dikodekan secara elegan dan independen dari sistem lain dan setiap baris kode yang diuji. Saya belum pernah melihat satu pun, proyek yang tampak seperti itu di rev 1. Di dunia nyata, pengiriman proyek berarti mengambil beberapa kompromi, mungkin bahkan kehilangan beberapa fitur utama tetapi produk dapat dikirimkan dan meskipun itu akan menjadi kualitas beta terbaik. , setidaknya Anda akan mendapatkan umpan balik tentang hal mana yang harus diperbaiki terlebih dahulu. Kelebihan dari ini adalah bahwa hal itu dapat menginformasikan manajemen bahwa perangkat lunak tidak pernah dilakukan dan daripada mencoba mengembangkan v 1.0 tertentu dalam ruang hampa lebih baik untuk beralih dan menanggapi perubahan dengan cara yang gesit. Akhirnya bagi Anda sebagai pengembang di posisi ini, Saya pikir kuncinya adalah mengembangkan kode sebagus mungkin dalam kondisi ini - mendokumentasikannya, menulis tes sendiri, jika Anda harus (terutama untuk dependensi eksternal) dan menggunakan pengetahuan Anda tentang sistem untuk berkomunikasi fitur mana yang benar-benar penting dan harus -memiliki dan mana yang bisa menunggu seminggu atau sebulan. Jadikan diri Anda vokal tentang kekhawatiran Anda dan benarkan seperti yang Anda lakukan pada kami. Alih-alih mempersiapkan rencana B, bersiaplah untuk fakta bahwa Anda dan jiwa-jiwa miskin lainnya mungkin akan memperbaiki semua kereta dan belum menyelesaikan kode SETELAH produk dikirimkan - sebagaimana dinyatakan di atas ini berarti menulis kode Anda dengan cara modular yang dipisahkan - jika Anda berpikir bahwa kode lapisan persistensi buruk, semoga Anda dapat menggantinya sepenuhnya di revisi berikutnya. Akhirnya, jangan putus asa - berurusan dengan situasi seperti itu adalah bagian dari apa yang Anda sedang dibayar dan itu adalah proses pembelajaran. Terlepas dari hasil dalam proyek khusus ini, ini akan dianggap sebagai pengalaman berharga di masa depan.