Spiegare le cose tecniche alle persone non tecniche [chiuso]

Tendo ad usare le analogie. Prendi qualunque argomento, e pensa a qualcosa di completamente non tecnico che capiresti e spiegaglielo in questo modo.

Il miglior esempio che riesco a pensare a mano a mano è se ho bisogno di spiegare l'orientamento degli oggetti, lo spiegherò usando un mazzo di carte. Oppure, quando stavo cercando di spiegare l'idea di internet wireless alla mia prozia (che non ha mai usato un computer), ho usato i telefoni cordless per spiegarlo.

Devo ancora imbattersi in alcun argomento che non possa essere minimamente descritto in questo modo.

Cose che uso

^{con un effetto grandioso e non eccezionale.}

• Analogie: quando spieghi una situazione o un processo, funziona davvero bene se puoi metterlo in termini che capiranno.
• Termini generici: invece di dire tag HTML potresti dire codice . Se seguiranno la richiesta di una spiegazione, potrebbe essere il momento di un breve riassunto dell'HTML e di come funziona. "Le pagine Web sono costituite da blocchi denominati" tag ". Se il tuo browser non supporta un tag specifico, non verrà visualizzato correttamente."
• Riepiloghi e panoramiche: a volte funziona bene per dare una breve sintesi prima di colpirli alla testa con un gergo tecnico.
• Rimuovi Jargon: Turn "Il database non bilancia correttamente il carico quando viene colpito da più richieste da una subnet IP." in "Il database sta riscontrando problemi nella gestione delle richieste da certe persone. " Se potresti doverlo spiegare, sostituiscilo con qualcos'altro. Se devi spiegare il database, sei nei guai. "Place to store stuff" è la mia riserva.
• Aiuti visivi: lavagne bianche. Usali a tuo vantaggio.
• Rendili tecnici: aiuta a mantenere manager, capi e colleghi nel ciclo. Se l'account manager è confuso alle riunioni perché tutti, tranne loro, comprendono ciò che viene detto, potrebbero indurli a leggere quelle e-mail su cui sono stati inseriti CC. Prenditi del tempo quando scrivi memo o e-mail per spiegarti bene o fai riferimento ai riferimenti per spiegazioni. Avere qualcuno che capisca che HTML è da solo sarà probabilmente meglio che provare a coinvolgerlo in una riunione importante.

Una volta, tanto tempo fa, mentre ero ancora uno studente universitario, mi è stato chiesto di spiegare qualcosa durante il pranzo della domenica - una delle esperienze più educative che abbia mai avuto. La persona che ha posto la domanda non è stata stupida, ma non aveva background, il livello di conoscenza che ho assunto non era lì. Ho iniziato a rispondere, ho ottenuto uno sguardo vuoto, cambiato, ancora vuoto, cambiato di nuovo, ancora vuoto ... hmm ... così ho iniziato nello stesso modo in cui inizi a creare un'applicazione, con pochi blocchi di spiegazione che puoi costruire in qualcosa di più sostanziale.

La parte fondamentale di questa lezione, per me, è stata (ed è) esattamente quanto supponiamo (non solo i programmatori, tutti) sulla conoscenza delle altre persone della specialità scelta, mentre in realtà, si potrebbe ragionevolmente presumere che il la maggior parte delle persone sa che 1 + 1 = 2 ma dopo diventa interessante.

Quindi la prima e più importante cosa da capire è che le persone non sanno e non capiscono cosa tu fai - ma capiscono cosa fanno loro e quando stai spiegando le cose devi quindi iniziare in modo semplice e rimanere ad un livello appropriato per il tuo pubblico.

In termini di tecniche specifiche - penso che @Josh K lo abbia abbastanza coperto - e sottolineo che le analogie sono un assoluto vincitore.

Un'altra cosa: potrebbe essere, di tanto in tanto, accettabile solo scrivere cose come "roba geek", le persone non sempre vogliono spiegazioni complete sul perché e se in precedenza hai dimostrato la volontà di spiegare e un capacità di farlo in un modo comprensibile quindi le persone saranno inclini a fidarsi di te quando suggerisci che "ragioni tecniche complesse" si applicano o che alla fine puoi ottenere un risultato particolare "facendo roba geek" (o "roba programmatore" o qualsiasi altro termine funziona bene nei tuoi dintorni).

Comunicare cose tecniche ad un pubblico non tecnico (di uno o più) è un'abilità, una che puoi sviluppare e una di cui hai bisogno.

Cerca di rispondere non in termini di tecnologia sottostante, ma in termini di dominio del problema. "quando un cliente che usa firefox tenta di effettuare un ordine, il suo browser non mostrerà il pulsante ACQUISTA IT - quel browser non supporta il tag HTML che stiamo usando"

Spesso questo è davvero il tipo di gestione della risposta che desidera. Se davvero vuole capire i dettagli di basso livello, la soluzione migliore è fare analogie con la tecnologia che sai che capisce.

Cerco di trovare un'analogia con qualcosa di simile nel mondo reale. Ad esempio, quando ho citato uno stack e qualcuno mi ha chiesto cosa fosse:

"Beh, hai dei bambini, giocano mai con quei piccoli blocchi di legno con delle lettere?"

"Sì".

"Mai vederli creare una grande torre impilando un blocco su un altro?"

"Sì".

"OK, e quando hai una torre come questa, è sicuro toccare la cima della torre, giusto? Puoi mettere un altro blocco, oppure puoi bloccare il blocco in alto, ma se muovi qualcosa sotto il blocco superiore, l'intera cosa cadrà, giusto? "

Ridendo. "Sì! Adorano distruggere la torre e farli cadere tutti!"

"Beh, uno stack è fondamentalmente come farlo con i dati. Si imposta una struttura dati in un modo che è possibile aggiungere solo le cose in alto o rimuovere l'elemento in alto. È utile per tenere traccia delle cose che Stai facendo parte del lavoro, ma prima devi fare qualcos'altro, e poi prima di finire devi fare qualcos'altro, e così via. " (Introducendo così l'idea di uno stack di chiamate.) "Tranne che non vuoi per abbattere la torre in questo caso."

"Oh, ho capito adesso. Fantastico!"

Non sentirti male. Ho dovuto spiegare che cosa significa copy on write per una completa e totale nitwit la settimana scorsa. Orribilmente, quella stupida era uno dei nostri venditori.

Se di persona, trova una lavagna bianca o almeno un foglio di carta in modo da poter diventare uno strato umano di astrazione.

Se lavori con qualcuno in remoto, ci sono molti strumenti di sketch / white board disponibili.

Il tentativo di semplificare qualcosa di astratto, estraendolo ulteriormente, senza alcun tipo di aiuto visivo è solo follia. Condurrà cose come abuso di droghe e alcol, privazioni di diritti dalla famiglia e dai pari e peggio ancora, crudeltà di unicorno.

+1 per chi parla di analogie, +1 per chi parla di lavagne o carta e matita come aiuti visivi.

Un altro trucco che ho imparato, è che alcune persone che ho trovato se scrivo 5 pagine sul perché qualcosa è, lo leggeranno davvero - posso dirlo, perché un mese dopo diranno qualcosa e so è dal documento che ho scritto.

La cosa strana è che sono sicuro di aver provato a spiegare la stessa cosa verbalmente prima (anche con aiuti visivi e analogie) e non avevano capito. Trovo che ciò sia particolarmente utile in situazioni politiche o caricate emotivamente o quando frequenti interruzioni portano via le cose.

Assicurati di spiegare effettivamente il problema, comunque - e spiega il perché in termini di benefici per l'azienda. Una volta ho spiegato il concetto di debito tecnico al nostro amministratore delegato - e ora, possiamo usarlo come stenografia colloquiale. "Perché vuoi fare questa cosa di tre giorni? Quella pagina mi sta bene!" "Rimuoverà il debito tecnico, in quanto la prossima volta che dovremo sistemarlo le cose andranno molto più velocemente." Quindi, la conversazione può diventare quanto più veloce.

Ti stai facendo un disservizio emotivo e di carriera facendoti arrabbiare nel dover spiegare i dettagli tecnici a persone non tecniche. Il fatto che le persone non tecniche abbiano bisogno di te per tradurre i processi tecnici in processi di business non tecnici e viceversa è quello che ti ha fatto lavorare. Più sei bravo a tradurre tra i due domini problematici, più sei prezioso per un datore di lavoro.

Familiarizza con le tecniche di produzione e spiega il processo di sviluppo in termini di processi della catena di montaggio.

Adesempio,spiegarel'elaborazionedeitaghtml(equindil'impossibilitàdiusarli)puòessereespressainterminidimatricidiestrusione,popolarmenteconosciuteinplay-doh.

Spiegare i problemi del processo di sviluppo, come ad esempio il cambiamento dei requisiti, l'aggiornamento delle interfacce, i difetti del prodotto, ecc., in termini di costi di spegnimento della linea, tempo e amp; spese spese per costruire la linea e dover modificarla quando cambiano i requisiti o le condizioni, ecc.

Sono entrato in maggiori dettagli in un'altra risposta.

• Considera una grande opportunità per affinare le tue capacità di presentazione.

• Considera una grande opportunità per rivedere i tuoi aspetti tecnici fondamentali.

• Parla nella lingua del pubblico, NON nella tua lingua.

• Indagare perché il non-techie vuole questa informazione. Qual è la ragione sottostante? È annoiato? Curioso di saperne di più? Vuole apparire competente? Ti piace farti impazzire? Super-estroverso con nessuno con cui parlare? Frustrato dalla tua mancanza di progressi nonostante le tue stime ottimistiche (è comune!)?