archivo

Archivos diarios: octubre 13, 2011

Una de las causas del desgobierno funcional de un proyecto de desarrollo de software o de un sistema de información es la no adopción por parte de la organización de una estructura organizativa que permita resolver determinadas necesidades que puede tener el mismo, sobre todo a nivel de toma de decisiones.

Supongamos un sistema horizontal que afecta a varios departamentos y en donde pueden existir cambios que afecten al funcionamiento general del sistema, puede darse el caso, más a menudo de lo que pueda parecer, que lo que a un departamento le parece bien, otro lo rechaza, llegado a este punto, ¿a quién hacer caso?.

Cierto es que se podría escalar y es algo que podría funcionar si el número de conflictos de este tipo fuera muy puntual o si las decisiones de carácter horizontal también fueran muy escalonadas, pero la realidad es que aunque efectivamente grandes decisiones no hay muchas, sí que hay muchas de menor relevancia que requieren de alguien que tenga la última palabra y ese alguien no puede, ni debe ser un desarrollador, salvo que el asunto sea de carácter eminentemente técnico.

Se necesita de una figura que agilice y coordine el ámbito funcional del proyecto, con mayor dedicación que la que le pueda dar un directivo pero con autoridad suficiente sobre los departamentos y tal vez esta figura requiera de cierto personal de apoyo. El problema es que de manera mayoritaria se opta por mantener la estructura existente algo que dificulta una gestión eficaz del proyecto o del sistema de información.

Se desarrolla en equipos de proyecto, pero incluso aunque se haga a nivel individual, el código realmente obtiene su valor cuando se consolida en un sistema de control de versiones o en un repositorio de código y puede ser accesible por el resto del equipo, por la comunidad o más adelante por el propio desarrollador. Esto es lo que opina Jeff Atwood cuando afirma que: “El código no existe hasta que se sube a un repositorio de fuentes”.

Cuanto más tiempo pasa el código en local, cuanto y más tiempo se tarda en hacer integraciones, más riesgo existe de que las piezas no encajen por mucho que se haya seguido un diseño riguroso.

Las prisas están reñidas con la calidad. Las tareas tienen un tiempo para llevarse a cabo, es cierto que no todo el mundo tarda lo mismo en hacerlas y que no todos les dan el mismo acabado, pero también lo es que esto no hace más que definir un umbral de tiempo para la realización de las mismas.

De ahí la importancia de planificar un proyecto de la mejor manera posible, de detectar desviaciones, de poner solución a las contingencias y de intentar adelantarse a problemas que puedan ocurrir.

Las prisas no solo afectan al resultado final sino a la propia productividad. Las prisas bloquean y hay que tener en cuenta que trabajar bajo presión y bajo la urgencia son cosas distintas.

Es mejor incumplir una planificación de manera controlada (salvo que el producto tenga que estar inexcusablemente en una fecha determinada, algo que por otra parte sucede en muy contadas ocasiones) que intentar cumplirla pase lo que pase, ya que al final, muy probablemente no se consiga un resultado satisfactorio y las posteriores correcciones requerirán un mayor esfuerzo.

Cuando se habla de prisas, urgencias, no viene mal recordar el algoritmo de planificación de Wexelblat.