Menjelaskan hal-hal teknis kepada orang-orang non-teknis [ditutup]

Saya sering harus menjelaskan hal-hal teknis dan keputusan teknis kepada manajer saya yang sangat non-teknis dan saya sangat buruk dalam hal itu. Apa cara yang baik untuk hal-hal bodoh yang penting bagi seluruh dunia yang tidak memiliki hasrat untuk pemrograman?

Contoh pertanyaan yang pernah saya tanyakan:

• Mengapa Anda menggunakan Django dan bukan Java (Tidak menerima bahwa itu lebih murah juga)
• Meminta saya untuk mengulangi hal-hal dalam kata-kata non teknis, kalimat saya adalah "Tag HTML tertentu tidak diizinkan". Bagaimana saya bisa membodohi itu?
• Hal-hal lain yang masuk akal bagi saya, tetapi sangat mendasar sehingga saya tidak tahu bagaimana menjelaskannya
• Mengapa ini, mengapa itu, mengapa semuanya!

Juga, bagaimana saya memberi tahu manajer saya untuk mencari hal-hal dasar di Google, seperti "Apa itu Pylons?"

Saya cenderung menggunakan analogi. Ambil apa pun topiknya, dan pikirkan sesuatu yang sepenuhnya non-teknis yang akan mereka pahami, dan jelaskan kepada mereka seperti itu.

Contoh terbaik yang dapat saya pikirkan begitu saja adalah jika saya perlu menjelaskan orientasi objek, saya akan menjelaskannya menggunakan setumpuk kartu. Atau, ketika saya mencoba menjelaskan ide internet nirkabel kepada bibi saya yang hebat (yang tidak pernah menggunakan komputer), saya menggunakan telepon nirkabel untuk menjelaskannya.

Saya belum menemukan topik apa pun yang saya tidak bisa bodoh dengan cara ini.

Hal-hal yang Saya Gunakan

^{untuk efek yang hebat dan tidak begitu besar.}

• Analogi: Ketika menjelaskan suatu situasi atau proses, itu benar-benar berfungsi dengan baik jika Anda dapat memasukkannya ke dalam istilah yang akan mereka pahami.
• Istilah umum: Alih-alih mengatakan tag HTML, Anda bisa mengatakan kode . Jika mereka menindaklanjuti meminta penjelasan, mungkin sudah waktunya untuk ringkasan singkat HTML dan cara kerjanya. "Halaman web dibangun dari blok yang disebut" tag. "Jika browser Anda tidak mendukung tag tertentu, itu tidak akan ditampilkan dengan benar."
• Ringkasan dan Tinjauan: Kadang-kadang bekerja dengan baik untuk memberikan sinopsis singkat sebelum memukulnya terbalik dengan jargon teknis.
• Hapus Jargon: Hidupkan "Database tidak memuat load dengan benar ketika terkena beberapa permintaan dari subnet IP." ke "Basis data mengalami kesulitan menangani permintaan dari orang-orang tertentu." Jika Anda mungkin harus menjelaskannya, gantilah dengan yang lain. Jika Anda harus menjelaskan basis data Anda sedang dalam masalah. "Tempat untuk menyimpan barang" adalah kemunduran saya.
• Alat Bantu Visual: Papan tulis batu. Gunakan untuk keuntungan Anda.
• Jadikan mereka teknis: Mempertahankan manajer, bos, dan rekan kerja dalam lingkaran membantu. Jika manajer akun bingung dalam rapat karena semua orang kecuali mereka mengerti apa yang dikatakan, itu mungkin membuat mereka ingin membaca email-email yang mereka ikuti. Luangkan waktu saat menulis memo atau email untuk menjelaskan diri Anda secara menyeluruh atau arahkan ke referensi untuk penjelasan. Memiliki seseorang yang mencari tahu apa HTML itu sendiri mungkin akan lebih baik daripada mencoba menjejalkannya ke mereka selama pertemuan penting.

Suatu hari, dahulu kala ketika masih sarjana, saya diminta untuk menjelaskan sesuatu saat makan siang hari Minggu - salah satu pengalaman paling mendidik yang pernah saya miliki. Orang yang mengajukan pertanyaan itu ternyata tidak bodoh - tetapi tidak memiliki latar belakang, tingkat pengetahuan yang saya duga tidak ada di sana. Saya mulai menjawab, melihat kosong, berubah turun, masih kosong, berubah lagi, masih kosong ... hmm ... jadi saya mulai dengan cara yang sama ketika Anda mulai membangun aplikasi, dengan sedikit blok penjelasan yang Anda bisa membangun sesuatu yang lebih substansial.

Bagian penting dari pelajaran ini, bagi saya, adalah (dan) seberapa banyak kita berasumsi (bukan hanya programmer, semua orang) tentang pengetahuan orang lain tentang spesialisasi pilihan kita, padahal, bahkan, Anda mungkin beranggapan bahwa mayoritas orang ketahuilah bahwa 1 + 1 = 2 tetapi setelah itu menjadi menarik.

Jadi hal pertama dan paling penting untuk dipahami adalah bahwa orang tidak tahu dan tidak mengerti apa yang Anda lakukan - tetapi mereka mengerti apa yang mereka lakukan dan ketika Anda menjelaskan hal-hal yang perlu Anda mulai dengan sederhana dan tetap pada yang tepat level untuk audiens Anda.

Dalam hal teknik spesifik - saya pikir bahwa @Josh K sudah cukup tertutup - dan saya menekankan bahwa Analogi adalah pemenang mutlak.

Satu hal lagi - mungkin, dari waktu ke waktu, dapat diterima untuk hanya menulis hal-hal sebagai "barang geek" orang tidak selalu ingin penjelasan lengkap tentang mengapa dan jika Anda sebelumnya telah menunjukkan kemauan untuk menjelaskan dan kemampuan untuk melakukan jadi dengan cara yang dapat dimengerti maka orang akan cenderung mempercayai Anda ketika Anda menyarankan bahwa "alasan teknis yang rumit" berlaku atau yang pada akhirnya Anda dapat mencapai hasil tertentu dengan "melakukan hal-hal geek" (atau "hal-hal programmer" atau istilah apa pun yang bekerja dengan baik di lingkunganmu).

Mengkomunikasikan hal-hal teknis kepada audiens non-teknis (satu atau lebih) adalah keterampilan, yang dapat Anda kembangkan dan yang Anda butuhkan.

Cobalah untuk menjawab bukan dalam hal teknologi yang mendasarinya, tetapi dalam hal domain masalah. "ketika seorang pelanggan yang menggunakan firefox mencoba melakukan pemesanan, perambannya tidak akan menampilkan tombol BELI - peramban itu tidak mendukung tag HTML yang kami gunakan"

Seringkali ini benar-benar jenis jawaban yang diinginkan manajemen. Jika dia benar-benar ingin memahami detail tingkat rendah, taruhan terbaik adalah membuat analogi dengan teknologi yang Anda tahu dia mengerti.

Saya mencoba untuk menemukan analogi dengan sesuatu yang serupa di dunia nyata. Seperti, ketika saya menyebutkan tumpukan dan seseorang bertanya apa itu:

"Yah, kamu punya anak. Apakah mereka pernah bermain-main dengan balok-balok kayu kecil dengan huruf di atasnya?"

"Ya."

"Pernah melihat mereka membuat menara besar dengan menumpuk satu blok di atas yang lain?"

"Ya."

"OK, dan ketika kamu punya menara seperti itu, hanya aman untuk menyentuh bagian atas menara, kan? Kamu bisa meletakkan blok lain, atau kamu bisa mengambil blok di atas, tetapi jika kamu memindahkan sesuatu di bawahnya blok atas, semuanya akan jatuh, kan? "

Tertawa. "Yap! Mereka suka menghancurkan menara dan membuat mereka semua jatuh!"

"Yah, tumpukan pada dasarnya seperti melakukan hal itu dengan data. Anda mengatur struktur data sedemikian rupa sehingga Anda hanya dapat menambahkan hal-hal ke atas atau menghapus elemen di atas. Ini berguna untuk melacak hal-hal yang sedang Anda jalani. melalui melakukan, tetapi Anda perlu melakukan sesuatu yang lain terlebih dahulu, dan kemudian sebelum Anda selesai Anda perlu melakukan sesuatu yang lain, dan seterusnya. " (Dengan demikian memperkenalkan gagasan tentang tumpukan panggilan.) "Kecuali bahwa Anda tidak ingin menjatuhkan menara dalam kasus ini."

"Oh, aku mengerti sekarang. Keren!"

Jangan merasa buruk. Saya harus menjelaskan apa artinya copy on write untuk nitwit yang lengkap dan mengucapkan minggu lalu. Mengerikan, nitwit itu adalah salah satu vendor kami.

Jika secara langsung, cari papan tulis, atau setidaknya beberapa kertas sehingga Anda bisa menjadi lapisan abstraksi manusia.

Jika bekerja dengan seseorang dari jarak jauh, ada banyak alat sketsa / papan tulis yang tersedia.

Mencoba menyederhanakan sesuatu yang abstrak, dengan mengabstraksikannya lebih jauh, tanpa semacam bantuan visual hanyalah kegilaan. Ini akan mengarah pada hal-hal seperti penyalahgunaan narkoba dan alkohol, pencabutan hak dari keluarga dan teman sebaya Anda dan lebih buruk lagi, kekejaman unicorn.

+1 untuk siapa saja yang berbicara tentang analogi, +1 untuk siapa saja yang berbicara tentang papan tulis atau kertas dan pensil sebagai alat bantu visual.

Trik lain yang saya pelajari, adalah beberapa orang yang saya temukan jika saya menulis 5 halaman tentang mengapa sesuatu itu, mereka akan benar-benar membacanya - saya tahu, karena sebulan kemudian mereka akan mengatakan sesuatu dan saya tahu itu dari dokumen yang saya tulis.

Yang aneh adalah, saya yakin saya telah mencoba menjelaskan hal yang persis sama secara verbal sebelumnya (bahkan dengan alat bantu visual dan analogi) dan mereka tidak mengerti. Saya menemukan ini sangat membantu dalam situasi politik atau emosional atau ketika gangguan sering mengambil hal-hal yang tidak biasa.

Pastikan untuk benar-benar menjelaskan masalahnya - dan jelaskan mengapa dalam hal manfaat bisnis. Setelah saya menjelaskan konsep utang teknis kepada CEO kami - dan sekarang, kami dapat menggunakan ini sebagai singkatan percakapan. "Mengapa kamu ingin melakukan hal tiga hari ini? Halaman web itu terlihat bagus bagiku!" "Ini akan menghapus utang teknis, di waktu berikutnya kita harus memperbaikinya segalanya akan berjalan lebih cepat." Kemudian, percakapan bisa menjadi tentang seberapa cepat.

Anda sendiri merugikan diri sendiri secara emosional dan karier dengan kesal karena harus menjelaskan detail teknis kepada orang-orang non-teknis. Fakta bahwa orang non-teknis membutuhkan Anda untuk menerjemahkan proses teknis ke proses bisnis non-teknis dan sebaliknya adalah apa yang membuat Anda dipekerjakan. Semakin mahir Anda menerjemahkan antara dua domain masalah, semakin berharga Anda bagi pemberi kerja.

Biasakan diri Anda dengan teknik manufaktur, dan jelaskan proses pengembangannya dalam hal proses jalur perakitan.

Misalnya, menjelaskan pemrosesan tag html (dan dengan demikian ketidakmampuan untuk menggunakannya) dapat diekspresikan dalam istilah dies ekstrusi, yang populer dikenal di play-doh.

Jelaskan masalah proses pengembangan, seperti mengubah persyaratan, memperbarui antarmuka, cacat produk, dll., Dalam hal biaya mematikan saluran, waktu & biaya yang dihabiskan untuk membangun saluran dan harus mengubahnya ketika persyaratan atau kondisi berubah , dll.

Saya masuk ke lebih detail dalam jawaban lain.

• Anggap itu peluang bagus untuk mengasah kemampuan presentasi Anda.

• Anggap itu peluang bagus untuk meninjau dasar-dasar teknis Anda.

• Berbicaralah dalam bahasa audiens, BUKAN bahasa Anda.

• Selidiki MENGAPA non-teknisi menginginkan informasi ini. Apa alasannya? Apakah dia bosan? Ingin tahu lebih banyak? Ingin tampil kompeten? Suka membuatmu gila? Super-ekstrovert tanpa ada yang diajak bicara? Frustrasi dengan kurangnya kemajuan Anda meskipun perkiraan optimis Anda (itu adalah yang umum!)?