a comunicação da equipe (especialmente via email) - aberta ou fechada por padrão? [fechadas]

https://stackoverflow.com/questions/672213

21-08-2019
|

Pergunta

Eu sou um razoavelmente experiente desenvolvedor C # (cerca de experiência 5 anos) que foi recentemente colocado no comando da minha primeira equipe de desenvolvimento como líder técnico (variando entre 3-5 outros desenvolvedores). Ao longo dos últimos 4 meses nessa função, um dilema que mantém decorrentes está tentando encontrar o grau certo de consciência partilha da comunicação que acontece entre o gerente de projeto, gerente de contas, clientes, estilistas, CEO e eu (especialmente via e-mails) .

Por um lado, eu sei que o mais consciência cada desenvolvedor tem a direção geral do projeto, o melhor que pode compreender o alcance que a sua funcionalidade particular tem no retrato grande.

No entanto, por outro lado, muito do meu tempo parece estar perdido no mar de e-mails entre todas as diferentes partes interessadas e gestores, assim que eu gosto de pensar que isolar os desenvolvedores para apenas "o que eles precisam para fazer o seu atual pouco de trabalho" vai mantê-los livre de interrupções.

Eu tenho considerado apenas Cópias Ocultas todos os desenvolvedores para que eles possam filtrar esses e-mails e essencialmente "opt in" para todos os e-mails, mas eu estou preocupado que alguns dos desenvolvedores só vai ver isso como o ruído extra para lidar com eles. Pode abrir a porta para "muitos cozinheiros" Se todos os desenvolvedores querem contribuir para muitas discussões. No entanto, por outro lado, outras opiniões pode me ajudar a alcançar melhores decisões (ou seja, estilo House MD).

Ufa ... tanta coisa a considerar. Alguém tem alguma orientação sábia nesta área?

Solução

Parece que você está técnica para que eu iria dar-lhe um conselho: O conselho de Acompanhamento Joel Spolsky sobre o que Gerentes de Programa fazer. Basicamente, tentar isolar seus desenvolvedores, tanto quanto possível para que eles possam ser tão produtivo quanto possível.

Ele apenas mencionou isso brevemente neste artigo recente, Como ser um programa gerente , mas ele tem ido em mais profundidade sobre este assunto antes. Olhar através de seus escritos passados ??para mais informações:

Uma vez que a especificação foi concluída ea equipe de desenvolvimento começou a trabalhar, tive duas responsabilidades: resolver quaisquer questões que surgiram sobre o projeto, e conversando com todos os outros times para que os desenvolvedores não tem que <. / p>

Se você não é técnico, então você precisa selecionar alguém de sua equipe para ajudar com o trabalho de design e eles terão a interface com o cliente um pouco para descobrir quais são os requisitos e que o melhor projeto é.

EDIT: Em home page do Joel há duas seções intituladas Tech Lead e Gerenciador de programas. Olhe para os artigos lá para mais algumas informações sobre os gestores de programas, especialmente Human Task Switches considerada prejudicial .

Outras dicas

Respondendo a tarde, mas ainda acredito que há algo a acrescentar ao conselho soberba dados até agora. Para responder à sua pergunta, precisamos ir um nível mais elevado, daí a resposta longa.

Você foi feito um líder técnico responsável pela equipe e, embora muitos aspectos do seu trabalho diário pode parecer assemelhar-se os seus dias dev do jeito que você precisa ir sobre eles mudou. No ambiente de desenvolvimento de software há geralmente não é muito de uma mudança tangível quando você nomeou um líder técnico (você provavelmente ainda estar na mesma mesa, usando a mesma roupa) em oposição a se tornar um contramestre no canteiro de obras ou uma fábrica. A mudança lisonjeiro, porém, é que agora você ser convidado para todos estes reunião e começar a receber todos esses e-mails e telefonemas de pessoas de fora da equipe de desenvolvimento.

A falta de mudança tangível pode enganar sua mente em pensar que você só precisa manter o tratamento de seu trabalho basicamente o mesmo. Este não é o caso e você precisa estar consciente sobre suas ações e re-ações na nova capacidade. Pode parecer que você está agora um pouco “mais respeitado” externamente e você pode estar inclinado a partilhar alguns dos que “respeito” vindo em sua direção internamente, jogar um pouco de democracia e, geralmente, ser justo.

Bem, isso não é muito sobre a justiça ou respeito, o novo trabalho é:

Direto a equipe de desenvolvimento (principalmente pelo exemplo pessoal e imagens criando retratando o objetivo).
Seja uma camada de abstração entre a equipe e outras unidades organizacionais.

Muito bem como na programação que você muitas vezes criam uma camada de abstração para encapsular e esconder a complexidade, o mesmo acontece nas organizações. Você é a camada, a interface que tem para encapsular a equipe de desenvolvimento. E qualquer bom encapsulamento de um ponto de vista estrangeiro:

Oculta complexidade interna que não é relevante para a tarefa à mão (tais como a implementação concreta de um algoritmo) do observador externo.
Faz coisas que poderiam afetar o usuário fora explícitas (exceções que podem ser lançadas, quaisquer limitações e restrições etc).
Sempre dá feedback significativo.
coerência.

Estes princípios são igualmente aplicáveis ??à comunicação fora da equipe. Não é uma tarefa fácil de seguir estes princípios; na verdade, envolve um monte de trabalho concreto, como decidir o que detalhes são internos e que fatos precisam ser comunicadas e quando, como as necessidades de feedback para ser melhor estruturado e ser apresentado de uma forma consistente e quem deve ser notificado externamente do que, e quem precisa acompanhados e quando. Este é um monte de trabalho, mesmo se alguns dos que parece ser apenas administrador trivial.

Agora, para comunicação interna, para dentro. Uma forma é a transmissão. Mas entope a rede interna e todo mundo tem que gastar seu tempo em decidir se a comunicação tem qualquer relevância para eles. É como ter um algoritmo muito genérico que, independentemente de entrada sempre faz exatamente a mesma quantidade de trabalho. É certo possível, mas por que você iria querer fazer isso? A maneira mais eficiente é, obviamente, para ajustar o processamento dependendo da entrada e aqui tem que ser trabalho de alguém para tomar uma decisão como a equipe deve ir com alguma coisa, para expedição, ou converter a entrada:

Decida o que seqüência de necessidades ações a serem tomadas,
ou apenas reconhece e loja para referência futura,
ou acompanhamento,
ou colocar uma questão off para uma revisão mais tarde e, em seguida, certifique-se que é revisto e alimentado de volta para o ciclo de tomada de decisão.

Este não é um trabalho pequeno quer e alguém tem que fazê-lo. Obviamente agora é seu trabalho para gerenciar a comunicação exterior e interior, e você tem que gastar algum do poder de processamento do seu cérebro para fazê-lo bem, para que ninguém mais tem que e devs pode se concentrar em suas tarefas.

Hásão algumas outras boas razões para não CC-ing ou BCC-ing todos, independentemente do seu cargo:

A significa “tomar medidas”, CC - “tomar nota para referência futura”, BCC - “eavesdrop ou massa mail”. Você deve ter cuidado ao usar um ou outro um grupo de pessoas-mails e:
- E-mails de uma única pessoa é uma frente “TO”, quando E-mails de um grupo de pessoas apenas “TO” estes que você precisa de tomar medidas (incluindo um simples reconhecimento). Este é o significado padrão, em qualquer outro caso lhes dizer explicitamente o que é esperado (ou seja, FYI, nenhuma ação é necessária etc).
- CC apenas estes que você quer tomar nota das informações para a referência futura. Se você espera um número de e-mails para ir e voltar antes que um acordo seja alcançado ou problema é resolvido não “CC”, é melhor enviar uma confirmação resumo mais tarde para outras partes que precisam ser notificado. Além de economizar tempo de todos e evitar erros de interpretação devido a alguém tomar nota de uma comunicação não-final que vai ajudar a tornar o intercâmbio mais pessoal, fluir mais naturalmente, e reduzir o formalismo e burocracia. Muitas vezes CC-d e-mails tratados formalmente e isso nem sempre é uma coisa boa (mas às vezes exatamente o que você quiser).
- Usando BCC quase nunca é ok. O conhecimento de alguém espionagem de suas conversas se vêm a luz vai facilmente arruinar sua credibilidade. É simplesmente uma questão de “quando”. E deve a sua preocupação equipe, então, que você pode ser BCC-ing suas conversas para outra pessoa? envio em massa através de BCC na maioria dos casos também é errado, ele cria uma impressão de que o e-mail é especificamente dirigida ao destinatário.
Forwarding, CC-ing e BCC-ing exigem pouco esforço, mas multiplicam ruído e dilui sinalizar. Vale a pena dar um pouco sobre o que exatamente você precisa de uma pessoa que fazer eo que eles devem saber para agir em sua comunicação antes de compor-lo.
Algumas conversas são as melhores tomadas completamente "off line" (telefone ou melhor ainda face-a-face), porque lhe dá mais espaço para maneveour. Transmitindo ou formalizar na escrita é como colocar-se em um canto. Você pode sempre confirmar por escrito último.

Mover-se para a segunda parte de uma responsabilidade tecnologia chumbo (dirigindo a equipe através do exemplo pessoal e imagens retratando o objetivo). Para conseguir isso, você não precisa para passar para a equipe de cada pedaço de informação que acontecer com fim em sua caixa de entrada. Você tem que criar uma história e qualquer boa história é uma abstração de eventos reais que consiste em único detalhe relevante e interessante para uma audiência particular. Criando esta história breve com base em sua experiência cotidiana e julgar o que é relevante e interessante e, em seguida, apresentá-lo regularmente para a equipe também é bastante um trabalho.

Mas não se esqueça que, dirigindo a equipe e servindo como abstração camada que desenvolvedores de ajuda e mundo exterior para interagir de forma mais eficiente, realizar mais e enfrentar maior complexidade, o trabalho tem um ponto.

A equipe de engenharia precisa entender as razões do negócio de por que eles são convidados a fazer as coisas em um nível macro. A equipe de engenharia vai ganhar a compreensão ea motivação deste. Mas muito falatório é um não-não, como você notar, parte de seu trabalho é filtrar , e parte do que meios não expondo-os a toneladas de ruído. Seus desenvolvedores provavelmente têm opiniões e idéias a respeito de como fazer as coisas particulares ou por escolher tecnologias específicas, e eles devem ser em campo por seus conhecimentos nessas áreas.

Definitivamente não criar uma cultura de Cópias Ocultas.

Uma opção é ter listas de endereços separadas que os interessados ??podem inscrever-se, mas é claro, nem todos Chatter será nessas listas.

E, claro, uma reunião ordinária empresa é uma obrigação. Deixar os caras de engenharia sabe por que o negócio depende da entrega de um estável, produto completo (ou o que as próximas etapas requerem). 20 minutos, sem slides, nenhuma besteira é o que funciona para mim. Sua equipe & situação pode variar.

Eu estaria usando um Wiki, você não deseja adicionar à tempestade e-mail, e seus desenvolvedores também podem contribuir e mudar as coisas. É também muito útil para compartilhar documentos, e se bem feito ele vai se tornar auto-sustentável.

BTW Cut / Paste de e-mail para wiki parece uma coisa estranha ter que fazer, alguém sabe um lightwieght Net wiki que eu possa enviar e-mail de conteúdo também?

Uma forma seria a de não avançar todos os e-mails e uma vez por semana compilar todas as informações relevantes, mudanças de design, e assim por diante em uma reunião semanal. Eu definitivamente não iria enviar uma enxurrada de e-mails para os desenvolvedores. Claro que, se algo crítico é discutido, então isso deve ser colocado à sua atenção. No entanto, tentar um resumo semanal e discussão de detalhes relevantes.

Eu estou vendo esta questão um ano depois de ter sido publicado, no entanto eu posso adicionar minha experiência com alguns dados específicos para o meu caso. Para 2-3 desenvolvedores do projeto, principalmente eu fazer one-on-ones. Muitas vezes eu fazer isso por IM ou telefone já que a maioria da minha equipe gasta muito tempo no escritório home. Reunião de vez em quando é inevitável, principalmente quando o projeto está começando (1-2 reuniões desenvolvedores tendem a ser suficiente para lançar projeto razoavelmente complicado), mas como regra geral, toda a comunicação com o resto da empresa passa por mim e desenvolvedores obter a digerir. Única exceção é quando eu desenvolvedor conectar diretamente com o usuário (não gestão!) Para acertar detalhes do projeto.

I tendem a evitar reuniões regulares (semanal ou diário) e agendar reuniões somente quando pelo menos dois dos estes acontecem, nesta ordem:

Informações importantes vem em (dependendo da urgência isso pode esperar até uma semana)
Os desenvolvedores estão no escritório, de preferência por outras razões (reuniões desenvolvedor-a-desenvolvedor)
Cliente está disponível (não há tanta escolha lá, mas eu tento fazer reuniões e desenvolvedores conectar com simples hands-on especialista no lado do cliente mais tarde)
Eu preciso projetar conselho (desde que eu sou um líder técnico, sou responsável para a maioria do alto nível decisões de arquitetura)

Para as equipes de 4-8 pessoas (8 pessoas geralmente significa duas equipes) eu descobri que curta de 30 minutos de reunião mais ou menos uma vez por semana é mais do que suficiente para manter todos atualizados. Isto, naturalmente, é, além de one-on-ones que eu faço diariamente por desenvolvedor júnior e duas vezes por semana para os desenvolvedores seniores.

Para one-on-ones, eu prefiro que os desenvolvedores contato me quando eles estão procurando mais a fazer ou quando estão têm perguntas sobre tarefa que apenas começou fazendo. Esta é também uma ótima maneira para eu ficar de olho em como as coisas estão indo sem desenvolvedores precisam pensar em manter-me atualizado. I tendem a evitar e-mail quando primário é suficiente, caso contrário, mudar para o telefone (quando há algo para explicar ou discutir) e e-mail quando:

Cliente relatado bug via e-mail
Há uma série de importantes pequenos detalhes e desenvolvedor, provavelmente vai passar por aquele e-mail muitas vezes durante a implementação

Há também reuniões desenvolvedor-a-desenvolvedor quando eles precisam para coordenar em algo (por exemplo, quando o Java e Javascript desenvolvedor precisa trabalhar detalhes de interface).

Esta forma de meios de trabalho que eu tenho que responder a IM tão rápido quanto possível, e que eu costumo lidar com um monte de interrupções para que os desenvolvedores tem que lidar apenas com interrupções para mim ou outros desenvolvedores. Que é OK, uma vez que parte importante do meu trabalho é fazer com que os desenvolvedores eficaz.

Se eu preciso de paz para a codificação (e puder pagar) eu descobri que a comunicação do cliente delegar a gestores de projecto não técnicos e até mesmo beta testers (que são muito melhor com distrações do que programadores).

Pergunte a eles o que eles preferem. Eu presumo que eles preferem não ser enviadas com cópia para cada e-mail e iria optar por um update verbal curta em uma base regular.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow