archivo

Archivo de la etiqueta: Wirth

Las prisas, esas prisas. Esa intención de tratar de sacar el máximo valor posible al presupuesto a costa de la presión y un esfuerzo de los desarrolladores por encima de lo recomendable, es algo en lo que hemos caído la mayoría.

Es el tiempo el que te enseña que tal vez de esa forma ganes alguna batalla pero terminarás perdiendo las guerras.

No puedes someter a los desarrolladores a una sobrecarga de trabajo y a una presión excesiva durante un tiempo prolongado. Llegado el momento todos podemos hacer un esfuerzo pero esa línea se debe adaptar a límites sostenibles lo antes posible y no mantenerse (o empeorar) porque al final, los desarrolladores no podrán mantener el ritmo y se resentirá todo, primero las personas, segundo el equipo, tercero el producto y cuarto el proyecto.

Para Niklaus Wirth: “La presión del tiempo corrompe gradualmente el estándar de calidad y perfección del ingeniero, y esto tiene un efecto muy negativo tanto en las personas como en los productos”.

Salvo que cumplir un determinado plazo sea esencial (y que lo sea de manera objetiva porque después la realidad termina mostrando en muchos casos que esos plazos inamovibles eran más caprichos que otra cosa), hazte el planteamiento de que lo más recomendable es conseguir un valor óptimo del producto y eso se consigue, entre otros factores, con un equipo implicado, motivado y con energía.

Niklaus With dijo (traducción libre): “Uno de los principales motivos de la complejidad es que los proveedores de software adopten sin crítica casi cualquier característica que los usuarios desean”.

Se puede adaptar la postura cómoda, que no quiere decir que sea sencilla, de limitarnos a recoger las especificaciones de los usuarios sin expresar una visión crítica.

Esto implica que nos guardaremos la opinión sobre la complejidad o simplicidad de la solución planteada, sobre la conveniencia de priorizar determinadas tareas sobre otras, en definitiva, no ponemos a disposición del product owner o del responsable funcional nuestro conocimiento y experiencia.

El desarrollo de software debe ser colaborativo porque las perspectivas, habilidades, conocimientos y experiencias del conjunto suman siempre más que cada una de ellas por separado.

¿Por qué adoptar esa posición? A veces, en función de la naturaleza del product owner, la confrontación de las opiniones puede originar desgaste y en cualquier caso siempre vas a trabajar más ante la necesidad de argumentar tus opiniones y de consensuar soluciones.

Sin embargo, en muchas ocasiones, la elección de esa postura es el resultado de arrojar la toalla como consecuencia de que el usuario ni quiere ni se deja asesorar.

El product owner debe definir la línea de desarrollo del producto, es su responsabilidad, pero también debe tener la capacidad de escuchar las recomendaciones de todo el conjunto de personas que colaboran en el proyecto, si deja esto de lado, probablemente la obtención de valor será más lenta y el producto resultante en cada iteración tendrá un nivel de complejidad mayor al necesario.

Los desarrolladores deben aportar, no solo su capacidad para desarrollar el software, sino también poner en valor su perspectiva y experiencias.