Bos saya memutuskan untuk menambahkan bidang "orang yang disalahkan" ke setiap laporan bug. Bagaimana saya bisa meyakinkannya bahwa itu adalah ide yang buruk?

Dalam salah satu gerakan "WTF" terbaru, bos saya memutuskan bahwa menambahkan bidang "Person To Blame" ke templat pelacakan kutu kami akan meningkatkan akuntabilitas (meskipun kami sudah memiliki cara untuk mengikat kutu pada fitur / cerita). Argumen saya bahwa ini akan mengurangi moral, meningkatkan jari-menunjuk dan tidak akan menjelaskan fitur yang hilang / disalahpahami dilaporkan sebagai bug yang tidak pernah terjadi.

Apa argumen kuat lain yang menentang praktik ini yang bisa saya gunakan? Apakah ada tulisan tentang topik ini yang bisa saya bagikan dengan tim dan bos?

Beri tahu mereka ini hanya nama amatir untuk bidang Root Cause yang digunakan oleh para profesional (ketika pelacak isu tidak memiliki bidang khusus, orang dapat menggunakan komentar untuk itu).

Mencari web untuk sesuatu seperti analisis software bug akar penyebab , ada banyak sumber daya untuk membenarkan alasan ini ^{1 , 2 , 3 , 4 , ...} .

... akar penyebab cacat tidak selalu merupakan pengembang tunggal (yang merupakan titik utama bidang ini) ...

Itulah sebabnya "akar penyebab" adalah profesional sementara "orang yang disalahkan" adalah amatir. Pertanggungjawaban pribadi itu bagus, tetapi ada kasus-kasus ketika itu hanya terletak "di luar" dari tim dev.

Memberitahu atasan Anda ketika ada adalah satu pengembang untuk menyalahkan, akar penyebab lapangan pasti akan menutupi bahwa ( "kesalahan coding yang dibuat oleh Bob di komit 1234, terjawab oleh Jim dalam tinjauan 567" ). Inti dari menggunakan akar penyebab adalah untuk mencakup kasus-kasus seperti itu, bersama dengan kasus-kasus yang keluar dari ruang lingkup tim dev.

^{Misalnya, jika bug disebabkan oleh perangkat keras yang salah (dengan orang yang disalahkan sebagai seseorang di luar tim yang membeli dan mengujinya), bidang akar penyebab memungkinkan untuk meliputnya, sementara "pengembang tunggal yang harus disalahkan" hanya akan memecah yang pelacakan masalah aliran.}

^{Hal yang sama berlaku untuk bug lain yang disebabkan oleh seseorang di luar tim pengembang - kesalahan penguji, perubahan persyaratan, dan keputusan manajemen. Katakanlah, jika manajemen memutuskan untuk tidak berinvestasi pada perangkat pemulihan bencana, "menyalahkan pengembang tunggal" untuk pemadaman listrik di pusat data tidak akan masuk akal.}

Kemungkinan hasil lain untuk kebijakan semacam itu adalah bahwa orang tidak akan melaporkan bug jika mereka pikir mereka mungkin adalah "orang yang harus disalahkan", jadi itu sebenarnya akan mengurangi jumlah bug yang dilaporkan oleh tim.

Argumen utama yang akan saya gunakan untuk menentangnya adalah untuk menanyakan masalah apa yang dia coba selesaikan. Hampir pasti ada cara yang lebih baik untuk menyelesaikan masalah yang sama.

Untuk satu hal, apakah hanya ada satu orang yang bisa disalahkan? Jika ada, Anda melakukan sesuatu yang salah. Proses yang baik membutuhkan pekerjaan melalui analis, programmer, reviewer dan tester sebelum sampai pada produksi. Jika Anda tidak melakukan semua tahapan ini, mungkin itulah solusi untuk masalah yang sedang dipecahkan atasan Anda. Jika Anda lalu yang mana yang harus disalahkan? Mungkin bukan mereka, bisa jadi kode warisan yang harus disalahkan.

Tidak ada gunanya membuat orang kembali menggigit dan menunjuk jari, berusaha menghindari tanda hitam yang tidak akan hilang begitu diatur. Itu tidak memecahkan apa pun. Sangat sedikit orang yang lalai. Anda perlu melakukan retrospektif yang tepat , melihat apa yang salah dan apa yang dapat Anda lakukan untuk memastikan itu tidak salah lagi.

Dari situ Anda akan melihat dengan jelas apakah satu orang secara salah dan itu mungkin merupakan masalah yang berbeda untuk dihadapi.

Trik untuk menghentikan seorang manajer menetapkan penciptaan akuntabilitas adalah dengan menawarkannya secara bebas , tetapi dengan cara yang benar-benar masuk akal bagi Anda.

Setidaknya ada tiga masalah dengan bidang itu.

Yang pertama adalah bahwa menyalahkan orang tidak baik untuk moral. Baik. Tapi mungkin dia tidak peduli dengan moral dan ingin memecat pengembang yang buruk. Sulit dibantah.

Yang kedua adalah bahwa memperbaiki bidang itu akan sulit dan waktu yang cukup lama. Ini lebih kompleks daripada hanya mencari tahu siapa yang menulis kode buruk. Dan setiap informasi yang berpotensi sulit dipecahkan dapat dikantongi / ditipu. Tapi mungkin dia siap membayar biaya itu dan mengaudit informasinya. Baik.

Masalah yang lebih mendasar adalah bahwa bidang ini tidak akan menjadi metrik yang baik untuk mengambil tindakan. Tentu, dia akan memiliki peringkat bagus yang kode-nya menyebabkan cacat paling banyak. Tapi coba tebak siapa yang akan berada di atas daftar itu? Mungkin pendiri perusahaan, atau mungkin pengembang teratas yang memiliki tingkat cacat sangat rendah tetapi sangat produktif sehingga dia menulis bagian kode yang tidak proporsional. Jadi dia akhirnya akan memecat pengembang terbaiknya, atau membuatnya sangat lambat sehingga dia bukan pengembang terbaiknya lagi. Dan mereka yang menulis satu baris kode sebulan - lebih disukai komentar - mungkin akan mendapat hadiah karena angka cacatnya yang rendah.

Namun kegagalan metrik perangkat lunak lain.

Penyebab utama cacat cacat tidak pernah satu orang. Orang yang benar-benar teliti akan membuat kesalahan, dan proses yang mengharapkan mereka sempurna tidak masuk akal. Jika Anda tidak memverifikasi perubahan pada sistem produksi sebelum penyebaran, baik secara manual atau melalui pengujian otomatis, maka bug tidak dapat dihindari.

Salah:

Bob lupa memeriksa input dan program macet membagi dengan nol.

Baik:

Kode rentan terhadap kesalahan pembagian dengan nol tidak terdeteksi sebelum penerapan. Kasus uji baru telah ditambahkan untuk memverifikasi penanganan input yang tidak valid dengan benar. Kode diperbaiki dan semua kasus uji baru lulus.

Ubah "Orang yang disalahkan" menjadi "Orang yang dipuji"

Orang utama yang memperbaiki bug mendapatkan namanya.

Jawaban sederhana

Kolom "Blame" akan digunakan hanya untuk pengkambinghitaman dan penentuan jari, semangat akan menurun, kepercayaan tim akan hancur dan semua orang akan berusaha menemukan cara untuk membuktikan bahwa ada sesuatu yang bukan kesalahan mereka alih-alih memperbaikinya. Orang juga akan lebih cenderung diam tentang bug daripada melaporkannya, karena mereka tidak ingin kolega mendapat masalah. Ini sepenuhnya kontra produktif.

Apa yang lebih penting, mengorbankan seseorang karena membuat kesalahan jujur, atau menyelesaikan masalah secepat mungkin?

Bos Anda tampaknya menganggap serangga adalah tanda kemalasan atau kecerobohan. Mereka tidak. Itu adalah fakta kehidupan. Berapa banyak tambalan yang dikeluarkan Microsoft dalam setahun?

Jika Anda siap untuk sedikit pembangkangan sipil, mintalah tim untuk setuju untuk menempatkan daftar semua pengembang di bidang itu untuk setiap bug. Jika itu tidak sesuai, tulis "Saya Spartacus!" sebagai gantinya. Intinya, tentu saja, Anda semua bertanggung jawab atas semua bug, dan Anda tidak senang harus menunjukkan individu yang membuat satu bug.

Pilihan lain: bermain bersama. Jangan melakukan sesuatu yang khusus - lakukan saja pekerjaan yang baik dan isi bidang ini seakurat mungkin selama beberapa bulan. Kemudian jelaskan kepada bos bahwa menuduh setiap bug membuat semua orang di tim tidak bahagia dan tidak nyaman. Katakan padanya bahwa Anda semua merasa ada sedikit korelasi antara bug yang dibuat dan yang lainnya (keterampilan, usaha, kewarasan). (Ini akan membantu jika Anda dapat menjalankan beberapa angka yang menunjukkan bahwa sebenarnya tidak ada korelasi.)

Gandhian Civil Disobedience: Taruh nama Anda di setiap bidang (kecuali pengembang lain meningkatkan dan menyebutkan nama mereka untuk bug mereka), dan menerima kesalahan untuk setiap bug apakah itu milik Anda atau tidak. Tidak ada yang akan membuat bidang itu atau gagasan menyalahkan seseorang lebih berguna daripada ini. Jika bos Anda bertanya mengapa nama Anda di setiap bidang, maka Anda dapat menjelaskan "karena saya tidak berpikir pengembangan adalah permainan menyalahkan, jika Anda benar-benar membutuhkan orang untuk disalahkan dan disalibkan, maka salibkan saya untuk semuanya dan biarkan tim saya bekerja dengan damai . "

Saya pernah memiliki bos yang menerapkan sistem yang sangat mirip dengan ini, dan meskipun itu bukan pemrograman (itu desain cetak untuk surat kabar harian) konsep dan respons yang sesuai adalah sama.

Apa yang dia lakukan adalah alih-alih menambahkan bidang 'menyalahkan orang' pada dokumen kami, dia memberi masing-masing desainer satu set stiker berwarna. Setiap desainer mendapat stiker berwarna berbeda dan diinstruksikan bahwa untuk setiap desain yang bekerja atau bahkan menyentuh stiker harus ditambahkan ke dokumen desain itu.

Tujuan bos yang disebutkan untuk "inisiatif stiker" adalah untuk menetapkan sumber dari semua kesalahan departemen kami (kesalahan dalam dokumen, misfilings, salinan buruk, pada dasarnya setara dengan bug)

Apa yang kami lakukan adalah memberi masing-masing desainer seperempat stiker kami sehingga kami masing-masing memiliki semua warna, dan alih-alih hanya menempatkan warna kami pada setiap desain, kami menempatkan keempat warna desainer.

Jangan hanya menuliskan nama Anda di kotak [Salahkan] - letakkan nama semua orang yang ada di tim / proyek, dan pastikan seluruh tim melakukan hal yang sama.

Kami bekerja bersama melawan kekotorannya dan akibatnya kami akhirnya menangkap kesalahan satu sama lain dan berbicara satu sama lain tentang hal itu dan akhirnya mengalami pengurangan kesalahan yang signifikan. Namun, dia adalah manajer yang pendek, dan alih-alih mengakui bahwa inisiatifnya malah menyatukan kita dan meningkatkan produktivitas, dia malah membenci dan membubarkan sistem stiker dan menyatakannya sebagai kegagalan dan secara resmi menegur kita semua.

Ini akan berakhir menghukum programmer yang paling produktif. Kemungkinannya, satu atau dua orang mungkin adalah karyawan terbaik yang pernah bekerja di sebagian besar proyek. Jika Anda memiliki, di departemen 10-orang, satu pembuat kode yang hanya sumber output dan dia menulis 60% dari kode antarmuka, maka 60% bug akan ada dalam kodenya.

Jelaskan bahwa sistem ini akan membuatnya terlihat seperti orang yang menulis kode terbanyak adalah programmer terburuk, dan orang yang menulis kode paling tidak adalah programmer terbaik.

Ini kedengarannya seperti ketika Scott Adams menunjukkan kebijaksanaan gagal dari Bounty Bug ketika Pointy Haired Boss di Dilbert. Wally mengumumkan dia akan pergi dan 'menulis Mini Van baru ".

Strip komik Dilbert untuk 11/13/1995 dari arsip strip komik resmi Dilbert.

Saya ingat suatu kali ketika Snow Skiing seseorang menunjukkan bahwa 'tidak jatuh' bukanlah pertanda seorang ski yang baik, tetapi seringkali tanda dari seseorang yang tidak mencoba apapun (atau tidak benar-benar bermain ski sama sekali).

Bug dapat diperkenalkan dalam kode dengan pemrograman yang buruk dan desain yang buruk; tetapi, mereka juga dapat datang sebagai akibat dari menulis banyak kode yang sulit. Dinging orang-orang yang menghasilkan bug terbanyak adalah seperti Ding pengembang miskin sebagai yang sangat produktif.

Sepertinya bos Anda mungkin frustrasi dengan jumlah cacat. Apakah orang-orang dalam kelompok Anda bergairah tentang kualitas? Membuat bidang 'apa' untuk tujuan daripada bidang 'siapa' bisa lebih produktif. Mis: Perubahan Persyaratan, Cacat Desain, Cacat Implementasi, dll. Bahkan ini akan gagal kecuali ada grup yang ikut-ikutan untuk meningkatkan kualitas produk.

Mungkin Anda harus melihatnya sebagai "Siapa yang berada di posisi terbaik untuk memperbaiki bug?" Sebagian dari saya juga merasa, Anda memecahkannya, Anda memperbaikinya. Harus ada pertanggungjawaban.

Saya tidak setuju dengan menjaga semacam skor. Beberapa orang membuat lebih banyak bug karena mereka bekerja pada bagian kode yang lebih kompleks. Jika baris kode bukan metrik yang berguna, saya ragu bug per baris kode lebih baik. Kode tidak akan pernah masuk.

Pada titik tertentu seorang manajer harus tahu siapa yang melakukan pekerjaan mereka dan siapa yang tidak, serta, siapa yang melakukannya dengan lebih baik karena anggota tim lainnya melakukannya.

Sungguh aneh bahwa tidak ada yang menyebutkan ini sebelumnya: Menambahkan fungsi seperti itu ke pelacak bug akan memotivasi karyawan untuk mencoba permainan sistem .

Ini adalah masalah umum untuk pendekatan seperti apa yang disajikan pertanyaan, di antara ide-ide serupa lainnya (membayar dengan jumlah baris kode, membayar dengan jumlah bug). Ini akan mendorong banyak orang untuk fokus mendapatkan skor yang baik, alih-alih menyelesaikan masalah yang terkait dengan perangkat lunak yang sedang mereka kerjakan.

Misalnya, mencoba mengirimkan laporan bug dengan kata-kata untuk mengurangi kesalahan sendiri, dan mendorongnya pada orang lain dapat menyebabkan pengembang salah paham penyebab masalah (atau pekerjaan yang diberikan kepada pengembang lain yang tidak tahu bagian mana dari masalah tersebut). kode sebaik yang paling mengerjakannya dan yang merupakan penyebab utama bug) yang mengarah ke lebih banyak waktu dan upaya untuk memperbaiki masalah.

Pertanyaan Anda yang sebenarnya adalah tentang bagaimana mengubah budaya sebelum Anda meninggalkan perusahaan, dengan meyakinkan atasan Anda bahwa menambahkan seseorang ke bidang kesalahan untuk laporan bug adalah ide yang buruk. Tapi tentu saja mengubah budaya mengharuskannya untuk benar-benar mengerti mengapa ini adalah ide yang buruk.

Ini perintah yang berat. Selain masalah menyelamatkan muka setelah mengubah pikirannya, ada masalah mendasar bahwa orang-orang yang memikirkan solusi terutama dalam hal menyalahkan individu biasanya cukup diatur dalam pola pikir itu.

Anda meminta tulisan tentang topik ini, dan Peopleware muncul di benak Anda. Ini sangat dihargai dan berbicara secara umum tentang bagaimana mengelola orang yang melakukan pekerjaan kreatif di mana hasilnya sulit untuk diukur. Masalahnya adalah bahwa Anda membacanya tidak akan banyak membantu, atasan Anda harus membacanya, dan percaya setidaknya sebagian.

Anehnya, karena masalah di sini lebih banyak tentang orang daripada laporan bug, itu sangat mungkin dimiliki lebih di Workplace daripada Programmer. Tetapi keberhasilan proyek perangkat lunak biasanya cukup banyak dapat dilacak ke interaksi sosial manusia, sehingga jawaban sebenarnya sering sebagian besar tentang hal-hal yang melampaui perangkat lunak.

Satu-satunya saran saya yang lain, setengah serius, adalah mengatakan (atau meyakinkan rekan kerja untuk mengatakan, karena Anda berencana untuk pergi) bahwa Anda bersedia mengambil tanggung jawab penuh untuk keberhasilan proyek, dan nama Anda harus selalu masuk ke lapangan , karena bahkan jika orang lain melakukan kesalahan secara langsung, Anda telah memikul tanggung jawab untuk memastikan semua orang di tim melakukan pekerjaan yang berkualitas.

Tentu saja tidak masuk akal, bagaimana Anda bisa mendukungnya, tetapi beberapa orang (terutama orang-orang yang disalahkan) benar-benar memakannya. Ronald Reagan dulu secara terbuka menerima tanggung jawab pribadi setiap kali ada anggota pemerintahannya terjebak dalam skandal (dan ada beberapa) dan itu benar-benar berjalan baik secara politis setiap saat. Bagian terbaik untuk Anda adalah bahwa tanggung jawab umumnya datang tanpa konsekuensi aktual, mereka hanya berpikir Anda adalah orang yang berdiri untuk mengambil tanggung jawab.

Atau mungkin bukan itu yang akan turun. Tidak masuk akal sama sekali bagi saya sehingga sulit bagi saya untuk memprediksi kapan itu akan berhasil, tetapi saya telah menyaksikannya bekerja ketika tampaknya tidak ada urusan yang dilakukan (di tempat kerja, bukan hanya contoh Reagan).

Orang tidak bekerja dengan niat untuk melakukan kesalahan, dan strategi apa pun yang ditetapkan, untuk secara khusus menyalahkan siapa yang mungkin atau tidak mungkin melakukan kesalahan manusia itu konyol - belum lagi sangat tidak profesional.

Paling tidak, "pihak yang bertanggung jawab" yang ditugaskan untuk mengambil alih dan "memperbaiki" masalah ini, atau membuat rencana untuk melacak dan / atau mencegah peristiwa serupa terjadi, akan baik. Terkadang solusinya tidak lebih dari pelatihan tambahan. Saya telah bekerja untuk sejumlah perusahaan di mana itu adalah bagian dari deskripsi pekerjaan Anda, untuk mendapatkan pendidikan "dibayar perusahaan / waktu perusahaan". Satu tempat bahkan membangun seluruh "pusat pelatihan", yang kadang-kadang "dipinjam" oleh perguruan tinggi setempat, untuk kursus teknologi industri mereka.

Saya telah bekerja di lingkungan manufaktur selama 20 tahun terakhir, di mana kesalahan pemrograman tidak hanya menyebabkan kesalahan, mereka secara fisik menghancurkan sesuatu, dan / atau lebih buruk, mereka membuat orang terluka. Namun, satu konstan dalam setiap bidang manufaktur yang berdiri kuat, adalah bahwa tidak pernah ada, dalam keadaan apa pun, seseorang untuk disalahkan. Karena itu cacat dalam sistem, jelas dan sederhana - bukan cacat pada manusia. Lihatlah dengan cara ini - penggunaan pemeriksa ejaan - alat yang sangat efektif, bagi mereka yang kurang beruntung dalam bidang keahlian tekstual, atau mungkin hanya mereka yang sedikit bekerja ... tetapi tidak berarti metode menyalahkan atau akuntabilitas.

Lingkungan kerja, apa pun jenisnya, atau untuk tujuan apa fungsinya, adalah sebuah sistem. Suatu sistem yang terdiri dari komponen-komponen individual, yang jika "selaras" dengan tepat, bekerja dalam harmoni total - atau kemiripan semacam itu.

Bacaan yang disarankan dari atasan Anda: 7 Kebiasaan Orang yang Sangat Efektif

Sepertinya dia bisa menggunakan sedikit kerendahan hati, jika bukan pemeriksaan realitas. Dia hanya menjadi bagian dari tim, seperti orang lain, dan dia perlu menyadari bahwa - atau itu tidak akan berhasil, dan pada akhirnya, dia akan memegang tas itu bagaimanapun juga.

Bacaan dan / atau penelitian yang disarankan untuk Anda:

Lihat ke 5 mengapa analisis, analisis akar penyebab ... hal apa pun yang menempatkan Anda pada posisi yang lebih baik untuk menawarkan solusi, bukan masalah . Dan ketidaksepakatan Anda dengan bos Anda, hanya itu, masalah, bukan solusi. Tawarkan padanya sesuatu yang lebih baik, sesuatu yang masuk akal, dan bahkan bersiaplah untuk mengizinkannya mengambil pujian atas gagasan itu.

Saat ini sepertinya dia tidak siap untuk memperbaiki apa pun, karena dia tidak memiliki pemahaman yang kuat tentang apa yang rusak, jika ada sesuatu yang rusak sama sekali - selain mentalitas "Aku bosnya".

Semoga berhasil! Saya harap Anda berhasil melewati ini, dengan cara yang dapat diterima untuk semua, terutama di masa-masa ini.

EDIT: Secara pribadi, dari pengalaman saya sendiri ... "Silakan, salahkan saya. Karena cukup yakin, saya akan memperbaikinya, dan di ujung jalan, ketika itu terjadi lagi, siapa yang akan berada di sana untuk menyelamatkan hari? Ya, Anda tebak ... aku, dengan senyum lebar. "

Untuk pertanggungjawaban saya tidak ingin person to blamelapangan, saya ingin Person who knows the codelapangan atau person who can fixlapangan, sehingga saya akan tahu ke mana harus mengirim tiket dukungan.

Ini akan mempercepat proses memperbaiki bug itu sendiri dan memberikan akuntabilitas, seperti membunuh dua burung dengan satu batu. Saya pribadi akan menyampaikan ini kepadanya dan membiarkan dia memutuskan apakah ini akan membantu meningkatkan moral dan akuntabilitas tanpa membuat orang merasa mereka gagal. Pengujian ekstrem tidak menangkap semua bug, jika tidak, tidak akan ada pelaporan bug.

Katakan padanya "menyalahkan" itu negatif. Ubah itu menjadi "orang untuk diperbaiki" maka paling tidak itu dibingkai secara positif, dan pekerjaan yang sama masih dilakukan. Bagaimana orang bisa bekerja jika mereka "disalahkan" ?!

Jika bos saya melakukan itu, hal berikut akan terjadi, dalam urutan yang tepat ini:

1) Saya akan segera mulai mencari pekerjaan baru.

2) Setiap kali bug dilaporkan dengan seseorang untuk disalahkan, nama bos saya akan muncul di sana, dan komentar tentang mengapa proses yang buruk dalam tim bertanggung jawab untuk itu. Dan CC itu ke bosnya (lebih disukai dalam batch). Apakah Anda memiliki tes unit? Jika tidak maka itu berarti bahwa proses dev rusak, maka bug. Apakah Anda memiliki pengujian integrasi otomatis yang konstan dengan semua sistem eksternal? Kemudian proses dev rusak, demikian juga bug. Apakah Anda memiliki kemampuan untuk membuat setiap lingkungan identik dalam produksi melalui skrip untuk tidak membiarkan kesalahan manusia? Kemudian proses dev rusak, demikian juga bug. Apakah satu pengembang mengerikan? Maka kriteria perekrutan adalah badm sehingga kesalahan bos. Apakah semua pengembang membuat kesalahan bodoh karena kurang istirahat karena mereka bekerja 12 jam sehari? Kemudian proses dev rusak.

Sebagai catatan: Setiap manajer pengembangan yang baik menyadari apa yang saya tulis di atas. Dan strategi Agile dimaksudkan untuk menunjukkan kepada bos atau atasannya mengapa dev melambat: Lihat, kita menghabiskan 50% waktu kita untuk memperbaiki bug. Mari kita lihat strategi untuk menguranginya sehingga kita dapat menghabiskan 40% dari waktu memperbaiki bug, dan kemudian mengunjungi kembali masalah ini hingga 30%. dll.

Sayangnya sepertinya Anda tidak memiliki manajer yang baik karena bidangnya. Jadi saya sarankan melakukan (1) dan tidak membawanya ke manajer (kecuali pada wawancara keluar Anda)

Sepertinya bos Anda tidak memiliki pemahaman yang mendalam tentang perangkat lunak dan mungkin dia juga tidak berniat untuk melakukannya. Jadi dia memiliki bahasa yang berbeda, budaya yang berbeda.

Berhenti dari pekerjaan karena masalah seperti ini, bahkan sebelum mencoba untuk mencari solusi, hanya menjadi orang yang gampang menyerah. Berhenti berarti berhenti. Jangan berhenti sampai dia membuat Anda yakin bahwa Anda tidak akan pernah bisa saling memahami. Untuk memastikannya, Anda harus terlebih dahulu mencoba.

Karena dia tidak tahu bahasa kita, dan dia bosnya, langkah pertama di sini adalah mencoba berbicara dengannya dalam bahasanya. Apa yang saya maksud dengan bahasa? Mari berfikir bersama:

Kami orang-orang peranti lunak, sebagian besar dari kami menyukai pekerjaan yang kami lakukan, kami memiliki koneksi yang mendalam dengan apa yang kami lakukan. Kalau tidak, itu tidak akan berhasil dan orang tidak dapat melanjutkan dalam bisnis ini untuk waktu yang lama tanpa menyukainya atau menjadi lengkap ... Anda mengisi kekosongan ...

Namun, dia melihat banyak hal secara berbeda. Dengan setiap laporan bug, sementara sebagian besar dari kita bersemangat untuk membuat hal itu bekerja lebih baik (tidak, bahkan jika kadang-kadang sangat sangat menegangkan, kita suka masalah, akui saja!), Dia melihatnya sebagai sebuah kegagalan, ukuran dari keberadaan gagal. Hal pertama yang harus dia pahami adalah bug itu baik. Bug membuat klien menyukai perusahaan. (Sekarang ini adalah bahasanya) Ketika seorang pelanggan melaporkan bug, atau ketika kami menemukan sendiri bug itu, setelah diselesaikan, itu jauh lebih baik daripada situasi yang tidak pernah terjadi. Bug menciptakan loyalitas pelanggan (saya serius!), Bug menciptakan alasan yang bagus untuk komunikasi antara konsumen dan produsen perangkat lunak.

Untuk "meningkatkan laba bug" Anda harus menawarkan membuat laporan bug lebih terbuka. Dengan setiap laporan bug dan solusi cepat, bersih, bagus, pelanggan merasakan dan melihat bahwa "wow, orang-orang ini luar biasa! Mereka bekerja sangat keras. Lihat hal-hal yang mereka selesaikan. Kami bahkan tidak menyadari bahwa perangkat lunak begitu rumit benda!" bla bla dan bla ...

Bergeraklah, bicaralah dalam bahasanya. Bug sangat bagus untuk perusahaan perangkat lunak, bukan masalah. Mereka mencari nafkah.

Untuk etika tim, efisiensi, atau jenis pembicaraan apa pun yang Anda lakukan mungkin akan bekerja berlawanan dengan yang Anda inginkan. Jika Anda ingin berhenti, dia akan berpikir "aha, solusi saya mulai bekerja sejak hari pertama! Tautan buruk sudah mulai menurun sendiri sebelum terpapar!" Dia percaya pada idenya untuk menemukan anak-anak nakal di perusahaan dan sangat sulit untuk meyakinkannya sebaliknya. Terutama ketika Anda mungkin salah satu dari anak-anak nakal itu!

Jadi, fokuslah pada masalah sebenarnya: Bug. Tunjukkan padanya bahwa bug bisa sangat berguna. Tanpa masalah, hubungan itu membosankan. Segala sesuatu yang tidak membunuhmu membuatmu lebih kuat. Setiap bug adalah peluang besar yang dapat Anda gunakan untuk meningkatkan kebahagiaan pelanggan.

Ini hanya satu hal yang bisa Anda katakan. Pikirkan kekhawatirannya dan Anda akan menemukan banyak item lain untuk ditambahkan ke daftar Anda. KUNCI EMAS adalah untuk menawarkan hal alternatif alih-alih berkelahi dengan idenya!

Jika Anda melakukan Agile, dan sepertinya Anda berasal dari fitur / cerita komentar. Orang yang akan disalahkan adalah orang QA yang membiarkan bug lolos, atau Pemilik Produk / Pelanggan yang menerima fitur / cerita sebagai lengkap dengan bug di dalamnya.

Saya melakukan typesetting kembali pada hari ini, inilah pendapat saya.

Ini seperti menyalahkan seorang penata huruf untuk kesalahan ejaan dan hal-hal lain yang seharusnya ditemukan oleh korektor kesalahan tetapi terlewatkan. Pengetik huruf membuat kesalahan ejaan, tetapi korektor kesalahan melewatkannya, jadi korektor yang bertanggung jawab atas kesalahan membuat untuk mencetak, bukan orang yang membuat kesalahan di tempat pertama.

Dalam lingkungan Agile itu adalah tanggung jawab orang QA untuk menangkap kesalahan (bug) dan merupakan tanggung jawab Pemilik Produk untuk tidak menerima hal-hal yang tidak benar. Ini adalah dua tingkat pembaca bukti yang harus melindungi pengembang dari hal-hal yang dirilis, yang merupakan satu-satunya cara apa pun harus diklasifikasikan sebagai bug dalam lingkungan Agile.

Saya pikir manajer Anda sedang mencoba menyelesaikan masalah dengan solusi yang salah. Saya pikir mungkin ada masalah bahwa terlalu banyak bug yang dirilis dan manajer Anda ingin pengembang mengambil lebih banyak kepemilikan dan akuntabilitas terhadap kode yang mereka tulis.

Menggunakan pengembangan yang digerakkan pengujian dan menyiapkan server integrasi berkelanjutan (seperti Jenkins ) akan membantu menyelesaikan masalah ini, tanpa memperkenalkan "game menyalahkan". Server integrasi berkesinambungan penting untuk ini karena ketika seseorang melakukan kode yang "merusak build" sebuah email keluar ke tim yang menunjukkan orang yang harus disalahkan. Karena kode ini belum dirilis ke lingkungan produksi, jenis kesalahan ini lebih proaktif dan menggembirakan (dan menyenangkan!).

Hasilnya adalah bahwa pengembang akan mengambil lebih banyak kepemilikan, merasa lebih percaya diri, dan akan ada lebih sedikit bug dalam kode produksi.

Tunjukkan bahwa jika kesalahan satu orang menyebabkan bug berakhir dalam produksi, maka ada sesuatu yang salah dengan metodologi Anda, atau cara Anda mengembangkan perangkat lunak secara berlebihan. Tekankan bahwa mencegah kutu sampai ke produksi adalah tanggung jawab seluruh tim.

Menggunakan salah satu dari dua argumen ini, lihat apakah Anda dapat meyakinkan bos Anda bahwa memiliki bidang "siapa yang harus disalahkan" sebagai bidang pilihan tunggal akan menyesatkan; dan karena itu, perlu untuk memastikan bahwa bidang "siapa yang harus disalahkan" adalah bidang pilihan ganda. Setelah Anda mencapai ini, maka pastikan bahwa untuk setiap bug, nama semua orang ada di lapangan. Bos Anda pada akhirnya akan melihat bahwa pelaporan apa pun di lapangan tidak ada gunanya.

Untuk memberi pujian pada bos, konsep "penugasan menyalahkan" sudah dimasukkan ke dalam alat-alat seperti SVN , dan penggunaan data yang tepat dapat konstruktif bagi pengembang dalam "mencari tahu siapa yang harus diajak bicara" saat debugging, misalnya: http: / /www.codinghorror.com/blog/2007/11/who-wrote-ini-crap.html

Walaupun saya setuju dengan respons nyamuk di atas bahwa bidang Sebab Penyebab adalah hal yang baik, ini bukan informasi yang sama, dan "mendenormalkan" bidang tersebut untuk terkadang menetapkan nama pengembang sebelumnya untuk sumber yang terpengaruh, dan terkadang memiliki deskripsi teknis (mis. "tidak menskalakan hingga 10.000 pengguna") hanya akan memperkeruh perairan. Saya menganjurkan untuk menjaga Root Rootbidang dengan jelas deskripsi teknis (mis. bahkan ketika kesalahan programmer jelas, minta ia menangkap detail seperti "Pengecualian IndexOutOfRange ketika fooData = 999") Ini berpotensi memberikan beberapa umpan balik yang berguna ketika ditinjau secara massal, dan memungkinkan beberapa tindakan korektif untuk diambil untuk menyelesaikan seluruh kelas masalah dengan perubahan arsitektur atau kerangka kerja (mis. meningkatkan kelas wadah kustom, penyerahan pengecualian tingkat atas)

Yang mengatakan, menambahkan bidang Person To Blame jelas dapat mengirim pesan yang sangat buruk dan pesan destruktif ke tim perangkat lunak yang manajemen ingin memilih dan menghukum pengembang individu yang paling sering melanggar kode. Saya menduga manajer percaya bahwa pengawasan publik ini akan menyebabkan pengembang lebih berhati-hati dan mengatur diri sendiri untuk menghindari nama mereka di "tembok rasa malu" ini, dan tidak mengerti mengapa pengembang akan merasa terancam oleh ini, terutama jika ditambahkan secara umum untuk setiap laporan bug.

Masalah dengan menambahkan ini sebagai bidang bug / metrik potensial mudah untuk memulai penghitungan:

1. Bug sangat bervariasi dalam kesulitan untuk diselesaikan, dan statistik sederhana penghitungan / pengembang bug tidak akan mencerminkan hal ini.
2. Pengembang sangat bervariasi dalam kapabilitas "" "" "" "" "" "
3. Banyak sistem perangkat lunak memiliki komponen yang memerlukan refactoring, namun refactoring komponen legacy (terutama jika basis legacy tidak memiliki / fasilitas unit test terbatas) pada awalnya akan memperkenalkan bug. Pengembang cenderung tidak disarankan untuk melakukan aktivitas "baik" ini, jika ada stigma / ketakutan terkait dengan menghasilkan bug baru (bahkan jika ini sepele untuk dipecahkan dan pada akhirnya menghasilkan peningkatan besar dalam sistem.)
4. Penguji dapat mengajukan jumlah bug yang sangat bervariasi terkait dengan masalah yang sama, menghasilkan jumlah / pengembang bug yang sangat miring, kecuali dilakukan analisis yang lebih terperinci.

Itu hanya puncak gunung es. Gabungkan semua ini dengan pengarahan jari siapa yang mengharapkan perilaku API apa, hasil tes yang salah yang diharapkan, dan masalah "sebelumnya dalam rantai" dengan persyaratan yang salah / hilang, dan harus jelas bahwa metrik seperti ini akan dianggap tidak berharga (kecuali tujuannya adalah untuk merusak moral dan menyebabkan eksodus massal.)

Kembali ke sudut pandang bos, boleh-boleh saja dia ingin mengetahui apakah ada pengembang yang melanggar kode berulang kali, dan mencoba dan melakukan sesuatu (semoga konstruktif) tentang itu. Mencoba mendapatkan informasi ini dengan menambahkan bidang ke laporan bug tidak akan memberikan informasi yang bermakna karena alasan yang tercantum di atas. Dalam pengalaman saya, informasi ini dapat dipelajari dengan cara terhubung dengan tim, berpartisipasi dalam sebagian besar pertemuan tim, mengintegrasikan (hati-hati) informasi yang dipelajari dalam pertemuan satu-satu dengan anggota tim, dan membiasakan diri dengan subsistem dalam kode (bahkan jika mereka tidak dapat membaca kode.)

Biarkan saja. Atasan Anda akan mengetahui sendiri bahwa itu menyebabkan masalah, jika itu terjadi.

Mari menjadi tumpul, Anda memiliki pendapat dan begitu juga dia. Dia adalah manajer Anda dan pendapatnya adalah yang menang.

Ya, Anda bisa berperang karena masalah ini, tetapi apakah itu benar-benar layak? Saya ragu itu berlangsung lebih dari 3 bulan sebelum tidak digunakan lagi.

Tetapi secara aktif menyabot ini atau berteriak tentang hal itu hanya menghabiskan modal politik yang lebih baik diselamatkan untuk meminta cuti tambahan, kenaikan gaji berikutnya, promosi, atau ketika keputusan desain yang sangat kritis akan dibuat.

Pada saat itu, ketika itu benar-benar berarti Anda ingin bos untuk mengingat bahwa Anda adalah orang yang secara aktif menyabot idenya untuk "orang yang disalahkan".

Hormati kantor meskipun Anda tidak menghormati keputusan itu.

Simpan stres dan pukulan meja untuk keputusan yang akan lebih tahan lama.

Katakan kepada atasan Anda bahwa berkembang dalam tim membutuhkan keterampilan sosial. Dia bahkan mungkin mengangguk.

Tetapi masalahnya adalah, ini adalah sesuatu yang sangat buruk bagi pengembang. Menambahkan alat yang menyarankan menyalahkan lebih penting daripada analisis masalah yang tepat adalah kontra-produktif.

Alih-alih, Anda memerlukan insentif untuk meningkatkan keterampilan sosial, dan infrastruktur komunikasi yang Anda miliki harus mendukungnya. Misalnya, koin itu secara positif: Sebutkan nama orang yang bertanggung jawab atas sebuah tiket, yang mengurusnya.

Juga mulai dengan ulasan kode sehingga Anda dapat saling belajar. Itu menghindarkan menyalahkan di kemudian hari.

Kirim email kepadanya pertanyaan SO ini. Jika dia terbuka untuk alasan, komentar di sini akan memberikan pemeriksaan kewarasan untuk alasannya. Jika dia tidak masuk akal, Anda tidak mungkin meyakinkannya dengan alasan yang masuk akal. Selain itu, ia akan dapat membaca alasan di luar percakapan (yang kadang-kadang bisa lebih meyakinkan karena motivasi yang dihapus untuk "menjadi benar" dalam panasnya percakapan).

Anda juga bisa mencoba memutarnya. Bidang ini bisa "langkah-langkah yang mungkin untuk menghindari bug serupa terjadi", atau sesuatu yang lebih pendek untuk efek itu. Kemudian Anda bisa mengumpulkan solusi dan memilih mana yang akan diterapkan untuk membuat tempat kerja Anda lebih baik. Mungkin pendekatan berorientasi solusi lebih produktif dan kemungkinan lebih baik diterima (asalkan ada tindak lanjut aktual pada meninjau kembali saran).

Saya melihat dua kemungkinan di sini: Dia ingin bisa menghukum orang yang melakukan kesalahan, atau dia belum memikirkannya. Biarkan dia tahu bahwa persepsi kepada semua orang adalah bahwa dia bermaksud untuk menghukum mereka yang melakukan kesalahan. Tanyakan padanya apakah itu budaya yang ingin ia dorong.

bos saya memutuskan bahwa menambahkan bidang "Person To Blame" ke templat pelacakan kutu kami akan meningkatkan akuntabilitas

Dalam pengalaman saya, ketika manajemen ingin "membuat orang lebih bertanggung jawab," yang mereka maksud adalah mereka ingin dapat memberikan hukuman atas kegagalan. Entah itu untuk memecat orang-orang yang berkinerja buruk, atau membiarkan mereka dikecam dalam review gaji tahunan ("Maaf, Bob, Anda memiliki 17 bug yang ditandai sebagai kesalahan Anda, dan itu melebihi batas 15"), itu adalah hukuman.

Dia mungkin akan berkata, "Oh, tidak, kami tidak menginginkan itu," jadi tanyakan padanya bagaimana data itu akan digunakan. Ingatkan dia bahwa Anda tidak menambahkan poin data ke database kecuali Anda akan menggunakannya. Apakah dia ingin memilih salah satu kriteria yang diberikan ("Tunjukkan semua bug terbuka di subsistem pembuat laporan"), sehingga Anda dapat mengerjakan berbagai hal, atau untuk bisa mendapatkan data agregat ("Subsistem mana yang memiliki paling banyak bug "), sehingga Anda dapat melakukan analisis post-mortem. Apakah dia membayangkan semacam papan tote kegagalan di mana orang bisa dipermalukan di depan umum?

Jadi, apa yang dia inginkan? Apakah dia ingin bisa mengatakan, "Tunjukkan semua bug yang salah Bob?" Mengapa? Atau apakah dia ingin bisa mengatakan, "Tunjukkan pada saya siapa yang paling sering bersalah?" Mengapa? Yang pertama tidak berarti, dan yang kedua hanya hukuman. Atau pilihan ketiga adalah dia tidak punya alasan nyata.

Saya akui ada kemungkinan dia bisa mencari programmer di tim yang membutuhkan bantuan dalam meningkatkan keterampilan mereka. Jika demikian, ada cara yang lebih baik untuk menangkap informasi ini yang tidak menciptakan budaya penunjuk jari.

Saya percaya aspek kunci untuk menonton di sini adalah seberapa terbuka komunikasi dalam tim menuju 'bos' dan sebaliknya. Menunjuk dengan jari tidak pernah baik, dari sudut pandang manajemen, jika salah satu pengembang Anda masuk ke masalah yang sama beberapa kali, mungkin sudah saatnya untuk masuk dan mencoba membantunya mengatasi masalah berulang ini (misalnya John tidak menguji dengan benar kode: 3 bug produksi dalam 3 bulan terakhir, mari kita beri dia daftar periksa jadi dia ingat bagaimana kode itu seharusnya dan bagaimana dia harus mengujinya).

Dari sudut pandang pengembangan, 'menyalahkan' sudah dimasukkan ke dalam alat utama seperti SVN, oleh karena itu saya benar-benar tidak melihat ada salahnya pergi "John, tolong perbaiki sepotong omong kosong yang Anda tulis" dan meletakkan nama di sebelah saya t. JIRA juga memasukkan nama seseorang ketika Anda mengajukan bug (namun bidang itu tidak benar-benar dimaksudkan untuk orang yang bertanggung jawab atasnya, itu cukup banyak sehingga seseorang memperbaikinya).

Inilah masalahnya, seperti banyak yang disebutkan di atas oleh banyak orang, jika bug muncul, itu adalah tanggung jawab bersama: dari pengembang, ke penguji, ke QA, ke manajer. Jika bos Anda pada suatu saat menangani klien yang marah melalui telepon dengan hal-hal seperti " Maafkan aku, John tidak pernah menguji ini dengan benar ", maka aku pasti akan mencari pekerjaan lain. Seorang bos yang baik harus pergi "kami akan mengurus ini". Tidak ada nama, tidak ada ujung jari, hanya solusi.

Sekali lagi, saya percaya ini semua tentang komunikasi. Mungkin satu-satunya hal yang bos Anda ingin lakukan adalah melihat siapa yang memiliki masalah dalam tim dev, atau masalah apa yang dihadapi tim (mungkin untuk sesi pelatihan?), Tapi saya tidak berpikir Anda akan mencari tahu persis apa yang ada di belakangnya keputusan (atau lebih baik dikatakan, kami poster / pembaca) kecuali Anda berbicara dengan bos Anda dan seluruh tim Anda.