Con quanta efficacia "vendi" un buon design in grandi riunioni

Molte volte ho assistito a una triste tragedia. Ecco cosa succede:

1. Una revisione del design del team per un nuovo progetto.
2. Vedo un design semplice che presenta alcuni buchi.
3. Cito casualmente i buchi e i modi per evitarli.
4. Gli avvertimenti vengono ignorati con commenti del tipo "che non accade mai nella vita reale"
5. Alla fine accadono le cose che "non accadranno mai"
6. Una revisione del design del team di emergenza per un progetto non funzionante.

Quindi cosa devo fare? Coprire l'atteggiamento "Te l'avevo detto" non conquisterà amici e influenzerà le persone. A volte passano gli anni e i commenti del passaggio 3 vengono comunque dimenticati. Sicuramente non voglio essere il fastidioso parassita che ricorda il mondo dei gotchas. Spesso mi siedo e guardo il Titanic salpare per l'Europa.

È frustrante vedere progetti cattivi andare avanti. È anche frustrante il fatto che non riesco a convincere gli altri del pericolo in sospeso del percorso attuale. Faccio del peggio nelle riunioni di gruppo in cui ognuno ha modi diversi di comprendere termini diversi. Inoltre, gli ego tendono a vincere la ragione e il pensiero. Sto cercando buone tattiche per convincere i gruppi di persone a usare alcune idee nuove e complicate.

Se possibile, suggerire modifiche che non aggiungeranno tempo significativo a un progetto. Cerca di sottolineare che se non lo fai ora, rielaborare più tardi sarà molto più doloroso. Sarà più difficile se stai cercando di convincere il tuo team che una nuova direzione completa è migliore, perché probabilmente ritarderà il progetto, ecc.

Non mettere le persone in modalità difesa in una riunione, ti combatteranno solo per essere il vincitore. Non riuscirai a convincerli che la terra è rotonda. Questa è una politica normale (es. Chiunque su FoxNews)

Aiuta davvero ad avere il rispetto degli altri sviluppatori. Se sei il nuovo ragazzo della squadra, penso che tu sia SOL. Quindi costruisci un rappresentante della squadra e cerca davvero di raggiungere un livello se non verrai espulso subito. Certo, se sei sempre roba pessimista, allora sarai etichettato come il ragazzo "negativo".

Per cose semplici (cioè non influisce sui programmi), assicurati di fare il tuo lavoro nel modo migliore. Se metti lo sforzo nell'output immediato (ad es. Costruendo casi di test o ottenendo alcune funzioni semplici (ma interessanti)) alla fine altre persone noteranno che il tuo codice funziona in modo affidabile e resiste alla prova del tempo. Quando inizi a mostrare loro alcuni trucchetti con il codice, ci penseranno due volte a spararti di fronte a tutti.

Infine, sono d'accordo che non vuoi fare la routine "Te l'ho detto", ma assicurati di provare a rilasciare suggerimenti al tuo capo / responsabile tecnico quando si trasforma in realtà avevi ragione. Forse reinvia una vecchia e-mail con i tuoi vecchi commenti. Chiedi loro se questo potrebbe aiutare a risolvere il "nuovo" problema. Se non lo fai, non si ricorderanno nemmeno che sei stato tu a farlo apparire per la prima volta. Alla fine avranno la sensazione che non stai solo cercando di essere uno showoff negli incontri. La prossima volta ci penseranno due volte a farti saltare in aria, soprattutto se si aggira il fatto che il tuo "vecchio" design sta sostituendo quello attualmente rotto.

Prova a costruire una reputazione come la persona che può identificare ciò che funzionerà e non solo ciò che pensi possa avere un problema in alcuni rari casi d'uso. Quando vedi questi potenziali problemi, considerali una nota a piè di pagina che potrebbe essere necessario affrontare in un secondo momento.

La gente impazzisce nelle congregazioni. Indica le tue preoccupazioni a una persona chiave al di fuori della riunione. Vedranno questo come meno minaccioso e potrebbe richiedere del tempo per ascoltare la tua discussione invece di pensare alla loro difesa del design. Potrebbero anche volerci più tempo per spiegarti le circostanze per cui potresti avere un punto valido, ma non è possibile affrontare la v1.0.

Chiave! Partecipa all'incontro con una completa comprensione di ciò che è l'agenda del tuo supervisore diretto. Forse vedono questo come un progetto minore e l'ultima cosa di cui hanno bisogno durante l'incontro è un noayayer che prende tempo lontano da questioni più importanti. Chiedi loro di aiutarti ad aiutarli.

Se vuoi influenzarli, parlane con loro al di fuori della riunione di progettazione. Altrimenti penseranno solo che stai cercando di "segnare punti" su di loro. Molte persone non vogliono mai avere delle vere discussioni in un incontro con un "pubblico".

Non vedo come questa situazione sia molto diversa da uno sviluppatore solitario con un capo senza conoscenza. Sfortunatamente, ho perso il conto del numero di volte in cui sono stato "convinto" a costruire un progetto in un certo modo e spedirlo, nonostante i miei avvertimenti di condanna imminente. Ciò ti lascia non solo a costruire, ma a guidare il proverbiale Titanic in un iceberg da solo.

Proprio come hai descritto, quando i pezzi hanno colpito il proverbiale secchio, i miei avvertimenti erano stati dimenticati da tempo. A volte (per fortuna per me) le cose sono andate male per mesi o più dopo che non ero più coinvolto nel progetto. Sfortunatamente, questo ha lasciato il mio successore pensando che dovevo essere pazzo, poiché puoi scommettere che il boss ha negato qualsiasi mano in esso :)

In ogni caso, un gruppo di programmatori 'convinti' può essere altrettanto incompetenti come un boss dai capelli a punta, a volte anche di più perché sono incompetenti con fiducia, come cita Jeff O . Quando ciò accade, hai tutto il tempo per sistemare le cose. Non cercare di far sentire una sola voce della ragione su una scoreggia cerebrale collettiva. Se riesci a farlo in modo efficace, il tuo posto è in un congresso, non dietro un software di scrittura da scrivania.

Poiché le azioni parlano più delle parole, puoi:

• Mostra (con scenari di test) il motivo per cui la progettazione fallirà in circostanze normali. Ciò si tradurrà probabilmente in una riunione più piccola in cui sei tu a presentare, ed è probabilmente tutto ciò di cui hai bisogno per essere ascoltato.

• Mostra un prodotto concorrente che affronti adeguatamente quelle che il gruppo pensava fossero solo "casi d'angolo". Si sarebbe stupito a che punto Google va ad anticipare gli errori nel suo programma di foglio di calcolo, per esempio.

• Ribadisci l'ultimo progetto che ha richiesto una nuova riscrittura una settimana prima della consegna.

In altre parole, il primo passo, indipendentemente da ciò che fai, è gestire le persone o un gruppo (molto) più piccolo. Se le tue preoccupazioni sono davvero valide, sono sicuro che riceveranno meglio una o due settimane in fase di sviluppo. Solo, come hai notato, evita la posizione "Te l'ho detto".

Se possibile, rivedi il progetto prima (o anche dopo) dell'incontro e parla con i designer in privato. Abbattere le persone in una riunione di fronte a tutti i loro colleghi tenderà a renderli immediatamente difensivi e di mentalità chiusa sui tuoi suggerimenti e può portare a una reputazione di "piantagrane" anche se pensi di essere utile.

Un buon modo (ma spesso difficile) per presentare "critiche" è quello di porre domande principali: lascia che l'altra persona cerchi di rispondere alla tua domanda e realizzi il difetto per se stesso. Quindi sembra molto più simile alla propria idea e saranno più propensi a portarla avanti. Ancora una volta, questo funziona meglio nelle discussioni private, ma può essere un modo più diplomatico ed efficace di avanzare in una situazione di riunione (Nota: cerca di evitare di entrare in una discussione o in una lunga discussione per convincere le persone alla riunione. Basta far passare l'idea e provare non lavorare sul punto. Potrebbe essere meglio lasciarlo andare e poi fare una chiacchierata con i designer dopo l'incontro per "chiarire qualcosa che non ho capito bene" piuttosto che essere "il ragazzo che ha fatto un semplice 30 minuti incontro sprecare la mia intera mattinata ")

Un altro approccio è inviare i tuoi suggerimenti (diplomaticamente) via e-mail al lead designer (o una lista di distribuzione pertinente ma piccola). Può aiutarti a prendere in considerazione le tue idee, e ti dà anche una "scia di carta" per supportare qualsiasi situazione "Te l'ho detto" in futuro (se le cose vanno a forma di pera, almeno hai la prova che hai cercato di aiutare ma ignorato. Ma se le cose peggiorano, probabilmente non stai lavorando nella compagnia giusta)

Infine, tieni presente che a volte potresti essere "sbagliato". Le persone con cui stai parlando potrebbero avere una comprensione più chiara o più completa del loro design di te e avere buone ragioni per il loro approccio (ad esempio, sono stato recentemente accusato da un membro del team di creare un design "inefficiente", ma era un progetto deliberato poiché sapevo che le prestazioni sarebbero state comunque accettabili, ma avrebbe dimezzato i costi di sviluppo - è stata una decisione commerciale piuttosto che una decisione sulla qualità del codice). Cerca solo di avere una mentalità aperta sulle idee degli altri - a volte ciò che ti sembra una cattiva idea può essere una buona idea per ragioni che non hai preso in considerazione.

Quando incontrati con lo scenario "che non accadrà mai", ricorda loro tutte le volte in cui hanno dovuto riparare quegli oggetti "che non accadranno mai". Ma devi stare attento a non imbatterti in "Te l'avevo detto". Trovo più efficace far emergere i problemi del passato (e quanto costosi e dolorosi fossero da risolvere) nel discutere il motivo per cui pensi che dovremmo fare qualcosa per questo progetto come esempi del perché pensi che sia importante prima che portino il "che "non accadrà mai".

Penso che forse il tuo problema sia che dici di menzionare casualmente un modo per evitare un problema, forse dovresti venire armato di più informazioni e mostrare loro più in dettaglio perché questo è un rischio per il sistema. A volte questo significa sollevare l'argomento in una seconda riunione dopo aver avuto il tempo di fare una piccola ricerca. Costruisci un business case per quanto sia economico fare ora e vice quanto costa farlo in seguito.

Sembra che la tua scommessa migliore sia quella di lavorare per arrivare a una posizione di leader della squadra. Usa queste opportunità per indicare i poteri che hai visto arrivare e che avrebbero potuto essere evitati. Non dovresti aver bisogno di vendere la tua squadra attuale per farlo.

Il "casual" nel "citare casualmente i buchi" sembra essere un problema. Prova a utilizzare (o introdurre se non esiste) un processo scritto per analizzare i rischi del progetto. In genere il risultato di una riunione di analisi dei rischi è una semplice tabella a due colonne: il rischio e quale sia la strategia concordata per mitigare il rischio ("pensiamo che non accada mai" è una mitigazione accettabile; l'importante è registrare il pensiero attuale sulla questione al momento). Assicurati che i tuoi problemi siano registrati come rischi. I rischi dovrebbero essere rivisti periodicamente; è probabile che alcune persone saranno arrivate al tuo punto di vista molto prima che la crisi effettivamente si verifichi e una revisione dei rischi fungerà da "OMG che accade; saremmo pazzi da portare avanti come questo "catalizzatore. A lungo termine, una traccia di carta è una prova utile per dire" guarda, qui sembra che ci sia un problema istituzionale "e ottenere atteggiamenti verso il design o qualunque cosa sia cambiata.

Come realizzare le tue idee

In primo luogo nelle riunioni si riferiscono ai problemi come sfide. Risolvi i problemi, superi le sfide. Le sfide sono cose buone, i problemi no.

Inizia lentamente e usa questa tecnica su una singola sfida alla volta. La prossima volta che vuoi che il tuo capo adotti una delle tue idee, procedi come segue:

• Sviluppa tre approcci simili ma diversi
• Di 'al tuo capo che hai bisogno del suo aiuto per qualcosa
• Spiega che non sei sicuro di quale dei tre metodi sia la migliore linea d'azione per risolvere il problema
• Chiedigli di aiutarti a scegliere una delle tre

1. Questo è estremamente potente. Quello che stai facendo è fornire scelte non un ultimatum. Gli Ultimatum più spesso non vengono abbattuti perché non è una loro idea e c'è solo un'opzione.

2. Il tuo uso delle parole è molto importante qui. " Ho bisogno del tuo aiuto ".

3. Lascia che il boss scelga "A", "B" o "C". Infatti, lascia che il boss crei l'opzione "D" estraendo le sezioni da "A", "B" e "C". Quello che stai facendo è lasciare che il tuo capo faccia una scelta.

A questo punto potresti non preoccuparti dell'opzione che sceglie, perché sono tutte le tue idee. Penserà di risolvere davvero il problema perché lasci che la decisione diventi sua.

Hanno Proof of Conceptimplementato la tua idea. Se mostri alla tua squadra qualcosa che funziona e risolve il problema attuale a loro piacerà.