Detectar los fallos

Cuando alguien prueba algo, lo que sea, si detecta fallos, deben ser aquellos que están en lo que se está probando y no otros. Sin embargo, en muchas ocasiones, cuando se prueba, quieres que los que diseñan el producto, objeto de la prueba, te solucionen problemas ajenos al producto.

Pongamos un ejemplo, ya que en abstracto, se ve fatal. Desarrollas una aplicación web, se la entregas al que tiene que probarla y le da un error, consecuencia del equipo que tiene, la red y cómo está instalado todo, por lo que te abre una incidencia, que, obviamente, no es consecuencia del software, si no de lo que ese software tiene a su alrededor.

Y resulta, que cuando les explicas que el problema no es del producto, se empeñan en que tienes que solucionar el problema. Por ia eso, siempre defendemos que los equipos de desarrollo de cualquier producto, aglutine a alguien de cada área, que siempre esté con ese producto, de manera que lo conozca y sea capaz de diferenciar, lo que es un error de producto del resto de errores, vamos a llamar, satélites.

Pero mucho nos tememos, que aunque nosotros pensemos así, seguiremos viendo empresas, que tienen departamentos aislados, que se encargan de cosas distintas y por mucho que se intente, jamás verán las cosas como una sola, ni darán valor a la experiencia de las personas. Eso sí, tendrán miles de procedimientos, orientados a conseguir que las personas y la experiencia no tengan valor, de manera que cuando una persona sobre, simplemente se cambia por otra persona y todo sigue igual. Pero que no os vendan la moto, eso no funciona, y si dejas que te convenzan para montarlo, cuando te quieras dar cuenta, estará tan metido dentro de la empresa, que será tarde para poner remedio.