archivo

Archivos diarios: noviembre 26, 2011

No podemos hablar de incertidumbre en el proceso de desarrollo de software, de la necesidad de aplicar estrategias basadas en enfoques iterativos incrementales, de la necesidad al fin y al cabo de adaptarnos a los cambios que pueden provocar esa incertidumbre si entendemos nuestro propio proceso de desarrollo como algo rígido, como algo no negociable.

La aplicación de una estrategia de desarrollo debe tener unos mínimos básicos que se vayan cumpliendo en el propio proceso de desarrollo, de lo contrario no habría estrategia, ni línea base sobre la que trabajar, de manera que pueda ser flexible cuando convenga que sea y si fuera necesario.

Sobre esto Tom DeMarco y Timothy R. Lister comentan lo siguiente: “El peligro de los procesos estándar es que la gente pierda la oportunidad de tomar importantes atajos”.

Una reacción desgraciadamente demasiado habitual es la huida hacia adelante ante situaciones de crisis o ante la detección de que se materialicen a corto/medio plazo riesgos que pueden poner en peligro el proyecto.

Huir hacia adelante es una manera de evitar las consecuencias de tus actos, de tus decisiones, hoy, esperando que en el futuro se pueda enderezar el rumbo del proyecto (casi nunca se consigue si se mantienen las mismas decisiones, estrategias y tácticas que han dado lugar a la situación actual) o que de tiempo para poder huir antes de que todo se colapse (aunque parezca difícil hay quienes salen indemnes de todo esto y dejan su maravilloso legado para que sean otros los que continúen con él).

En la gestión de proyectos, hay que tomar decisiones, nos podemos equivocar, podemos acertar, pero no debemos empeñarnos en continuar por un camino que no termina de ofrecernos buenos resultados, ya que seguir por ahí lo único que hará será empeorar la situación del proyecto. En nuestra responsabilidad se encuentra asumir los errores propios de nuestro trabajo y tomar las medidas oportunas para que de manera efectiva se invierta la situación en la que se encuentra el proyecto y si eso no es posible, por lo menos paliar los resultados del mismo.

Tom DeMarco y Timothy Lister realizan la siguiente reflexión donde consideran que (traducción libre): “la primera regla de la mala gestión consiste en que si algo no funciona, continuar con ello”.

Desarrollar y/o mantener un sistema de información con deuda técnica y con funcionalidades que se utilizan residualmente o no se usan es lo habitual, ahora bien, el problema lo tenemos cuando una de esas dos variables (o las dos) son importantes respecto al tamaño del sistema de información (estoy generalizando, ya que a veces, para provocar problemas no se requiere que tengan un valor excesivamente importante).

Trabajar de esa manera es como correr con una carga en la espalda, exige más esfuerzo y nos alejará de las marcas que nos permitiría alcanzar nuestro estado de forma, por tanto, reduce las expectativas de resultado que puede obtener el equipo de proyecto, la evolución del sistema se hace más lento y el coste económico es mayor.

Un tipo de proyecto muy frecuente es la migración de grandes sistemas de información a nuevas tecnologías o soluciones que se consideren más adecuadas o más apropiadas, o bien que sea consecuencia de la falta de soporte de algún elemento base para el funcionamiento del mismo.

Estos proyectos son tremendamente delicados ya que, tras ellos, se encuentra la gestión de una serie de procesos de negocio, generalmente críticos, dentro de una organización.

Un error típico en este tipo de proyectos se encuentra en pensar que la mayor parte del problema está resuelto, ya que se trata de trasladar el negocio de una tecnología a otra y no es así:

– Los procesos de negocio están vivos y pueden cambiar durante el desarrollo, por lo que es necesario gestionar esta situación.
– Es posible que la migración tecnológica se aprovecha para hacer cambios funcionales sobre las especificaciones del producto origen o para ampliar o reducir su alcance.
– El funcionamiento de la organización es dinámico y esto no solo afecta a los procesos, también a las personas, esto implica que cambios de personal en el proyecto pueden provocar diferentes visiones sobre la solución, funcionalidades o gestión.
– Las prioridades pueden cambiar.

A lo anterior hay que sumar el riesgo que supone la adopción de una tecnología nueva para gestionar estos procesos de negocio. Los usuarios pueden estar acostumbrados a un rendimiento, disponibilidad, respuesta al cambio, usabilidad, etc…, que la nueva solución está por ver si cumple o que tal vez cumpla, pero de otra manera.

¿A dónde quiero ir? Pues que la migración de estos sistemas debe realizarse de manera paulatina, lo que dará lugar a la convivencia del antiguo sistema y el nuevo durante un período de tiempo. Esta convivencia también es un problema, pero minimiza riesgos.

Por tanto, el enfoque iterativo incremental, reduce riesgos, ya que permite ir acomodando la nueva solución a las expectativas del usuario y detectar de manera temprana decisiones erróneas en cuanto a tecnología, arquitectura, etc… y se limitan los procesos que se pueden ver afectados por una interrupción del servicio.

Recuerdo hace más de un año cuando me estuvieron informando de un modelo orientado a procesos en el desarrollo de software que se estaba estudiando implantar en una serie de organizaciones que compartían un determinado sector de actividad.

Lo primero que me llamó la atención es que el marco no fuera un modelo que fuera internacionalmente reconocido y que a partir de ahí se definieran procesos asumibles para las organizaciones, sino que se tratara de un modelo híbrido de modelos de procesos de esas características con algún que otro ingrediente exótico.

Esto y reinventar la rueda es lo mismo, bueno no, es reinvertar la rueda pero pinchada.

Quiero aclarar que estoy a favor de que cada organización implante el modelo de procesos que considere más conveniente porque no hay que olvidar que el mejor modelo de procesos es aquel que te funciona. en el caso que comento se trataba de trasladar un modelo común de funcionamiento a una serie de organizaciones de manera que se armonizasen sus actuaciones en materia de desarrollo de software y ese modelo común no tomaba de base un conocimiento en profundidad de la problemática real de los proyectos que se realizaban en las mismas ni de su contexto organizativo, de personal y presupuestario, es decir, se trataba de un modelo que venía desde fuera, con conocimiento parcial de lo de dentro, que no se aplicaba en quien lo promulgaba y para dotarlo de cierta relevancia se asociaba a determinados procesos de modelos reconocidos internacionalmente.

Pero ahí no quedaba la cosa, cuando se exponía el contenido de los procesos me sonaba todo a ciencia ficción. No porque lo que se contara no fuera la solución más óptima (en algunos casos podría ser discutible si lo era o no) sino porque no se podía aplicar en el contexto de las organizaciones a la que estaba dirigido porque en primer lugar requeriría un cambio cultural en la misma, desde la alta dirección hasta la base y un contexto económico y presupuestario distinto.

Como decía antes, el mejor modelo de procesos es el que te funciona y puedes además mejorar, pero para ello la base es que tanto el modelo inicial como los diferentes modelos objetivos que se planteen en el proceso de mejora continua sean asumibles, de lo contrario se abandonan o se pervierten.

Casi todos o todos los que nos dedicamos a esto hemos visto o participado en proyectos que terminan en un cajón (ya sea porque nunca terminaron de ponerse en marcha o porque fracasaron a las primeras de cambio), desgraciadamente es una constante para los que nos dedicamos a esto negocio.

Y no son solo los millones y millones que se han tirado a la basura, sino también lo es el esfuerzo, los malos momentos y el desgaste sufrido en los mismos por parte de las personas que han intervenido en él, eso no lo paga el salario que se percibe.

Cuando un proyecto termina en un cajón las miradas y responsabilidades se centran en el equipo técnico del proyecto (tanto del cliente como del proveedor). Independientemente de que en ocasiones esa mirada y esas responsabilidades estén bien dirigidas, generalmente son el resultado de la falta de valor por asumir que has sido parte o todo el problema y es que está claro, sueldos de seis cifras son muy bonitos como perderlos. Como además, quienes cobran ese dinero están en una situación de poder y están más cerca del que todavía tiene más poder que ellos, estás vendido ante su juicio sumarísimo.

Estoy seguro que muchos menos proyectos terminarían en un cajón, si todos los stakeholders se hicieran responsables de verdad de su correcto desempeño y cuando digo de verdad es que no sean simplemente nombres que aparecen en un acta de constitución o en reuniones de seguimiento semestrales, sino que se impliquen y no se pongan de perfil al entender que su único cometido ha sido poner el dinero o recibirlo.

Hacerse responsables significa tomar decisiones, orquestar tareas y asumir consecuencias dentro de tu ámbito de actuación, cualquier otra cosa no le podemos llamar responsabilidad.

Bajo ese marco, en el que todas las partes reconozcan y se responsabilicen de verdad en que el único fin es que el proyecto cumpla las expectativas puestas en él, es en el que se puede empezar a trabajar en el proyecto con empate a cero en el marcador. Bajo otras circunstancias, el partido comenzará con derrota en el marcador y tocará remontar, lo mismo en un entorno hostil, con diez jugadores y árbitro en contra.