Cuando trabajamos en equipo, siempre conocemos para dónde vamos. ¿O no?
Los desarrolladores somos creativos, sobre todo a la hora de evitar hacer más trabajo que el necesario. Podríamos encontrar una forma de hacer lo que nos piden con menos trabajo, una que podamos justificar fácilmente como una mejora: «Esta entrega tiene todo lo que pidió el cliente y además: !lo mejoramos poniendo la imagen de un gatito para adornar la pantalla!».
Pero lo que a veces no conocemos es el contexto completo. Tal vez existan bases que no pueden negociarse: «El cliente es alérgico a los gatos, y tiene Ailurofobia (fobia a los gatos). !Casi muere al verlo!».
Ahora, viéndolo con un escenario técnico:
Un cliente nos pide que se realice una conexión entre dos sistemas sin darnos el contexto de la clasificación de privacidad de su información. Los desarrolladores, podíamos utilizar una librería Opensource que ya implementa la solución, pero al no conocer el contexto completo:
- No darímos importancia a que esta librería exponga los datos por medio de una base de datos pública.
- Los datos que se están exponiendo, se consideran sumamente sensibles.
- Alguna entidad de control podría imponer cuantiosas multas a nuestro cliente por esta exposición de datos.
En resumen: cuando no tenemos un contexto claro, vamos a asumir lo que más nos convenga para rellenar los puntos vacíos.
Uno de los pilares de Scrum es la Transparencia:
«Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado«
La guía de Scrum. Ken Schwaber y Jeff Sutherland.
Esto, en nuestro contexto, corresponde a que todo el equipo de desarrollo debería conocer el por qué, el para qué y las restricciones que pudieran existir. Si nuestros desarrolladores hubieran conocido la condición del cliente, tal vez hubiesen sido conscientes de que debían hacer el trabajo bien hecho, o habrían buscado la manera de hacer menos trabajo sin escoger el componente de los gatos, sino el de los perritos, o para el ejemplo técnico, algún componente con encripción y seguridad en la transmisión de los datos.
En ocasiones, para algún Dueño de Producto, Gestor, Mánager, o alguien que tenga que responder por el tiempo utiliza el equipo, reunir a todos significaría tener que encontrar un complicado soporte de las horas dedicadas a una reunión.
Digamos que esto solo se da en algunos casos aislados, debido a que en la industria del desarrollo de software ya no se tiene control sobre las horas… (Digamos, supongamos, hagamos como si así fuera, ¿ok?)
Sin embargo, será más costoso aún perder varias horas de trabajo construyendo el producto equivocado. Y más horas aun corrigiendo lo que pudo evitarse. Y algunas horas tratando de calmar al cliente que casi muere del susto al ver su más grande pesadilla materializada ante sus ojos (pagar una millonaria multa o una terrorífica bestia), intentando que no termine nuestro contrato.
Cuando todos tenemos el contexto claro, el objetivo será obvio (o al menos más fácil de ver). Y cuando todos tenemos el mismo objetivo en común, y sabemos bien hacia dónde queremos ir, podremos escoger el mejor camino para lograrlo, todos juntos: ¡como un solo Equipo!
Ver en Contactos Ágiles
Una respuesta a “Los beneficios de no ocultar el contexto”
[…] Ver en nassao.com […]