archivo

Archivos diarios: enero 8, 2013

El desarrollo de software es cosa de equipos, de personas que colaboran unas con otras para alcanzar un fin. Esas personas son las que conocen lo que va bien y lo que va mal, cada una de ellas dentro de su ámbito de visión. Conforme se va ascendiendo niveles fuera del proyecto la visión del mismo se va difuminando y en algunos casos, incluso pervirtiendo, en función de comentarios interesados de quién te haga llegar la información.

Una pena, porque perfectamente se puede acudir en persona a fuentes más directas y no se haces porque se vive mucho más tranquilo sin conocer la realidad tal como es. Tener mucho trabajo no es excusa para pulsar por uno mismo el estado de un proyecto ya sea desde tu organización o de equipos externos a la misma que participen en el proyecto. No hay que olvidar que independientemente de que el día a día lo lleven otros, sigues siendo el responsable directo de lo que pase.

Este antipatrón se suele producir cuando se ignora a niveles jerárquicos inferiores de tu organización (salvo el inmediatamente inferior) o de aquellas con las que estás trabajando y solo deseas tener un trato con “iguales”. Algo que políticamente puede ser correcto pero que te sitúa al otro lado del muro de lo que está pasando.

Insisto muchas veces en la necesidad de reconocer nuestros errores y nuestras limitaciones, para poder seguir creciendo personal y profesionalmente.

En el desarrollo de software es algo esencial porque trabajas en un contexto cambiante y en el que te va a resultar complicado conseguir buenos resultados en todos los proyectos. en el éxito y en el fracaso tienes que ser crítico contigo mismo porque seguro que hay margen de mejora, siempre lo hay.

No reconocer los errores o nuestro amplio margen de mejora puede ser una actitud ante los problemas que pueden surgir en el trabajo, como una autodefensa: “si no reconozco que hago algo mal o que no se me da bien hacer esto otro, es posible que nadie me lo diga y con el tiempo todo se olvide”.

Sin embargo, hay veces que no se actúa así de manera consciente, tal como lo demostraron Justin Kruger y David Dunning tras una serie de experimentos llegando a la conclusión de que personas con escaso conocimiento tienden a pensar de manera ilusoria que su habilidad es mucho mayor que la media y a considerarse más inteligentes que otras personas más preparadas, debido a que su propia falta de competencia les hace más complicado reconocer los errores y medir el nivel de competencia de los demás (a esto se le ha denominado efecto Dunning-Kruger).

Por el lado contrario, las personas más competentes tienden a subestimar su propia capacidad.

El efecto Dunning-Kruger no es permanente, ya que conforme las personas van mejorando sus habilidades se van dando cuenta no solo del conocimiento que no tenían, sino del que todavía necesitan adquirir.

Recuerdo una conferencia a la que asistí en la que uno de los ponentes defendía que los procesos de desarrollo de software requerían carga burocrática con el objeto de conseguir un cierto orden en el funcionamiento del Departamento TIC y en las relaciones del mismo con la organización y que, por tanto, la implantación de metodologías ágiles no eran adecuadas para entornos de estas características, salvo para algún caso aislado donde sí pueda ser de interés aplicarlas o para organizaciones pequeñas.

Cuando se refería a la carga burocrática se refería a la documentación como token de entrega ya sea como parte del proceso de desarrollo, para reportar el estado del desarrollo de proyecto a otros niveles organizativos o como resultado de la entrega final del producto o de la versión, ya que a partir de ese momento intervendrían otros equipos.

Dicho así, todo parece muy idílico, pero generalmente ese sistema tiende a pervertirse salvo que se implante un estado policial y ambos extremos deben ser evitables.

Claro que tienen que existir procesos, claro que es necesario armonizar los desarrollos, claro que no vale todo, pero tampoco vale simplificar que la solución a todos esos problemas se encuentra en los procesos o peor aún, en los entregables definidos en los mismos.

Proceso para esto, proceso para esto otro, ¿y las personas?, ¿dónde quedan las personas?.

Es cierto que cuanto más grande es una organización más complicada resulta de gestionar, pero eso no quita que no sea viable la aplicación de estrategias ágiles tanto como filosofía de funcionamiento dentro de la misma como en los procesos de producción. ¿Acaso no se puede considerar como prácticas compatibles y/o que alimentan el agilismo la aplicación de lean?, ¿es acaso Toyota una organización pequeña?, ¿acaso son también pequeñas toas las organizaciones que lo utilizan?.

No puedo entender que se defienda la sobredocumentación en proyectos utilizando como argumento el tamaño de una organización porque una mayor documentación de por sí no solucionada nada. La documentación solo resulta útil cuando cumple un propósito efectivo y se tiene en cuenta cuál es el ciclo de vida del documento, a la hora de exigirle mayor nivel de formalidad o no.

También es importante tener en cuenta que hay información que no necesariamente tiene que ser reformateada y que podría obtenerse perfectamente a través de la propia gestión ordinaria de los proyectos.