archivo

Archivos diarios: febrero 1, 2012

En el artículo “¿Qué es un proyecto?” daba una posible definición de los mismos (una de entre otras tantas que se podía aplicar):

“Conjunto de actividades planificadas en el tiempo (su realización, por tanto, es gradual) que tienen como objetivo producir unos resultados (entregables) en base a los objetivos para los cuales se constituyó… Un proyecto, por tanto y por definición, debe ser finito”.

Vamos a ver si existe algún conflicto con un desarrollo iterativo incremental.

– Actividades planificadas en el tiempo.

Cada iteración está planificada en el tiempo, incluso podría establecerse una planificación inicial basada en una visión optimista de que nada va a cambiar durante el desarrollo, que no se va a producir ninguna contingencia o que siempre se va a acertar. Ahora bien, dicha planificación general debería adaptarse al feedback que se obtenga del usuario en cada ciclo, no hacerlo es atentar contra el cumplimiento de las expectativas del usuario que no es otra cosa que el fin último del proyecto.

– Producir unos resultados (entregables) en base a los objetivos para los cuales se constituyó.

Esto es lo que puede crear algo más de controversia, si bien la misma controversia que puedes aplicar a un desarrollo iterativo incremental la puedes aplicar a un desarrollo en cascada que muchos consideran el paradigma de lo debe ser un proyecto.

La controversia la podemos tener en el hecho de si realmente los entregables obtenidos entre el inicio y el fin del proyecto cumplen con los objetivos que dieron origen al mismo.

Si entendemos como objetivo la obtención de una aplicación que satisfaga las expectativas del usuario (o del cliente) en base a las especificaciones que se hayan podido implementar entre un inicio y fin pactado de un proyecto (en el siguiente punto, vemos esto de manera más concreta), el conflicto lo podemos encontrar no tanto en el nivel de acabado del producto sino en el cumplimiento de las expectativas, las cuales pueden ser satisfechas o no independientemente de la metodología o ciclo de vida aplicado.

Si no se ajustan dichas expectativas (que evolucionan desde los objetivos iniciales) a un final pactado del proyecto en función de su presupuesto, plazos y contingencias que se produzcan en su desarrollo, es cuando los proyectos parecen eternizarse o no tener fin.

Por tanto al final, la consideración de si los entregables del proyecto satisfacen los objetivos iniciales, es más cuestión de sentido común aplicado al contexto del proyecto que otra cosa (por eso, porque es cuestión de sentido común y de ética, existen tantos problemas a la hora de determinar un cierre de proyecto y esto es aplicable tanto a clientes como proveedores).

– Finito. Lo son. ¿Qué delimita el inicio y el fin? Posibilidades tenemos muchas, unas más objetivas que otras:

Si tomamos como base un presupuesto de partida, el inicio es el momento en que empezamos a consumir el mismo y el final cuando lo hemos agotado. Si hay un incremento sobre el presupuesto de origen, una segunda fase del proyecto (que en realidad es un nuevo proyecto) vendría delimitado de la misma forma por el inicio y fin de ese presupuesto adicional y así sucesivamente.

Otra posibilidad es tomar como referencia la entrega de un producto final que satisfaga las especificaciones del usuario, independientemente de que algunas hubieran cambiado desde la definición del alcance del proyecto (pudiendo haber diversas entregas intermedias que pasen a producción que satisfagan determinadas funcionalidades).

Ambas posibilidades, que son dos ejemplos posibles de delimitar un principio y un fin del proyecto son perfectamente compatibles con un enfoque iterativo incremental.

Por encima de todo lo importante es que si tienes implantada una gestión de procesos, sea efectiva y te funcione. Eso es lo principal, de nada vale ser ortodoxo si después la solución hace aguas.

Ahora bien, si se quiere implantar una gestión orientada a procesos, ya sea desde cero o a partir de una gestión parcial que cubre algunos de ellos (sea efectiva o no), mi recomendación es que utilicemos como referencia un estándar, siempre y cuando la organización pueda obtener un beneficio competitivo en base a las ventajas que voy a indicar a continuación (así como su adecuación al propio tamaño y mercado objetivo de la organización).

Para empezar nos evitamos reinventar la rueda y aprovechamos la experiencia acumulada que supone un estándar. Además, En muchos casos los estándares establecen básicamente líneas base que desarrollas y adaptas para tu organización (evitando de esta forma el antipatrón “martillo de oro“).

Otra ventaja del uso de estándares es que el cumplimiento de nuestros procesos supone una referencia para posibles clientes, ya que estarán auditados, supervisados o certificados por un tercero independiente y los efectos de la aplicación del estándar sobre el funcionamiento de la organización serán conocidos (por toda la bibliografía y experiencia acumulada a lo largo de los años en entidades que lo utilicen).