Quanto efficacemente "vende" un buon design nelle grandi riunioni

Se possibile suggerisci modifiche che non aggiungano tempo significativo a un progetto. Prova e sottolinea che se non è stato fatto ora, ri-lavorare più tardi sarà molto più doloroso. Sarà più difficile se stai cercando di convincere la tua squadra che una nuova direzione completa è migliore, perché probabilmente ritarderà il progetto, ecc.

Non mettere le persone in modalità difesa in una riunione, ti batteranno solo per essere il vincitore. Non li farai accettare che la terra è rotonda. Questa è una politica normale (ad esempio chiunque su FoxNews)

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

Per cose semplici (cioè non ha impatto sui programmi), assicurati di fare il tuo lavoro nel modo migliore. Se metti lo sforzo nel tuo output immediato (ad esempio costruendo casi di test o ottenendo alcune semplici (ma interessanti) funzionalità), altre persone noteranno che il tuo codice funziona in modo affidabile e resiste al test del tempo. Quando inizi a mostrare loro alcuni trucchetti con il codice, ci penseranno due volte a spararti davanti a tutti.

Infine, sono d'accordo sul fatto che non vuoi fare la routine "Ti ho detto così", ma assicurati di provare a rilasciare suggerimenti al tuo capo / capo tecnico quando ti fanno effettivamente avere ragione. Forse inviare nuovamente 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 ricorderanno nemmeno che sei stato tu a portarlo su per la prima volta. Alla fine capiranno che non stai solo cercando di essere uno showoff negli incontri. La prossima volta ci penseranno due volte prima di soffiarti, soprattutto se si aggira il fatto che il tuo "vecchio" design sta ora sostituendo quello attuale rotto.

Cerca di costruire una reputazione come la persona che può identificare ciò che funzionerà e non solo quello che pensi abbia un problema in qualche raro caso d'uso. Quando vedi questi potenziali problemi, considera solo una nota a piè di pagina che potrebbe essere necessaria in seguito.

Le persone impazziscono nelle congregazioni. Menziona le tue preoccupazioni a una persona chiave al di fuori della riunione. Vedranno questo come meno minaccioso e potrebbe impiegare il tempo per ascoltare la tua argomentazione invece di pensare alla loro difesa del design. Potrebbero anche avere più tempo per spiegarti le circostanze per le quali potresti avere un punto valido, ma non è possibile indirizzarlo nella v1.0.

chiave! Partecipa all'incontro con una comprensione completa di quale sia 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 oppositore 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 semplicemente che stai cercando di "guadagnare punti" da loro. Molte persone non vogliono mai avere discussioni reali in un incontro con un "pubblico".

Non vedo come questa situazione sia molto diversa da uno sviluppatore solitario con un capo clueless. Sfortunatamente, ho perso il conto del numero di volte in cui ero "convinto" a costruire un progetto in un certo modo ea spedirlo, nonostante i miei avvertimenti di imminente rovina. Ciò ti lascia non solo costruendo, ma navigando il proverbiale Titanic direttamente in un iceberg tutto da solo.

Proprio come hai descritto, quando i pezzi hanno colpito il secchio proverbiale, i miei avvertimenti erano stati da tempo dimenticati. A volte (fortunatamente 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, dato che puoi scommettere che il capo ha negato qualsiasi mano in esso:)

Ad ogni modo, un gruppo di programmatori "convinti" può essere altrettanto indifferente di un capo dai capelli a punta, a volte anche di più perché non ha confidenza, come Jeff O cita . 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 congresso, non dietro un software di scrittura da scrivania.

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

• Mostra (con scenari di test) perché il progetto fallirà in circostanze normali. Questo probabilmente si tradurrà in un incontro più piccolo in cui tu sei quello che presenta, ed è probabilmente tutto ciò che devi sentire.

• Mostra un prodotto concorrente che affronta in modo adeguato ciò che il gruppo pensava fossero solo "casi d'angolo". Ad esempio, rimarrai stupito su quale lunghezza Google anticipa gli errori nel suo foglio di calcolo, ad esempio.

• Conferma l'ultimo progetto che richiedeva una riscrittura di base una settimana prima della consegna.

In altre parole, il primo passo, indipendentemente da ciò che fai, è trattare con individui o con un gruppo (molto) più piccolo. Se le tue preoccupazioni sono davvero valide, sono sicuro che saranno meglio accolte una settimana o due in fase di sviluppo. Proprio come hai notato, evita la posizione "ti ho detto così".

Se possibile, rivedere il disegno prima (o anche dopo) della riunione e parlare in privato con i progettisti. Sparare le persone in un incontro di fronte a tutti i loro colleghi tenderà a renderle istantaneamente difensive e chiuse sui tuoi suggerimenti, e può portare ad una reputazione come un "guastafeste" anche se pensi di essere di aiuto.

Un buon (ma spesso difficile) modo di presentare "critiche" è quello di porre domande importanti - lasciare che l'altra persona cerchi di rispondere alla tua domanda e realizzare il difetto per se stesso. Quindi sembra molto più simile alla loro idea e saranno più propensi a portarlo avanti. Ancora una volta, questo funziona meglio nelle discussioni private, ma può essere una via più diplomatica ed efficace in una situazione di incontro (Nota: cerca di evitare discussioni o lunghe discussioni per convincere le persone all'incontro. Per non affaticare il punto, potrebbe essere meglio lasciarlo andare e poi fare una chiacchierata con i designer dopo l'incontro per "chiarire qualcosa che non ho capito" piuttosto che essere "il ragazzo che ha fatto un semplice 30 minuti incontro per la mia intera mattinata ")

Un altro approccio è quello di inviare i tuoi suggerimenti (diplomaticamente) via email 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 cartacea" per supportare qualsiasi situazione "Ti ho detto così" in futuro (se le cose vanno a pera, hai almeno la prova che hai cercato di aiutare ma ignorato, ma se le cose vanno così male, probabilmente non stai lavorando nella giusta compagnia)

Infine, ricorda che a volte potresti essere "sbagliato". Le persone con cui stai parlando potrebbero avere una comprensione più chiara o completa del loro progetto rispetto a te e hanno 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 disegno intenzionale perché sapevo che le prestazioni sarebbero state comunque accettabili, ma avrebbe dimezzato i costi di sviluppo: era una decisione commerciale piuttosto che una decisione sulla qualità del codice). Cerca solo di essere aperto sulle idee degli altri - a volte ciò che sembra una cattiva idea per te può essere una buona idea per ragioni che non hai considerato.

Quando si incontra lo scenario "che non accadrà mai", ricorda loro tutte le volte in cui hanno dovuto riparare quegli elementi "che non accadrà mai". Ma devi stare attento a non presentarti come "te l'avevo detto". Trovo che sia più efficace far emergere i problemi del passato (e quanto costosi e dolorosi dovessero risolvere) nel discutere perché pensi che dovremmo fare qualcosa per questo progetto come esempi del perché pensi questo importante prima che portino "quel non accadrà mai "quote.

Penso che forse il tuo problema è che dici di menzionare casualmente un modo per evitare un problema, forse dovresti venire armato con più informazioni e mostrarle 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. Costruire un business case per quanto è economico fare ora vice di quanto sia costoso farlo in seguito.

Sembra che la cosa migliore da fare sia lavorare per ottenere una posizione di comando della squadra. Usa queste opportunità per sottolineare i poteri che hai visto arrivare e che avrebbe potuto essere evitato. Non dovresti aver bisogno di vendere la tua squadra attuale in questo modo.

Il "casual" in "casualmente menzionare i buchi" sembra essere un problema. Prova ad usare (o portare se non esiste) un processo scritto per analizzare i rischi del progetto. In genere l'output di una riunione di analisi dei rischi è una semplice tabella a due colonne: il rischio e la strategia concordata per mitigare il rischio ("pensiamo che non accada mai" è una mitigazione accettabile, l'importante è registrare il pensiero corrente sul problema al momento). Assicurati che i tuoi problemi siano registrati come rischi. I rischi dovrebbero essere rivisti regolarmente; è probabile che alcune persone si siano rivolte al tuo punto di vista molto prima che la crisi possa effettivamente accadere e una revisione dei rischi agirà come un "OMG che succederà ; saremmo pazzi a continuare come questo "catalizzatore. A lungo termine, una traccia cartacea è una prova utile per dire "guarda, sembra che abbiamo qui un problema istituzionale" e ottenere atteggiamenti verso il design o qualsiasi altra cosa sia cambiata.

Come implementare le tue idee

Il primo degli incontri fa riferimento a problemi come sfide. Risolvi i problemi, superi le sfide. Le sfide sono buone cose, i problemi non lo sono.

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
• Dì al tuo capo che hai bisogno del suo aiuto con qualcosa
• Spiega che non sei sicuro di quale dei tre metodi sia la soluzione migliore per risolvere il problema
• Chiedigli di aiutarla a scegliere uno dei tre

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

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

3. Lascia che il capo scelga "A", "B" o "C". In effetti, il capo crea 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 ti potrebbe interessare meno l'opzione che sceglie, perché sono tutte le tue idee. Penserà che in realtà sta risolvendo il problema perché lasci che la decisione diventi sua.

Hai implementato Proof of Concept della tua idea. Se mostri alla tua squadra qualcosa che funziona e risolva il problema attuale, gli piacerà.