comunicazione della squadra (soprattutto via e-mail) - aperto o chiuso di default? [chiuso]

Question

Sono un ragionevolmente esperto sviluppatore C # (esperienza circa 5 anni) che è stato recentemente messo a capo del mio primo team di sviluppo come responsabile tecnico (variabile tra 3-5 altri sviluppatori). Nel corso degli ultimi 4 mesi in questo ruolo, un dilemma che tiene derivante sta cercando di trovare il giusto grado di condivisione consapevolezza della comunicazione che avviene tra il project manager, account manager, i clienti, i progettisti, CEO e me stesso (in particolare tramite e-mail) .

Da un lato, so che la maggiore consapevolezza ogni sviluppatore ha la direzione generale del progetto, il meglio che possano capire la portata che la loro funzionalità particolare ha nel quadro generale.

Tuttavia d'altra parte, un sacco del mio tempo sembra perdersi nel mare di messaggi di posta elettronica tra tutti i diversi soggetti interessati e responsabili, così mi piace pensare che isolare gli sviluppatori a poco "ciò che devono fare la loro attuale po 'di lavoro" li terrà libera da interruzioni.

ho preso in considerazione solo BCCing tutti gli sviluppatori in modo che possano filtrare questi messaggi di posta elettronica ed essenzialmente "opt-in" per tutti i messaggi di posta elettronica, ma io sono preoccupato del fatto che alcuni degli sviluppatori sarà solo vedere questo rumore come extra da affrontare. Può aprire la porta a "troppi cuochi" se tutti gli sviluppatori vogliono contribuire a troppe discussioni. Eppure, d'altro canto, altre opinioni possono aiutarmi a raggiungere decisioni migliori (cioè House MD stile).

Uff ... così tanto da prendere in considerazione. Qualcuno ha qualche saggia guida in questo settore?

Answer 1

Sembra che tu sei tecnica quindi vorrei dare questo consiglio: Seguire i consigli di Joel Spolsky su quale programma gestori fanno. In sostanza, cercare di isolare gli sviluppatori, per quanto possibile in modo che possano essere il più produttivo possibile.

Ha appena menzionato brevemente in questo recente articolo, Come essere un programma di direttore , ma lui è andato più in profondità su questo argomento prima. Guardare attraverso i suoi scritti precedenti per ulteriori informazioni:

  

Una volta che la specifica era finito e il team di sviluppo si mise al lavoro, avevo due responsabilità:. Risolvere eventuali questioni che si avvicinò circa il disegno, e parlando con tutte le altre squadre in modo che gli sviluppatori non hanno dovuto

Se non si è tecnica quindi è necessario selezionare qualcuno della tua squadra per aiutare con il lavoro di progettazione e avranno per interfacciarsi con il cliente un po 'per capire quali sono i requisiti e quale sia il miglior design è.

EDIT: Su home page di Joel ci sono due sezioni intitolate Tech Lead Program Manager. Guardate gli articoli per qualche più informazioni gestori dei programmi, in particolare Human Task Interruttori considerato nocivo .

Answer 2

Risposta a tardi, ma comunque credo che ci sia qualcosa da aggiungere alla superba consiglio dato finora. Per rispondere alla tua domanda abbiamo bisogno di andare un livello più alto, quindi la risposta a lungo.

Sei stato fatto un vantaggio tecnico responsabile della squadra e anche se molti aspetti del vostro lavoro di tutti i giorni potrebbe sembrare per assomigliare le vostre giornate dev il modo avete bisogno di andare su di loro è cambiato. In ambiente di sviluppo software v'è di solito non più di tanto di un cambiamento tangibile quando si nominato un lead tech (probabilmente stai ancora posti a sedere allo stesso tavolo, indossando lo stesso vestito) in contrapposizione a diventare un caporeparto in cantiere o di una fabbrica. Il cambiamento lusinghiero però è che ora invitato in tutti questi incontri e iniziare a ricevere tutte queste e-mail e telefonate da parte di persone al di fuori del team di sviluppo.

La mancanza di cambiamento tangibile potrebbe ingannare la mente a pensare che basta per mantenere il trattamento il vostro lavoro in gran parte la stessa. Questo non è il caso e bisogna essere consapevoli circa le vostre azioni e re-azioni nella nuova capacità. Potrebbe sembrare che sei ora un po ' “più rispettata” esternamente e si potrebbe essere incline a condividere parte di quel “rispetto” venire dalla tua parte internamente, giocare un po' di democrazia e in generale essere equo.

Bene, questo non è più di tanto l'equità e il rispetto, il nuovo lavoro è quello di:

• Dirigere il team di sviluppo (per lo più con l'esempio personale e la creazione di immagini raffiguranti l'obiettivo).

• Essere un livello di astrazione tra il team e le altre unità organizzative.

Più o meno come nella programmazione spesso si crea un livello di astrazione per incapsulare e nascondere la complessità, lo stesso accade nelle organizzazioni. Sei il livello, l'interfaccia che deve incapsulare il team di sviluppo. E ogni buon incapsulamento da un punto di vista esterno:

• nasconde complessità interno che non è rilevante per il compito a mano (come concreta applicazione di un algoritmo) da un osservatore esterno.

• rende le cose che potrebbero influenzare l'utente al di fuori espliciti (le eccezioni che possono essere lanciate, le eventuali limitazioni e vincoli, ecc).

• dà sempre un feedback significativo.

• la coerenza.

Questi principi sono applicabili anche alla comunicazione verso l'esterno della squadra. Non è un compito facile da seguire questi principi; in realtà si tratta di un sacco di lavoro concreto, come ad esempio decidere quali informazioni sono interni e quali fatti devono essere comunicati e quando, come il feedback ha bisogno di essere meglio strutturata e deve essere presentata in modo coerente, e che dovrebbero essere comunicate all'esterno di ciò che, e che ha bisogno di un seguito e quando. Questo è un sacco di lavoro, anche se alcuni di essi sembra essere solo amministratore banale.

Ora per interno, verso l'interno di comunicazione. Un modo è quello di trasmettere. Ma intasa la rete interna e tutti devono trascorrere il loro tempo per decidere se la comunicazione porta alcuna rilevanza per loro. È come avere un algoritmo molto generico che indipendentemente dall'ingresso fa sempre la stessa quantità di lavoro. E 'certo possibile, ma perché si vuole farlo? Un modo più efficace è ovviamente quello di regolare il trattamento a seconda dell'ingresso e qui deve essere il lavoro di qualcuno per prendere una decisione come la squadra dovrebbe andare di qualcosa, di essere spedite, o convertire l'ingresso:

• Decidere quale sequenza di azioni deve essere presa,

• o semplicemente riconoscere e conservare per riferimento futuro,

• o di follow-up,

• o mettere un problema fuori di una relazione entro e quindi assicurarsi che sia rivisto e reimmessa nel circuito decisionale.

Questo non è un piccolo lavoro sia e qualcuno deve pur farlo. Ovviamente ora è il tuo compito è di gestire l'andata e verso l'interno di comunicazione, e si deve passare un po 'di potenza di elaborazione del cervello per farlo bene, in modo che nessun altro ha da e sviluppatori possono concentrarsi sui loro compiti.

sono alcune altre buone ragioni per non CC-zione o indipendentemente dal vostro titolo di lavoro BCC-zione tutti:

• Per significa “agire”, CC - “prendere nota per riferimento futuro”, BCC - “origliare o mail di massa”. Si dovrebbe fare attenzione quando si utilizza uno o l'altro di e-mail un gruppo di persone:

  • E-mailing una sola persona è un dritto in avanti “TO”, quando di e-mail un gruppo di persone solo “A” questi che è necessario prendere provvedimenti (tra cui un semplice riconoscimento). Questo è senso di default, in ogni altro caso dire esplicitamente cosa ci si aspetta (cioè FYI, nessuna azione necessaria, ecc).

  • CC solo questi che si vuole prendere atto delle informazioni per il riferimento futuro. Se vi aspettate un certo numero di e-mail di andare avanti e indietro prima che venga raggiunto un accordo o problema viene risolto non lo fanno “CC”, è meglio per inviare conferma di sintesi in seguito ad altri soggetti che devono essere notificate. Oltre a risparmiare tempo di tutti e di evitare interpretazioni errate a causa di qualcuno che prende atto di una comunicazione non-finale che contribuirà a rendere lo scambio più personale, il flusso più naturale, e ridurre il formalismo e la burocrazia. Spesso CC-D E-mail trattati formalmente e questo non è sempre una buona cosa (ma a volte esattamente quello che vuoi).

  • Utilizzo BCC non è quasi mai ok. La conoscenza di qualcuno intercettazione delle conversazioni se vengono alla luce sarà facile rovinare la vostra credibilità. E 'semplicemente una questione di “quando”. E se la tua squadra preoccuparsi allora che si potrebbe essere BCC-zione loro conversazioni a qualcun altro? mailing di massa attraverso BCC nella maggior parte dei casi è anche sbagliato, crea l'impressione che la posta elettronica è specificatamente indirizzata al destinatario.

• Spedizioni, CC-ing e BCC-ing richiedono poco sforzo, ma si moltiplicano rumore e diluisce segnale. Vale la pena di riflettere su che cosa esattamente hai bisogno di una persona a fare e ciò che dovrebbero sapere ad agire per la vostra comunicazione, prima che lo compongono.

• Alcune conversazioni sono più presi completamente "off line" (telefono o meglio ancora faccia a faccia), perché ti dà più spazio per maneveour. Broadcasting o formalizzazione in scrittura è come mettersi in un angolo. È sempre possibile confermare per iscritto quest'ultimo.

Lo spostamento verso la seconda parte di una responsabilità di piombo tech (dirigere la squadra attraverso l'esempio personale e le immagini raffiguranti l'obiettivo). Per fare che non hai bisogno di trasmettere alla squadra ogni singolo pezzo di informazione che capita di finire nella posta in arrivo. È necessario creare una storia e ogni buona storia è un'astrazione di eventi reali che si compone di unico dettaglio rilevante e interessante per un pubblico particolare. La creazione di questa breve storia sulla base della vostra esperienza di tutti i giorni e, a giudicare ciò che è rilevante e interessante e poi presentare regolarmente per la squadra è anche un bel lavoro.

Ma non dimenticate che dirigendo la squadra e che serve come livello di astrazione aiutare gli sviluppatori e mondo esterno di interagire in modo più efficiente, realizzare sempre di affrontare una maggiore complessità, il lavoro è un punto.

Answer 3

Il team di ingegneri ha bisogno di capire le ragioni di business del perché si chiede loro di fare le cose su un livello macro. Il team di ingegneri guadagnerà la comprensione e la motivazione da questo. Ma troppo chiacchiericcio è un no-no, come si nota, parte del tuo lavoro è quello di filtrare , e parte di questo significa non esponendoli a tonnellate di rumore. I suoi sviluppatori probabilmente hanno opinioni e valutazioni su come fare le cose particolari o perché a raccogliere particolari tecnologie, e dovrebbero essere messi in campo per la loro esperienza in quelle aree.

Sicuramente non creare una cultura di BCCing.

Una possibilità è quella di avere liste separate che gli interessati possono sottoscrivere, ma, naturalmente, non tutti chiacchiere sarà in tali elenchi.

E, naturalmente, una riunione ordinaria società è un must. Lasciate che i ragazzi di ingegneria sanno perché il business dipende la consegna di un prodotto completo stabile (o qualsiasi altra cosa le prossime tappe richiedono). 20 minuti, non scivoli, nessun bullshit è ciò che funziona per me. La tua squadra e la situazione può variare.

Answer 4

Sarei usando un Wiki, non si desidera aggiungere alla tempesta e-mail, e gli sviluppatori possono anche contribuire e cambiare le cose. E 'anche molto utile per la condivisione di documenti, e se fatto bene diventerà autosufficiente.

BTW Taglia / Incolla da e-mail a wiki sembra una cosa strana di avere a che fare, qualcuno sa un lightwieght Net wiki che posso-mail contenuti troppo?

Answer 5

Un modo potrebbe essere quello di non inoltrare tutte le email e una volta alla settimana riuniscono tutte le informazioni rilevanti, modifiche di progettazione, e così via, in un incontro settimanale. Certamente non inviare una raffica di e-mail agli sviluppatori. Naturalmente, se si discute qualcosa di critico, allora questo dovrebbe essere messo alla loro attenzione. Tuttavia, provare per un recap settimanale e discussione dei dettagli rilevanti.

Answer 6

sto vedendo questa domanda un anno dopo che è stato pubblicato, ma posso aggiungere la mia esperienza con alcuni dati specifici per il mio caso. Per 2-3 sviluppatori sul progetto, che per lo più faccio one-to-one. Sacco di volte che faccio questo oltre l'IM o telefono dal momento che la maggior parte della mia squadra spende un sacco di tempo in ufficio a casa. Incontro di tanto in tanto è inevitabile, soprattutto quando progetto sta iniziando (1-2 incontri sviluppatori tendono ad essere abbastanza per dare il via progetto ragionevolmente complicato), ma come regola, tutte le comunicazioni con il resto della società passa attraverso di me e gli sviluppatori di ottenere un digerire. Unica eccezione è quando mi collego sviluppatore direttamente con l'utente (non la gestione!) Per definire i dettagli del progetto.

Io tendo ad evitare di riunioni periodiche (settimanali o giorno) e pianificare riunioni solo quando almeno due di questi accadere, in questo ordine:

1. Informazioni importanti è disponibile in (a seconda della urgenza questo può aspettare fino a una settimana)
2. Gli sviluppatori sono in ufficio, preferibilmente per altri motivi (riunioni developer-to-sviluppatore)
3. Client è disponibile (non molta scelta lì, ma cerco di fare incontri e collegare gli sviluppatori con i singoli hands-on esperto sul lato del cliente in seguito)
4. Ho bisogno di consigli di progettazione (dato che sono un responsabile tecnico, sono responsabili della maggior parte ad alto livello decisioni architetturali)

Per le squadre di 4-8 persone (8 persone di solito significa due squadre) ho scoperto che breve incontro di 30 minuti circa una volta alla settimana è più che sufficiente per tenere tutti aggiornati. Questo, naturalmente, è in aggiunta a one-to-one, che faccio tutti i giorni per gli sviluppatori Junior e circa due volte a settimana per gli sviluppatori di alto livello.

Per one-to-one, preferisco che gli sviluppatori in contatto con me quando sono alla ricerca di più di fare o quando sono domande sul compito che hanno appena iniziato a fare. Questo è anche un ottimo modo per me mantenere occhio su come stanno andando le cose, senza gli sviluppatori che hanno bisogno di pensare a me mantenersi aggiornati. Io tendo ad evitare e-mail quando IM è sufficiente, altrimenti passare al telefono (quando c'è qualcosa da spiegare o discutere) e a e-mail quando:

• Clienti bug segnalato via e-mail
• Ci sono un sacco di piccoli dettagli importanti e sviluppatore probabilmente passare attraverso quella e-mail un sacco di volte durante l'implementazione

Ci sono anche developer-to-sviluppatore incontri quando hanno bisogno di coordinare su qualcosa (ad esempio, quando Java e sviluppatore Javascript devono definire i dettagli di interfaccia).

Questo modo di lavorare significa che devo rispondere a IM il più velocemente possibile, e che di solito fare con un sacco di interruzioni in modo che gli sviluppatori hanno a che fare solo con le interruzioni per me o altri sviluppatori. Il che va bene, dal momento che una parte importante del mio lavoro è quello di rendere gli sviluppatori efficace.

Se ho bisogno di pace per la codifica (e se lo può permettere) ho scoperto che delegare la comunicazione client di project manager non tecnici e anche le beta tester (che sono molto meglio con le distrazioni di programmatori).

Answer 7

Chiedete loro quello che preferisce. Presumo che sarebbe piuttosto non essere in copia per conoscenza ogni email e sarebbe optare per un breve aggiornamento verbale su base regolare.