Vértigo técnico

Cuando en proyecto de desarrollo de software se ofrece formación tecnológica, tanto si va a usar dicha tecnología en el proyecto como si no se va a usar, el técnico siempre mostrará predispuesto a realizar dicha formación. Es normal, es bueno para el técnico y para el proyecto en general. Pero es muy diferente aprender que producir. Es decir, se puede producir un efecto en la respuesta del técnico que confunda y parezca extraño desde la gestión ya que el técnico puede estar muy dispuesto a formarse pero puede puede mostrar muchas pegas a la hora de desarrollar tareas productivas con lo que ha aprendido. Esto puede parecer contradictorio pero tiene mas sentido de lo que parece.

Desarrollar una tarea productiva tiene asociadas una serie de características que no son técnicas como son:

• Se le pedirá al técnico una fecha fin.
• Se le pedirá al técnico una calidad.
• Se le pedirá al técnico que explique que es la mejor solución.

 y por supuesto es mas fácil para técnico (y para cualquiera) garantizar estos puntos usando la tecnología con la que trabaja siempre que una tecnología que acaba de aprender.

A este efecto lo llamo vertigo técnico.

Como solucionarlo:

• Mas formación del técnico: para que adquiera mas conocimiento y pueda garantizar todos los puntos anteriores.
• Selección del técnico: puede que el mismo técnico no quiera moverse de su zona de confort. Si este es el caso se debe considerar la opción de no pedir al técnico que aprenda algo nuevo y seleccionar a otro técnico en su lugar.
• Comprensión en la gestión: Por parte del gestor hay que entender que una nueva tecnología convierte a un técnico senior en uno junior y no se le puede pedir resultados tan rápido como se hacia antes.     

Documentación Util

Este es un punto donde hay mucha discusión ya que tenemos en el enfoque básico que indica que cuanto mas documentación se haga y cuanto mas detalle tenga esa documentación mejor. Pero este planteamiento es el claro ejemplo de cosas que suenan bien pero en la practica son un fracaso. Por que? vamos a ver los factores que SI hay que tener en cuenta:

• Tiempo de elaboración: Cuanto mas extensa y mas en detalle sea la documentación mas va a costar redactarla.
• Mantenimiento: No existe (al menos en el mundo del software) documentación que este bien desde el principio. Ni los pliegos. Cuanto mas extensa y mas en detalle sea la documentación mas va a costar las modificaciones y las ampliaciones.
• Capacidad de comprensión: la documentación tiene que ser un punto de referencia, debe ser la "CONSTITUCIÓN" del reino del proyecto. Cuanto mas extensa y mas en detalle sea sera mas posibilidad exista de que en algún punto diga una cosa y en otro diga completamente lo contrario (que existan contradicciones).

La documentación de software debe seguir la siguientes reglas:

• Del axioma "Cuanto mas extensa y mas en detalle sea ..." del punto anterior tampoco saquemos la conclusión de que la documentación debe ser escasa. La documentación en un proyecto de desarrollo de software debe ser precisa y completamente determinista.
• Debe tener el mayor número de dibujos que expliquen gráficamente lo que se esta explicando con palabras.  
•  Debe tener un formato fácilmente accesible por todo el mundo. Sea técnico, gestión, cliente, etc.. Olvida los words, excel, etc... Tiene que ser un formato web tipo wiki, blog, etc..

La clave es que cuando algún miembro del equipo pregunte por cualquier cosa se le pueda solucionar "enviandolo" a una url donde esta la documentación precisa que le solucione el problema.