la communication de l'équipe (notamment par courrier électronique) - par défaut ouvert ou fermé? [fermé]

Question

Je suis un développeur C # raisonnablement expérimenté (environ de 5 ans d'expérience) qui a récemment été chargé de ma première équipe de développement en tant que responsable technique (variant entre 3-5 autres développeurs). Au cours des 4 derniers mois dans ce rôle, un dilemme qui ne cesse qui se pose est d'essayer de trouver le bon degré de sensibilisation de partage de la communication qui se passe entre le gestionnaire de projet, gestionnaire de compte, les clients, les concepteurs, chef de la direction et moi-même (en particulier par l'intermédiaire des e-mails) .

D'une part, je sais plus conscience chaque développeur a la direction générale du projet, mieux ils peuvent comprendre la portée que leur fonctionnalité particulière a dans la grande image.

Cependant d'autre part, beaucoup de mon temps semble se perdre dans la mer des e-mails entre tous les différents acteurs et gestionnaires, donc je plais à penser que l'isolement des développeurs juste « ce qu'ils doivent faire leur courant peu de travail » va les garder sans interruptions.

Je l'ai considéré que BCCing tous les développeurs afin qu'ils puissent filtrer ces e-mails et essentiellement « opt in » à tous les e-mails, mais je crains que certains des développeurs vont tout simplement voir ce que le bruit supplémentaire pour traiter. Il peut ouvrir la porte à « trop de cuisiniers » si tous les développeurs veulent contribuer à trop de discussions. Pourtant, d'autre part, d'autres opinions peuvent me aider à atteindre de meilleures décisions (à savoir le style House MD).

... Ouf tant de choses à considérer. Quelqu'un at-il quelques conseils sages dans ce domaine?

Answer 1

On dirait que vous êtes technique, donc je vous donnerais ce conseil: Suivez les conseils de Joel Spolsky sur ce que les gestionnaires de programme font. Fondamentalement, essayez d'isoler vos développeurs autant que possible afin qu'ils puissent être aussi productifs que possible.

Il vient de mentionner brièvement dans cet article récent, Comment un programme directeur , mais il est allé plus en profondeur sur ce sujet avant. Regardez à travers ses écrits passés pour plus d'informations:

  

Une fois la spécification a été terminé et l'équipe de développement se mettre au travail, j'avais deux responsabilités:. Résoudre toutes les questions qui ont été soulevées au sujet de la conception, et de parler à toutes les autres équipes afin que les développeurs ne devaient pas

Si vous n'êtes pas technique, vous devez sélectionner une personne de votre équipe pour aider avec le travail de conception et ils auront un peu à l'interface avec le client de savoir quelles sont les exigences et quelle est la meilleure conception est.

EDIT: Le page d'accueil de Joel il y a deux sections intitulées Lead Tech et gestionnaire de programme. Regardez les articles là pour un peu plus d'informations sur les gestionnaires de programme, en particulier Human Task Switches Considered Harmful .

Answer 2

Réponse à la fin, mais encore croire qu'il ya quelque chose à ajouter au superbe conseils donnés à ce jour. Pour répondre à votre question, nous devons aller plus haut niveau, d'où la réponse à long.

Vous avez fait une avance technologique responsable de l'équipe et bien que de nombreux aspects de votre travail quotidien peut sembler ressembler à vos jours dev la façon dont vous avez besoin d'aller à leur sujet a changé. Dans l'environnement de développement de logiciels, il est généralement pas beaucoup d'un changement tangible lorsque vous a nommé un chef de file de la technologie (vous êtes probablement un coin toujours au même bureau, portant la même tenue) plutôt que de devenir un contremaître sur chantier de construction ou une usine. Le changement est flatteur que si vous êtes invité maintenant dans toutes ces réunions et commencer à obtenir tous ces e-mails et les appels téléphoniques de personnes en dehors de l'équipe de développement.

L'absence de changement tangible pourrait faire croire à votre esprit en pensant que vous avez juste besoin de garder le traitement de votre travail la plupart du temps la même chose. Ce n'est pas le cas et vous devez être conscient de vos actions et re-actions dans la nouvelle capacité. Il peut sembler que vous êtes maintenant un peu « plus respecté » à l'extérieur et vous pourriez être enclin à partager une partie de ce « respect » sur votre route interne, jouer un peu de démocratie et généralement juste.

Eh bien, ce n'est pas grand-chose sur l'équité ou le respect, le nouveau travail consiste à:

• Diriger l'équipe de développement (la plupart du temps par l'exemple et la création d'images représentant l'objectif).

• être une couche d'abstraction entre l'équipe et d'autres unités d'organisation.

Jolie vous créez souvent un peu comme dans la programmation d'une couche d'abstraction pour encapsuler et masquer la complexité, la même chose se produit dans les organisations. Vous êtes la couche, l'interface qui doit encapsuler l'équipe de développement. Et toute bonne encapsulation d'un point de vue extérieur:

• Hides complexité interne qui ne concerne pas la tâche à accomplir (telles que la mise en œuvre concrète d'un algorithme) de l'observateur extérieur.

• rend les choses qui pourraient affecter l'utilisateur à l'extérieur explicites (exceptions qui peuvent être levées, les limites et les contraintes, etc.).

• donne toujours une rétroaction significative.

• cohØrence.

Ces principes sont également applicables à la communication vers l'extérieur de l'équipe. Ce n'est pas une tâche facile à suivre ces principes; en fait, il implique beaucoup de travail concret, par exemple, décider quels détails sont internes et quels faits doivent être communiqués et quand, comment les commentaires doit être mieux structurée et présentée de manière cohérente et qui devraient être informés à l'extérieur de ce que, et qui a besoin de suivi et quand. Ceci est beaucoup de travail, même si certaines d'entre elles semble être juste admin trivial.

à la communication interne, vers l'intérieur. Une façon est de diffuser. Mais il obstrue le réseau interne et tout le monde doit passer leur temps à décider si la communication porte tout intérêt pour eux. Il est comme avoir un algorithme très générique que quelle que soit l'entrée fait toujours la même quantité de travail exacte. Il est sûr possible, mais pourquoi voudriez-vous faire? Une façon plus efficace est évidemment d'adapter le traitement en fonction de l'entrée et ici, il doit être le travail d'une personne de prendre une décision comment l'équipe doit aller quelque chose, à envoyer, ou convertir l'entrée:

• Décider quelle séquence d'actions doivent être prises,

• ou tout simplement reconnaître et conserver pour référence ultérieure,

• ou le suivi,

• ou mettre un problème hors d'un examen plus tard, puis assurez-vous qu'il est examiné et réinjectée dans la boucle de prise de décision.

Ce n'est pas un petit travail soit et que quelqu'un doit le faire. De toute évidence, maintenant il est votre travail pour gérer la communication vers l'extérieur et vers l'intérieur, et vous devez passer une partie de votre puissance de traitement du cerveau pour le faire, donc personne n'a d'autre et devs peuvent se concentrer sur leurs tâches.

sont d'autres bonnes raisons de ne pas CC-tion ou tout le monde BCC-ing quel que soit le titre de votre travail:

• TO signifie « prendre des mesures », CC - « prendre note pour référence ultérieure », BCC - « écouter vos conversations ou courrier de masse ». Vous devez être prudent lorsque vous utilisez un ou l'autre e-mailing un groupe de personnes:

  • Envoi d'une seule personne est un droit devant « TO », lorsque E-mailing un groupe de personnes que « TO » ce qui vous devez prendre des mesures (y compris un simple accusé de réception). Ceci est le sens par défaut, dans tout autre cas leur dire explicitement ce qu'on attend (à savoir votre information, aucune action nécessaire, etc.).

  • CC seulement ceux qui vous voulez prendre note des informations pour la référence future. Si vous vous attendez à un certain nombre d'e-mails pour aller et venir avant qu'une entente soit conclue ou problème est résolu ne pas « CC », il est préférable d'envoyer une confirmation sommaire plus tard à d'autres parties qui doivent être notifiées. En plus d'économiser du temps de chacun et d'éviter une mauvaise interprétation due à une personne prenant acte d'une communication non-finale qui contribueront à rendre l'échange plus personnel, plus naturellement flux et réduire le formalisme et la bureaucratie. Souvent CC-d e-mails traités formellement et ce ne sont pas toujours une bonne chose (mais parfois exactement ce que vous voulez).

  • L'utilisation BCC est presque jamais correct. La connaissance de quelqu'un espionnant vos conversations si venir à la lumière va facilement ruiner votre confiance. Il est tout simplement une question de « quand ». Et si votre équipe vous inquiétez alors que vous pourriez être BCC-ing leurs conversations à quelqu'un d'autre? Publipostage par BCC dans la plupart des cas est également faux, il crée une impression que le courrier électronique est adressé spécifiquement au destinataire.

• Forwarding, CC-ing et BCC-ing nécessitent peu d'effort, mais multiplier le bruit et diluent le signal. Il vaut la peine de réfléchir à exactement ce que vous avez besoin d'une personne à faire et ce qu'ils doivent savoir pour agir sur votre communication avant la composant.

• Certaines conversations sont mieux prises complètement « hors ligne » (téléphone ou mieux encore face à face), car il vous donne plus de place pour maneveour. Radiodiffusion ou formalisant est writting comme vous mettre dans un coin. Vous pouvez toujours confirmer par écrit ce dernier.

Le passage à la deuxième partie de la responsabilité de chef de file de la technologie (diriger l'équipe par l'exemple personnel et des images représentant l'objectif). Pour y parvenir, vous n'êtes pas obligé de transmettre à l'équipe chaque élément d'information qui viennent à se terminer dans votre boîte de réception. Vous devez créer une histoire et une bonne histoire est une abstraction d'événements réels qui se compose de seulement détail pertinent et intéressant pour un public particulier. La création de cette brève histoire sur la base de votre expérience quotidienne et à en juger ce qui est pertinent et intéressant, puis présenter régulièrement à l'équipe est aussi tout un travail.

Mais ne pas oublier que l'équipe en dirigeant et servant de couche d'abstraction vous aider les développeurs et dans le monde en dehors d'interagir de manière plus efficace, plus accomplissez une plus grande complexité et abordez, le travail a un point.

Answer 3

L'équipe d'ingénierie a besoin de comprendre les raisons commerciales de la raison pour laquelle ils sont invités à faire des choses sur un niveau macro. L'équipe d'ingénierie gagnera la compréhension et la motivation de cette situation. Mais trop bavardage est un non-non, comme vous le notez, une partie de votre travail consiste à filtrer , et une partie de cela ne concerne pas les exposer à des tonnes de bruit. Vos développeurs ont probablement des opinions et des idées quant à la façon de faire des choses particulières ou pourquoi choisir des technologies particulières, et ils devraient être alignés pour leur expertise dans ces domaines.

Je ne vous conseille pas créer une culture de BCCing.

L'une des options est d'avoir des listes de diffusion distinctes que les parties intéressées peuvent souscrire, mais bien sûr, pas tout bavardage sera sur ces listes.

Et bien sûr, une réunion ordinaire de la société est un must. Que les gars ingénieurs savent pourquoi l'entreprise dépend de la livraison d'un produit stable et complet (ou quelles que soient les étapes à venir ont besoin). 20 minutes, pas de diapositives, aucune connerie est ce qui fonctionne pour moi. Votre équipe et la situation peut varier.

Answer 4

J'utiliser un wiki, vous ne voulez pas ajouter à la tempête de courrier électronique et vos développeurs peuvent également contribuer et changer les choses. Il est aussi très utile pour le partage de documents, et si bien fait, il deviendra autonome.

BTW Couper / Coller e-mail à wiki semble être une chose étrange d'avoir à faire, personne ne sait un wiki .Net lightwieght que je peux envoyer un courriel contenu aussi?

Answer 5

Une façon peut-être pour ne pas transférer tous les e-mails et une fois par semaine compiler toutes les informations pertinentes, des changements de conception, et ainsi de suite dans une réunion hebdomadaire. Je ne doute envoyer un déluge de courriels aux développeurs. Bien sûr, si quelque chose est discuté critique, qui devrait être mis à leur attention. Cependant, essayez de récapituler toutes les semaines et la discussion des détails pertinents.

Answer 6

Je vois cette question un an après qu'il a été affiché, mais je peux ajouter mon expérience avec des données spécifiques pour mon cas. Pour les développeurs 2-3 sur le projet, je fais la plupart du temps un sur les. Lot de fois que je fais ce sur la messagerie instantanée ou par téléphone puisque la plupart de mon équipe passe beaucoup de temps dans le bureau à domicile. Réunion de temps en temps est inévitable, la plupart du temps quand projet commence (1-2 réunions de développeurs ont tendance à être assez pour lancer projet assez compliqué), mais en règle générale, toute communication avec le reste de la société passe par moi et les développeurs à un condensé. La seule exception est lorsque je me connecte développeur directement avec l'utilisateur (pas de gestion!) pour régler les détails du projet.

J'ai tendance à éviter des réunions régulières (réunions hebdomadaires ou quotidiennes) et l'horaire que si au moins deux de ces situations se produisait, dans cet ordre:

1. Information importante arrive (en fonction de l'urgence, cela peut attendre jusqu'à une semaine)
2. Les développeurs sont au bureau, de préférence pour d'autres raisons (réunions développeur-à-développeur)
3. Client est disponible (pas beaucoup de choix là-bas, mais j'essaie de faire des rencontres et se connecter avec les développeurs simples mains sur experts du côté du client plus tard)
4. J'ai besoin des conseils de conception (puisque je suis un responsable technique, je suis responsable de la plupart des décisions d'architecture de haut niveau)

Pour les équipes de 4-8 personnes (8 personnes signifie généralement deux équipes) j'ai découvert que brève réunion de 30 minutes à peu près une fois par semaine est plus que suffisant pour garder tout le monde à ce jour. Ceci, bien sûr, est en plus d'un sur-ceux que je fais tous les jours pour les développeurs juniors et environ deux fois par semaine pour les développeurs supérieurs.

Pour un sur-ones, je préfère que les développeurs me contacter quand ils cherchent plus à faire ou quand ils sont des questions sur la tâche qu'ils viennent de commencer à faire. Ceci est aussi un excellent moyen pour moi de garder les yeux sur la façon dont les choses vont sans développeurs ont besoin de penser à me tenir à jour. Je tends à éviter e-mail quand IM est suffisant, sinon passer au téléphone (quand il y a quelque chose à expliquer ou à discuter) et e-mail quand:

• bug signalé client par e-mail
• Il y a beaucoup de petits détails et importants développeur ira probablement par cette e-mail un grand nombre de fois au cours de la mise en œuvre

Il y a aussi des réunions-développeur à développeur quand ils ont besoin de coordonner quelque chose (par exemple, lorsque Java et développeur Javascript ont besoin pour régler les détails de l'interface).

Cette façon de procéder signifie que je dois répondre à la GI aussi vite que possible, et que je traitent habituellement avec beaucoup d'interruptions afin que les développeurs doivent traiter uniquement avec des interruptions pour moi ou d'autres développeurs. Quelle est OK, étant donné qu'une partie importante de mon travail est de faire les développeurs efficaces.

Si je besoin de paix pour le codage (et peut le permettre) je trouve que la délégation de la communication client aux gestionnaires de projets non techniques et même bêta-testeurs (qui sont beaucoup mieux avec les distractions que les programmeurs).

Answer 7

Demandez-leur ce qu'ils préféreriez. Je suppose qu'ils sur chaque e-mail préféreraient ne pas être CC'D et opteraient pour une courte mise à jour verbale sur une base régulière.