la comunicación del equipo (sobre todo a través de correo electrónico) - abierta o cerrada por defecto? [cerrado]

Question

Soy un desarrollador de C # razonablemente con experiencia (la experiencia alrededor del 5 año) que recientemente ha sido puesto a cargo de mi primer equipo de desarrollo como líder técnico (variando entre otros desarrolladores 3-5). En los últimos 4 meses en este papel, un dilema que mantiene que surge está tratando de encontrar el grado correcto de la conciencia puesta en común de la comunicación que tiene lugar entre el director del proyecto, gerente de cuentas, clientes, diseñadores, CEO y yo (en especial a través de mensajes de correo electrónico) .

Por un lado, sé que la mayor conciencia cada desarrollador tiene de la dirección general del proyecto, mejor podrán entender el alcance que su funcionalidad particular tiene en el cuadro grande.

Sin embargo, por otro lado, una gran parte de mi tiempo parece haberse perdido en el mar de correos electrónicos entre los diferentes actores y gestores, así que me gusta pensar que el aislamiento de los desarrolladores simplemente "lo que necesitan para hacer su actual poco de trabajo" los mantendrá libre de interrupciones.

He considerado simplemente BCCing todos los desarrolladores para que puedan filtrar estos mensajes de correo electrónico y, esencialmente, "opt in" a todos los correos electrónicos, pero me preocupa que algunos de los desarrolladores se acaba de ver esto como el ruido adicional de tratar. Se puede abrir la puerta a "demasiados cocineros" si todos los desarrolladores quieren contribuir a demasiadas discusiones. Sin embargo, por otro lado, otras opiniones pueden ayudar a alcanzar mejores decisiones (es decir, el estilo House MD).

Uf ... tanto considerar. Alguien tiene alguna sabia orientación en esta área?

Answer 1

Parece que estás técnica así que le dará este consejo: Siga el consejo de Joel Spolsky en lo que hacen los gerentes del programa. Básicamente, tratar de aislar a los desarrolladores tanto como sea posible para que puedan ser lo más productivo posible.

Se acaba de mencionar esto brevemente en este artículo reciente, Cómo ser un programa gerente , pero ha ido a más a fondo sobre este tema antes. Mira a través de sus escritos anteriores para más información:

  

Una vez que la especificación se terminó y el equipo de desarrollo se puso manos a la obra, que tenía dos responsabilidades:. Resolver las preguntas que surgieron sobre el diseño, y hablando a todos los demás equipos para que los desarrolladores no tienen que

Si usted no es técnico, entonces usted necesita para seleccionar a alguien de su equipo para ayudar con el trabajo de diseño y que tendrá que interactuar con el cliente un poco para averiguar cuáles son los requisitos y lo que es el mejor diseño.

EDIT: Página principal de los de Joel hay dos secciones tituladas Tech Lead y Administrador de programas. Mira las artículos allí por algo más de información sobre los directores de programas, especialmente Human Task Interruptores considera perjudicial .

Answer 2

Respondiendo tarde, pero aún creer que hay algo que añadir a la excelente consejo dado hasta el momento. Para responder a su pregunta tenemos que ir un nivel más alto, por lo tanto el tiempo de respuesta.

Usted ha llegado a ser un líder de tecnología responsable de equipo y aunque muchos aspectos de su trabajo diario podría parecer a parecerse a sus días dev la forma en que tiene que ir sobre ellos ha cambiado. En el entorno de desarrollo de software normalmente no hay mucho de un cambio tangible cuando se nombró un plomo tecnología (que está probablemente todavía de estar en la misma mesa, vestido con el mismo traje) en contraposición a convertirse en un capataz en el sitio de construcción o una fábrica. El cambio favorecedor sin embargo, es que ahora te invitan a todas estas reuniones y comienza a recibir todos estos correos electrónicos y llamadas telefónicas de personas fuera del equipo de desarrollo.

La falta de cambio tangible podría engañar a su mente a pensar que sólo tiene que seguir tratando su trabajo sobre todo el mismo. Este no es el caso y hay que ser consciente de sus acciones y re-acciones en la nueva capacidad. Podría parecer que está ahora un poco “más respetado” externamente y que podría estar inclinado a compartir algo de ese “respeto” que te lanzan internamente, jugar un poco de la democracia y en general ser justos.

Bueno, esto no es mucho acerca de la imparcialidad o el respeto, el nuevo trabajo consiste en:

• Dirigir el equipo de desarrollo (sobre todo con el ejemplo personal y la creación de imágenes que representa la meta).

• Ser una capa de abstracción entre el equipo y otras unidades organizativas.

Más o menos como en la programación que a menudo crea una capa de abstracción para encapsular y ocultar la complejidad, lo mismo sucede en las organizaciones. Eres la capa, la interfaz que tiene que encapsular el equipo de desarrollo. Y cualquier buena encapsulación desde un punto de vista extraño:

• Oculta la complejidad interna que no es relevante para la tarea en cuestión (como aplicación concreta de un algoritmo) desde el observador externo.

• Hace que las cosas que podrían afectar al usuario fuera explícitas (excepciones que pueden ser lanzadas, las limitaciones y restricciones, etc.).

• Siempre da una retroalimentación significativa.

• Hechos consistente.

Estos principios son igualmente aplicables a la comunicación hacia el exterior del equipo. No es una tarea fácil de seguir estos principios; En realidad se trata de una gran cantidad de trabajo concreto, como por ejemplo decidir qué detalles son internos y qué hechos deben ser comunicados y cuándo, cómo necesita la regeneración fuera mejor estructurado y ser presentados de una manera consistente y que deben ser notificados en el exterior de lo que, y que necesita un seguimiento y cuándo. Se trata de una gran cantidad de trabajo, incluso si algunos de ellos parece ser sólo administrador trivial.

Ahora a lo interno, hacia el interior de la comunicación. Una forma es transmitido. Pero obstruye la red interna y cada uno tiene que gastar su tiempo en decidir si la comunicación tiene alguna relevancia para ellos. Es como tener un algoritmo muy genérica que independientemente de la entrada siempre hace la misma cantidad de trabajo. Es seguro posible, pero ¿por qué quieres hacer eso? Una manera más eficiente es, obviamente, para ajustar el procesamiento dependiendo de la entrada y aquí tiene que ser el trabajo de alguien para tomar una decisión de cómo el equipo debe ir por algo, a la expedición, o convertir la entrada:

• Decide qué secuencia de acciones debe ser tomada,

• o simplemente reconocer y almacenar para referencia futura,

• o seguimiento,

• o poner fuera un problema para una revisión posterior y luego asegúrese de que se revisa y se alimenta de nuevo en el bucle de toma de decisiones.

Esto no es un trabajo pequeño sea y alguien tiene que hacerlo. Obviamente ahora es su trabajo para gestionar la comunicación externa e interna, y usted tiene que pasar parte de la potencia de procesamiento del cerebro para hacerlo bien, para que nadie más tiene que desarrolladores y puede concentrarse en sus tareas.

hay algunas otras buenas razones para no CC-ción o BCC-ción de todos, independientemente de su puesto de trabajo:

• A significa “tomar medidas”, CC - “tomar en cuenta para futuras referencias”, BCC - “espiar o correo masivo”. Usted debe tener cuidado cuando se utiliza uno u otro un correo electrónico a un grupo de personas:

  • Envío de una sola persona es una recta hacia adelante “A”, cuando envío por correo electrónico a un grupo de personas sólo “A” estos que usted necesita tomar acción (incluyendo un simple acuse de recibo). Esto es significado por defecto, en cualquier otro caso les diga explícitamente lo que se espera (es decir, su información, ninguna acción necesaria, etc).

  • CC solamente estos que desea tomar nota de la información para la futura referencia. Si esperas un número de correos electrónicos a ir y volver antes de que se llegue a un acuerdo o problema se ha resuelto no hacer “CC”, lo mejor es enviar una confirmación resumen más adelante a otras partes que necesitan ser notificado. Además de ahorrar tiempo de todos y evitar interpretaciones erróneas debido a que alguien tome nota de una comunicación no final que ayudará a hacer el intercambio más personal, fluya de forma más natural, y reducir el formalismo y la burocracia. A menudo CC-D E-mails tratados formalmente y esto no es siempre una buena cosa (pero a veces exactamente lo que quiere).

  • El uso de BCC casi nunca es aceptable. El conocimiento de alguien de aquella práctica en sus conversaciones si salir a la luz va a arruinar fácilmente su confiabilidad. Es simplemente una cuestión de “cuándo”. Y si su equipo se preocupa entonces que usted puede ser BCC-ción de sus conversaciones a otra persona? envío masivo de correo a través de BCC en la mayoría de los casos también es incorrecto, se crea la impresión de que el correo electrónico se dirige específicamente al receptor.

• Expedición, CC y CCO-ción-ción requieren poco esfuerzo, pero se multiplican ruido y diluye la señal. Vale la pena pensar un poco en qué es exactamente lo que necesita una persona para hacer y lo que deben saber para actuar en su comunicación antes que la componen.

• Algunas conversaciones se toman mejor por completo "off line" (teléfono o mejor aún cara a cara), porque le da más espacio para maneveour. Radiodifusión o formalización en escritura es como poner a sí mismo en una esquina. Siempre se puede confirmar por escrito esta última.

Pasando a la segunda parte de la responsabilidad de tecnología de plomo (dirigir al equipo a través del ejemplo personal y la imagen que representa la meta). Para lograr esto no es necesario transmitir al equipo de cada pieza de información que pasan a terminar en su bandeja de entrada. Hay que crear una historia y cualquier buena historia es una abstracción de los acontecimientos reales que consiste único detalle relevante e interesante para un público en particular. La creación de esta breve historia sobre la base de su experiencia cotidiana y juzgar lo que es relevante e interesante y luego presentar regularmente para el equipo también es un buen trabajo.

Pero no se olvide que al indicar al equipo y que sirve como capa de abstracción que ayudan a los desarrolladores y mundo exterior para interactuar de manera más eficiente, lograr más y hacer frente a una mayor complejidad, el trabajo tiene un punto.

Answer 3

El equipo de ingeniería tiene que entender las razones de negocio de por qué se les pide hacer las cosas en un nivel macro. El equipo de ingenieros ganar la comprensión y motivación de esta. Pero el exceso de charla es un no-no, como señalas, parte de su trabajo es filtrar , y parte de eso significa no exponerlos a un montón de ruido. Sus desarrolladores probablemente tienen opiniones y puntos de vista en cuanto a cómo hacer las cosas particulares o por qué escoger tecnologías particulares, y deben ser alineados por su experiencia en esas áreas.

Sin duda, no crear una cultura de BCCing.

Una opción es tener listas de correo separadas que las partes interesadas pueden suscribirse a, pero por supuesto, no todos la charla habrá en esas listas.

Y, por supuesto, una reunión regular de la compañía es una necesidad. Deje que los chicos de ingeniería saben por qué el negocio depende de la entrega de un producto estable, completa (o lo que los próximos hitos requieren). 20 minutos, no se desliza, sin mierda es lo que funciona para mí. Su equipo y situación pueden variar.

Answer 4

Yo estaría utilizando un Wiki, usted no desea agregar a la tormenta de correo electrónico, y sus desarrolladores también pueden contribuir y cambiar las cosas. También es muy útil para compartir documentos, y si se hace bien que va a ser autosuficientes.

Por cierto cortar / pegar desde el correo electrónico a wiki que parece una cosa extraña a tener que hacer, ¿alguien sabe de un .Net wiki lightwieght que puedo enviar por correo electrónico el contenido también?

Answer 5

Una forma podría ser la de no transferir todas esas mensajes de correo electrónico y una vez a la semana recopilar toda la información relevante, cambios de diseño, y así sucesivamente en una reunión semanal. Sin duda alguna no enviar un aluvión de mensajes de correo electrónico a los desarrolladores. Por supuesto, si se discute algo crítico, que debe ser puesto en su conocimiento. Sin embargo, trate de resúmenes semanales y discusión de los detalles pertinentes.

Answer 6

Estoy viendo esta pregunta un año después de que ha sido publicada, sin embargo, puedo añadir mi experiencia con algunos datos específicos para mi caso. Para los desarrolladores de 2-3 sobre el proyecto, que en su mayoría hago uno-a-uno. Muchas veces hago esto más de la mensajería instantánea o por teléfono ya que la mayoría de mi equipo pasa mucho tiempo en la oficina en casa. Reunión de vez en cuando es inevitable, sobre todo cuando el proyecto está empezando (1-2 reuniones de desarrolladores tienden a ser suficiente para poner en marcha razonablemente complicada del proyecto), pero como regla general, todas las comunicaciones con el resto de la compañía pasa por mí y desarrolladores consigo un digerir. La única excepción es cuando conecto desarrollador directamente con el usuario (no gestión!) Para trabajar en los detalles del proyecto.

Me tienden a evitar las reuniones regulares (semanal o diaria) y programar reuniones sólo cuando al menos dos de estos suceda, en este orden:

1. Información importante viene en (dependiendo de la urgencia que esto puede esperar hasta una semana)
2. Los desarrolladores están en la oficina, de preferencia por otras razones (reuniones-desarrollador a desarrollador)
3. Cliente está disponible (no hay mucho donde elegir, pero trato de hacer reuniones y conectarse con los desarrolladores individuales manos a la experta en el lado del cliente más adelante)
4. necesito consejos de diseño (ya que soy un líder técnico, soy responsable de la mayoría de las decisiones de alto nivel de arquitectura)

Para los equipos de 4-8 personas (8 personas por lo general significa dos equipos) descubrí que corta reunión de 30 minutos más o menos una vez a la semana es más que suficiente para mantener a todos al día. Esto, por supuesto, es, además de uno-a-uno que voy a hacer al día durante desarrollador junior y dos veces por semana para los desarrolladores de alto nivel.

Para uno-a-uno, prefiero que los desarrolladores en contacto conmigo cuando están buscando algo más que hacer o cuando están teniendo dudas sobre la tarea que acaba de empezar a hacer. Esta es también una gran manera para mí mantener ojo en cómo van las cosas sin que los desarrolladores necesitan para pensar que me mantiene al día. Me tienden a evitar el correo electrónico cuando primario es suficiente, de lo contrario cambiar a teléfono (cuando hay algo que explicar o discutir) y al correo electrónico cuando:

• Cliente informe de error a través del correo electrónico
• Hay una gran cantidad de importantes detalles pequeños y desarrollador probablemente ir a través de esa dirección de correo muchas veces durante la implementación

También hay reuniones-desarrollador a desarrollador cuando tienen que coordinar en algo (por ejemplo, cuando Java y Javascript desarrollador necesitan para trabajar en los detalles de la interfaz).

Esta forma de trabajar significa que tengo que responder a mensajes instantáneos lo más rápido posible, y que por lo general hacer frente a una gran cantidad de interrupciones para que los desarrolladores tienen que tratar sólo con interrupciones para mí o otros desarrolladores. Lo que está bien, ya que una parte importante de mi trabajo es hacer que los desarrolladores eficaz.

Si necesito la paz para la codificación (y puede permitir) me encontré con que la delegación de la comunicación del cliente a los administradores de proyectos no técnicos e incluso los probadores beta (que son mucho mejor con distracciones que los programadores).

Answer 7

Pregúnteles lo que prefieres. Asumo que prefieren no ser puesto en copia todos los correos electrónicos y optaría por una actualización verbal a corto sobre una base regular.