Sebagai bagian dari tinjauan semua deskripsi pekerjaan, perusahaan saya telah memutuskan untuk memasukkan yang berikut ini sebagai output utama:

pengembangan situs web selesai tepat waktu, dalam spesifikasi dan bebas kesalahan

Mengingat bahwa spesifikasi secara teratur berubah, tidak ada proses kontrol perubahan formal dan lingkungannya, haruskah kita katakan, sedikit tidak dapat diprediksi, seberapa realistis dan masuk akal KPI ini?

"Bebas Kesalahan" terlalu subjektif . "Permintaan fitur yang tidak terpenuhi" dari satu orang adalah "Kesalahan" dari orang lain. Sesuatu seperti "Harus secara substansial memenuhi spesifikasi desain" akan lebih tepat. Saya tidak pernah benar-benar melihat apa yang Anda gambarkan dalam deskripsi pekerjaan. Saya sudah melihatnya untuk pekerjaan kontrak , tetapi tidak untuk karyawan.

Saya akan mengambil posisi berlawanan dengan sebagian besar jawaban dan mengatakan itu benar-benar masuk akal dan realistis.

Apakah semua pengembangan akan selesai tepat waktu? Tentu saja tidak, tidak selalu.

Apakah semua pengembangan akan diselesaikan dalam spesifikasi? Anda ingin berharap demikian, tetapi kadang-kadang itu tidak mungkin dan Anda harus menandai penyimpangan dari spesifikasi yang mustahil atau kontradiktif sendiri.

Dan apakah semua pengembangan akan bebas dari kesalahan? Tidak pernah .

Tapi itulah gunanya KPI. Ini adalah sesuatu yang dapat diukur dan dimana Anda dapat melacak kinerja dan kemajuan.

Jika spesifikasi berubah secara teratur, tidak ada proses kontrol perubahan formal dan lingkungan tidak dapat diprediksi, maka akan menjadi tantangan untuk menjaga angka ini dekat dengan "bebas dari kesalahan". Tapi tantangan itu adalah pekerjaan Anda , dan itu pekerjaan yang mudah-mudahan Anda lakukan dengan sangat baik - dan bahkan lebih baik tahun depan, saat Anda lebih banyak berlatih mengelola kekacauan khusus perusahaan Anda sendiri.

Pertanyaan balasan: KPI apa yang akan Anda usulkan untuk seorang programmer? Itu yang sulit. Banyak hal yang kita lakukan sulit untuk diukur.

Jika itu adalah deskripsi pekerjaan, maka saya tidak akan terlalu khawatir tentang hal itu karena bekerja menuju kode bebas kesalahan adalah bagian dari pekerjaan khas programmer (bahkan jika kita tidak pernah dapat mencapainya).

Namun, sebagai KPI terlalu jauh jangkauannya, tetapi jangan salahkan orang yang menyarankannya jika mereka bukan programmer. Cukup jelaskan bahwa pernyataan itu menetapkan tujuan yang mungkin tidak diinginkan untuk organisasi. Artinya, "bebas kesalahan" adalah standar yang sangat tinggi untuk perangkat lunak yang akan membutuhkan banyak uang untuk benar-benar dikirimkan. Jelaskan bahwa proyek perangkat lunak yang dikelola dengan baik membutuhkan keputusan yang harus dibuat tentang apakah setiap cacat layak menghabiskan waktu pengembang yang berharga.

Berikut adalah contoh yang membuat intinya dengan baik.
Seorang programmer menemukan bahwa perangkat lunak kami memiliki bug "tahun 3000" dan akan berhenti berfungsi setelah 31 Desember 1999. Diperlukan 6-8 bulan untuk menyelesaikan masalah. Berdasarkan KPI didorong untuk mengambil proyek ini meskipun tidak memiliki nilai nyata bagi perusahaan.

Oke, jadi contoh itu agak ekstrem, tetapi dalam proyek perangkat lunak apa pun akan ada puluhan cacat kecil yang ditemukan yang juga tidak menghasilkan ROI yang diperlukan untuk memperbaikinya. Jika KPI dimaksudkan untuk menyiratkan bahwa programmer tidak pernah memperkenalkan cacat pada awalnya, apakah masuk akal bagi setiap karyawan untuk berpegang pada standar tidak pernah membuat kesalahan dalam kinerja pekerjaan mereka?

Tidak

Bukan saja itu tidak tepat, itu menggelikan

Pengujian hanya dapat membuktikan adanya kesalahan, bukan ketidakhadirannya, sehingga setiap program yang ditulis dalam perjanjian ini harus menyertakan bukti ketelitian yang benar ... dan cakupan pengujian 100%

"Waspadalah terhadap bug dalam kode di atas; Saya hanya membuktikannya benar, tidak mencobanya." - D. Knuth

Tentu saja adalah tugas setiap programmer, dan tanggung jawab, untuk menulis kode yang bebas kesalahan. Itu harapan yang masuk akal. Bagaimana Anda bisa menjadi programmer profesional jika Anda merilis kode yang tidak berfungsi? Bagaimana Anda dapat menganggap diri Anda sebagai programmer profesional jika Anda merilis kode yang tidak Anda ketahui berfungsi?

Jika Anda menyewa seorang pelukis, Anda berharap dia melakukan pekerjaannya dengan baik. Anda berharap hasil karyanya bebas kesalahan. Jika ada kesalahan, Anda berharap dia bertanggung jawab atas kesalahan itu dan memperbaikinya secara gratis. Terlebih lagi, jika kesalahan itu membuat Anda kehilangan uang, Anda berharap dia akan mengembalikan uang Anda. Mengapa Anda memiliki harapan ini? Karena pelukisnya adalah seorang profesional.

Programmer suka menyalahkan orang lain atas kesalahan mereka. "Program saya memiliki bug karena persyaratan, atau karena jadwal, atau karena Bulan ada di rumah ke-8" Tapi sebenarnya tidak ada orang lain yang bisa disalahkan. Jika program Anda memiliki kesalahan, Anda taruh di sana.

Profesi kita tidak akan pernah menjadi profesi sampai programmer menyadari bahwa tanggung jawab berhenti pada mereka. Bahwa mereka bertanggung jawab atas kualitas program mereka.

Apakah Anda tahu mengapa perusahaan membuat departemen QA Perangkat Lunak? Karena programmer tidak melakukan pekerjaannya! Programmer mengeluarkan banyak omong kosong sehingga perusahaan harus membentuk departemen baru untuk memeriksa mereka.

Berapa lama daftar bug? Profesional untuk memiliki ribuan bug di database bug? Jelas bukan. Itu adalah cerminan dari perilaku buruk, disiplin yang buruk, dan, sejujurnya, aib.

Kami tidak akan pernah menjadi profesi sampai kami menyadari bahwa itu adalah tugas kami untuk memastikan bahwa QA tidak menemukan apa pun.

Sayangnya ini hanya terdengar seperti cara bagi mereka untuk "menutupi semua pangkalan", dan jelas tidak direkomendasikan dan mungkin hanya menimbulkan kekecewaan pada pengembang.

Namun demikian, ini benar-benar hanya penting setelah Anda melihat apa yang mereka lakukan dengan teks tersebut selama periode peninjauan. Jadi jangan bereaksi terlalu cepat - mungkin masih ada kewarasan di ujung terowongan.

"Bebas kesalahan" seperti "sempurna?" Seperti dalam "yang ditulis oleh Tuhan dan para malaikat, bukan manusia?" (kita berbicara di sini tentang kesalahan program-logika dan mungkin hardware-logika)

Saya tidak bisa mengatakan dengan jujur ​​tentang satu baris kode pun tanpa kesalahan. Itu karena kita manusia, yah, kita tidak dapat membuktikan tidak ada hipotesis negatif!

Yang terbaik yang bisa saya katakan adalah bahwa probabilitas kesalahan adalah angka antara 0 dan 1. Saya mencapai angka itu dengan prinsip pengembangan dan pengujian perangkat lunak yang baik atau kurang dipahami dan dipahami dengan baik; oleh hitungan garis sumber perangkat lunak yang dimaksud; dengan pemahaman tentang seberapa baik atau buruknya kandidat, anjing malang, menerapkan prinsip-prinsip tersebut dalam menghasilkan garis-garis kode; dan lainnya.

Dan saya bisa mengungkapkan bahwa pemahaman hanya sebagai probabilitas. Jadi istilah "bebas kesalahan logika" berarti hampir tidak ada artinya.

Jika saya melihat iklan untuk insinyur perangkat lunak yang menghasilkan kode "bebas kesalahan", saya akan langsung mendaftar atau langsung kabur: perusahaan belum memikirkan bagaimana mengembangkan, menguji, dan memberikan perangkat lunaknya . Jadi itu akan menjadi peluang besar atau mimpi buruk tanpa akhir.

Dari perangkat lunak apa pun, saya dapat dengan mudah - dan harus - mengatakan saya mengharapkan kode yang tidak memiliki kesalahan yang berada di luar hal -hal yang sial, keruh, dan logis: kode yang menyusun dan menghubungkan tanpa kesalahan atau peringatan; itu adalah "html valid" atau "css valid"; JavaScript (katakanlah) yang tidak menghasilkan pesan kesalahan atau kesalahan browser yang tidak dapat dijelaskan. Bagian itu dapat saya ukur dengan lugas dan beri tanda hitam putih pada grafik.

Bagian itu semudah pie. Siapa saja bisa melakukan itu .

Hai, semoga sukses dalam pencarian Anda :-)

Apakah saya bodoh, atau apakah "kesalahan" tidak berarti "pesan kompilator fatal sebesar kode yang tidak dapat dikompilasi"?

Menurut definisi itu, ini adalah persyaratan yang sangat masuk akal ...