Come migliorare la mia comunicazione e-mail

Potresti provare a riordinarlo in modo da dire loro cosa vuoi all'inizio dell'e-mail.

I noticed a problem with System A that I would like you to look at. I have already looked at X and determined that is not the cause. It might be caused by Y, which is why I need your assistance. This issue is keeping So & So from doing their work, so if you could look at Y at your earliest convenince, I would really appreciate it.

Thanks!

Potresti provare qualcosa del genere.

Inoltre, la riga dell'oggetto è talvolta più importante del corpo. Per questa e-mail, vorrei dire al soggetto:

Subject: Having issue with System A, please check Y

Non dovrebbe essere una email.

Dovrebbe entrare nel tuo sistema di tracciamento:

• La voce del caso è il rapporto di errore.
• Inizialmente assegnato a te e con la prima risposta a notare che non è una conseguenza di X perché hai controllato (con qualsiasi informazione aggiuntiva per supportare questa conclusione).
• Viene quindi assegnato al collega con una nota che si sospetta possa essere Y

A questo punto dovrebbe essere abbastanza chiaro che è il suo problema ...

Modifica:

In realtà questo è, sotto alcuni aspetti, una risposta scarsa alla domanda perché non lo è - ma il punto che rende è valido cioè che basta inviare un'e-mail senza (per citare il termine di vendita) una specifica "chiamata all'azione" "cioè qualcosa che rende chiaro che è ora il problema dei destinatari da affrontare.

Nel caso di un'email - potresti iniziare con qualcosa lungo la linea "Potresti dare un'occhiata al seguente problema ..." ma è meglio averlo esplicitamente contrassegnato come attività al di sopra del testo del messaggio

Non prendere questo sfogo personale, sono colpevole pure.

Questo è ciò che odio per l'utilizzo della posta elettronica. Questo dovrebbe essere inviato come una Task / Todo che mai il tuo sistema di posta elettronica chiama. Con una data di scadenza. Forse c'è qualche problema culturale dell'azienda riguardo l'invio di un compito perché non si presenta come se chiedesse gentilmente, ma più come dare un ordine. Non dovrebbe essere così perché il destinatario può rifiutare la richiesta (che sarebbe stata un vantaggio nel tuo caso) e stabilire un orario diverso.

Le richieste di riunione sono voci del calendario. Questo è particolarmente doloroso quando qualcuno ti chiede se puoi avere una riunione e non danno alcun limite di tempo ed è un calcio nello stomaco quando hanno accesso al calendario di maggio.

Dopo 3-4 e-mail avanti e indietro una e-mail di sentimento, è ora di alzare il telefono o almeno di fare una chiacchierata. Ciò vale anche per la spiegazione di 47 paragrafi di qualcosa che non ho bisogno di avere archiviato nel testo.

A proposito di archiviazione. Perché ricevo email su un cliente che entra solo nella "mia" Posta in arrivo? Quando esco dall'azienda, qualcuno potrebbe volerlo e non riceveranno la mia casella di posta. Potrei inoltrarlo alla persona che 'potrebbe' prendere il mio account quando me ne sarò andato. Quindi ora devo copiare l'e-mail su un sistema di documenti o essere come tutti gli altri e avere 50 cartelle in grado di inviarlo via e-mail per ogni cliente e trascinarlo lì. E quando me ne sarò andato, un povero sucker passerà attraverso tutte quelle cartelle e continuerà a ricevere lo spam inviato al mio vecchio indirizzo email (Onestamente, non sono andato su quel sito porno.).

Quando un'email da [email protected], deve andare in una posizione centrale per chiunque abbia bisogno di farlo ora o in futuro può ottenerlo. Se è diretto a MyBigBoss, allora forse no. Ma dovrebbe avere la capacità di instradare importanti email client e business partner.

Wiki e SharePoint e le applicazioni di mercato verticale che incorporano la gestione di contactg sono carine, ma non gestiscono le e-mail. Qualcuno deve ripulire questo casino fino a quando non ci liberiamo di esso.

Mi spiace, la risposta alla tua domanda è lì da qualche parte. Proprio come il nostro sistema di posta elettronica.

Ci deve essere un modo migliore e sicuramente non è Twitter.

• Mantieni il tuo messaggio breve e conciso.
• Preferisci elenchi puntati su prosa in stile paragrafo
• Conosci i tuoi destinatari (ad esempio, evita il gergo tecnico quando parli con i non programmatori).
• Usa l'email con parsimonia.
  • Se la tua comunicazione è eccessiva, le persone si sintonizzeranno.

Gestire il tuo esempio specifico attraverso il meccanismo di scelta del bug tracking è, come altri hanno detto, probabilmente la soluzione migliore. Detto questo, la tua più ampia domanda sulla comunicazione e-mail merita un'occhiata più da vicino.

• Dato che le tue e-mail sono chiare come affermi (e non ho motivo di dubitarne in base alla tua domanda chiaramente espressa qui)
• E visto che le persone riconoscono entrambi ricevere e leggere le e-mail dette
• E considerato che questo non è un caso isolato o raro
• Quindi dubito che il problema sia la chiarezza delle e-mail.

Sembra che tu sospetti tanto quando chiedi "Forse c'è qualcosa di intrinseco nel mezzo di posta elettronica che non è efficace per questi tipi di comunicazioni?" Ma dubito che avrai successo in qualsiasi altro mezzo. Sospetto che la fonte della tua frustrazione sia più probabile in base al tuo rapporto con il tuo team.

Mi sembra che le persone della tua squadra non ti prendano sul serio e questo è un problema più ampio di quello che può essere risolto con un cambiamento di stile di comunicazione o media. Se vuoi che la tua comunicazione sia presa sul serio, devi capire i motivi per cui non ti prendi sul serio e risolvilo. Ci sono molti fattori che possono essere al centro di questa mancanza di rispetto (sei nuovo, o giovane, o culturalmente diverso, o non dimostrato, o hai sbagliato in passato) e ognuno indica un approccio diverso alla bonifica. E diverse squadre rispondono in modo diverso a diversi tipi di personalità. Quindi, senza conoscere ulteriori dettagli, esito a dare consigli su come andare avanti da qui.

Se questo fosse un film di prigionia, ti suggerirei di trovare il più grande della squadra e saltarlo. Ottenere il rispetto di una squadra di programmatori può essere più difficile (anche se generalmente c'è una minore possibilità di finire in ospedale).