Bagaimana saya membuat orang berhenti bikeshedding (fokus pada hal-hal sepele)?


139

Saya telah ditugaskan untuk mengajarkan basis kode baru kepada tim lain, tetapi saya terus mengalami masalah. Setiap kali saya pergi untuk benar-benar berjalan melalui kode dengan orang-orang, kami tidak mendapatkan terlalu jauh sebelum seluruh latihan berubah menjadi bikeshedding (anggota organisasi yang memberikan bobot yang tidak proporsional untuk masalah sepele) latihan. Karena mereka tidak tahu basis kode, tetapi berpikir mereka perlu membantu memperbaikinya, mereka fokus pada hal-hal yang dapat mereka pahami:

Why is that named that? (2 menit untuk menjelaskan alasannya, 10+ menit memperdebatkan nama baru)

Why is that an abstract base class rather than an interface? (2 menit untuk menjelaskan, 10+ menit memperdebatkan manfaat relatif dari keputusan ini)

...dan seterusnya. Sekarang, jangan salah paham - nama baik dan desain bagus, konsisten adalah penting, tetapi kita tidak pernah membahas apa yang sebenarnya dilakukan kode atau bagaimana sistem dirancang dengan cara yang berarti. Saya telah melakukan beberapa pertemuan wasit untuk mengeluarkan orang-orang dari garis singgung ini, tetapi mereka pergi - terganggu oleh kode apa yang akan / seharusnya terjadi ketika kesederhanaan hewan peliharaan mereka diperbaiki, dan mereka kehilangan gambaran yang lebih besar.

Jadi kami mencoba lagi nanti (atau dengan bagian basis kode yang berbeda) dan karena orang tidak mendapatkan pengetahuan yang cukup untuk mengatasi efek bikeshedding, itu berulang.

Saya sudah mencoba grup yang lebih kecil, grup yang lebih besar, kode, papan tulis, diagram visio, dinding teks raksasa, membiarkan mereka berdebat sampai mati, memotong argumen dengan segera ... beberapa membantu lebih dari yang lain, tetapi tidak ada yang berhasil . Sial, saya bahkan mencoba meminta orang lain dari tim saya menjelaskannya karena saya pikir mungkin saya buruk dalam menjelaskan berbagai hal.

Jadi, bagaimana Anda cukup mendidik programmer lain sehingga mereka berhenti memfokuskan pada hal-hal sepele dan dapat berkontribusi untuk desain?


44
Saya benci mengatakannya, tetapi bagi saya sepertinya fenomena ini menggambarkan lebih banyak masalah dengan basis kode daripada dengan para pendatang baru.
Nicole

30
Sudahkah Anda mencoba menunda pertanyaan sampai akhir? "Tunggu beberapa menit lagi dan saya bisa jelaskan di akhir" dan kemudian hanya mendorong melalui seluruh konten. Mungkin beberapa dari pertanyaan ini akan menjawab sendiri
jozefg

21
@NickC, saya percaya bahwa kodenya bagus atau tidak, tidak ada hubungannya dengan bagaimana Anda memahaminya, bagaimana Anda mengelola untuk mendapatkan gambaran besar yang jelas tentangnya. Membuang-buang waktu untuk detail kecil sejak bepergian tanpa meluangkan waktu untuk mendapatkan gambaran besar awal adalah buruk dan tidak akan pernah membantu dalam memperbaiki kode buruk potensial itu.
Shivan Dragon

11
Apa tujuan mengajar seseorang basis kode? Mungkin Anda dapat mengomunikasikan tujuan itu dengan lebih jelas, dan mengapa itu penting, sehingga mereka dapat melihat bahwa memperdebatkan nama baru untuk suatu objek mengalihkan perhatian dari tujuan itu dan harus disediakan untuk pertemuan lain.
LarsH

56
Ada saran bagus dalam jawaban ini. Secara singkat saya akan menambahkan: pertimbangkan untuk menggunakan "proses" sebagai sekutu Anda. Ketika seseorang mengatakan "desain ini di bawah optimal" respons yang benar adalah "sangat baik, saya senang Anda memperhatikan hal itu. Setelah pertemuan ini, silakan masukkan bug di database pelacakan dengan deskripsi rinci masalah dan perbaikan yang Anda usulkan. Tim triase akan meninjau proposal Anda, memprioritaskannya terhadap item pekerjaan lainnya, dan menugaskannya kepada pengembang yang tepat untuk memperbaikinya setelah semua item dengan prioritas lebih tinggi diperbaiki. Pindah ... "
Eric Lippert

Jawaban:


159

Saya pikir masalahnya adalah tugas: "Saya telah ditugaskan untuk mengajar tim lain basis kode baru".

Anda telah diberikan pekerjaan yang salah, atau mungkin salah mengartikan pekerjaan yang telah Anda berikan.

Dengan mempresentasikan di tingkat kode, Anda mengundang pemikiran tingkat kode.

Mulai dari level sistem dan sajikan desain dan pilihan desain yang dibuat. Jangan izinkan diskusi panjang: Anda tidak memeriksanya. Izinkan pertanyaan: Anda ingin mereka memahami sistem. Jika orang "akan melakukannya secara berbeda", baiklah. Mungkin setuju. Atau tidak. Tapi lanjutkan. Seperti sekarang ini.

Ketika Anda sampai ke level kode, Anda sudah membuatnya siap dengan terminologi sistem. Nama-nama (saya anggap) akan masuk akal. Sama seperti di atas: tidak ada diskusi panjang, pertanyaan untuk pemahaman. Berpindah.

Sekarang atur beberapa masalah kelas untuk diselesaikan. Bagaimana kita bisa membuat peningkatan X? Pilih sesuatu yang tidak sepele yang "sesuai dengan alur" desain sistem, dan kerjakan apa yang akan Anda ubah. Mereka harus mendapatkan alasan sistem sekarang. Pilih perangkat tambahan lain yang dapat merusak sistem jika dilakukan dengan salah, dan tunjukkan bagaimana itu dapat dilakukan dengan benar. Itu seharusnya menjadi momen Ah Ha bagi mereka. Beberapa bahkan mungkin mengalahkan Anda untuk itu!

Ini adalah pertunjukan yang sulit, terutama setelah awal yang salah yang Anda miliki. Kedengarannya seperti Anda telah menginvestasikan banyak waktu dan usaha, dan mungkin ada sedikit perasaan saya versus mereka. 'Fess, dan mulai lagi. Kami berasumsi bahwa mereka adalah orang pintar. Beri mereka tantangan untuk berpikir di tingkat yang lebih tinggi. Dan bagi grup yang sudah ada dengan memilih berbagai bagian tim yang berbeda untuk sesi baru.


3
Saya telah melakukan sedikit instruksi desain tingkat tinggi terlebih dahulu, serta pelatihan tentang beberapa teknologi baru / asing (wadah IoC, dinamika) untuk membantu persiapan. Pelatihan itu berjalan cukup baik. Ini poin bagus untuk diangkat.
Telastyn

+1 karena saya tidak mencoba untuk bertarung dengan orang-orang dengan "peretasan psikis" seperti "Saya akan menjawab pertanyaan-pertanyaan Anda di luar dan di waktu Anda!" melainkan mengubah sudut pandang
Buksy

3
Jawaban yang fantastis. Saya terutama menyukai saran untuk membuat fokus menjadi 'apa yang dilakukannya' daripada 'apa yang disebut komponen internal'.
Daniel Hollinrake

66

"Parkirkan mereka". Di awal pelajaran, jelaskan apa yang akan Anda diskusikan, dan jelaskan apa yang dianggap Off Topic. Jika Anda ditanya pertanyaan yang jelas-jelas PL, katakan demikian dan teruskan. Jika mereka kembali ke sana, tulis pertanyaan di papan tulis (Ini sangat penting) untuk diskusi nanti dan lanjutkan. Di akhir pelajaran, ketika mereka berada di waktu mereka sendiri, bukan milikmu, perhatikan seberapa cepat pertanyaan-pertanyaan itu diselesaikan.


8
+1 Dengan cara itu orang merasa tidak diabaikan.
andy256

Saya setuju dengan ini. JIKA masalahnya terlalu lama membahas hal-hal yang tidak relevan maka jangan membahas hal-hal yang tidak relevan ...
Chris

7
Mungkin alih-alih meluangkan waktu semua orang dengan menulis pertanyaan PL di papan tulis, tanyakan si penanya untuk mencatatnya (di halaman wiki yang ditunjuk, masalah JIRA, di mana pun).
LarsH

14
Saya pikir tindakan fisik meluangkan waktu untuk menulis pertanyaan mereka di papan tulis dengan jelas menunjukkan kepada penanya bahwa Anda menunda pertanyaan mereka (daripada mengabaikannya) dan menunjukkan kepada seluruh hadirin yang menanyakan semua pertanyaan dan dengan demikian menunda kemajuan.
JBRWilkinson

1
@ LarsH - tepatnya. Dengan memakai papan tulis, agar semua orang bisa melihatnya, percakapan terhenti. Jika itu muncul lagi, instruktur hanya menunjuk ke pertanyaan dan mengatakan "Saya berjanji kita akan kembali ke sana".
mattnz

21

Tetapkan harapan dengan benar dan jujur, terbuka, dan terbuka.

Pastikan tujuan Anda terbuka dan transparan.

Mulailah diskusi dengan tampilan tingkat tinggi seperti yang dipromosikan oleh andy256 (+1) tetapi juga pastikan bahwa Anda memasukkan tujuan Anda, misalnya

"... seperti yang kita lihat pada masalah ini, mari kita pastikan kita tidak fokus pada x, y dan z. Mari kita juga memastikan bahwa kita tidak melihat detail implementasi seperti a, b, c atau detail sepele seperti j, k, L. Saya tahu pasti ada banyak detail dalam kode dan detail hal-hal yang dapat diatasi, ditingkatkan atau dibuat lebih standar, tetapi mari kita coba dan lihat apa yang sebenarnya dicapai di level yang lebih tinggi terlebih dahulu. "


+1 untuk 2 kalimat pertama. Namun, mengatakan pada orang untuk tidak memikirkan sesuatu bukanlah cara yang baik untuk membuat mereka tidak memikirkannya. "Apa pun yang kamu lakukan, jangan pikirkan unicorn pink." Sebelum saya menyebutkan unicorn merah muda, apakah Anda memikirkannya? Mungkin tidak. Jika sebaliknya saya berkata "Mari kita tidak terganggu oleh hewan imajiner dan sebaliknya fokus pada hewan Australia" maka koala dan kanguru mungkin terjadi pada Anda, tetapi mungkin bukan unicorn merah muda.
Michael Shaw

Poin bagus. Namun poin sebenarnya adalah bukan untuk menghentikan orang berpikir (dan tidak mengatakan) tetapi untuk menghindari orang masuk ke dalam percakapan berlarut-larut yang bertemu pembunuh dan pengisap moral. Orang akan selalu berpikir banyak hal yang tidak terucapkan. Tidak apa-apa. Dalam situasi bisnis profesional, beberapa hal dikatakan dan banyak yang tidak.
Michael Durrant

17

Jadi, bagaimana Anda cukup mendidik programmer lain sehingga mereka berhenti memfokuskan pada hal-hal sepele dan dapat berkontribusi untuk desain?

Pertama, jangan menganggap kekhawatiran mereka sebagai "hal sepele" atau "bikeshedding". Itu adalah kata-kata menghakimi, dan mereka menghina. Kekhawatiran mereka valid. Mereka tidak penting saat ini.

Kunci dari setiap rapat yang baik adalah agar semua orang tahu:

  • mengapa Anda mengadakan rapat dan
  • apa yang Anda harapkan dari itu
  • berapa lama itu akan bertahan

Nyatakan hal-hal ini di muka, secara eksplisit, dan jelaskan tujuannya.

Misalnya, Anda mungkin berkata: "Rapat ini untuk saya untuk membiasakan Anda dengan paket Foo dan bagaimana itu digunakan dalam modul pelaporan kami. Tujuan saya adalah membuat Anda cukup memahami tentang Foo sehingga Anda dapat bekerja pada proyek Laporan Bar yang akan datang minggu depan. Saya ingin kita selesai dalam 90 menit ke depan. "

Kemudian, ketika sebuah topik muncul, itu bisa seperti ini:

Orang baru: "Mengapa FooWidget diimplementasikan sebagai pola fasad?"

Anda: "Yah, saya pikir itu karena (penjelasan singkat tentang keputusan desain)" atau "Saya tidak tahu."

Jika jawabannya cukup, itu bagus. Jika tidak, dan itu berlanjut:

NP: "Tidakkah Anda pikir itu akan lebih baik dilakukan sebagai seorang lajang?"

Anda: "Saya belum benar-benar memikirkannya, tetapi saya ingin terus bergerak maju dengan menjelaskan bagaimana FooWidget bekerja."

NP: "Tapi jika itu dilakukan sebagai singleton maka kita bisa -"

Anda: "Saya minta maaf mengganggu, tetapi saya harus tetap fokus pada cara kerja FooWidget ini. Rapat ini hanya dijadwalkan hingga pukul 11:00 dan kami harus banyak melewatinya. Diskusi desain harus menunggu waktu lain . "

Setelah melalui satu atau dua kali, Anda dapat menyingkatnya menjadi "Itu di luar ruang lingkup pertemuan ini."

Perhatikan bahwa Anda tidak mengatakan "Itu bodoh untuk dikhawatirkan" atau "Tidak masalah" atau "Diam" atau "Anda terlalu baru untuk mendapat masukan." Anda hanya memfokuskan pertemuan pada apa yang perlu dilakukan dan waktu yang diperlukan.


1
Mudah mengetahui kapan presenter benar-benar tidak tertarik dengan umpan balik. Pertemuan itu berlangsung cepat. Tidak ada yang peduli.
chux

4

Dalam organisasi tertentu Anda tidak akan pernah bisa mencapai ini. Banyak organisasi menghargai perselisihan politik dan cara mendaki tangga lebih dari kapasitas intelektual, ketekunan, dan kesetiaan. Dan mengapa tidak? Memanjat tangga menempatkan orang pada posisi kekuasaan, memungkinkan mereka untuk meningkatkan kehidupan pribadi mereka dengan pendapatan yang lebih bebas dan benar-benar tidak pernah menjadi usang.

Bandingkan perselisihan kekuasaan ini dengan penyelesaian masalah aktual, pemikiran abstrak, dan pengambilan keputusan tentang masalah-masalah sulit yang mereka mungkin bertanggung jawab atas konsekuensi di kemudian hari, dan banyak karyawan sangat membebani upaya untuk bersepeda sebanyak mungkin.

Satu-satunya saran yang saya sarankan adalah agar Anda membuatnya lebih jelas, dalam konteks organisasi Anda, jika mungkin, bahwa nasib pribadi para peserta ini tergantung pada pemahaman, kontribusi, dan upaya mereka terhadap masalah nyata yang Anda coba selesaikan. Jika itu arsitektur perusahaan, yang dinyatakan dalam basis kode -er ini dan semua kegagalannya, itu saja. Jelaskan kepada mereka bahwa mereka harus memberikan masukan yang berarti tentang hal itu . Bukan sembarang keacakan, yang kebetulan adalah kesayangan seseorang yang senior atau lainnya dan akan mendapatkan poin-poin brownies yang bagus dengan menyetujui dengan seseorang senior tersebut.

Ini sering kali sulit dilakukan, karena seseorang senior biasanya tidak memahami teknologi yang terjadi, tidak tertarik, dan sayangnya, mengendalikan bahan mentah: waktu karyawan; menyewa & memecat, politik ruang konferensi, promosi, dll. dengan serius, dan lain-lain.


3

Apa yang Anda sebut bikeshedding, saya sebut mengubah aliran pemikiran seseorang menjadi pemikiran kita sendiri. Dengan mendiskusikan nama, pola, mereka dapat memahami kode ke dalam istilah mereka sendiri dan tidak ada cara untuk mencegahnya, itu diperlukan.

Selain itu, tidak perlu melakukan langkah-langkah yang sangat terperinci dari seluruh basis kode, karena detail akan dilupakan jauh sebelum mereka mengerjakannya.

Berdasarkan dua ide ini, saya akan menyarankan untuk memecah basis kode menjadi unit, dan peserta didik menjadi kelompok dua orang. Untuk setiap unit kode, masing-masing kelompok akan memiliki, katakanlah 25 menit (tergantung pada LOC tentunya), untuk dapat melakukan walkthrough 5-10 menit dari kode ke yang lain. Tiga menit pertanyaan dan ulangi dengan unit berikutnya. Jelaskan adalah kata kuncinya; mereka harus memastikan yang lain mengerti semua itu.

Anda hanya akan berada di sana untuk menegakkan waktu, tidak ada topik di luar dan mengendalikan unit telah cukup dipahami. Mereka akan menjadi aktor pembelajaran mereka dan akan lebih fokus pada menjelaskan kepada yang lain daripada bikeshedding.

Anda mungkin memerlukan skema gambar tangan tingkat tinggi dari mereka dari unit kode, yang akan disalin dan disimpan pada dokumen tim-bersama, sehingga mereka memiliki sesuatu yang nyata untuk dirujuk di masa depan. Itu bagus untuk menyimpan kenangan juga.

Maaf jika Anda sudah mencobanya ...


1

Sudahkah Anda mencoba membuat pra-pelajaran yang orang pandang secara individual?

Buat video atau presentasi singkat yang menjelaskan konten, bagaimana kode bekerja, atau pada dasarnya semua yang ingin Anda ajarkan dalam format di mana mereka perlu melihatnya sendiri dan mempelajari informasi yang Anda coba ajarkan kepada mereka.

Kemudian Anda menggunakan sesi berbasis tim untuk membahas masalah yang terkait dengan konten. Anda perlu mengidentifikasi dengan jelas bahwa sesi tim adalah untuk membahas dan mengatasi masalah yang terkait dengan konten saja.

Jika Anda memberikan pelajaran kepada orang-orang secara individual, Anda mungkin dapat menghindari masalah sosial lainnya di mana satu masalah dapat menjadi suara kelompok sebagai kolektif dan mengalihkan perhatian dari tujuan sebenarnya dari pelajaran.


13
Tidaak ......., bukan video ..... "Death By Powerpoint" telah digantikan oleh nasib yang lebih buruk ......, Meskipun itu akan memiliki efek yang diinginkan dari menghentikan pertanyaan - mengancam mereka dengan lebih banyak video yang memerlukan waktu 10 menit untuk menjelaskan apa yang dapat dibaca dalam 30 dan dipahami dalam hitungan detik ....
mattnz

6
+1 mattnz Masalah komunikasi tidak mungkin diperbaiki dengan interaksi satu arah.
Michael Durrant

1
Saya tidak ingin dijeda walaupun saya berada di video! Format video / codec apa yang menonaktifkan jeda? :) :) :)
Kaz

1

Cobalah mengajari mereka desain basis kode terlebih dahulu, membimbing mereka di sekitar arsitektur, SEBELUM Anda mulai melihat contoh-contoh spesifik. Dengan begitu mereka dapat melihat bagaimana contoh kode yang Anda lihat cocok dengan gambar yang lebih besar. Pikirkan tentang bagaimana program pelatihan Anda disusun. Dan sertakan motivasi bisnis di balik desain.

Saya menghabiskan beberapa tahun melatih pengembang lain, dan saya tidak pernah masuk ke kode sebelum menunjukkan kepada mereka bagaimana sistem dipasang bersama. Kemudian ketika saya membuat mereka melakukan latihan kode dalam kerangka pertanyaan terstruktur dan sesuai topik.

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.