Il nostro capo progetto è un geniale architetto del software, una persona gentile e premurosa in generale, un disadattato per natura e delicato con la voce. Ma, a volte, noi (i miei compagni di squadra ed io) differiamo nelle opinioni - in particolare su 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
Pensa sempre al risultato. Nella maggior parte dei casi non vuoi essere giusto per il bene di essere giusto, devi solo fare un buon lavoro. La terza opzione aiuta a raggiungere questo obiettivo.
Trattalo allo stesso modo - gentilmente e con rispetto quando esprimi opposizione.
Essere professionisti implica essere rispettosi dei tuoi pari e superiori, non significa che non puoi essere in disaccordo significa solo 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à di educazione, sia per me che per i membri del mio team.
Non è questo un esempio del vecchio errore anticonformista o passivo?
La terza opzione classica è l'assertività, che consente la critica costruttiva e il disaccordo educato .
Altrettanto importante - accettare la critica costruttiva (senza necessariamente essere d'accordo con esso), e accettare un ragionevole disaccordo (non essere ossessionato da un concorso who-is-right-and-who-is-wrong).
E alla fine della giornata, una sorta di passività - rimandando al tuo superiore - sarà sempre necessaria. È lui l'unico responsabile della decisione: capacità, autorità e responsabilità non sono la stessa cosa, ma almeno dovrebbero andare insieme.
BTW - "People Skills" di Robert Bolton è un buon (e abbastanza economico) libro per cose come questa: capacità di ascolto, assertività e altro.
Visto che sembri rispettarlo e sembra un tipo intelligente, perché non chiederglielo nel modo seguente:
"In che modo il tuo metodo / modo / architettura gestisce il problema di x?" In caso contrario, dire qualcosa come: "Beh, che ne dici di farlo in questo modo, in che modo viene gestito il problema x?"
In questo modo, puoi imparare se ha già pensato a "x problema" e se ha imparato qualcosa. O se non lo ha, ci penserà e magari userà la tua soluzione o penserà a un'altra (forse la risolverai insieme).
Vorrei poter trovare un esempio più concreto, ma penso che dovresti essere in grado di ottenere l'idea.
Non penso che prima andrai dal tuo capo, specialmente se non è un programmatore o qualcosa del genere.
E non c'è bisogno di dire che la sua strada è cattiva, ma chiedendo come gestisce certe situazioni potrebbe realizzare un problema o essere in grado di dirti perché non è un problema.
Spero che questo aiuti.
Usando la parola CONFRONT, stai dimostrando che non ti stai avvicinando al problema con la giusta mentalità.
Non è un confronto. Non è ostile. Non è bellicoso o arrabbiato. È una discussione su diversi approcci e costi e benefici.
Non entrare con sei cannoni ardenti. Digli solo qualcosa a cui hai pensato. "E se dovessimo farlo in questo modo?" Chissà, potresti convincerlo.
E se non lo fai - e qualche volta non lo farai - ricordati che potrebbe ben sapere cose che tu non sai, su budget, orari, requisiti, altre priorità e così via. Non è necessariamente un idiota solo perché non è d'accordo con te.
Non è sbagliato dubitare di qualsiasi decisione o di una determinata architettura di progettazione / software. A meno che tu abbia appena iniziato il tuo primo lavoro, nel qual caso ti sbagli il 99% delle volte perché ti manca alcune parti dell'immagine più grande .
Quando tu (e / o il team) differisci nelle opinioni, chiedi al capo del progetto se ha del tempo per discuterne, o magari pianifica anche una piccola riunione (15-30 minuti). Sfogare la propria opinione in modo rispettoso e ascoltare perché ha preso la sua decisione diversamente. Se vedo come lo descrivi, sarà felice di discutere e condividere le sue opinioni sul problema. Non dirà "perché ho detto così" (tali persone esistono purtroppo). In tal caso ignora la tua opinione se vuoi mantenere il tuo lavoro, o sfogarlo e partire per un altro lavoro perché diventerai infelice.
Una buona discussione può finire in diversi modi:
Ad ogni modo, dovresti vederlo come un'opportunità per imparare e finché lo mantieni civilizzato e rispettoso, avrai ottime esperienze con queste discussioni.
Sollevalo!
Nel modo più civile possibile, dirò in genere "Sono interessato a questo aspetto, quali sono i tuoi pensieri su questo potenziale problema?"
Metterò la palla nella sua corte per istruirmi.
Il segno n. 1 di uno sviluppatore e manager maturo è che sono in grado di ammettere di aver sbagliato. Dimostra innanzitutto al tuo capo che tutti voi siete perfettamente disposti ad ammettere che avete 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 farlo), questo non sarà generalmente un problema! Vedrai che puoi avere una discussione costruttiva e venire alla soluzione migliore per tutti voi.
Una cosa su cui devi stare attento: assicurati che la maggior parte delle volte tu abbia delle vere ragioni tecniche, ben fondate, per dubitare del progetto proposto. "Sembra sbagliato" in genere non è sufficiente e non contribuirà a una discussione costruttiva. Se questo accade troppo spesso, il tuo capo non avrà altra scelta che mandare in cortocircuito la "discussione" (che è una luce di fatto, quindi non una vera 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: prendere le decisioni che gli sviluppatori potrebbero trovare difficili da fare.
Secondo me e come mi comporto generalmente con il mio capo:
Sempre dai la tua opinione e fallo al più presto mentre l'argomento è caldo. Idealmente quando stai avendo una mischia su un nuovo problema o progetto piuttosto che dopo, quando hai raccolto il tuo coraggio e le decisioni sono già state stabilite.
Dovresti suggerire apertamente le tue opinioni, i tuoi dubbi, i tuoi problemi e assicurarti che si presentino come suggerimenti o preoccupazioni piuttosto che imporre che deve essere fatto in questo modo.
Prendi l'abitudine e diventa un comunicatore migliore, membro del team e, a sua volta, una squadra migliore. Una buona squadra parlerà apertamente delle cose negative e del positivo. Un buon capo squadra ascolterà la sua squadra e prenderà una decisione prendendo in considerazione le informazioni fornite.
Buona fortuna.
Se è un buon architetto come descrivi, avvicinati a lui in modo istruito con motivi logici e specifici per le tue preoccupazioni.
Se hai tempo / risorse, prova a fare dei test sugli scenari che dimostrerebbero che hai ragione, avere alcuni dati dalla tua parte è un vantaggio enorme.
Una volta che parli con lui, può solo:
a) Accetto con te: problema risolto!
b) Rifiutali e spiegali perché: forse dopotutto sei tu a sbagliare.
c) Rifiutali senza motivo: se è irragionevole e sei del tutto 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 di Il gruppo. Non renderà l'architetto molto felice, ma è la cosa etica da fare (immagina di aver progettato un edificio e di aver visto un difetto nella struttura ...)
My question is: when and how (whether?) to express the differences in opinions.
Assolutamente sì è la risposta. A meno che tu non abbia una situazione di rara fuori controllo dove anche il potenziale di turbolenza o di perdere il lavoro a causa di ciò è così grande, dovresti confrontarti con gli altri quando hai opinioni diverse.
La vera chiave qui è quando e come.
1st the 'When': Ogni ambiente è diverso ma alcuni luoghi hanno riunioni settimanali o discussioni tavola aperta / rotonda in cui sollevare determinati argomenti è l'arena appropriata per farlo. La cosa principale che non vuoi fare è renderla come se stai 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 l'essere sfidati e forse persino imbarazzati in pubblico. Per queste situazioni, prova a pianificare un incontro 1 su 1 con la / le persona / e in questione per descrivere i tuoi pensieri.
Secondo il "come": se stai andando da una persona anziana, assicurati di avere tutte le anatre di fila a sostegno dei tuoi pensieri. Non puoi semplicemente divagare in un ufficio per le persone di alto livello dicendo "Tutti i moduli web devono essere fermati e noi dobbiamo fare MVC!". Alla domanda "Perché?" e tu dici "Beh, questo è quello che stanno facendo tutti ed è in tutte le riviste", non andrà lontano. Preparati per il dibattito avanti e indietro e chiedendo di giustificare i tuoi pensieri su architettura, codifica, progettazione, buone pratiche, ecc. Se hai esempi di codice funzionante da giustificare (cioè una piccola bardatura di prova per provare un pensiero) questo può aiuto pure. La cosa importante qui è non entrare in una battaglia dell'ego o permettere che le emozioni si innalzino. Ciò si tradurrà in una riunione non produttiva e potresti non riuscire a implementare le tue idee.
Alla fine, se hai suggerimenti solidi, giustificabili e logici, dovrebbero essere presi in considerazione. Comunque sia anche preparato che ci siano solo persone irragionevoli in questo mondo che non vogliono ascoltare nessuno tranne se stessi. Spero che tu non sia appoggiato in un angolo con questo tipo di personalità.
Buona fortuna!
Non sono sicuro di come si possa diventare un geniale architetto di software senza commettere errori e interrogarsi su di loro. Penso che sia sicuro presumere che sia stato in questa situazione prima.
Le persone intelligenti, mature e professionali non possono resistere a lungo alla tentazione di idee migliori. Anche se all'inizio è preoccupato di avere le sue idee in discussione, alla fine dovrebbe venire in giro e ne guadagnerai rispetto. Se non è né maturo né professionale, hai un problema più grande, e forse questo farà brillare una 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. Tieni anche presente che per quanto riguarda l'architettura esistono sostanzialmente due diverse possibilità per questi problemi:
Leggi altre domande sui tag teamwork