Actualización: (una preocupación específica de PM) Tener desarrolladores trabajando juntos es valioso para mi equipo: las personas tienden a hacer más preguntas de forma natural, se involucran en conversaciones relacionadas con el código que escuchan por casualidad, hacen más sesiones de programación en pareja, etc. Con la nueva configuración, perderemos algunos de estos beneficios. ¿Debería encontrar formas de formalizar estas prácticas ahora: sesiones semanales de intercambio de conocimientos, áreas Scrum designadas, etc.? ¿Cómo recupera los intangibles perdidos al cambiar un arreglo de trabajo productivo para los desarrolladores?
Pregunta inicial:
Mi jefe se convirtió recientemente en jefe de los equipos BA y Developer, y quiere reorganizar el espacio de la oficina y reubicar los cubículos de todos para que los equipos estén más intercalados.
Como administrador de desarrollo, veo esto como una mala idea porque:
¿Qué es lo correcto hacer aquí? Aprecio la visión del jefe de un equipo más unido, pero no estoy seguro de si está en el camino correcto.
Las desventajas que menciona podrían aplicarse fácilmente a los equipos de proyecto si continúa teniendo diferentes grupos en silos.
Un parámetro clave sería preguntar "¿Qué nivel de comunicación multifuncional necesitan nuestros equipos para tener éxito y lo estamos logrando en el sistema actual?" Deduzco de su pregunta que la respuesta de su jefe es NO, no está obteniendo el nivel de comunicación interfuncional que necesita y está tratando de abordar esto rompiendo los silos que han creado las unidades funcionales. Y una excelente manera de hacer esto es ubicar a sus equipos de proyecto en el mismo lugar.
Mi experiencia personal es que la ubicación conjunta de miembros de diferentes grupos funcionales cuando están trabajando en el mismo proyecto hace que esos proyectos sean más fáciles de administrar y es más probable que se entreguen a tiempo/calidad/presupuesto en un orden de magnitud.
El propósito de sentarse juntos es una práctica ágil que se basa en la idea de que la colocación aumenta el ancho de banda de comunicación dentro del equipo. Existe una amplia aceptación de esta premisa, pero también hay objeciones bien pensadas a la práctica, incluida la observación de que los asientos de planta abierta y la colocación pueden aumentar las interrupciones, reducir la relación señal-ruido y crear una sobrecarga adicional de cambio de tareas.
En otras palabras, la práctica se considera ampliamente beneficiosa, pero no es esencial . Ciertamente tiene alternativas, en caso de que realmente las necesite.
Si bien "al final del pasillo" puede ser un inconveniente para el intercambio de información osmótica, no es un problema de la misma manera que lo sería la coordinación con equipos geográficamente dispersos o modelos de desarrollo en alta mar. Honestamente, si un problema no es lo suficientemente grande como para justificar caminar 20 o 100 pies, probablemente no sea un problema real o urgente.
También hay beneficios para la integración dentro de la organización más grande. Si su equipo de desarrollo necesita coordinarse con alguien fuera del proyecto (por ejemplo, los analistas de negocios), entonces los beneficios de la colocación también se aplicarían a ellos. ¿Por qué no querría que sus desarrolladores tuvieran un acceso más fácil a DBA, BA u otros roles dentro de la organización con los que puedan necesitar trabajar para hacer bien su trabajo?
Los equipos que no se sientan juntos aún pueden trabajar bien juntos. Se trata de comunicación. Si tiene un equipo que está disperso, ya sea al final del pasillo o al otro lado del océano, el siglo XXI está inundado de métodos de comunicación productivos.
La mensajería instantánea, el correo electrónico, los teléfonos, el chat de video, las listas de correo, los wikis y el uso compartido de pantalla son solo algunas de las formas en que los equipos pueden trabajar juntos sin sentarse juntos. Cada mecanismo tiene sus pros y sus contras, y los equipos deben encontrar los flujos de trabajo y las fórmulas que mejor se adapten a ellos.
Anime a su equipo a crear los canales de comunicación y las prácticas de trabajo en equipo que necesiten. Se sorprendería de lo bien que pueden funcionar los equipos cuando la cultura organizacional fomenta las comunicaciones innovadoras.
¿Qué es lo correcto hacer aquí?
pregunte a sus empleados.
Si realmente te preocupa su productividad, pregúntales de qué manera serían más productivos. Y cuando preguntes, asegúrate de escuchar lo que dicen (he visto a un jefe "preguntar" así " vamos a tener tales y tales cambios, ¿de acuerdo? ")
Estoy de acuerdo con Steve y Doug en que depende de un par de cosas. El primero depende de cómo ha funcionado su organización en el pasado y cómo su(s) equipo(s) pueden adaptarse al cambio fácilmente. Pasar de un entorno de equipo funcional tradicional a un entorno de equipo Maxtrix de proyecto más abstracto requiere un gran esfuerzo para salir adelante sin problemas. Gran parte tiene que ver con la formación y preparación de los nuevos "equipos" para las eventualidades del desarrollo del equipo (formación, asalto, etc.). Nuestra oficina trabaja completamente en un entorno matricial, donde los miembros del equipo están en más de 6 a 10 proyectos cada uno. Toma tiempo acostumbrarse, pero si su cultura corporativa facilita la facilidad de comunicación, puede ser una metodología muy efectiva.
Parece que te enfrentas a una transición de arriba a abajo menos agradable. En casos como este, existe una buena posibilidad de que sus acciones fracasen sin el apoyo adecuado desde arriba. Recuperar los viejos hábitos es importante, pero creo que deberías encontrar una manera de mantenerlos en lugar de recuperarlos .
Debe haber otros colegas que estén preocupados como usted. Tenga una conversación informal con ellos y vea con quién podría hablar con su nuevo jefe sobre la situación actual y convencerlo de que deje su plan actual. Para hacerlo, necesitará ayuda, apoyo y alternativas. Esto debe ser un trabajo en equipo.
Cazador de ciervos
Vishal Bardoloi
voluntad