Saltar al contenido

Blog técnico | Responsabilidad del equipo

¿Qué significa para un equipo ser responsable? ¿De qué debería ser responsable un equipo? ¿Cómo deberían estructurarse los equipos?

En nuestras carreras, hemos experimentado dolor cuando las respuestas a esas preguntas no han sido bien definidas. En que hemos tratado de hacerlo mejor, aprendiendo de la comunidad y de nuestras propias experiencias pasadas.

Blog técnico | Responsabilidad del equipo
Blog técnico | Responsabilidad del equipo

Todas las personas adecuadas

Lo primero que hacemos es estructurar nuestros equipos de manera que incluyan a todas las personas necesarias para pasar de una idea a la producción. Esto significa que cada equipo tiene poder de decisión, puede implementar sus características y llevarlas a la producción. Y aunque cada miembro del equipo tiene funciones y habilidades específicas, compartimos mucho del trabajo.

La mayoría de nuestros equipos se centran en el desarrollo de productos, por lo que estos equipos incluyen un director de producto, un diseñador de UX, un jefe técnico, un ingeniero de operaciones y algunos desarrolladores.

Otros equipos varían en su composición, pero todos tienen las personas que necesitan para cumplir con su cometido. Por ejemplo, nuestro equipo de plataforma no tiene un gerente de producto o un diseñador de UX porque trabajan en la arquitectura interna y la plomería que no está orientada al cliente. De la misma manera, el equipo de operaciones no tiene miembros del producto porque se centran en la administración del servidor y la infraestructura.

Esta configuración nos da muchas ventajas. Una de las mayores ralentizaciones para cualquier equipo es la sobrecarga de la comunicación entre los equipos, especialmente cuando se toman decisiones entre ellos. La mayoría de las empresas ponen a los desarrolladores en un equipo separado del producto, que está separado de UX, y todos están separados de las operaciones. Esto hace intrínsecamente más difícil conseguir cualquier cambio específico de la idea a la producción porque el trabajo tiene que ser lanzado por encima de la pared de equipo a equipo.

También intentamos dividir el trabajo para minimizar la necesidad de coordinación entre los equipos. Idealmente cada equipo posee una parte vertical completa del producto: incluyendo bases de datos, APIs, sitios web, etc. De esta manera el equipo puede construir todas las partes que necesita dentro de su área de… Por supuesto, a veces la comunicación entre los equipos es inevitable, pero hemos diseñado intencionadamente el sistema para reducir esa sobrecarga.

No QA dedicado

Notarán que no mencioné a los probadores. “¿Dónde está la gente de control de calidad?” Actualmente no tenemos probadores dedicados en nuestros equipos. Hacemos que sea responsabilidad de los desarrolladores probar su código y asegurarnos de que funciona. Tenemos una fuerte ética de artesanía de software, lo que significa que para nosotros, los errores no son una consecuencia inevitable de escribir código, sino que representan un fracaso para hacer nuestro trabajo correctamente.

Esto no quiere decir que descartemos el valor que pueden proporcionar los probadores dedicados. Su enfoque y experiencia a menudo pueden encontrar problemas que los desarrolladores pasan por alto. Pero su capacidad para encontrar problemas no absuelve a los desarrolladores de su responsabilidad por la calidad del código, por lo que hemos optado por centrarnos en la construcción de la calidad en lugar de tratar de añadirla en un paso posterior.

Se espera que cada equipo utilice la automatización de pruebas en múltiples niveles de la pirámide de pruebas, desde las pruebas de unidad hasta las pruebas de interfaz de usuario. Y le corresponde a cada equipo hacerlo, porque si hay un problema depende del equipo resolverlo.

Cultura DevOps

Cada equipo es responsable de su código en la producción. Son dueños de su proceso de despliegue y supervisión. Por eso hay una persona de operaciones en cada equipo; esa persona permite al equipo acceder al entorno de producción (incluyendo el aprovisionamiento de servidores, credenciales y similares). Si algo sale mal en la producción, es el trabajo del equipo arreglarlo.

Tenemos un equipo de operaciones dedicado que ayuda con la supervisión, y a menudo triaje los incidentes de producción. A menudo ayudan con la infraestructura compartida, pero no se puede esperar que entiendan los detalles de la base de código de cada equipo. Si pueden arreglar un problema, eso es genial. Pero incluso entonces, el equipo original finalmente tiene que averiguar cómo evitar que suceda de nuevo.

Los miembros de cada equipo tienen roles y especialidades definidas, pero tratamos de compartir la carga de trabajo de manera interfuncional. Todos pueden ayudar con los incidentes de producción, no sólo el ingeniero de operaciones. Todos pueden ayudar con el diseño del producto, no sólo el gerente de producto o el diseñador de UX.

Equipos autónomos responsables

Todo esto se combina para significar que cada equipo tiene una verdadera responsabilidad. Son responsables de su trabajo, desde las decisiones sobre el producto hasta su rendimiento en la producción. No hay que pasar la pelota por el río (“problema de operaciones ahora”) o señalar con el dedo la culpa a través de los silos cuando algo sale mal.

Los equipos también tienen un alto grado de independencia y autonomía. Dentro del ámbito de lo que poseen, son capaces de tomar decisiones sobre las reglas de negocio, la aplicación, las pruebas, etc. (No es una autonomía ilimitada, sin embargo, porque ningún equipo está completamente aislado de los demás por lo que todos tenemos que jugar bien dentro de algunas directrices establecidas).

Encontramos que esta estructura funciona mejor para nosotros – y es más ágil – que la forma en que los equipos se establecen en la mayoría de las otras empresas para las que hemos trabajado en el pasado.

Categorías: cultureTags: devops, cross-functional