archivo

Archivos diarios: febrero 20, 2013

He aprendido mucho más de mis errores que de mis aciertos y no creáis que ha sido fácil porque para ello hay que asumir que uno se equivoca y que si algo sale mal hemos tenido responsabilidad, tal vez la máxima, de que haya salido así.

A todos nos gusta vernos guapos en el espejo por eso cuesta tanto asumir que hemos fallado, que nos hemos equivocado o que hemos fracasado.

Pero no hacer caso a la realidad no la cambia solo te condena a volver a repetir el mismo error más adelante y así una y otra vez.

Para levantarse hay que darse cuenta que nos hemos caído. Caerse se caen todos, no hay nadie infalible, nadie.

Asumir tus errores, aprender de ellos no garantiza que no vuelvas a equivocarte, somos seres humanos, pero al menos estás sobre aviso de lo que hiciste mal y de lo que te llevó a esos malos resultados.

Soy de la opinión de que tenemos miedo a la autocrítica no solo porque nos guste salir bien en la foto sino porque solemos ser muy duros con nosotros mismos una vez que decidimos dar ese paso, cuando eso te pase recuerda que esto se hace para levantarnos con más fuerza y no para quedar rotos en mil pedazos.

Norm Kerth lo resume todo en la siguiente reflexión (experto en retrospectivas en proyectos de desarrollo de software): “La autocrítica es dura pero creo que podemos aprender más de nuestros fallos que de nuestros éxitos”.

Comenta Pete McBreen que: “Con un ciclo corto de feedback es fácil aprender qué funciona y qué no”.

Los usuarios no tienen claro que es lo que quieren hasta fases muy avanzadas del proyecto. Al principio del mismo tienen ideas generales (por mucho que digan que lo tienen clarísimo ya que una cosa es la teoría y otra la realidad) relacionadas con el problema que quiere solucionar o con el proceso que quiere informatizar.

Si esperamos demasiado, si el paso a producción se eterniza o si el usuario no tiene posibilidad de trabajar con el sistema que se está desarrollando nos encontraremos con que su feedback vendrá muy tarde precisamente cuando el presupuesto esté prácticamente agotado y cuando el coste el cambio sea importante. No me invento nada, lo hemos vivido (y vivimos) prácticamente todos.

Hay que intentar conseguir ese feedback cuanto antes, tiene más intención si el sistema está en producción (aunque sea solo con una parte del sistema en funcionamiento) ya que ahí se puede apreciar el impacto real que tiene en el negocio, es decir, se puede ver qué ha funcionado y qué no.

Si son necesarias varias iteraciones para tener pasar el producto a producción (aunque sea parcialmente) utilicemos otras estrategias (que requerirán una colaboración y un compromiso fuerte del usuario) para obtener ese feedback al final de cada iteración.