Menghentikan diskusi teknis tanpa akhir dan membuat keputusan

Saya selalu menemukan orang-orang yang suka menggedor selama berabad-abad atas "hal teknis" terkecil.

Jangan salah paham, saya seorang programmer geek yang menyukai apa yang saya lakukan, tetapi Anda tahu jenis percakapannya.

• Mac jauh lebih baik daripada Windows
• Jangan gunakan Untuk Setiap loop, gunakan loop Sementara
• Jangan membeli PC berbasis Intel, dapatkan PC berbasis AMD.
• Kita harus menggunakan satu wadah IoC di atas yang lain.

Semua "hal" ini memiliki pro dan kontra yang valid untuk kedua belah pihak, dan Anda tidak akan pernah mendapatkan jawaban yang "benar", dan orang tersebut tidak akan pernah menyetujui intinya. (tentu saja akan ada beberapa di mana ada jawaban, mungkin :).

Pertanyaan saya (saya akan ke sana !!) adalah: Dalam tim perangkat lunak, bagaimana Anda memotong diskusi panjang ini tanpa menghambat inovasi, sehingga keputusan dapat dibuat dan Anda bisa menyelesaikan masalah bisnis yang sebenarnya.

Masalah 1. Beberapa orang tidak suka kehilangan. Jika mereka tidak memanggil tembakan, mereka akan berdebat sampai mereka memanggil tembakan melalui gesekan.

Masalah 2. Tidak ada yang benar-benar dipertaruhkan, jadi berdebat ditoleransi.

Tidak ada yang dipertaruhkan? Iya nih. Sebagian besar keputusan memiliki dampak hampir nol dolar. Fakta bahwa ia datang ke "menggedor selama berabad-abad" berarti bahwa kedua pilihan secara efektif identik.

Melakukan apa?

1. Sadarilah bahwa tidak ada yang dipertaruhkan.

2. Sadarilah bahwa dalam 2 atau 3 tahun, seluruh subjek akan dibuka kembali karena sesuatu di luar organisasi berubah.

3. Lempar koin. Serius. Pilih saja sesuatu dan lanjutkan. Beberapa orang akan melihat kekonyolan dalam berdebat. Beberapa orang kemudian akan memperdebatkan sifat koin yang dilemparkan. Jika orang tidak dapat puas dengan lemparan koin, mereka memiliki masalah ego dan perlu belajar bahwa (a) tidak ada yang dipertaruhkan dan (b) keputusan akan diubah dalam beberapa tahun.

Jika mereka tidak tahu bahwa tidak ada yang dipertaruhkan, mereka perlu menuliskan nilai dolar dari kedua sisi argumen. Pada titik tertentu, seseorang mungkin melihat bahwa lebih banyak jam kerja dihabiskan untuk analisis daripada keputusan yang sebenarnya. Pelemparan koin menghasilkan nilai yang sama dengan biaya yang lebih rendah.

Beberapa hal untuk dipertimbangkan:

1. Hanya terima argumen yang dapat dihitung. Jika seseorang mengatakan itu akan menghemat waktu, minta mereka untuk mengukurnya dan menahan mereka pada jawabannya. Dengan cara ini, jika mereka berbicara tentang sampah, mereka hanya dapat melakukannya sebelum semua orang tahu bahwa mereka adalah flush yang rusak.

2. Buat orang untuk bertanggung jawab atas rekomendasi mereka. Jelaskan bahwa pada akhir tahun jika mereka telah melakukan panggilan buruk yang akan menjadi bagian dari penilaian mereka. Saya tidak keberatan berdebat tapi saya ingin orang-orang dengan keberanian keyakinan mereka - jika Anda akan bersumpah sesuatu itu hebat dan mengharapkan kami untuk mengadopsinya, Anda sebaiknya bisa hidup dengan konsekuensinya.

Ini adalah hal-hal nyata untuk menjauh dari dua masalah S.Lott - bahwa beberapa orang tidak suka kehilangan dan bahwa tidak ada yang dipertaruhkan. Respons saya dipertaruhkan sehingga tidak ada perdebatan untuk diperdebatkan.

1. Diskusi timebox. - Jika dibutuhkan lebih dari 5 menit untuk masing-masing pihak untuk menyatakan kasus mereka, maka itu terlalu rumit. Kami sebenarnya menggunakan timer dapur untuk ini . Mereka bekerja luar biasa, dan biaya sekitar 5 dolar.
2. Mengharuskan peserta berdebat dengan data dan pengalaman.
3. Kami menyimpan opsi di atas meja. Setelah masing-masing pihak memiliki waktu, kami menghabiskan 5 menit untuk membahas implikasi dari setiap pendekatan. Setelah 20 menit, kami keluar dan melakukannya (mengimplementasikannya). Jika tidak berhasil, maka kita pergi dengan pendekatan lain.

Aturannya sederhana. Setelah Anda tidak tahu apa yang harus dipilih - pikirkan apa yang lebih baik untuk perusahaan.

Ya, pilihan Intel v AMD tidak semudah itu. Tapi mana yang lebih baik untuk perusahaan Anda? Misalnya, jika ada seseorang yang bertanggung jawab untuk memesan barang dan akan butuh waktu lama baginya untuk memesan PC berbasis prosesor AMD, tetapi berbasis Intel dapat dipesan dalam satu menit dan Anda benar-benar tidak peduli akan seperti apa - pesan saja yang berbasis Intel karena itu lebih baik untuk perusahaan.

Biasanya diskusi ini benar-benar hanya bikeshedding . Orang-orang berdebat format transfer mana atau menyimpan data mana yang akan digunakan dan banyak detail lainnya yang harus benar-benar transparan untuk semua komponen tetapi yang menerapkan detail yang sangat. Tidak ada yang peduli selama komponen memenuhi kontrak desain dan mereka yang bertanggung jawab akan dapat menanggapi perubahan kontrak dalam jumlah waktu yang wajar.

Sebagian besar dari semua masalah teknis yang Anda temui dalam pengembangan perangkat lunak adalah masalah bikeshedding. Hanya karena mereka sudah memiliki solusi dan satu-satunya pertanyaan adalah, solusi mana yang ingin Anda pilih.
Anda seharusnya tidak mengunci diri Anda dalam keputusan seperti itu. Anda harus mengunci keputusan seperti itu ke dalam lapisan abstraksi yang memisahkan aplikasi Anda dari detail tersebut .
Masalah yang sangat penting dalam pengembangan perangkat lunak adalah masalah desain di tingkat fitur dan sistem. Yang lainnya sekunder.

Jadi jangan benar-benar memulai debat semacam itu. Fokuskan energi Anda dalam membagi proyek Anda menjadi bagian-bagian independen. Ini menghasilkan perangkat lunak, yang lebih kuat dan fleksibel. Dan jika Anda dapat menentukan dengan tepat keputusan teknis yang memiliki kerugian yang jelas (sesuatu yang hanya dapat Anda lakukan, begitu Anda memiliki perangkat lunak yang sedang berjalan), maka Anda dapat membuat keputusan yang berbeda tanpa mempengaruhi sisa sistem.

Standardisasi adalah satu pendekatan

Tim Anda harus mencapai konsensus tentang apa yang akan mereka adopsi sebagai standar untuk pengembangan dan kemudian berpegang teguh pada itu untuk jangka waktu yang wajar (diputuskan oleh tim). Jika standar gagal, maka yang baru diadopsi mungkin dari sejumlah kerangka kerja solusi yang mungkin.

"Hei, PC-PC itu pada akhirnya tidak berguna, mari kita coba Mac!"

atau

"Sudah kubilang! Musim semi jauh lebih baik daripada EJB."

Dan seterusnya.

Memiliki standar berarti bahwa kode menjadi lebih mudah untuk bekerja dengan lintas tim yang pada gilirannya mengarah ke lingkungan yang lebih produktif.

Saat ini saya sedang menguji pendekatan, kode bernama "Konklaf Kepausan" dan cukup menjanjikan. Hal ini didasarkan pada sebuah cerita, bahwa selama salah satu pemilihan Paus ada "jalan buntu" dan para kardinal tidak bisa membuat pilihan. Entity menjadi tuan rumah pemilihan (kemungkinan besar beberapa City mayor) pertama kali mengunci para kardinal di sebuah gedung, kemudian secara drastis mengurangi pasokan makanan dan kemudian menyingkirkan atap bangunan untuk membuat perdebatan bahkan menjadi kurang nyaman. Seperti yang diharapkan, para kardinal membuat pilihan setelah atap dilepas mengakhiri jalan buntu tiga tahun.

Jadi pendekatan saya adalah bahwa ketika orang tidak setuju pada beberapa hal, mereka dipaksa untuk membahasnya sampai mereka punya pilihan. Saya tidak memberikan ketidaknyamanan lainnya, bahkan kendala waktu dan tentu saja saya tidak melakukan apa-apa dengan atap :). Yang saya lakukan adalah terus-menerus mengangkat masalah ini setiap hari. Jika seseorang berkata, "Kami tidak bisa membuat keputusan," saya menjawab dengan "Ya ... Anda harus". Sejauh ini saya belum pernah bertemu seseorang yang begitu kecanduan dengan detail teknologi kecil sebanyak itu. Setelah banyak pertemuan, mereka cenderung mencari kompromi seperti halnya para kardinal.

Saya setuju bahwa ini lebih merupakan diskusi yang berkelanjutan, daripada memotong melalui itu. Namun diskusi tidak berkesudahan dan sebagai nilai tambah, beberapa orang setelah "pertemuan" semacam itu cenderung menghindari perdebatan teknologi kecil, yang membuat segalanya lebih nyaman bagi seluruh tim.

Saya sudah membaca di suatu tempat daripada Anda tidak boleh bepergian lebih dari 6 bersama-sama jika Anda perlu menyetujui di mana Anda akan pergi dan apa yang harus dilakukan, karena Anda tidak akan mencapai konsensus.

Ini adalah contoh utama mengapa harus ada orang dengan kekuatan yang menentukan. Dalam contoh khusus ini, orang tersebut perlu membuat keputusan dan mengatakan "harus seperti ini", dan yang lain perlu menghormati keputusan itu sehingga pekerjaan nyata dapat dilakukan.

Jika keputusan itu kemudian terbukti buruk, Anda setidaknya tahu pasti, dan dapat belajar darinya.

Salah satu pendekatan adalah dengan memilih dan bekerja dengan baik dalam tim berukuran lebih kecil.

Sementara dua orang mungkin sedang mengobrol; pindahkan ke forum terbuka ... debat untuk jumlah waktu N kemudian memegang suara dengan mengangkat tangan.

Sederhana namun demokratis dan memungkinkan Anda untuk bergerak maju.

Pertanyaan serupa bisa berupa:

Bagaimana cara menghentikan perang agama / api di forum?

Saya pikir @ S.Lott benar dalam komentarnya, jika satu-satunya poin adalah "diskusi", "berjalan pergi" atau mengabaikannya mungkin satu-satunya jawaban. Saya telah menggunakan teknik itu di masa lalu.

Jika intinya adalah untuk mencapai solusi, timbang pro / kontra untuk domain yang dimaksud, tetapkan batas waktu dan (mengangguk ke Nike) lakukan saja.

Idealnya - IMO - tokoh teknologi atau otoritas mengatakan, "oke, terima kasih atas poin Anda, kami ..." suara dadu roll "... sesuai dengan ide ini-dan-itu." dan semua orang pergi dan duduk.

Geekery atas poin yang sangat kecil telah menyia-nyiakan banyak waktu pertemuan saya, dan saya tidak ingin mendengarnya lagi. : - /

Saya menemukan bahwa ketika Anda memfokuskan pembicaraan bukan pada alternatif mana yang benar tetapi pada apa konsekuensi dari memilih yang salah, Anda cenderung untuk tidak menjadi terlalu macet. Jika kita dapat mencapai sebuah konsensus bahwa meskipun A benar, B tidak akan membunuh kita, tidak ada yang terlalu peduli kecuali kita berakhir dengan B. Jika kita tidak dapat mencapai konsensus itu, itu umumnya karena ada masalah nyata yang harus kita atasi.

Yang utama adalah kita harus menjadi dewasa, dan memahami bahwa kita tidak selalu bisa saling setuju, yang besar dan dewasa adalah belajar dari satu sama lain, mengapa kita memiliki posisi yang kita miliki, dan mungkin terkait dengan milikku pertanyaan, pelajari pengalaman apa dan alasannya. Kemudian kita bisa membuat opini sendiri dan terkutuk atau tidak.

Saya pribadi tidak membutuhkan atau berharap orang lain setuju dengan saya, itu akan menyenangkan, tetapi tidak penting. Dan sampai titik ini, saya mengutip Voltaire.

"Aku mungkin tidak setuju dengan apa yang kamu katakan, tapi aku akan membela sampai mati, hakmu untuk mengatakannya." -Voltaire, Filsuf Abad ke-5

Setiap pertemuan harus memiliki ketua yang bertanggung jawab atas agenda dan menjaga ketertiban (dan mengambil menit, meskipun mereka dapat mendelegasikan tugas ini kepada orang lain jika pertemuan itu terlalu besar bagi mereka untuk menangani semuanya). Tugas ketua adalah memberi tahu seseorang untuk berhenti berdebat ("kawan, harap luring" dalam pembicaraan perusahaan).

Jika pertemuan itu tidak layak mengangkat ketua, itu bukan pertemuan yang layak untuk dijalani. Anda mungkin mengobrol di watercooler.

Orang bisa mengatakan "lebih mudah diucapkan daripada dilakukan, quant_dev". Nah ... ketua alami adalah pemimpin tim, manajer proyek, manajer tim. Mereka harus memiliki otoritas yang diperlukan. Rapat di mana tidak ada yang tahu siapa yang benar-benar memimpin rapat adalah tanda-tanda kekacauan dalam organisasi, masalah yang lebih dalam yang perlu dipecahkan.

Selesaikan masalah umum terlebih dahulu: kita membutuhkan server web, server aplikasi, DB, dll.

Untuk perdebatan tentang DB atau server mana yang akan digunakan, parkir item-item itu untuk pertemuan lain.

Selama pertemuan berikutnya, biarkan diskusi untuk "daftar pendek" penawaran potensial misalnya MySQl, MS SQL Server, Postgres, dll.

Izinkan anggota tim menyuarakan pendapat mereka, tetapi minta mereka mendukung mereka dengan fakta. Produk X menyebalkan! Tidak memotongnya, Produk Y tidak skala! Terlalu kabur. Dll

Setelah semua detail keluar dan di atas meja, Anda perlu memberikan suaranya atau sebagai pimpinan tim membuat keputusan eksekutif.

Jika Anda perlu mengeluarkan pemenang yang jelas atau mengonfirmasi dukungan / kekurangan untuk fitur / konsep, silakan luangkan waktu untuk melakukan POC (Proof Of Concept) tetapi sadari ini akan membutuhkan waktu dan ada kecenderungan bagi pengembang untuk ingin menjalankan dengan apa pun yang mereka mulai dengan ... Pastikan untuk memverifikasi hambatan / masalah teknologi sebelum pergi dengan POC.

Sebagai pemimpin tim, saya merasa itu tergantung jika keputusan harus dibuat di sini dan sekarang.

Jika harus maka saya mencari yang dengan biaya pembalikan terendah. Selalu penting, sebagai tim pengembangan, untuk mengetahui bahwa keputusan Anda mungkin salah, Anda mungkin harus membuat pilihan yang berani dan mengubah pikiran Anda. Biaya melakukannya harus selalu diminimalkan.

Jika bisa menunggu maka pertimbangkan fakta bahwa tidak satu pun dari pihak yang berselisih memiliki semua fakta. Minta mereka untuk pergi dan meneliti lebih lanjut dan melakukan penelitian sendiri.

Apakah kita selalu melakukan ini dalam panasnya pertempuran? Tidak, terutama ketika saya salah satu dari mereka yang memiliki pendapat yang panas (saya tidak mengklaim sebagai sempurna). Tetapi saya berpikir bahwa ini adalah cara untuk mendekati situasi seperti itu. Time-boxing sepertinya tidak pernah membuat semua orang setuju, itu hanya mengarah pada argumen yang tidak tertutup.

Kecuali jika Anda memiliki anggota tim yang sulit, Anda biasanya tidak memiliki perdebatan tanpa akhir kecuali jika tidak ada keuntungan yang jelas untuk pendekatan mana pun. Berikut ini adalah beberapa pendekatan yang baik untuk memutuskan hubungan:

• Biarkan orang yang benar-benar harus mengimplementasikannya memutuskan.
• Untuk masalah UI, biarkan orang yang paling mengetahui persyaratan pelanggan memutuskan.
• Biarkan orang yang paling berpengalaman dalam hal subjek atau bagian dari basis kode memutuskan.
• Biarkan orang dengan kendala jadwal paling ketat atau tenaga kerja dan keterbatasan sumber daya memutuskan.
• Biarkan orang tersebut memutuskan siapa yang memiliki keberatan yang lebih konkret daripada teoretis.
• Temukan kompromi antara pendekatan.
• Kumpulkan lebih banyak informasi dan putuskan pada pertemuan berikutnya, berikan bobot lebih kepada orang-orang yang jelas menghabiskan waktu meneliti sejak pertemuan terakhir.

Sejauh cara mengumumkan keputusan, Anda hanya berkata, "Oke, kita akan melakukan ini karena ini ." Jika orang merasa seperti Anda telah memberi mereka pemeriksaan yang adil, dan Anda tidak plin sebagai pemimpin, mereka akan mengikuti keputusan Anda. Untuk yang keras kepala, Anda dapat berjanji untuk mengevaluasi kembali setelah sejumlah implementasi dilakukan, tetapi kebanyakan orang akan membatalkannya pada saat itu.

Seorang fasilitator pertemuan yang baik dapat memfasilitasi diskusi semacam ini tanpa membiarkan mereka lepas kendali.