Apa cara paling produktif untuk menangani kegagalan terkait pembangunan? [Tutup]

Kita semua pernah ke sana:

• Proyek Anda gagal atau dibatalkan.
• Kode yang Anda habiskan berhari-hari bekerja ditolak oleh tim Anda.
• Pola desain yang Anda perkenalkan kepada tim menciptakan kekacauan.
• Semua orang mengabaikan ide Anda.

Pertanyaan saya adalah, apa cara paling produktif bagi seorang programmer untuk menangani kegagalan terkait pembangunan seperti ini?

Proyek Anda gagal.

Pengembangan perangkat lunak sangat rentan terhadap kegagalan proyek, dan tergantung pada tingkat keparahannya, ini paling baik ditangani oleh manajemen.

Banyak proyek telah gagal dan banyak lagi yang akan gagal, maka catatlah! Pelajari mengapa proyek Anda gagal sehingga Anda tidak membuat kesalahan yang sama lain kali. Anda belajar lebih banyak dari kegagalan Anda daripada dari kesuksesan Anda.

Hari-hari pengkodean yang Anda habiskan ditolak oleh tim Anda.

Simpan pekerjaan Anda (untuk nanti). Ada dua kemungkinan: (a) Menyebalkan, dan fakta bahwa banyak orang merespons dengan cara yang sama merupakan indikasi dari hal ini (b) Ini benar-benar karya jenius, tetapi jauh di depan apa yang digunakan atau dapat dipahami orang. Orang pada umumnya tidak menyukai apa yang tidak mereka mengerti. Mungkin lebih baik untuk menunjukkan kapan waktunya tepat ATAU di tempat yang berbeda dengan "Budaya" yang berbeda

Tidak ada yang mendengarkan ide Anda di perusahaan Anda.

Ini mungkin ide yang buruk, ATAU budaya tidak selaras dengan pemikiran Anda. Entah pindah ke tempat yang mendukung budaya Anda atau mengevaluasi kembali ide Anda secara kritis (secara objektif tanpa bias Anda sendiri) -> apakah ide saya benar-benar bagus? <- Bunuh egomu

Pola desain yang Anda perkenalkan dengan kekuatan di tim Anda membuat kekacauan.

Jujur saja, Anda sudah mencoba yang terbaik tetapi ternyata tidak seperti yang Anda rencanakan. Mungkin lebih baik untuk memulai lagi atau belajar dari kesalahan yang dibuat dalam desain sebagai tim dan bergerak maju.

Itu bukan kegagalan - itu adalah pengalaman

Anda belajar dan tumbuh dari pengalaman Anda dengan merefleksikan bagaimana perasaan mereka membuat Anda dan jika Anda menginginkan lebih dari perasaan itu.

Jika itu adalah pengalaman buruk (seperti daftar yang Anda tawarkan) maka perasaan buruk yang menyertainya mungkin adalah sesuatu yang ingin Anda hindari (dengan asumsi Anda tidak begitu berkulit tebal sehingga Anda tidak peduli dengan dampak tindakan Anda).

Secara keseluruhan, jangan terlalu terlibat dalam membandingkan diri Anda dengan orang lain, mereka mengalami banyak kesulitan dalam mengerjakan semuanya seperti Anda .

• Tetap tenang - jangan panik, itu tidak akan membuat sesuatu yang lebih baik
• Kontrol kerusakan - simpan apa yang masih bisa diselamatkan
• Belajarlah dari kesalahan Anda - melakukan hal yang salah lagi mungkin tidak akan berhasil
• Pertimbangkan awal yang baru - mulailah upaya Anda berikutnya tanpa membawa rasa kecewa dan perasaan bersalah
• Lihatlah kegagalan yang lebih besar - dibandingkan dengan penerbangan pertama Ariane 5 , kegagalan Anda dapat diabaikan
• Konsultasikan dengan psikoterapis jika Anda tidak bisa mengatasinya sendiri

Anda membangun sesuatu.

Bagi saya (saya pikir itu tidak tepat untuk semua orang), membangun sesuatu (komik, gambar, permainan kecil, apa saja) adalah seperti membangun sedikit kepercayaan diri untuk kembali ke kegagalan perjuangan. Mungkin juga cara yang baik untuk mengungkapkan kemarahan atau kepahitan Anda atau perasaan apa pun yang berhubungan dengan kegagalan, tetapi dengan cara yang "konstruktif".

Lagipula itu berhasil bagi saya.

Baiklah, Anda bertanya :) Satu per satu:

* Your project failed.

Itu bukan hal baru. Kita semua gagal secara pribadi, dan kita semua gagal dalam tampilan penuh dari rekan-rekan kita. Siapa pun yang telah menempuh pendidikan dasar dan menengah telah mengalami hal ini.

Jika saya tidak dapat membuat kesalahan dan mengharapkan pekerjaan yang stabil, Anda harus mempertimbangkan untuk mengirim memo ke HR agar mereka tahu bahwa manusia akan dilarang dari pertimbangan di masa depan.

Beberapa kegagalan berturut-turut berarti Anda memiliki tuntutan dan spesifikasi yang tidak masuk akal, atau Anda tidak belajar dari kesalahan Anda. Skenario manapun meminta tindakan segera.

Bisa dibayangkan bahwa banyak orang menandatangani sesuatu hanya untuk mendapatkan pekerjaan, kemudian mencari cara untuk mewujudkan persyaratan tersebut.

* What you have spent days coding was rejected by your team.

Yang terjadi. Seperti yang dicatat orang lain, simpanlah. Melakukannya lagi. Inilah mengapa kami menyebutnya bekerja. Saya pikir, dalam hal ini, Anda mungkin tidak melibatkan tim terlalu banyak dalam apa yang Anda lakukan.

Bisa juga persyaratan berubah kemarin, atau satu jam yang lalu. Namun ini harus menjadi pengecualian, bukan norma. Tinjauan sejawat sama brutalnya dengan membantu. Jika kode Anda terus-menerus diberhentikan sebagai 'tidak memadai' (atau semacamnya), Anda harus menghabiskan lebih banyak waktu memilih otak dan melibatkan orang lain. Saya percaya pertanyaan ini menjadi kekeliruan di sebagian besar pengaturan tim, kecuali jika 'tim' tidak bisa menggambarkan diri.

* Nobody listens to your ideas in your company.

Sekali lagi, ini membutuhkan konteks. Sudah berapa lama kamu di sana? Seberapa besar rekan peretas Anda memercayai kemampuan Anda? Sudahkah Anda mempertimbangkan bahwa ide-ide yang menghasilkan lebih banyak pekerjaan bagi banyak orang mungkin mengundang alasan APA SAJA untuk menolaknya? Saya pernah memiliki sesuatu yang diberhentikan karena IPV6 belum siap, namun menggunakan soket domain sederhana pada perangkat loopback (khusus). Orang yang menenggelamkannya tidak bisa lagi bekerja.

Juga, seberapa baik Anda mengartikulasikan diri sendiri? Bisakah Anda berteman dan memengaruhi orang?

* The design pattern you introduced with force in your team created a mess.

Karena itu mengapa kekerasan harus dihindari. Mampu berbicara bukanlah prasyarat untuk dapat mendengarkan. Tidak ada komentar lain.

Oh boy, itu banyak jika Anda benar-benar berarti semuanya terjadi pada Anda!

PERINGATAN : Dalam banyak poin di bawah ini Anda mungkin merasa seperti saya mengkritik Anda dan bahwa saya ingin membuat Anda bertanggung jawab atas kesalahan-kebahagiaan dan tidak mempertimbangkan faktor-faktor eksternal. Bukan saya. Hanya saja Anda tidak memberikan banyak perincian, dan saya hanya memberikan daftar tindakan untuk memastikan bahwa semuanya tidak berjalan salah. Saya tahu saya sendiri telah melakukan banyak kesalahan (semua orang) dan kita hanya akan menjadi lebih baik jika kita belajar darinya. Dan untuk belajar dari mereka, kita harus mulai melihatnya sebagai kesalahan sejak awal, dan menerima tanggung jawab atas kesalahan kita. Sial, terima tanggung jawab atas kesalahan yang terjadi di bagian orang lain, Anda bisa belajar dari itu juga.

Proyek Anda gagal

Tidak banyak yang dapat Anda lakukan untuk mengurangi itu sekarang.

Namun Anda dapat melakukan banyak hal untuk menghindari hal itu terjadi di masa depan. Saya sarankan mencoba meningkatkan keterampilan manajemen proyek dan waktu Anda.

Salah satu buku dengan rasio terbaik ((saran yang valid) / halaman) yang pernah saya baca tentang subjek ini, sementara mungkin bukan yang terbaik, itu adalah Rad Thomsett's Radical Project Management .

Anda tidak benar-benar menentukan apa proyek Anda gagal, tetapi saya akan menganggap kombinasi hal yang membawa ketidakseimbangan dalam biaya / waktu / qualiy segitiga biasa . Faktor yang paling penting di mata saya adalah untuk memimpin proyek dan pengembangan sambil selalu berhubungan dengan kedua aktor teknis Anda (pengembang dan penguji) tetapi juga para pemangku kepentingan Anda. Terlalu banyak proyek gagal karena tidak mendengarkan sponsor atau pemangku kepentingan dan tidak mendorong mereka untuk terlibat dalam proses.

Jika mereka tidak terlibat, Anda tidak bisa tahu apa yang mereka inginkan. Jika Anda tidak tahu apa yang mereka inginkan, Anda tidak bisa mengirimkannya. Jika Anda tidak mengirimkannya, mereka tidak akan senang. Itu gagal. Selain itu, jika Anda tidak melibatkan pemangku kepentingan Anda, mereka terputus dari realitas rekayasa perangkat lunak, yang berarti mereka tidak memahami masalah Anda. Jika mereka sering berhubungan dengan Anda, mereka mendapatkan pemahaman yang lebih baik tentang apa yang harus Anda tangani. Mereka akan lebih bisa memahami ketika Anda memberi tahu mereka bahwa fitur [tawa] "kecil" akan memakan waktu berbulan-bulan. Mereka dapat mempercayai perencanaan Anda dengan lebih baik karena mereka membantu membangunnya. Sebuah proyek tidak dapat berhasil hanya dengan "spesifikasi di awal, dev, pengujian, pengiriman di akhir". Itu tidak pernah terjadi. Anda dapat memberikan apa yang diminta dalam spesifikasi,

Yang paling penting juga, lakukan retrospektif , dan pastikan itu tanpa ego dan bukan permainan menyalahkan. Identifikasi saja masalah.

Pengodean yang Anda habiskan selama berhari-hari ditolak oleh tim Anda

Saya sudah dalam situasi itu. Sekali lagi, tidak banyak yang dapat Anda lakukan untuk mengurangi itu kecuali:

• Simpan di SCM untuk nanti.
• Mungkin mencoba untuk mendorong potongan-potongan kecil secara progresif ke basis kode utama alih-alih refactoring besar.

Tetapi ada beberapa hal lagi yang dapat Anda lakukan untuk mencegah situasi seperti ini:

• Kenapa ini terjadi? Apa alasan penolakan itu?
• Sebagian besar waktu ketika saya melihat ini terjadi (dan itu juga terjadi pada saya), itu berarti pengembang menjadi solo atau dalam mode pengodean cow-boy dan menghasilkan hal-hal yang tidak pernah diminta. Kode yang tidak berasal dari persyaratan bisnis mungkin mewah dan "lebih baik", tetapi seringkali membuang-buang waktu dan uang. Plus, akan lebih mahal jika Anda mengintegrasikannya karena akan perlu pengujian lagi. Berpikirlah seperti orang-orang yang memberi Anda uang: Anda harus efisien pada tingkat itu juga.
• Apakah kualitas perangkat lunak yang dihasilkan memuaskan? Apakah itu mematuhi standar dan konvensi dalam kegiatan di perusahaan Anda?
• Apakah Anda secara berkala (dan sering!) Melaporkan kepada manajer langsung tentang hal ini? Apakah Anda sesekali bertukar dengan pengembang tim lainnya? Jika tidak, mereka tidak tahu apa-apa tentang itu, itu akan menjadi biaya waktu yang sangat besar bagi mereka untuk menilai dan memeriksanya sekarang. Ini TIDAK memperhitungkan waktu yang sama pada akhirnya. Ini seperti selalu mencoba menunda membersihkan apartemen sewaan Anda dan kemudian mencoba untuk membersihkannya hanya ketika Anda pindah: Ini adalah pekerjaan yang buruk, melelahkan, lebih sulit daripada seharusnya jika dilakukan secara teratur, dan seringkali tidak akan dilakukan Baik.
• Apakah Anda menghasilkan tes produksi? Tes unit? Tes integrasi?
• Apakah kode Anda diperiksa ke dalam SCM secara teratur? Apakah itu di cabang yang berbeda? Apakah perlu cabang lain atau mungkinkah dilakukan di bagasi? Menunda kode komitmen biasanya merupakan pertanda buruk. Jelas kadang-kadang Anda tergoda untuk melakukannya, tetapi Anda hanya menembak diri sendiri.

Tidak ada yang mendengarkan ide Anda di perusahaan Anda

Ada 2 opsi di sini, dan kita akan melihat keduanya:

• Ide Anda buruk.
• Ide Anda bagus.

Mari kita mulai dengan menganggap mereka buruk (sekali lagi, merefleksikan diri sendiri tentang itu dan menerima ide Anda benar-benar buruk mungkin sulit, saya tahu). Apa yang Anda lakukan untuk mengubahnya?

• Mengapa Anda datang dengan ide itu? Apa alasannya ? Apakah ada kebutuhan nyata atas apa yang coba dibawa oleh ide Anda ke meja?
• Bagaimana Anda mendapat ide itu? Apakah Anda melakukannya sendiri? Apakah Anda berbagi? Brainstorm? Rencana? Prototipe? (lakukan ini dalam urutan yang benar. Jika gagal di jalan, maka buang idenya, jangan teruskan. Atau setidaknya tidak pada jadwal kerja Anda.)

Gagasan hanyalah gagasan. Jika Anda hanya menyarankan mereka sebagai ide dan mereka ditolak, saya tidak melihat mengapa Anda akan merasa sedih karenanya. Namun jika Anda bertindak atas mereka tanpa memberitahu siapa pun dan MAKA hanya mengirimkan ide-ide Anda dan mereka ditolak, jelas saya merasakan frustrasi pada saat itu sia-sia. Dan manajer Anda melakukannya!

Anggap ide Anda bagus:

• Apakah presentasimu bagus?
• Apakah cara Anda menyampaikan presentasi itu baik? (Saya seorang pengembang, saya tahu apa yang saya bicarakan: Kami PITA yang pemarah, sombong , dan bertele-tele yang selalu benar dan dengan siapa sulit untuk bekerja sama karena sering kali ego kita yang tidak proporsional ).
• Apakah Anda memiliki rencana untuk mengimplementasikannya? Apakah Anda memikirkan biaya dan waktu? Apakah Anda memikirkan manfaatnya bagi pengguna / pelanggan? Apakah Anda memikirkan dampaknya terhadap penjualan? Apakah Anda berpikir bagaimana mengerjakan ide itu dapat memengaruhi proyek dan prioritas lain? Anda akan memberi tahu saya, "mengapa saya harus melakukan semua ini, mereka adalah pekerjaan manajer saya dan tim pemasaran atau penjualan ?!" Kecuali saat ini, Anda mencoba melakukan sebagian dari semua pekerjaan mereka.

Pola desain yang Anda perkenalkan dengan kekuatan di tim Anda membuat kekacauan

• Mengapa Anda memperkenalkan polanya?
• Jika itu membuat kekacauan, maka kemungkinan itu salah:
  • bukan pola yang tepat,
  • tidak diterapkan dengan benar,
  • tidak terintegrasi dengan benar.
• Bagaimana Anda memperkenalkannya? Bagaimana tepatnya Anda mendefinisikan negara "berantakan"?
  • kode yang kurang mudah dibaca?
  • kurang bisa dirawat?
  • membangun rusak?
  • Ada berbagai jenis "kekacauan". Mengetahui apa kekacauan itu mungkin membantu untuk mengetahui apa kegagalan di sana, dan apakah itu kesalahan pola desain.

Juga, saya sedikit terkejut dengan pendekatan itu sendiri. Anda harus benar-benar mendorong untuk pola desain yang akan diperkenalkan? Itu agak aneh. Sebuah pola sudah ada di sana, atau Anda perlu memperbaiki bagian dari solusi Anda sesuai dengan pola tersebut. Anda tidak mendorongnya seperti Anda akan mengadopsi kerangka kerja atau teknologi (seperti orang - orang mendorong sangat keras untuk memiliki XML di mana-mana, dan sekarang seperti orang-orang mulai mendorong untuk dapat menulis HTML5 pada sampul produk mereka dalam huruf-huruf besar yang terang).

Mengapa Anda harus mendorong? Mengapa ada perlawanan? Mungkin itu dibenarkan.

Apakah Anda dapat memberikan contoh bahwa pola tertentu ini akan membantu meningkatkan basis kode Anda secara signifikan (misalnya, dengan mencocokkannya dengan contoh Refactoring ke Pola ).

Catatan yang sepenuhnya di luar topik, tetapi itulah yang pertama kali saya pikirkan ketika saya membaca judul pertanyaan ketika saya pikir itu merujuk pada kegagalan perangkat lunak ... Saya memiliki perangkat lunak yang mengimplementasikan kelas BlackHole untuk mengelola jenis pengecualian yang sangat khusus di salah satu komponen. Ini mungkin terlihat seperti (dan benar-benar) peretasan yang jelas-jelas aneh dan kotor, tetapi penamaannya sendiri sangat luar biasa, kami semua menghargainya karena cara yang cukup keren untuk menangani kegagalan! :)

Langkah 1: Tidak apa-apa untuk marah!

Pertama, bisa dimengerti untuk marah atau marah ketika menemui kegagalan. Jika memberi nasihat kepada seseorang dalam situasi seperti itu, kemungkinan besar mereka tidak akan mau mendengar "Lupakan saja dan lanjutkan" atau "Anggap saja itu sebagai kesempatan belajar".

Sebenarnya, saya pikir sehat dan produktif bisa membuat Anda marah dan melampiaskan rasa frustrasi Anda, asalkan Anda melakukannya secara pribadi atau dengan seorang teman. Orang-orang memiliki cara yang berbeda untuk melakukan itu, tetapi saya pikir salah satu cara yang paling produktif adalah menulis surat palsu yang marah (Penting! Jangan mengirim surat ini kepada siapa pun ). Jelaskan perasaan Anda, seperti mengapa Anda merasa bahwa apa pun yang terjadi tidak dapat dibenarkan.

Langkah 2: Luangkan waktu untuk menenangkan diri.

Pastikan Anda telah mengungkapkan semua yang Anda rasakan, dan setelah melampiaskan kemarahan Anda, luangkan waktu untuk menenangkan diri. Mungkin Anda hanya perlu beberapa menit, atau mungkin beberapa jam.

Langkah 3: Tinjau apa yang terjadi pada langkah 1

Pada titik ini semoga Anda dapat berpikir lebih objektif tentang situasi ini. Jika Anda menulis surat, bacalah untuk diri sendiri. Jika Anda curhat pada seseorang, cobalah untuk mengingat apa yang Anda katakan. Jika Anda hanya membayangkan berteriak pada seseorang, maka tinjau saja secara mental.

Saya sering menulis surat ketika saya marah dan kemudian setelah saya tenang saya akan berusaha memperbaiki surat itu untuk lebih jelas mengomunikasikan apa yang awalnya saya coba katakan sampai saya puas bahwa seseorang yang membacanya akan mengerti apa saya perasaan pada saat itu.

Intinya adalah mencoba secara objektif untuk memilih poin Anda. Apakah itu masuk akal? Mungkin mereka membutuhkan klarifikasi atau perincian lebih lanjut. Apakah mereka tidak berdasar? Jika Anda secara objektif menempatkan diri pada posisi orang lain, akankah Anda memahami poin yang Anda buat? Apakah Anda setuju dengan poin-poin itu? Anda dapat menggunakan kesempatan ini untuk mengevaluasi diri Anda sendiri. Apa yang kamu lakukan dengan baik? Apa saja hal yang dapat Anda lakukan dengan lebih baik?

Langkah 4: Tentukan tindakan yang akan diambil

Adakah sesuatu yang dapat dilakukan untuk memperbaiki situasi atau setidaknya untuk memperbaikinya? Luangkan waktu sejenak untuk mempertimbangkan apakah ada yang realistis yang dapat dilakukan untuk memperbaiki atau memperbaiki situasi. Seringkali tidak ada, tetapi terkadang ada.

Jika Anda salah karena sesuatu, maka itu mungkin sesederhana permintaan maaf formal kepada seseorang, dengan jelas menjelaskan apa yang salah, apa yang Anda lakukan, mengapa Anda melakukannya, dan apa yang akan Anda lakukan untuk memperbaikinya atau mencegahnya terjadi di masa depan.

Selanjutnya, pertimbangkan apa yang dapat Anda lakukan untuk meningkatkan masa depan. Apa yang dapat Anda lakukan untuk mencegah hal yang sama terjadi lagi? Putuskan apa yang ingin Anda capai dan gunakan apa yang telah Anda pelajari dari langkah 3 untuk membuat rencana untuk diri sendiri.

Jika semuanya gagal, cobalah me-reboot:

        try
        {
            // ...
        }
        catch (OhNoes111Exception)
        {
            // reboot fixes everything!
            System.Diagnostics.Process.Start("ShutDown", "/r");
        }