Quando confrontarsi con un buon capo progetto o capo

Il nostro capo progetto è un geniale architetto del software, una persona gentile e premurosa in generale, un fanatico della natura e delicato con la voce. Ma, a volte, noi (i miei compagni di squadra e io) differiamo nelle opinioni, in particolare per quanto riguarda i problemi di architettura del software, problemi di progettazione del sistema, problemi di interfaccia utente, ecc., Con il nostro leader.

Quando e come (se mai) dovremmo esprimere la differenza di opinioni?

Supponi di pensare che il tuo capo abbia torto. Hai tre opzioni

• fai quello che dice e finisci frustrato pensando di fare qualcosa di stupido - non molto a lungo termine
• digli che è un idiota - o lo ignorerà o avrai problemi di comunicazione - non ti fa niente o ti fa male.
• digli che hai delle preoccupazioni specifiche riguardo alle idee che propone e spiega quelle preoccupazioni : qualsiasi buon capo spiegherà la sua posizione e quindi potrai prendere una decisione che fa bene all'azienda. È molto probabile che vedrai che la sua idea è migliore della tua e hai ignorato qualcosa di molto importante.

Pensa sempre al risultato. Nella maggior parte dei casi non vuoi essere giusto per il bene di avere ragione, devi solo fare un buon lavoro. La terza opzione aiuta a raggiungere questo obiettivo.

Trattalo allo stesso modo - delicatamente e con rispetto quando esprimi l'opposizione.

Essere professionali implica essere rispettosi con i tuoi pari e superiori, non significa che non puoi dissentire, ma significa che dovrebbe essere educato e rispettoso in natura.

Quando la mia squadra ha un dubbio o un'opinione dissenziente sulle mie indicazioni, la considero un'opportunità per l'educazione, sia per me che per i membri del mio team.

Non è questo un esempio del vecchio errore aggressivo o passivo?

La terza opzione classica è l'assertività, che consente critiche costruttive e un gentile disaccordo.

Altrettanto importante: accettare critiche costruttive (senza necessariamente concordare con essa) e accettare ragionevoli disaccordi (non essere ossessionati da una competizione tra chi ha ragione e chi ha torto).

http://en.wikipedia.org/wiki/Assertiveness

E alla fine della giornata, sarà sempre necessaria una sorta di passività - che rimanda al tuo superiore. È lui con la massima responsabilità per la decisione: capacità, autorità e responsabilità non sono la stessa cosa, ma almeno dovrebbero andare insieme.

A proposito: "People Skills" di Robert Bolton è un buon libro (e abbastanza economico) per cose come questa: capacità di ascolto, assertività e altro.

http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

Dal momento che sembri rispettarlo e sembra un ragazzo intelligente, perché non chiederglielo nel modo seguente:

"In che modo il tuo metodo / modo / architettura gestisce il problema x?" In caso contrario, dire qualcosa del tipo: "Beh, che ne dici di farlo in questo modo, in questo modo il problema x viene gestito?"

In questo modo, puoi sapere se ha già pensato al "problema x" e se ha imparato qualcosa. Oppure, se non ce l'ha, ci penserà e forse userà la tua soluzione o ne penserà un'altra (forse ci riuscirai insieme).

Vorrei poter dare un esempio più concreto, ma penso che dovresti essere in grado di ottenere l'idea.

Non credo che prima andrai da nessuna parte dal tuo capo, soprattutto se non è un programmatore o qualcosa del genere.

E non c'è bisogno di dire che la sua strada è cattiva, ma chiedendo come gestisce determinate situazioni potrebbe realizzare un problema o essere in grado di dirti perché non è un problema.

Spero che aiuti.

Usando la parola CONFRONTA, stai dimostrando che non stai affrontando il problema con la giusta mentalità.

Non è uno scontro. Non è ostile. Non è bellicoso o arrabbiato. È una discussione di diversi approcci, costi e benefici.

Non entrare con sei pistole in fiamme. Digli semplicemente qualcosa a cui hai pensato. "E se dovessimo farlo in questo modo?" Chissà, potresti convincerlo.

E se non lo fai - e talvolta non lo farai - ricorda che potrebbe ben sapere cose che non conosci, su budget, programmi, requisiti, altre priorità e così via. Non è necessariamente un idiota solo perché non è d'accordo con te.

Non è sbagliato dubitare di alcuna decisione o di una determinata architettura di progettazione / software. A meno che quando hai appena iniziato il tuo primo lavoro, nel qual caso ti sbaglierai il 99% delle volte perché ti mancano alcune parti del quadro generale .

Quando tu (e / o il team) differisci nelle opinioni, chiedi al responsabile del progetto se ha un po 'di tempo per discuterne, o magari pianifica un piccolo incontro (15-30 minuti). Sfida la tua opinione in modo rispettoso e ascolta perché ha preso la sua decisione altrimenti. Se vedo come lo hai descritto, sarà felice di discutere e condividere le sue intuizioni sul problema. Non dirà "perché l'ho detto" (queste persone esistono tristemente). In tal caso, ignora la tua opinione se vuoi mantenere il tuo lavoro o sfogarti e partire per un altro lavoro perché diventerai infelice.

Una buona discussione può finire in diversi modi:

• Il responsabile del progetto accetterà la tua soluzione come un modo migliore per risolvere il problema (e forse ha imparato una nuova tecnologia, modello, ... con cui non aveva ancora molta esperienza).
• Tu e il team potete vedere una parte più grande dell'immagine o avere una buona spiegazione del perché dovreste farlo in questo e in quel modo. Imparerai qualcosa di nuovo e capirai che la soluzione iniziale era quella giusta, o forse troverai persino un modo per migliorarla con le nuove informazioni (anche se a un certo punto dovrai essere d'accordo).
• La discussione non aiuta e non sei ancora d'accordo. Succhiatelo e implementate la sua soluzione (perché molto probabilmente avrà più esperienza), o andate via.

Ad ogni modo, dovresti vederlo come un'opportunità per imparare e finché lo manterrai civile e rispettoso, avrai grandi esperienze con queste discussioni.

Tiralo su!

Nel modo più civile e maniacale che posso, in genere dirò "Mi preoccupo di questo aspetto, quali sono i tuoi pensieri su questo potenziale problema?"

Metterò la palla nel suo campo per educarmi.

Il segno n. 1 di uno sviluppatore e manager maturo è che sono in grado di ammettere di avere torto. Dimostra innanzitutto al tuo capo che tutti voi siete perfettamente disposti ad ammettere di avere torto quando lo siete, e fate capire al vostro capo che vi aspettate la stessa cortesia da loro.

Se hai un buon capo (e dici di sì) questo generalmente non sarà affatto un problema! Vedrai che puoi avere discussioni costruttive e giungere alla soluzione migliore per tutti voi.

Una cosa di cui devi fare attenzione: assicurati che la maggior parte delle volte tu abbia reali ragioni tecniche e fondate per dubitare del progetto proposto. "Sembra sbagliato" generalmente non è sufficiente e non contribuirà a una discussione costruttiva. Se ciò accade troppo spesso, il tuo capo non avrà altra scelta che cortocircuitare la "discussione" (che è leggera, quindi non proprio una discussione) e dire "scusate ragazzi, ma farete ciò che ho suggerito fino a quando non potete dimostrare con fatti perché qualche altra idea è chiaramente migliore ".

Ecco perché il tuo capo è il capo - per prendere le decisioni che gli sviluppatori potrebbero trovare difficili da prendere.

Secondo me e come mi comporto generalmente con il mio capo:

Dai sempre la tua opinione e fallo al più presto mentre l'argomento è caldo. Idealmente quando si sta vivendo una mischia per un nuovo problema o progetto piuttosto che farlo più tardi, quando si è raccolto il proprio coraggio e le decisioni sono già state stabilite.

Dovresti suggerire apertamente le tue opinioni, preoccupazioni, problemi e assicurarti che si presentino come suggerimenti o preoccupazioni piuttosto che imporre che debba essere fatto in questo modo.

Prendi l'abitudine e diventa un comunicatore, un membro del team migliore e, a sua volta, un team migliore. Una buona squadra parlerà apertamente delle cose negative e di quelle positive. Un buon team leader ascolterà la sua squadra e prenderà una decisione prendendo in considerazione le informazioni fornite.

In bocca al lupo.

Se è un bravo architetto come lo descrivi, avvicinati a lui in modo educato con ragioni logiche e specifiche per le tue preoccupazioni.

Se hai il tempo / le risorse prova a fare dei test sugli scenari che dimostrerebbero che hai ragione, avere dei dati dalla tua parte è un grande vantaggio.

Una volta che parli con lui, può solo:

a) Concordo con te: problema risolto!

b) Respingili e spiega perché: forse dopo tutto sei tu quello che ha torto.

c) Rifiutali senza motivo: se è irragionevole e sei assolutamente sicuro, esprimi la tua preoccupazione per il progetto responsabile, in questo caso hai davvero bisogno di dati freddi e, se puoi, il supporto degli altri membri del team. Non renderà molto felice l'architetto, ma è la cosa etica da fare (immagina di progettare un edificio e di aver visto un difetto nella struttura ...)

La mia domanda è: quando e come (se?) Esprimere le differenze di opinioni.

Assolutamente Sì, è la risposta. A meno che tu non abbia una situazione rara fuori dal tuo controllo maggiore in cui anche il potenziale di turbolenza o perdita del lavoro a causa di esso è così grande, dovresti confrontarti con gli altri quando hai opinioni diverse.

La vera chiave qui è quando e come.

1 ° il "Quando": ogni ambiente è diverso, ma alcuni luoghi hanno incontri settimanali o discussioni di tavolo aperto / rotondo in cui la presentazione di determinati argomenti è l'arena appropriata per farlo. La cosa principale che non vuoi fare è renderlo come se stessi sminuendo o rendendo pubblico qualche argomento di design personale che è tra te e solo 1 o 2 altri. Le persone che stai sfidando non apprezzeranno essere sfidate e forse anche imbarazzate in pubblico. Per queste situazioni, prova a pianificare un incontro 1 su 1 con le persone in questione per dettagliare i tuoi pensieri.

2 ° "Come": se stai andando da una persona anziana, assicurati di avere tutte le tue anatre di fila per sostenere i tuoi pensieri. Non puoi semplicemente entrare in un ufficio per persone di livello senior dicendo "Tutti i moduli web devono essere fermati e dobbiamo fare MVC!". Alla domanda "Perché?" e tu dici "Bene, è quello che fanno tutti ed è su tutte le riviste", non andrà lontano. Preparati alla discussione avanti e indietro e ti viene chiesto di giustificare i tuoi pensieri su architettura, codifica, progettazione, migliori pratiche, ecc. Se hai esempi di codice di lavoro da giustificare (ad esempio un piccolo cablaggio di prova per dimostrare un pensiero), questo può anche di aiuto. La cosa importante qui è non entrare in una battaglia dell'Io o permettere alle emozioni di emergere.

Alla fine, se hai suggerimenti solidi, giustificabili e logici, dovrebbero essere presi in considerazione. Tuttavia, preparati anche che ci sono solo alcune persone irragionevoli in questo mondo che non vogliono ascoltare nessuno tranne loro stessi. Spero che non ti trovi in ​​un angolo con questo tipo di personalità.

In bocca al lupo!

Non sono sicuro di come diventare un brillante architetto del software senza fare errori e senza essere interrogato su di essi. Penso che sia sicuro presumere che si sia già trovato in questa situazione.

Le persone intelligenti, mature e professionali non possono resistere a lungo al richiamo di idee migliori. Anche se all'inizio è arrabbiato perché le sue idee sono state messe in discussione, alla fine dovrebbe venire in giro e te ne guadagnerai il rispetto. Se non è né maturo né professionale, hai un problema più grande, e forse questo farà luce su di esso.

Se è un architetto professionista, rispetterà e accetterà una seconda opinione. Tuttavia, in ogni caso è necessario preparare bene l'alternativa basata su fatti / competenze e anche presentarla bene. Inoltre, tieni presente che per quanto riguarda l'architettura esistono sostanzialmente due diverse possibilità per tali problemi:

1. Un approccio / disegno può essere semplicemente giusto o sbagliato, come in matematica 2 + 2 = 4 e non cinque. Nel caso in cui sia sbagliato, devi trovare la soluzione giusta al più presto, sulla base di obiezioni di fatto.
2. Di gran lunga la maggior parte degli argomenti nella progettazione del sistema sono possibili approcci che non sono esclusivi. Esistono anche altre alternative, che scegliere dipende dall'esperienza, dal gusto, dalla propensione, dall'immagine generale, ecc. Per non sorvegliare un approccio forse migliore, di solito ci sono presentazioni e discussioni, quando gli sviluppatori sono incoraggiati a parlare e condividere le loro opinioni. Ma tieni anche presente che ci sono periodi di discussione e periodi di attuazione, nella programmazione agile queste fasi sono ben definite.