archivo

Archivos Mensuales: marzo 2012

En el desarrollo de software hay una circunstancia paradójica, mientras que el universo digital que se implementa en cada software está compuesto finalmente por unos y ceros, el conjunto de relaciones entre las personas que participan en el proyecto funcionará mejor cuanto más alejada se encuentre su percepción y sus opiniones de valores extremos, olvidando toda la gama de posibilidades que hay en medio.

Son tantas la variables que intervienen en el proceso de desarrollo, son tantas las que definen un contexto que limitar las visiones de una situación a valores extremos no es algo objetivo, por mucho que creas que lo es. Lo más probable es que no hayas reflexionado lo suficiente y/o no tengas suficiente información.

No quiero decir que no tengas la razón pero lo mismo no te has parado a analizar que pueden existir matices que hagan que tu opinión esté más fundamentada. A veces los matices no cambian lo sustancial pero otras veces son lo suficientemente significativos para que te permitan ampliar la comprensión de una situación y ser más receptivo a escuchar otros puntos de vista o entender determinadas explicaciones.

Anuncios

Los proyectos de desarrollo de software tipo “llave en mano” son una fuente continua de fracasos, salvo excepciones (que las hay), se salvarán aquellos proyectos en los que se haya acertado en su valoración, hayan tenido una cierta estabilidad en el desarrollo (sin cambios significativos en procesos, interlocutores, etc…) y en los que tanto cliente como proveedor hayan estado acertados y hayan colaborado en la consecución de un objetivo común que no es otro que desarrollar un sistema que satisfaga las expectativas de los usuarios.

Sin embargo, lo normal es que estos proyectos no vayan bien y terminen por dejar descontentos sobre todo al cliente, pero también dejarán descontentos a muchos proveedores, de los cuales algunos se sentirán así por no haber cumplido con las expectativas del cliente y otros porque el proyecto han tenido pérdidas (como he dicho en numerosas ocasiones, desgraciadamente un número significativo de proveedores les da igual el cliente y solo miran los números).

En este artículo no analizo quién es el principal culpable del fracaso (entre otras cosas porque eso es algo que habría que analizar caso a caso) sino en señalar como una de las principales causas el enfoque de proyecto llave en mano en el que se espera que a partir de una previsión inicial de coste, se haya acertado en la misma y que todo en el proyecto haya discurrido con normalidad para alcanzar los objetivos marcados.

Cuanto más grande sea el proyecto, más probabilidad existirá de que el coste estimado sea erróneo y que existan contingencias en el desarrollo que provoquen desviaciones.

Hay que tener en cuenta que un proyecto llave en mano el proveedor está vendido si el cliente así lo quiere, pero también lo está el responsable técnico del cliente ante sus usuarios. ¿Por qué está vendido? Porque si no se gestiona adecuadamente los costes de los cambios de especificaciones en el desarrollo, al final todo quedará en un montón de actas de reuniones, correos y conversaciones que no son más que papel mojado y palabras que no valen para nada.

¿Solución? Enfoque iterativo incremental con valoración y priorización de los diversos requisitos bajo un marco de actitud ágil.

El feedback y tener capacidad para dar respuesta rápida al mismo es esencial, como también lo es dividir el desarrollo del sistema en incrementos donde la capacidad de error en las previsiones se minimice. Por otro lado, se debe establecer un mecanismo en el que los usuarios sean conscientes del coste del cambio y hacerse responsables de ellos y en el que los proveedores se responsabilicen de su trabajo y se centren más en el producto y en el cliente que en salvar los números del proyecto.

Existen diferentes formas de implementar este tipo de solución, podéis tener más información en la serie de artículos que dediqué a la contratación ágil:

Contratación ágil I
Contratación ágil II
Contratación ágil III
Contratación ágil IV
Contratación ágil V

Poner en producción y de golpe un sistema de información de un tamaño medio/alto puede provocar una situación de crisis que acabe con el propio sistema.

A la oposición inicial que tendrá la nueva herramienta por el simple hecho de modificar hábitos ya adquiridos se le suma que, salvo que se haya acertado muy mucho en la fase de análisis, el proceso o procesos que se informatizan hayan permanecido estables y se tenga muy controlada la aplicación de los procesos entre quiénes trabajan en los mismos (algo que se complica cuanto más descentralizada es una organización), se empezarán a solicitar cambios de todo tipo en el sistema y probablemente se dispongan de pocos medios para ejecutarlos ya que el esfuerzo se habrá centrado en el desarrollo del producto.

En esta situación los usuarios empezarán a decir que el sistema no se ajusta a sus necesidades y se quejarán de que el tiempo de respuesta para realizar dichos cambios es muy alto, ejerciendo presión a sus superiores indicando que la disminución de su rendimiento y productividad es debida al sistema de información.

No entro a valorar el comportamiento de los usuarios ya que en cada caso su intención puede ser diferente, lo que sí entro a valorar es que resulta complicado dar una respuesta cuando se tiene que actuar sobre un sistema grande y no se disponen de los medios adecuados para llevar diversas líneas de trabajo en paralelo.

Por este motivo el enfoque iterativo incremental no solo me parece la respuesta más natural a las problemáticas del proceso de desarrollo, sino que también resulta la solución más adecuada a la hora de realizar la puesta en marcha de un nuevo sistema, ya que se encontrará acotado el posible marco de actuación a los diferentes módulos que se vayan liberando de manera que se puedan centrar los esfuerzos en ir mejorándolos o corrigiéndolos en base al feedback del usuario y de esta forma no tenemos que estar intentando sofocar más fuegos que los que realmente podemos tratar.

Soy muy exigente con el trabajo de las personas que tienen algún tipo de relación profesional conmigo y también lo soy con aquellas personas que de alguna u otra forma están a mi cargo, ellos lo saben.

Por ese motivo mi objetivo es intentar facilitar el trabajo de quienes colaboran conmigo independientemente de lo que eso suponga para mi, intentando además que la mayoría de las veces sea iniciativa mía. Cabría esperar que esta cadena siguiera hacia arriba, eso sería lo ideal, pero lo realmente importante es que el equipo que depende de cada uno pueda desarrollar su trabajo de la mejor manera posible.

No hace mucho un compañero me dijo que temía que yo pudiera reventar, yo le respondí que había algo peor que reventase yo y es que reventásemos los dos.

En una entrevista preguntaron a Steve Wozniak si en la actualidad su mente funcionaba como cuando tenía veinte o treinta años (hay que tener en cuenta que en el colegio midieron su cociente intelectual y se situaba por encima de 200) en los que fue referente para la construcción del Apple II considerado por muchos como el primer ordenador personal tal y como hoy lo conocemos (hay otros muchos candidatos a tener esa distinción y probablemente sean varios los que tengan ese honor, dependiendo del criterio que se tenga a la hora de definir el concepto de ordenador personal.

Desde mi punto de vista, es más que probable que Apple a día de hoy no existiera de no ser por el Apple II y no solo por ser el motor económico inicial de la compañía sino por el hecho de siguió siendo motor años después cuando los proyectos del Apple III y el Lisa fracasaron y el Mac no terminaba de arrancar.

A la pregunta Steve Wozniak respondió que su mente seguía funcionando de esa manera pero que realmente ya no tenía el tiempo y la energía para seguir creando y que centraba su esfuerzo en pequeños proyectos.

Wozniak con esta respuesta ha mencionado un aspecto fundamantal a la hora de sacar adelante un proyecto y no es otro que la energía y por extensión la motivación como motor generador de la mismas. Se puede tener un talento excepcional pero si no te sientes motivado no sacas proyectos adelante.

De ahí la necesidad de que existan líderes que sean capaces de obtener lo mejor de aquellas personas que todavía se sientan con la energia y motivación suficiente para seguir afrontando retos. Esto fue una de las principales virtudes de Steve Jobs.

Cuando se está realizando el desarrollo de un sistema de información o se están llevando a cabo actividades relacionadas con su mantenimiento es cierto que puedes tener un grupo de usuarios como referencia que han sido designados como responsables funcionales del sistema, sin embargo tu relación con el resto de usuarios que pueden ser perfectamente el 99% restante puede llegar a ser inexistente ya que se han añadido por medio diferentes capas que hace que no se interactúe con ellos: los propios responsables funcionales, el centro de atención a usuarios, herramientas para la recogida de incidencias, problemas, peticiones, consultas, etc…

Cuando un sistema tiene problemas, resulta muy cómodo tener todos esos filtros ya que evitas tener que escuchar todo tipo de quejas, algunas razonables, otras no, algunas realizadas con educación, otras sin ninguna, etc…, sin embargo este aislamiento de la realidad te está edulcorando la situación real del sistema por muy malas noticias que te vayan llegando respecto al mismo y por mucho que los usuarios de referencia se quejen de manera continuada.

Sé que te va a provocar desgaste, que vas a escuchar cosas que no te gustan, que vas a tener que aguantar como te echan la culpa de circunstancias que no han dependido exclusivamente de ti, pero es algo que al final vas a agradecer porque has podido pulsar en persona la realidad del sistema, una vez hecho eso, tu visión del sistema cambiará y pondrás los medios oportunos (si resulta posible) para que la siguiente vez que vayas a ver los usuarios empieces a notar un cambio en su opinión.

En más de un artículo he indicado la necesidad de que cuando se herede la gestión de un proyecto o de un sistema de información se haga un análisis lo más riguroso y objetivo posible del estado en que se encuentra el mismo y que el resultado del mismo sea informado a quiénes corresponda.

De la misma manera que todo aquello que sigas descubriendo lo sigas informando.

Esta es la mejor forma de aislarte de la historia del proyecto. Es posible que la herencia sea nefasta, es posible que tengas que sufrirla durante mucho tiempo, es posible que te señalen por resultados que no han sido provocados por ti, pero tu ya has informado de lo que has recibido, si alguien decide actuar contra ti después de conocer lo que te han dejado entre manos no es tu problema, el problema es tener a alguien en la organización que busque chivos expiatorios y decida hacer lo más fácil y lo más cómodo que no es otra cosa que echar la culpa al último que ha llegado al proyecto.

A veces necesitarás por propia higiene mental desahogarte con tu equipo (pero cuidado cómo te desahogas y el mensaje que das) pero no te puedes quedar atrapado en la historia del proyecto ya que mirar para atrás solo soluciona problemas si es para analizar qué es lo que se ha hecho mal y mejorarlo.

Yo me he lamentado muchas veces de problemas que me he encontrado con proyectos, unos provocados por terceros, otros por un determinado contexto y otros por errores míos en la gestión y os puedo asegurar que ninguno de esos lamentos ha solucionado ninguna incidencia o ha mejorado la experiencia de usuario y la productividad en el uso de la aplicación por parte de los usuarios.