Dapatkah perwakilan, pemungutan suara dan lencana internal mendorong praktik pemrograman yang baik?


17

Hanya berpikir keras-keras - kami programmer suka semua voting / badges / hal rep ini sehingga skema seperti ini dapat dimasukkan ke dalam proses peninjauan kode perusahaan untuk mendorong pengkodean yang lebih baik.

Sesuatu seperti

  • Anda (atau orang lain atas nama Anda) dapat memposting ulasan (dapat berupa cuplikan, komit tunggal atau serangkaian) untuk ulasan kode

  • Orang lain dapat mengomentarinya (akan serupa dengan jawaban dalam SE)

  • Lencana dapat diberikan / disarankan (beberapa akan baik, beberapa akan buruk seperti "Komentar Gurun" atau semacamnya)

  • Anda dapat memberi suara naik / turun pada kode itu sendiri dan komentar serta lencana (misalnya jika seseorang menyarankan lencana dan Anda setuju / tidak setuju)

Tujuan dari skema seperti ini adalah

  • Perkenalkan sedikit kesenangan untuk mendorong penggunaan ulasan kode

  • Tingkatkan kualitas (dalam skema ini, peninjau kode dan pengulas cenderung belajar)

  • Kurangi kemungkinan ulasan kode yang memicu 'perang ego'

  • Berikan beberapa metrik untuk membantu mengukur kinerja individu

Bisakah ini bekerja? Pikiran?


2
Baru saja menemukan situs ini - StackExchange untuk ulasan kode - ide bagus untuk proyek open source / pribadi tetapi publik untuk banyak perusahaan dengan codereview.stackexchange.com
Ryan

5
Kedengarannya itu akan menjadi ide yang bagus untuk sementara waktu, tetapi satu-satunya hal yang akan saya lakukan secara berbeda adalah menyingkirkan lencana hukuman. Mereka membawa stigma dan kerendahan hati dengan mereka yang akan mencegah mereka yang tertinggal untuk mencoba mengejar ketinggalan.
maple_shaft

1
Yang sulit itu. Saya pikir kebenaran yang brutal adalah bahwa kita sering dapat belajar lebih banyak dari kesalahan (kita sendiri dan orang lain) daripada yang kita dapat dari keberhasilan. Dan untuk semua pembicaraan hippy berbunga-bunga, hukuman yang adil berhasil. Tanyakan orang tuamu;)
Ryan

9
Satu-satunya masalah adalah bahwa Jon Skeet akan selalu duduk di atas dengan 100k rep. Jon Skeet tidak bekerja untuk perusahaan Anda? Tidak masalah. Dia akan tetap di sana.
Tom Anderson

1
Poin bagus - mungkin tanda "Saya masuk kelas tanpa satu baris komentar" tanda malu harus berakhir dalam satu waktu atau dicabut setelah Anda melakukan sesuatu yang positif - karena jika tidak, tidak ada insentif untuk meningkatkan karena Anda sudah mendapat 'tanda' dan itu tidak masalah lagi
Ryan

Jawaban:


20

Hadiah ekstrinsik seperti uang, lencana, atau perwakilan akan bekerja, jangka pendek , seperti diet dan sistem penghargaan / hukuman lainnya.

Penghargaan intrinsik , seperti tujuan & otonomi harus digunakan sebagai gantinya dan memberikan hasil yang lebih jangka panjang. Jauh lebih sulit untuk mempraktikkannya daripada sistem imbalan ekstrinsik sederhana, tetapi membayar.

Banyak ahli melakukan penelitian tentang masalah ini. Inilah dua favorit saya:

Daniel Pink membuat presentasi yang bagus di TED tentang topik yang mudah ditonton dan dipahami.

Alfie Kohn , penulis Punished by Rewards , menulis tentang hal ini:

Tentu, suap dan ancaman dapat menghasilkan kepatuhan sementara. Tawarkan hadiah kepada orang dewasa untuk pergi ke gym, atau untuk anak-anak karena mengambil buku, dan itu mungkin berhasil - untuk sementara waktu. Tetapi mereka menganggap diri mereka sebagai termotivasi secara ekstrinsik, sehingga ketika hadiah tidak lagi tersedia tidak ada alasan untuk melanjutkan. Memang, mereka mungkin kurang tertarik berolahraga atau membaca daripada sebelumnya.

Masalah lain dengan hadiah (dan hukuman) adalah bahwa hal itu akan mengubah cara orang berperilaku. Misalnya jika Anda memberikan bonus kepada karyawan Anda, mereka akan fokus pada mendapatkan bonus tersebut, terlepas dari tujuan (perusahaan lainnya) yang lain. Ini akan menciptakan individualisme dan persaingan antara departemen dan karyawan. Kekesalan akan terjadi dan semua orang akan menonton semua orang. Terutama ketika salah satu tujuan Anda adalah "membantu mengukur kinerja individu".

Karyawan lainnya dapat menyangkal aturan permainan dan berhenti. Meningkat turnover akan menjadi masalah baru.

Harap dicatat bahwa banyak saran tentang cara meningkatkan motivasi telah dibuat di komunitas ini .


2
Pierre, sementara saya setuju dengan beberapa hal yang Anda katakan dan temuan dari Daniel Pink, saya tidak benar-benar berpikir mereka berlaku untuk solusi seperti yang dijelaskannya. Akan berbeda jika perwakilan, badge dll terikat pada hadiah uang, tetapi di sini mereka hanya digunakan untuk meningkatkan perilaku yang memiliki makna intrinsik. Dalam beberapa hal, tidak ada bedanya dengan aspek permainan stackexchange yang dapat dikatakan bermanfaat secara keseluruhan. Ini adalah masalah yang kompleks sehingga harus diimplementasikan dengan hati
Homde

2
@ mko: Uang adalah jenis hadiah. Lencana atau reputasi adalah hal lain. Saya percaya mereka memiliki efek yang sama persis.

2
Pierre, aku harus tidak setuju. Tidak hanya hadiah ini murni idealis, tetapi juga diberikan kepada Anda bukan oleh kepala suku Anda, tetapi oleh rekan-rekan Anda. Pengakuan mereka adalah salah satu poin referensi paling penting bagi diri kita sendiri untuk mengukur penguasaan kita dan tujuan dari tindakan kita. Sistem penilaian, lencana, dan skor reputasi hanya mengkuantifikasi umpan balik dan mengembunkan loop. Maksud saya, inilah mengapa SE bekerja.
back2dos

1
Pierre, saya benar-benar merekomendasikan Anda membaca Buku Daniel Pinks "Drive" ini secara mendalam tentang insentif dan motivasi. Ada banyak contoh di mana hadiah uang sebenarnya merugikan sementara hadiah intrinsik tidak '
Homde

1
ya, tetapi jika sebuah lencana, peringkat adalah ukuran yang baik dari itu akan berfungsi untuk menyoroti dan mengarahkan perilaku menuju penghargaan intrinsik. Yaitu saya mungkin tidak peduli bahwa banyak tentang reputasi saya yang sebenarnya tapi saya lakukan ingin menjadi pengembang yang baik. Oleh karena itu perwakilan mungkin baik jika tidak mengukur keterampilan absolut saya, mengukur kemajuan relatif dan memotivasi saya untuk meningkatkannya dan diri saya sendiri. Hal-hal yang tidak dapat kita ukur tidak dapat kita ubah. Bagian yang sulit tentu saja merancang pengukuran untuk benar-benar memiliki makna dan mendorong perilaku yang benar.
Homde

5

Ya bisa

Tetapi hanya jika Anda mendesainnya dengan sangat hati-hati, jika tidak maka akan menjadi bumerang. Saya sudah membuat beberapa komentar tetapi berpikir saya akan merangkum posisi saya

Untuk reputasi, tujuan utamanya adalah untuk memberikan ukuran yang dapat digunakan karyawan untuk melacak peningkatan keterampilan mereka dari waktu ke waktu. Rancang dengan sangat hati-hati dengan hal itu, hal yang sulit datang dengan cara yang baik untuk mengukur keterampilan, saya tidak bisa dari atas kepala saya melakukan itu.

Lencana terutama merupakan hal yang "menyenangkan", saya akan menjauhkan mereka dari masalah yang lebih berorientasi pada keterampilan. Yaitu lencana seperti "burung hantu malam minggu ini" atau grup "Pengiriman! Lencana" tidak masalah. Jika Anda memiliki beberapa lencana berbasis keterampilan seperti "Memperbaiki sebagian besar bug" atau "Bug yang paling banyak dilaporkan" pikirkan dengan sangat hati-hati tentang bagaimana hal itu dapat dirasakan dan dilihat. Lencana harus lebih menonjolkan perilaku daripada mempromosikannya IMO. Pastikan memiliki lencana tim dan individu.

Saya sangat merekomendasikan terhadap lencana negatif, hal-hal ini harusnya menyenangkan dan membuat orang takut membuat kesalahan itu berbahaya. Alih-alih, buat email ramah yang ramah untuk kasus-kasus itu.

Saya sangat merekomendasikan agar mereka tidak memutuskan dan memberikan suara pada lencana. Orang-orang dapat mengirimkan saran mereka untuk lencana tetapi karena pengaruhnya terhadap orang bisa sangat parah, lencana apa yang digunakan harus dibuat dengan keputusan yang cermat dari seseorang yang tahu apa yang mereka lakukan dan bukan suara mayoritas.

Ulasan kode adalah ide yang menarik dan saya kira salah satu cara Anda dapat menghasilkan nilai keterampilan. Menyoroti kode dan mendiskusikannya bisa sangat membantu. Namun, itu mungkin menjadi bumerang, jika semua orang tahu bahwa mereka menilai potensi semua yang mereka tulis pengembangannya mungkin lambat merangkak. Terutama dengan pengembangan berulang di mana Anda kadang-kadang menulis sesuatu dengan cepat dan kemudian menolak Anda tidak ingin perilaku itu.

Mungkin itu bisa diimbangi oleh orang yang mengirimkan kode sendiri atau orang lain hanya bisa mengirimkan kode pada usia tertentu. Namun demikian bisa sulit mengetahui efek apa yang akan terjadi

Pada akhirnya saya pikir Anda harus mencobanya dan melihat mana yang berhasil dan yang tidak, ada buku bagus berjudul Reality yang rusak yang mungkin menarik. Buku Daniel Pinks "Drive" juga wajib dibaca.


2

Menurut pendapat saya, TIDAK , karena itu mengukur bukan praktik yang baik itu sendiri, tetapi gejala (jika orang lain berpikir praktik yang baik).

Mengutip sebuah buku karya Paman Bob (lupa judulnya): Kode yang bagus sepertinya hampir tanpa usaha, itu membuat masalah terlihat sepele, seolah-olah bahasa itu dibuat untuk menulisnya.

Dalam pengalaman saya, kode seperti itu tidak diketahui, dan hanya setelah waktu yang lama menjadi perhatian, bahwa kode ini tidak pernah membuat masalah, dan mungkin kemudian orang ingat, bahwa masalahnya adalah, sebelum pengenalan kode, kekacauan ketidakpastian yang besar dan ketidakjelasan. Kode yang mendapat pujian dalam ulasan biasanya kode yang dilihat oleh pengulas pada hari yang baik ketika tidak berminat untuk melakukan nitpick, dan yang memiliki perubahan paling sedikit.


1
Erm - re: poin pertama Anda - ya tapi itu yang terbaik yang kami miliki bukan? Metrik kode tidak memberikan gambar yang cukup baik sendiri.
Ryan

1
Bukankah itu benar untuk semua jenis metode peninjauan kode?
nikie

Masalahnya adalah bukan Anda mencoba mengukurnya, tetapi Anda menetapkan lingkaran umpan balik antara pengukuran Anda dan, pada dasarnya, motivasi tim. Dalam pengalaman saya, ini mengarah dengan cepat untuk memotivasi tim untuk 'mengalahkan ujian', bukan kode yang lebih baik.
keppla

1
"Kalahkan tes" jauh lebih berlaku untuk metrik daripada tinjauan kode manual. Untuk mengambil argumen 1 Anda ke ekstrim Anda mengatakan bahwa tidak ada cara untuk memutuskan sesuatu itu 'baik'. Yah itu benar tetapi pada tingkat tertentu kita harus menerima bahwa jika cukup banyak orang berpikir sesuatu itu baik, maka itu mungkin baik.
Ryan

1
+1 untuk argumen ke-2 - kode hebat mungkin tidak dicatat.
Ryan

1

Idenya akan membawa dinamika baru ke tim. Jika Anda merasa tim sedang dalam masalah maka ini adalah cara yang baik untuk mengguncang segalanya.

Ingatlah bahwa tidak akan semua unicorn dan pelangi. Beberapa tidak akan menyukai inisiatif ini sehingga produktivitas / kualitas secara keseluruhan dapat menurun. Namun risiko ini mungkin sepadan. Tergantung pada situasi Anda.


1

Saya sarankan menggunakan motivasi ekstrinsik (yang Anda usulkan adalah bentuk motivasi ekstrinsik) untuk memotivasi orang untuk melakukan hal-hal yang "mekanis", berulang dan membosankan, seperti:

  • Datang tepat waktu ke rapat
  • Dapatkan lembar waktu yang dikirimkan tepat waktu
  • Memperbarui dokumentasi
  • Berbagi informasi dengan tim

Saya tidak akan menggunakannya untuk motivasi pada semua jenis pekerjaan yang membutuhkan kreativitas, atau di mana kualitas tidak dapat diukur secara objektif. Misalnya, jika Anda memiliki orang yang membuat widget dan Anda dapat secara otomatis memvalidasi apakah bagian itu baik atau buruk, dan Anda memiliki proses yang tidak akan membiarkan bagian dibuat kecuali mengikuti proses yang disetujui, maka itu produktif untuk memotivasi pekerja dengan imbalan ekstrinsik untuk produktivitas karena proses tidak memungkinkan mereka mengambil jalan pintas untuk membuat lebih banyak unit dengan mengorbankan kualitas.

Jika Anda tidak memiliki perlindungan itu, maka upaya Anda pada motivasi ekstrinsik pasti akan menjadi bumerang. Pemrograman benar-benar masuk dalam kategori ini - kami hanya tidak dapat mengukur kualitas perangkat lunak dengan andal. Itu karena ketika Anda membuat widget, ia meninggalkan pabrik dan tidak memengaruhi pekerjaan yang Anda lakukan pada widget berikutnya, tetapi ketika Anda membuat perangkat lunak, Anda harus terus memperbaikinya berulang kali. Hal-hal yang Anda lakukan sekarang memiliki efek jangka panjang. Efek jangka panjang inilah yang sangat penting tetapi tidak dapat diukur. Motivasi intrinsik adalah motivator yang jauh lebih berguna untuk hal semacam ini.

Itu berarti:

  • Biarkan orang mengambil tanggung jawab atas pekerjaan mereka
  • Dorong orang untuk berbicara satu sama lain tentang apa yang bekerja dengan baik, dan apa yang tidak
  • Tunjukkan penghargaan yang tulus atas pekerjaan orang-orang

Bukankah semacam internal SO melakukan ketiga hal itu, maksud saya mengapa orang mencurahkan begitu banyak waktu untuk SO? Dan poin tentang 'pemungutan suara' adalah bahwa saya pikir itu jauh lebih mungkin untuk menjadi adil, akurat dan berharga dalam bidang seperti ini karena saya sepenuhnya setuju - kami tidak memiliki cara non-obyektif yang baik untuk mengukur kualitas.
Ryan

0

Bagian dari apa yang membuat pekerjaan ini adalah sejumlah besar peserta yang tidak mengenal satu sama lain atau harus bekerja satu sama lain setiap hari. Saya akan berpikir bahwa dalam kelompok kecil, itu akan menjadi lebih banyak cara untuk permainan sistem untuk terlihat bagus atau untuk membuat persaingan Anda untuk promosi terlihat buruk. Inilah sebabnya mengapa evaluasi sebaya formal seringkali merupakan sistem yang buruk. Dalam sebuah kelompok kecil, orang-orang dengan perwakilan terbaik adalah mereka yang paling cerdik secara politis, bukan programmer terbaik.


0

Jawaban singkatnya adalah, ya, itu bisa berhasil.

Jawaban yang sedikit lebih lama adalah, ya, itu bisa berhasil, tetapi bisa juga menjadi bumerang.

Selain menjadi programmer profesional, saya juga seorang analis perilaku amatir.

Salah satu temuan utama dari ilmu perilaku modern adalah bahwa perilaku sangat dipengaruhi oleh konsekuensinya.

Jika Anda mengendalikan konsekuensinya, Anda dapat memengaruhi perilaku hingga taraf tertentu. Tingkatnya tergantung pada seberapa penting konsekuensi spesifik bagi setiap individu yang perilakunya Anda coba ubah, dan seberapa mudah bagi mereka untuk menghindari konsekuensi Anda dan menemukan orang lain yang mereka inginkan.

Sebagai seorang programmer profesional, salah satu konsekuensi dari penulisan kode adalah saya dibayar; berhenti membayar saya, dan saya akan berhenti muncul lama. Bayaran adalah konsekuensi yang sangat penting bagi saya (saya membesarkan keluarga), dan tidak ada konsekuensi lain di perusahaan saya saat ini bahwa saya bersedia bekerja untuk bukannya dibayar.

Jika Anda adalah bos saya, Anda akan bisa memutuskan konsekuensi apa (insentif, penguat) yang ditawarkan kepada saya. Tetapi Anda tidak bisa memutuskan bagaimana saya memandang mereka. Misalnya, bos saya mungkin memutuskan untuk menawarkan tempat parkir khusus jika saya dipilih sebagai "Coder of the Month". Jika saya tinggal di San Francisco atau Kota New York dan saya mengendarai mobil, saya mungkin mau bekerja untuk itu. Tapi tempat saya tinggal sekarang, parkir tidak masalah, dan saya bisa berjalan kaki ke tempat kerja.

Dalam pengalaman saya, risiko terbesar yang Anda jalankan dengan menerapkan program seperti SO di tempat kerja adalah bahwa Anda mungkin dianggap menawarkan suara sebaya sebagai pengganti membayar orang berapa nilainya.


"Salah satu temuan utama dari ilmu perilaku modern adalah bahwa perilaku sangat dipengaruhi oleh konsekuensinya." Itu temuan? Betulkah?? Bukankah itu sesuatu yang kita semua pelajari sejak dini dalam kehidupan kita? Jangan menyentuh hal-hal panas karena konsekuensinya menyakitkan! Pikiran Anda, saya masih minum terlalu banyak kadang-kadang ...
Ryan

@Ryan: Anda akan berpikir. Tetapi "jangan menyentuh hal-hal panas karena itu menyakitkan" tidak membuat ilmu. Menunjukkan bagaimana membuat perubahan perilaku dapat diukur, diulang, direplikasi, dan dapat diprediksi - itulah yang membuat ilmu perilaku menjadi ilmu.
Mike Sherrill 'Cat Recall'
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.