archivo

Archivo de la etiqueta: predictivo

El enfoque evolutivo del desarrollo de software desde una perspectiva ágil consiste en ir descubriendo el camino hacia el cumplimiento de las expectativas de usuario a través de la oscuridad de la incertidumbre que rodea a los proyectos, de la resistencia que encontremos y de los cambios de dirección y sentido que provocan los cambios de contexto.

La brújula es el feedback sobre iteraciones del producto teniendo como base nuestro background como desarrolladores de software y la intención con que se afronta cada evolución del sistema (una cosa es tener que descubrir el camino y otra no tener muy claro realmente a dónde se quiere ir) y nuestro motor el funcionamiento real como un equipo de trabajo.

Los enfoques clásicos, predictivos por naturaleza, entienden que desde el principio se sabe cómo llegar al producto que se desea y que en cualquier caso a lo largo del proceso de desarrollo se podrían realizar ligeros ajustes.

La realidad que nos encontramos en los proyectos de desarrollo de software nos indica que en la mayoría de los casos no se sabe qué es lo que se quiere realmente (o por lo menos con la suficiente precisión como para poder plantear un enfoque clásico) y que el camino para llegar a ese objetivo tiene muchas curvas, subidas y bajadas, asfalto de distinta naturaleza y diferentes condiciones climáticas.

Han pasado casi tres años desde que escribí una serie de artículos dedicados a la definición de un plan de sistemas de información:

Plan de sistemas de información I
Plan de sistemas de información II
Plan de sistemas de información III
Plan de sistemas de información IV
Plan de sistemas de información V
Plan de sistemas de información VI
Plan de sistemas de información VII
Plan de sistemas de información VIII
Plan de sistemas de información IX

Llevaba pensando un tiempo pensando en escribir un nuevo artículo sobre los planes de sistemas, haciendo hincapié en uno de sus principales problemas: su carácter eminentemente predictivo, basado en un fotografía de la organización en un momento dado, algo que no se ajusta a la realidad de las entidades.

En resumidas cuentas, presenta el mismo problema que las metodologías software basadas en métodos predictivos como el ciclo de vida en cascada, lo que hoy puede ser válido (si es que la especificación realizada es buena, algo que no es sencillo), mañana puede dejar de serlo porque las condiciones de partida han variado sensiblemente.

Finalmente, unas series de tweets que leí ayer a Jon Kern (uno de los padres del manifiesto ágil) sobre gobierno ágil, me animaron a escribir sobre este asunto.

Básicamente Kern expresaba la dificultad de establecer planes de gobierno a largo plazo ante una situación basada en la incertidumbre.

Un plan de sistemas no es más que un plan de gobierno de los sistemas de información de una organización, en la que se estudia una situación inicial, se determina un modelo objetivo al que se quiere llegar y un plan de acción que nos permita llegar desde esa situación inicial al modelo objetivo. Se suelen definir con un período de vigencia de tres o cuatro años.

Como ya recomendaba cuando escribí esos artículos, el tránsito desde la situación actual a una situación que se aproxime a lo que consideramos como ideal (dadas las características de nuestra organización y su contexto), probablemente si la organización no se encuentra lo suficientemente madura a nivel de procesos relacionados con el desarrollo de software y el gobierno TIC, requiera de la realización de varios planes de sistemas de información.

Este enfoque iterativo incremental tiene en esencia fundamentos ágiles, sin embargo, el tiempo que hay entre planes de sistemas, difumina casi todos los atisbos de agilidad que pudieran existir.

Mi recomendación sería en primer lugar, disminuir el período de vigencia de un plan de sistemas, situándolo a lo sumo en dos años y existiendo la posibilidad de que tenga una vigencia anual si existen riesgos ciertos de cambios de contexto o se han producidos cambios no previstos en la organización, procesos, de la organización hacia el exterior, etc… En cualquier caso, tanto si se decide que la vigencia sea de dos años, como de uno, hay que estar abiertos a reorganizar las prioridades si fuera preciso, para poder adaptarnos a cualquier variación de las condiciones iniciales o para ayudar a la organización a conseguir algún objetivo operativo o táctico de mayor trascendencia.

Por otro lado, también recomiendo, ¿por qué no?, plantear desde el principio hacia dónde queremos llegar, pero no con el presente plan de sistemas, sino a nivel estratégico definiendo cuál es la política de sistemas de información que sería deseable tener y realizando ajustes a ese alcance final en cada plan de sistemas, el cual, a su vez pretenderá recorrer parte de ese camino que nos separa de esa meta.

No lo es. El problema consiste en no tener en cuenta la naturaleza adaptativa del proceso de desarrollo de software o que si bien, no se ha tenido en cuenta, no se plantee una renegociación del alcance del proyecto entre cliente o proveedor o se compense económica ese esfuerzo de más que se va a echar.

Lo ideal es que todas las partes tengan en cuenta que el desarrollo de software no es un proceso predictivo, lo que obliga a hacer cambios a lo largo del desarrollo y además pueden ocurrir contingencias que rompan los planteamientos iniciales.

¿Cómo se tiene en cuenta? Pues teniendo en cuenta en el proceso de presupuestar proyectos esta circunstancia. Generalmente se presupuesta pensando en que todo va a ir bien o dando un cierto margen por encima en el caso de que haya incertidumbre. Y lo peor de todo no es eso, sino que por regla general no se tiene previsto que después el producto hay que mantenerlo y que eso ocurrirá siempre (será poco o mucho lo que haya que ir adaptando, pero lo que es cierto es que ocurrirá).

Una vez que los presupuestos tienen en cuenta que un proyecto de desarrollo de software es de naturaleza adaptativa el siguiente paso es aplicar una metodología que se adapte a ello porque si bien con dinero suficiente se reducen los problemas, la utilización de una metodología adecuada permite optimizarlo, lo cual redunda en el beneficio de todas las partes, el cliente porque tendrá más margen de adaptación, el proveedor porque tendrá más controlado el proyecto y el usuario final porque progresivamente tendrá un producto que se aproxime más a sus necesidades.