Spiegare cose tecniche a persone non tecniche [chiuso]

Devo spesso spiegare cose tecniche e decisioni tecniche al mio manager estremamente non tecnico e sono abbastanza terribile. Quali sono i modi migliori per sminuire le cose essenziali per il resto del mondo che non hanno una passione per la programmazione?

Domande di esempio che mi sono state poste:

• Perché stai usando Django invece di Java (Non ho accettato che fosse neanche più economico)
• Chiedendomi di riformulare le cose in parole non tecniche, la mia frase era "Alcuni tag HTML non sono ammessi". Come posso eventualmente smorzarlo?
• Altre cose che hanno perfettamente senso per me, ma sono così semplici che non so come spiegarle
• Perché questo, perché quello, perché tutto!

Inoltre, come faccio a dire al mio manager di cercare le cose di base su Google, come "What is Pylons?"

Tendo a usare analogie. Prendi qualunque sia l'argomento e pensa a qualcosa di completamente non tecnico che potrebbero capire, e spiegaglielo in quel modo.

Il miglior esempio che mi viene in mente è che se devo spiegare l'orientamento agli oggetti, lo spiegherò usando un mazzo di carte. Oppure, quando stavo cercando di spiegare l'idea di Internet wireless a mia prozia (che non ha mai usato un computer), ho usato i telefoni cordless per spiegarlo.

Devo ancora imbattermi in qualsiasi argomento che non riesco a sminuire in questo modo.

Cose che uso

^{di grande effetto e non così grande.}

• Analogie: quando si spiega una situazione o un processo funziona davvero bene se si può mettere in termini che possano capire.
• Termini generici: invece di dire tag HTML potresti dire codice . Se seguono la richiesta di una spiegazione, potrebbe essere il momento di un breve riepilogo dell'HTML e di come funziona. "Le pagine Web sono costruite da blocchi chiamati" 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 a testa in giù con un gergo tecnico.
• Rimuovi gergo: girare "Il database non esegue correttamente il bilanciamento del carico quando viene colpito da più richieste da una sottorete IP." in "Il database ha problemi a gestire le richieste di determinate persone." Se potresti doverlo spiegare, sostituiscilo con qualcos'altro. Se devi spiegare il database sei nei guai. "Place to store stuff" è il mio fallback.
• Aiuti visivi: lavagne rock. Usali a tuo vantaggio.
• Renderli tecnici: mantenere manager, capi e colleghi in contatto aiuta. Se il gestore dell'account è confuso durante le riunioni perché tutti, tranne loro, capiscono cosa viene detto, potrebbe far loro desiderare di leggere quelle e-mail su cui erano state inviate. Prenditi del tempo quando scrivi memo o e-mail per spiegarti a fondo o punta a riferimenti per una spiegazione. Avere qualcuno a capire che cosa è l' HTML da solo sarà probabilmente meglio quindi provare a stiparlo in loro durante un incontro importante.

Una volta, molto tempo fa mentre ero ancora studente, 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 è evidentemente stupida - ma non ha avuto precedenti, il livello di conoscenza che ho assunto non esisteva. Ho iniziato a rispondere, ho avuto un aspetto vuoto, cambiato in basso, ancora vuoto, cambiato di nuovo in basso, ancora vuoto ... hmm ... quindi ho iniziato nello stesso modo in cui inizi a creare un'applicazione, con piccoli blocchi di spiegazioni che puoi costruire in qualcosa di più sostanziale.

La parte chiave di questa lezione, per me, era (ed è) quanto assumiamo (non solo i programmatori, tutti) sulla conoscenza delle altre persone della specialità prescelta mentre, in effetti, potresti ragionevolmente presumere che la maggior parte delle persone sappi 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 quello che fai, ma capiscono quello che fanno e quando spieghi cose devi quindi iniziare in modo semplice e rimanere livello per il tuo pubblico.

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

Ancora una cosa - può essere, di tanto in tanto, accettabile semplicemente scrivere le cose come "cose ​​da geek" che le persone non vogliono sempre spiegazioni complete sul perché e se in precedenza hai dimostrato la volontà di spiegare e la capacità di fare quindi in modo comprensibile, allora le persone saranno inclini a fidarsi di te quando suggerisci che si applicano "ragioni tecniche complesse" o che alla fine puoi ottenere un risultato particolare "facendo cose geek" (o "cose ​​programmatore" o qualunque termine funzioni bene in i tuoi dintorni).

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

Cerca di rispondere non in termini di tecnologia di base, ma in termini di dominio problematico. "quando un cliente che utilizza Firefox tenta di effettuare un ordine, il suo browser non visualizzerà il pulsante ACQUISTA IT - quel browser non supporta il tag HTML che stiamo utilizzando"

Spesso questo è davvero il tipo di gestione delle risposte che desidera. Se vuole davvero capire i dettagli di basso livello, la scommessa 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 menzionato una pila e qualcuno ha chiesto cosa fosse:

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

"Si."

"Li hai mai visti costruire una grande torre impilando un blocco sopra l'altro?"

"Si."

"OK, e quando hai una torre come quella, è sicuro toccare la cima della torre, giusto? Puoi mettere un altro blocco o puoi prendere il blocco sopra, ma se sposti qualcosa sotto il blocco superiore, tutto cadrà, vero? "

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

"Bene, uno stack è fondamentalmente come farlo con i dati. È possibile impostare una struttura di dati in modo da poter solo aggiungere cose in cima o rimuovere l'elemento in cima. È utile per tenere traccia delle cose che si stanno partendo facendo, 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 in questo caso non si vuole abbattere la torre."

"Oh, ora capisco. Fantastico!"

Non stare male. Ho dovuto spiegare cosa significa copia su scrittura per un idiota completo e totale la scorsa settimana. Orribilmente, quel coglione era uno dei nostri venditori.

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

Se si lavora con qualcuno in remoto, sono disponibili molti strumenti di schizzo / lavagna.

Tentare di semplificare qualcosa di astratto, astrattandolo ulteriormente, senza un qualche tipo di aiuto visivo è solo follia. Condurrà a cose come l'abuso di droghe e alcol, la privazione del diritto di famiglia da parte di familiari e colleghi e, peggio, la crudeltà dell'unicorno.

+1 per chiunque parli di analogie, +1 per chiunque parli di lavagne o carta e matita come ausili 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 che è dal documento che ho scritto.

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

Assicurati comunque di spiegare effettivamente il problema e di spiegare il perché in termini di vantaggi commerciali. Una volta ho spiegato il concetto di debito tecnico al nostro CEO - e ora, possiamo usarlo come stenografia conversazionale. "Perché vuoi fare questa cosa di tre giorni? Quella pagina web mi sta benissimo!" "Rimuoverà il debito tecnico, in quella prossima volta che dovremo risolverlo le cose andranno molto più velocemente." Quindi, la conversazione può diventare molto più veloce.

Ti stai facendo un disservizio emotivo e professionale arrabbiandoti 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 aziendali non tecnici e viceversa è ciò che ti ha impiegato. Quanto più sei bravo a tradurre tra i due domini problematici, tanto più diventi prezioso per un datore di lavoro.

Acquisire familiarità con le tecniche di produzione e spiegare il processo di sviluppo in termini di processi della catena di montaggio.

Ad esempio, la spiegazione dell'elaborazione dei tag html (e quindi l'impossibilità di usarli) può essere espressa in termini di matrici di estrusione, popolarmente conosciute in play-doh.

Spiegare i problemi del processo di sviluppo, come la modifica dei requisiti, l'aggiornamento delle interfacce, i difetti del prodotto, ecc., In termini di costi di chiusura della linea, tempo e spese spesi per costruire la linea e doverlo modificare quando cambiano i requisiti o le condizioni , eccetera.

Sono andato più in dettaglio in un'altra risposta.

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

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

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

• Scopri PERCHÉ il non tecnico vuole queste informazioni. Qual è la ragione di fondo? È annoiato? Curioso di saperne di più? Vuole apparire competente? Ti piace farti impazzire? Super estroverso senza nessuno con cui parlare? Frustrato dalla tua mancanza di progressi nonostante le tue stime ottimistiche (è comune!)?