Seberapa efektif "menjual" desain yang baik dalam pertemuan besar

Sering kali saya menyaksikan tragedi yang menyedihkan. Inilah yang terjadi:

1. Tinjauan desain tim untuk proyek baru.
2. Saya melihat desain sederhana yang memiliki beberapa lubang.
3. Dengan santai saya menyebutkan lubang dan cara untuk menghindarinya.
4. Peringatan diabaikan dengan komentar seperti "yang 'tidak pernah' terjadi di kehidupan nyata"
5. Akhirnya hal-hal yang "tidak akan pernah terjadi" terjadi
6. Tinjauan desain tim darurat untuk proyek yang rusak.

Jadi apa yang saya lakukan? Menghentikan sikap "Sudah kubilang" tidak akan memenangkan teman dan memengaruhi orang. Kadang-kadang tahun berlalu dan komentar dari langkah 3 tetap dilupakan. Saya jelas tidak ingin menjadi hama yang mengganggu yang mengingatkan dunia para gotcha. Saya sering duduk dan menonton Titanic berlayar ke Eropa.

Sangat frustasi melihat desain buruk bergerak maju. Ini juga membuat frustasi karena saya tidak bisa meyakinkan orang lain tentang bahaya yang tertunda dari jalan saat ini. Saya melakukan yang terburuk pada pertemuan tim di mana setiap orang memiliki cara berbeda dalam memahami istilah yang berbeda. Juga, ego cenderung menang akal dan berpikir. Saya mencari taktik yang bagus untuk meyakinkan kelompok orang untuk menggunakan beberapa ide baru dan rumit.

Jika memungkinkan sarankan modifikasi yang tidak akan menambah waktu yang signifikan untuk suatu proyek. Coba dan tekankan bahwa jika itu tidak dilakukan sekarang, maka bekerja kembali nanti akan jauh lebih menyakitkan. Akan lebih sulit jika Anda mencoba meyakinkan tim Anda bahwa arah baru yang lengkap lebih baik, karena itu mungkin akan menunda proyek, dll.

Jangan menempatkan orang dalam mode pertahanan dalam rapat, mereka hanya akan bertarung dengan Anda untuk menjadi pemenang. Anda tidak akan membuat mereka setuju bahwa bumi itu bulat. Ini adalah politik normal (mis. Siapa pun di FoxNews)

Sangat membantu untuk mendapatkan rasa hormat dari pengembang lain. Jika Anda orang baru di tim, saya pikir Anda SOL. Jadi, bangun beberapa perwakilan tim dan benar-benar mencoba untuk naik ke level seandainya Anda tidak akan diberhentikan begitu saja. Tentu saja, jika Anda selalu pesimistis, maka Anda hanya akan dicap sebagai pria "negatif".

Untuk hal-hal sederhana (yaitu tidak mempengaruhi jadwal), pastikan untuk melakukan pekerjaan Anda dengan cara terbaik. Jika Anda memasukkan upaya ke dalam output langsung Anda (misalnya membuat kasus uji, atau mendapatkan beberapa fitur sederhana (tapi keren)) akhirnya orang lain akan melihat bahwa kode Anda bekerja dengan andal dan tahan terhadap ujian waktu. Ketika Anda mulai menunjukkan kepada mereka beberapa trik rapi dengan kode, mereka akan berpikir dua kali menembak Anda di depan semua orang.

Akhirnya, saya setuju Anda tidak ingin melakukan rutinitas "Saya bilang begitu", tetapi pastikan untuk mencoba dan memberikan petunjuk kepada bos / pimpinan teknologi Anda ketika ternyata Anda benar. Mungkin mengirim ulang email lama dengan komentar lama Anda. Tanyakan kepada mereka apakah ini akan membantu memecahkan masalah "baru". Jika Anda tidak melakukan ini, mereka bahkan tidak akan ingat bahwa Anda adalah orang yang membawanya pertama kali. Akhirnya mereka akan mendapatkan petunjuk bahwa Anda tidak hanya berusaha menjadi pamer di rapat. Lain kali mereka akan berpikir dua kali untuk meledakkan Anda, terutama jika disadari bahwa desain "lama" Anda sekarang menggantikan yang sudah rusak.

Cobalah untuk membangun reputasi sebagai orang yang dapat mengidentifikasi apa yang akan berhasil dan bukan hanya apa yang menurut Anda akan memiliki masalah dalam beberapa kasus penggunaan yang jarang terjadi. Ketika Anda melihat masalah potensial ini, anggap saja itu catatan kaki yang mungkin perlu ditangani nanti.

Orang-orang menjadi gila di sidang. Sampaikan kekhawatiran Anda kepada orang kunci di luar rapat. Mereka akan melihat ini sebagai kurang mengancam dan mungkin meluangkan waktu untuk mendengar argumen Anda alih-alih memikirkan mereka membela desain. Mereka mungkin juga membutuhkan lebih banyak waktu untuk menjelaskan kepada Anda keadaan mengapa Anda mungkin memiliki poin yang valid, tetapi tidak layak untuk membahas di v1.0.

Kunci! Pergilah ke pertemuan dengan pemahaman lengkap tentang apa agenda penyelia langsung Anda. Mungkin mereka melihat ini sebagai proyek kecil dan hal terakhir yang mereka butuhkan pada pertemuan itu adalah seorang penentang mengambil waktu dari masalah yang lebih penting. Minta mereka untuk membantu Anda membantu mereka.

Jika Anda ingin memengaruhi mereka, bicarakan dengan mereka di luar rapat desain. Kalau tidak, mereka hanya akan berpikir Anda mencoba "mencetak poin" dari mereka. Banyak orang tidak ingin berdiskusi dalam pertemuan dengan "audiens".

Saya tidak melihat bagaimana situasi ini jauh berbeda dari pengembang tunggal dengan bos yang tidak mengerti. Sayangnya, saya telah kehilangan hitungan berapa kali saya 'diyakinkan' untuk membangun sebuah proyek dengan cara tertentu dan mengirimkannya, terlepas dari peringatan saya akan malapetaka yang akan datang. Yang membuat Anda tidak hanya membangun, tetapi berlayar Titanic pepatah ke gunung es sendirian.

Seperti yang Anda jelaskan, ketika bit-bitnya mengenai ember pepatah, peringatan saya sudah lama terlupakan. Kadang-kadang (untungnya bagi saya) segalanya berjalan buruk selama berbulan-bulan atau lebih setelah saya tidak lagi terlibat dalam proyek. Sayangnya, ini membuat penerus saya berpikir bahwa saya pasti gila, karena Anda dapat bertaruh bahwa bos tersebut membantahnya :)

Pokoknya, sekelompok 'yakin' programmer bisa sama clueless bos berambut runcing, kadang-kadang bahkan lebih karena mereka percaya diri mengerti, seperti Jeff O menyebutkan . Ketika ini terjadi, Anda punya cukup waktu untuk memperbaiki keadaan. Jangan mencoba membuat satu suara nalar didengar melalui kentut otak kolektif. Jika Anda dapat melakukannya secara efektif, tempat Anda berada di kongres, bukan di belakang perangkat lunak penulisan meja.

Karena tindakan berbicara lebih keras daripada kata-kata, Anda dapat:

• Tunjukkan (dengan skenario uji) mengapa desain akan gagal dalam keadaan normal. Ini mungkin akan menghasilkan pertemuan yang lebih kecil di mana Anda adalah orang yang hadir, dan mungkin hanya itu yang perlu Anda dengar.

• Perlihatkan produk yang bersaing yang secara memadai menjawab apa yang menurut kelompok itu hanya 'kasus sudut'. Anda akan kagum dengan berapa lama Google pergi untuk mengantisipasi kesalahan dalam program spreadsheet-nya, misalnya.

• Mengulangi proyek terakhir yang membutuhkan penulisan ulang seminggu sebelum seharusnya dikirimkan.

Dengan kata lain, langkah pertama, apa pun yang Anda lakukan adalah berurusan dengan individu atau kelompok (banyak) yang lebih kecil. Jika kekhawatiran Anda benar-benar valid, saya yakin mereka akan lebih baik menerima satu atau dua minggu dalam pengembangan. Seperti yang Anda catat, hindari sikap 'Saya bilang begitu'.

Jika memungkinkan, tinjau desain sebelum (atau bahkan setelah) pertemuan, dan berbicara dengan desainer secara pribadi. Menembak orang dalam rapat di depan semua kolega mereka akan cenderung membuat mereka langsung bersikap defensif dan tertutup tentang saran Anda, dan dapat menyebabkan reputasi sebagai "pembuat masalah" meskipun Anda pikir Anda sedang membantu.

Cara yang baik (tetapi seringkali sulit) untuk mengajukan "kritik" adalah dengan mengajukan pertanyaan-pertanyaan utama - biarkan orang lain mencoba menjawab pertanyaan Anda dan menyadari kekurangannya untuk diri mereka sendiri. Maka itu tampaknya lebih seperti ide mereka sendiri dan mereka akan lebih cenderung membawanya ke depan. Sekali lagi, ini bekerja paling baik dalam diskusi pribadi, tetapi bisa menjadi cara yang lebih diplomatis dan efektif untuk maju dalam situasi pertemuan (Catatan: Cobalah untuk menghindari pertengkaran atau diskusi panjang untuk meyakinkan orang-orang dalam pertemuan itu. Cukup sampaikan ide dan coba jangan memaksakan intinya. Mungkin lebih baik untuk melepaskannya dan kemudian mengobrol dengan para desainer setelah pertemuan untuk "menjernihkan sesuatu yang saya tidak mengerti" daripada menjadi "orang yang membuat 30 menit sederhana rapat buang seluruh pagi saya ")

Pendekatan lain adalah dengan mengirim email saran Anda (secara diplomatis) ke desainer utama (atau daftar distribusi yang relevan tetapi kecil). Ini dapat membantu mempertimbangkan ide-ide Anda, dan juga memberi Anda "jejak kertas" untuk mendukung situasi "Saya katakan begitu" di masa depan (jika segala sesuatunya berubah menjadi buah pir, Anda setidaknya memiliki bukti bahwa Anda mencoba membantu tetapi diabaikan. Tetapi jika semuanya menjadi buruk, Anda mungkin tidak bekerja di perusahaan yang tepat)

Akhirnya, ingatlah bahwa kadang-kadang Anda mungkin "salah". Orang yang Anda ajak bicara mungkin memiliki pemahaman yang lebih jelas atau lebih lengkap tentang desain mereka daripada Anda, dan memiliki alasan yang baik untuk pendekatan mereka (misalnya, saya baru-baru ini dituduh oleh anggota tim menciptakan desain "tidak efisien", tetapi itu desain yang disengaja karena saya tahu kinerja akan tetap dapat diterima, tetapi itu akan mengurangi biaya pengembangan - itu adalah keputusan bisnis daripada keputusan kualitas kode). Cobalah untuk berpikiran terbuka tentang ide orang lain - terkadang ide yang tampaknya buruk bagi Anda mungkin ide yang bagus untuk alasan yang belum Anda pertimbangkan.

Ketika bertemu dengan skenario "itu tidak akan pernah terjadi", ingatkan mereka tentang semua waktu di masa lalu ketika mereka harus memperbaiki barang-barang "yang tidak akan pernah terjadi". Tetapi Anda harus berhati-hati untuk tidak bertemu karena "Saya sudah bilang begitu." Saya merasa paling efektif untuk mengemukakan masalah masa lalu (dan seberapa mahal dan menyakitkannya untuk memperbaikinya) dalam membahas mengapa Anda berpikir bahwa kita harus melakukan sesuatu sekarang untuk proyek ini sebagai contoh mengapa Anda berpikir ini penting sebelum mereka membawa "yang tidak akan pernah terjadi "kutipan.

Saya pikir mungkin masalah Anda adalah Anda mengatakan dengan santai menyebutkan cara untuk menghindari masalah, Mungkin Anda harus dipersenjatai dengan lebih banyak informasi dan menunjukkan kepada mereka secara lebih rinci mengapa ini merupakan risiko bagi sistem. Kadang-kadang itu berarti memunculkan subjek dalam pertemuan kedua setelah Anda punya waktu untuk melakukan sedikit riset. Membangun kasus bisnis untuk seberapa murah itu untuk dilakukan sekarang dan seberapa mahal itu untuk dilakukan nanti.

Kedengarannya seperti taruhan terbaik Anda adalah bekerja untuk membawa diri Anda ke Posisi Pemimpin Tim. Gunakan kesempatan ini untuk menunjukkan kekuatan yang Anda lihat akan datang dan ini bisa dihindari. Anda tidak perlu menjual tim Anda saat ini dalam melakukan hal itu.

"Santai" dalam "santai menyebutkan lubang" tampaknya menjadi masalah. Coba gunakan (atau bawa jika tidak ada) beberapa proses tertulis untuk menganalisis risiko proyek. Biasanya hasil dari pertemuan analisis risiko adalah tabel dua kolom sederhana: risiko, dan apa strategi yang disepakati untuk memitigasi risiko adalah ("kami pikir itu tidak pernah terjadi" adalah mitigasi yang dapat diterima; yang penting adalah mencatat pemikiran saat ini pada masalah saat itu). Pastikan masalah Anda dicatat sebagai risiko. Risiko harus ditinjau secara berkala; kemungkinan beberapa orang akan datang ke sudut pandang Anda jauh sebelum krisis benar-benar terjadi dan tinjauan risiko akan bertindak sebagai "OMG yang memang terjadi; kita akan menjadi gila untuk melanjutkan seperti ini "katalisator. Jangka panjang, jejak kertas adalah bukti yang berguna untuk mengatakan" lihat, kita tampaknya memiliki masalah kelembagaan di sini "dan mendapatkan sikap untuk merancang atau apa pun yang berubah.

Cara menerapkan ide Anda

Pertama dalam rapat merujuk masalah sebagai tantangan. Anda memperbaiki masalah, Anda mengatasi tantangan. Tantangan adalah hal yang baik, masalah tidak.

Mulai dengan lambat dan gunakan teknik ini pada satu tantangan tunggal pada satu waktu. Lain kali Anda ingin bos Anda mengadopsi salah satu ide Anda, lakukan hal berikut:

• Kembangkan tiga pendekatan yang serupa tetapi berbeda
• Beri tahu atasan Anda bahwa Anda membutuhkan bantuannya dengan sesuatu
• Jelaskan bahwa Anda tidak yakin yang mana dari tiga metode yang merupakan tindakan terbaik untuk menyelesaikan masalah
• Minta Dia untuk membantu Anda memilih salah satu dari ketiganya

1. Ini sangat kuat. Apa yang Anda lakukan adalah memberikan pilihan bukan ultimatum. Ultimatum lebih sering daripada tidak ditembak jatuh karena itu bukan ide mereka dan hanya ada satu pilihan.

2. Penggunaan kata-kata Anda sangat penting di sini. " Aku butuh bantuanmu ".

3. Biarkan bos memilih "A", "B", atau "C". Bahkan biarkan bos membuat opsi "D" dengan menarik bagian dari "A", "B" dan "C". Apa yang Anda lakukan adalah membiarkan atasan Anda membuat pilihan.

Pada titik ini Anda tidak terlalu peduli dengan pilihan apa yang dia pilih, karena itu semua adalah ide Anda. Dia akan berpikir dia benar-benar menyelesaikan masalah karena Anda membiarkan keputusan menjadi miliknya.

Apakah Proof of Conceptide Anda diimplementasikan. Jika Anda menunjukkan kepada tim Anda sesuatu yang bekerja dan menyelesaikan masalah saat ini di tangan daripada mereka akan menyukainya.