archivo

Archivo de la etiqueta: Pete McBreen

La teoría está muy bien, adquirir conocimientos a través de la experiencia de otros puede, sin duda, incrementar los tuyos porque por un lado te ofrecen otros puntos de vista con los que contrastar tus ideas y por otro porque es posible que encuentres la solución a problemas que todavía no has conseguido resolver o encuentres nuevas formas de enfocar determinadas situaciones.

He aprendido (y aprendo) mucho desde la teoría pero creo que he conseguido extraer más de la misma gracias a mi experiencia personal o, lo que es lo mismo, la práctica.

Para Pete McBreen: “Tan pronto como una persona deja de practicar, su maestría se desvanece”.

Y es que el mundo del desarrollo de software no se rige por leyes físicas, es cierto que hay un cuerpo de conocimiento, procesos, metodologías, buenas prácticas, arquitecturas, frameworks, lenguajes de programación, etc… pero no son más que instrumentos o herramientas. Puedes conocerlos, ser un experto, pero después hay que aplicarlos al mundo real, en proyectos con sus restricciones, su incertidumbre, con contextos que varían, donde interactúas con más personas que tendrán intereses u objetivos diferentes y que pueden pertenecer a tu departamento u organización o a otra, etc…

A lo anterior hay que sumar que el desarrollo de software (y las entidades en las que se o para las que se desarrolla) se encuentran en constante evolución, lo que tal vez funcionó en un momento del tiempo para contextos concretos es posible que ya no produzca tan buenos resultados.

Para Pete McBreen: “La maestría o la sabiduría no han sido nunca resultado de encontrar la mejor manera, sino el resultado de un viaje de descubrimiento en que nuevas ideas son posibles, incluso en las más mundanas de las tareas”.

Por tanto, se trata de un viaje sin fin, en el que vamos evolucionando conforme vamos ampliando nuestras experiencias y conocimientos y, en donde en cualquier situación y con cualquier persona tenemos la capacidad de mejorar.

Las ideas están ahí fuera es muy pretencioso pensar que todas las tenemos en nuestra cabeza.

En el momento en que pensamos que lo sabemos casi todo y que muy pocas situaciones o personas nos pueden aportar cosas, estamos limitando, no solo nuestro conocimiento sino nuestro margen de maniobra ante un determinado problema si pensamos que la solución al mismo solo puede proceder de nosotros mismos.

Cuando trabajas con más personas, pensar que nadie te puede aportar nada o que solo algunos de ellos puede hacerlo estás cometiendo un error, te estás poniendo límites sin necesidad, estás dejando que tu arrogancia ponga resistencia al éxito.

Este tipo de actitudes llevadas al campo de los proyectos de desarrollo de software producen resultados nefastos ya que tiendes a crear castas: aquellos a los escuchas y aquellos que solo están para ejecutar trabajo y eso produce división y desmotivación entre aquellos que consideran que su opinión o conocimientos no vale para nada.

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.