Equipos de desarrolladores remotos: ¿Cómo comparte información sobre las funciones recientemente implementadas?

Jack lo ha hecho por el camino equivocado … si está al final, sin hablar con su equipo a menos que el cambio no sea muy grande.

Es crítico que los empleados remotos se comuniquen TODO el tiempo. En realidad, es más crítico que en persona, porque puede ser fácilmente malentendido. Por lo tanto, debe enviar el mensaje varias veces y de varias maneras.

En una situación como esta, haría cosas como:

1. Explícalo diariamente para ver qué piensa su equipo.
2. Escriba un correo a su equipo con su diseño.
3. Ponga el código para su revisión.
4. Proporcione medidas sobre por qué es mejor.

Con todo eso hecho … Hay alguna posibilidad de que aún puedan ignorarlo, pero las posibilidades son bastante remotas. Si la administración es CCd, en el # 4, diría que cerca de 0.

Al final … ¡El objetivo de Jack debería ser tener al equipo esperando ansiosamente su brillante trabajo! Sin preguntarme qué les había hecho Jack.

La diferencia está en la comunicación y en obtener retroalimentación temprana y frecuente.

Depende mucho del proceso seguido por el equipo. Un equipo que no sigue ningún proceso está en peligro. Lea la respuesta de Ira Cooper y la respuesta de Paul Bissex primero.

Asumiré que el equipo tiene un proceso y que el trabajo realizado por Jack ya fue planeado y acordado por el equipo. También asumiré que el equipo usa un sistema de control de versiones (por ejemplo, git, mercurial, etc.), usa herramientas de comunicación y herramientas de productividad de algún tipo.

El primer objetivo aquí es difundir la información. El enfoque más simple y directo sería enviar un correo electrónico a todos sus compañeros de equipo. “No leo correos electrónicos” no es excusa para un desarrollador del siglo XXI.

Una desventaja obvia de un correo electrónico es que puede permanecer en la bandeja de entrada de otro desarrollador durante unas horas o un día entero hasta que lo lea. Si la información necesita difundirse muy rápido, utilice una herramienta de mensajería instantánea. Me gusta usar Slack, pero Google Hangout también funciona. Slack tiene más funciones orientadas al equipo y mantiene las conversaciones mejor organizadas.

Segundo objetivo, hacer cumplir el cambio. Si existen múltiples funciones que alcanzan el mismo objetivo, es probable que las personas usen ambas. Así que elimine la característica más antigua por completo. Para facilitar la transición a otros desarrolladores y para que el resto del sistema funcione, mantenga la interfaz con la nueva función. Y dado que Jack es un caballero desarrollador (o quiere ser visto como uno), debe documentar los cambios claramente en sus mensajes de compromiso y en la herramienta wiki / documentación del equipo.