Jummp’s Blog

Un día un proveedor de software me dijo: “tío, esto de la informática es un marrón, a mi hermano cuando toca la sirena y sale de la fábrica, cierra página y hasta el día siguiente, mientras que nosotros siempre tenemos el duendecito detrás de la oreja recordando que hay que hacer tal o cual entrega, que el proyecto va retrasado, que hay que intentar conseguir ventas…”.

La verdad es que el proveedor tenía toda la razón del mundo, independientemente de que este hecho no es exclusivo de la profesión informática, ni le sucede a todo el mundo que se dedica a la informática.

En el sector de la informática en el que trabajo, que es el desarrollo de software, sucede demasiadas veces que aunque tu trabajo sean las horas que sean, la cabeza siempre anda dando vueltas con aquella incidencia que no te ha dado tiempo de resolver o que todavía no has conseguido saber cómo se resuelve o en todas las tareas que tienes que hacer y que crecen por encima del tiempo que existe para resolverlas.

A mi me pasa mucho, demasiado, lo que acabo de comentar, lo cual no es positivo, ya que por un lado empuja a dedicar más horas al trabajo, genera inquietud y además la mente no se termina de despejar, algo que es fundamental para rendir bien al día siguiente.

¿Es fácil desconectar? Depende exclusivamente del individuo ya que en las farmacias no venden ningún jarabe para la desconexión y en nosotros está la solución al problema, no obstante pese a que sepa donde está la clave no debe resultar demasiado sencillo desencriptarla ya que somos muchos los que nos cuesta cambiar de contexto y guardar en un cajón hasta el día siguiente las tareas relacionadas con el trabajo. En cualquier caso y aunque no sea simple, hay que esforzarse por intentar desconectar, ya que resulta tremendamente beneficioso para nosotros mismos e incluso para el trabajo, ya que nos permite ser mucho más productivos.

Me comenta un amigo que acaba de comenzar un proyecto en otra Comunidad Autónoma que el cliente le ha dicho que el objetivo principal del mismo es que su organización a nivel de desarrollo de aplicaciones evolucione de un nivel de madurez A a un nivel de madurez B, siendo B>A. No obstante, pese a perseguirse ese objetivo, el proyecto se basa en la realización de una serie de actuaciones sometidas a acuerdo de nivel de servicio y penalizaciones en el caso de incumplimiento de los mismas.

Es decir se va a penalizar si se incumple en tiempo, forma y calidad esas actuaciones, las cuales vistas de cerca, se lleven a cabo correcta o incorrectamente no tendrían que provocar un impacto positivo o negativo en el nivel de madurez del proceso de desarrollo de la organización. Y este precisamente es el peligro principal que tiene la consecución del objetivo principal.

Que el objetivo principal sea que la organización evolucione a nivel de desarrollo de software no quiere decir que se olviden los distintos objetivos parciales. De hecho será fundamental que estos objetivos se cumplan para llegar al objetivo final porque de lo contrario los problemas que tendrá la ejecución del contrato serán tales que se invertirá el esfuerzo en apagar fuegos que en dar ese paso adelante que se pretende.

La mejor forma de ir a por el objetivo final sin perjudicar a los objetivos parciales es incluir en los procesos de desarrollo aquellas variables que permitan conseguir la mejora esperada, teniendo en cuenta que hay que tener paciencia porque los objetivos a medio/largo plazo, son eso, objetivos a medio/largo plazo y que por tanto no se pueden conseguir ni en un día, ni en un mes y que hay que ser constante, tampoco vale de nada hacer un esfuerzo durante seis meses si después se abandona.

La inclusión de dichas variables llevan consigo un overhead, sobre todo al principio, ya que hay que acostumbrarse a una nueva forma de hacer las cosas, no obstante, ese sobreesfuerzo que se requiere irá disminuyendo conforme se pase de la adaptación al hábito. Es posible que ese sobreesfuerzo nunca sea igual a cero, será cuestión en este caso que cliente y proveedor analicen la conveniencia en base a un retorno de la inversión futuro de tener en cuenta este aspecto en la valoración de los desarrollos parciales.

La consecución de los objetivos parciales no asegura el cumplimiento del objetivo principal (aunque como comenté anteriormente la no consecución de los mismos muy probablemente traerá consigo la no consecución del objetivo principal). Como es lógico llegar a tener éxito en los objetivos parciales proporcionará satisfacción al cliente, ¿lo suficiente cómo para que este olvide la no consecución de un objetivo principal? Dependerá del cliente, ya que se ha demostrado efectividad para cumplir el trabajo que se genera en el día a día, pero no en conseguir lo realmente difícil que es cumpliendo con los objetivos parciales colaborar en que el proceso de desarrollo en una organización evolucione positivamente.

Hace unos días hice una prueba en uno de los sistemas de información que están bajo mi responsabilidad y que había comenzado el proceso de construcción pocas semanas antes. Dicha prueba consistió en que tanto el arquitecto Java de mi departamento como uno de los integrantes de la Oficina de Calidad revisaron junto a técnicos de la empresa desarrolladora, tanto la arquitectura que iba a tener la aplicación, la implementación elegida en los distintas capas de la misma, ejemplos significativos de clases que tuvieran ya construidas y el fichero pom.xml.

Es cierto que la revisión de la arquitectura y de la implementación elegida en cada capa se debería haber realizado antes de iniciarse la construcción, pero la ventaja de utilizar un libro blanco de desarrollo en la organización, que dicho documento sea de uso obligatorio y que indique con claridad qué arquitectura utilizar y qué posibilidad de implementación hay de sus distintos niveles, da bastante tranquilidad en este aspecto. Además, antes de iniciarse la construcción recalqué al proveedor el marco de desarrollo base que tenía que tomarse como referencia.

La revisión permitió detectar algunos aspectos en la construcción que hacían la aplicación menos mantenible y por tanto corregirse a tiempo para que el resto del proceso tuviera en cuenta esas políticas, lo cual llevará consigo que cuando la aplicación se entregue tendrá una mayor calidad.

La política que había empleado en mis aplicaciones hasta ahora es que la Oficina de Calidad interviniera a partir de la entrega del producto (ya sea de uno nuevo o de una evolución del mismo), esto permite detectar y corregir errores funcionales y no funcionales, pero corregir, cuando se producen, malas prácticas de programación o la no adecuación al libro blanco de desarrollo es tan costoso en este punto, que la mayoría de las veces no se actúa contra ellas, salvo que afecte al funcionamiento, rendimiento o seguridad de la aplicación.

También aproveché para que la Oficina de Calidad tuviera la oportunidad de conocer de qué iba el sistema de información, ya que la mayoría de las veces se enteran cuando se le entrega el producto final. En este caso, dada la complejidad del mismo, creí conveniente que cuanto antes empezasen a conocer las características del sistemas, más fácil iban a tener después la comprensión del mismo y de la documentación del proyecto una vez realizada la entrega.

La experiencia ha sido muy positiva y pienso aplicarla a partir de ahora en todos los desarrollos que estén bajo mi responsabilidad ya que estoy seguro que va a incrementar la calidad de los productos que se entreguen y el mayor conocimiento por parte de la Oficina de Calidad del sistema de información le permitirá ser más preciso en la realización de las pruebas del sistema de información e incluso en la revisión del plan de pruebas antes de ser entregado.

No existen recetas mágicas. La gestión y el propio proceso de desarrollo de software no se rige por ninguna ley universal. La algorítmica es matemáticas, pero todo lo demás es la suma de una infinidad de variables, lo que hace que los resultados no sean siempre todo lo previsibles que serían deseables.

Por este motivo lo que sí existe en el mundo del desarrollo de software y de los servicios TIC son un conjunto de buenas prácticas que si se implementan y adaptan (las buenas prácticas son genéricas y necesitarán además de una correcta ejecución, su correspondiente particularización a la naturaleza del proyecto y de todo el entorno que interviene en el mismo) convenientemente dentro del ámbito de una organización o de un proyecto de desarrollo de software producirán en la mayoría de los casos, unos resultados aceptables, ya que éstas proceden de la experiencia.

Por tanto, los proyectos software (y en general la mayoría de los proyectos TIC) dependen de una gran cantidad de factores para que tengan éxito, no existen recetas mágicas y para contrarrestar esta inestabilidad existen existen buenas prácticas, además de la propia experiencia de los gestores del proyecto por parte del cliente y el proveedor, del equipo de proyecto y de las organizaciones implicadas.

Dado que no existen recetas mágicas, lo que ha funcionado para un proyecto concreto no tiene por qué funcionar para otro, aunque sea similar, ya que son multitud de variables las que intervienen. Es muy importante ser consciente de esto, ya que es un riesgo intentar aplicar soluciones sin tener en cuenta el tipo de cliente, el equipo de proyecto que va a participar, el conjunto de usuarios, los gestores, etc…

Hace unos meses un usuario se puso en contacto conmigo para intentar resolver un problema que consistía en que tenían una base de datos Access que se mantenía en una determinada provincia y tenía intención que la información la mantuvieran empleados de más de una provincia.

La base de datos Access se encontraba en una unidad de red en la provincia donde se estaba trabajando. La solución que adoptamos fue persistir la información en una base de datos Oracle centralizada (que es nuestro sistema de gestión de base de datos corporativo) y utilizar Access como interfaz donde los usuarios puedan interactuar con los datos.

El motivo de utilizar esta solución fue la necesidad de encontrar una solución en cuestión de muy poco tiempo (ya que era necesario y urgente que otras provincias empezasen a trabajar con el programa cuanto antes) y con el menor esfuerzo posible (todavía había opciones que hubieran llevado menos tiempo y menos esfuerzo, pero no estaba dispuesto a que se prescindiera de utilizar el sistema de gestión de base de datos corporativo). Es decir, se trataba de una solución provisional, ya que con el paso del tiempo, la información almacenada en la base de datos se migrará a un sistema de información corporativo.

Con el paso de los días y una vez ejecutado el trabajo, llegué a la conclusión de que la decisión que tomé no fue acertada por diferentes motivos:

1) Pese a que es una solución provisional, se prevé que el tiempo que van a estar trabajando con la misma puede ser amplio y si tiene aceptación pues todavía puede que se alargue más en el tiempo.

2) Esta solución provisional no se adapta a la estrategia de desarrollo y mantenimiento de aplicaciones de mi organización, basado en el uso de la tecnología Java (y dentro de ella en una determinada arquitectura) y si estamos intentando migrar lo que no tenemos en Java a esta tecnología (y por supuesto, desarrollar todo lo nuevo en la misma), flaco favor estoy haciendo si admito una solución que no se adapta a la estrategia corporativa.

3) Como consecuencia de que la estrategia de desarrollo y mantenimiento sea Java, los técnicos y asistencias técnicas que tenemos en plantilla y externalizadas están especializados en esa tecnología y no en otro tipo de soluciones.

Si la solución provisional se convierte en definitiva tendremos que realizar más pronto que tarde una migración de la aplicación a tecnología Java, no obstante el problema no es ese, ya que no se trata de un problema complejo, el problema está en que si el usuario tiene resuelto su objetivo no será para él tan prioritario (es más, no será nada prioritario) realizar una inversión para realizar la migración.

Todos los clientes y todos los proveedores no son iguales, esto implica que sea complicado encontrar una fórmula que funcione en todos los casos. No obstante, lo que voy a indicar a continuación es mi visión ante una circunstancia que pasa muy a menudo y que desde mi punto de vista se puede resolver de forma muy sencilla.

Pasa muchas veces que el cliente solicita al proveedor la realización de una serie de tareas ya sea de manera verbal o a través de un correo electrónico y el proveedor queda “indefinidamente” en silencio mientras realiza la tarea (o mientras no la realiza). Al no recibir respuesta o comunicación por parte del proveedor, el cliente (como por otra parte resulta lógico) tiende a mosquearse, ya que piensa que están pasando de lo que ha solicitado, cuando lo mismo el proveedor está totalmente implicado en la realización de la tarea. Es decir, a los clientes nos gusta saber, ¿cómo va lo mío?.

Este posible malentendido se soluciona si el proveedor, mientras realiza la tarea (y sobre todo si la misma dura más de una semana) se pone en contacto con el cliente ya sea verbalmente o por escrito indicando cómo lleva la realización de la misma. Con eso, el cliente se sentirá tranquilo en cuanto a que sabe que lo que ha pedido se está atendiendo. Otra cosa será si se retrasa sistemáticamente la tarea, si esta se entrega incorrectamente, etc…, pero eso son otros problemas y no el que estoy analizando en el presente artículo.

Se ha vuelto a plantear la situación de que un determinado desarrollo no iba a estar para la fecha estimada. Mirándolo por el lado positivo se ha detectado la desviación con tiempo. También el retraso tiene cierta lógica ya que los plazos inicialmente planteados eran demasiado optimistas para un proyecto con la complejidad de este.

Cuando hay que tomar la decisión sobre retrasar la entrega de un producto (siempre que se pueda retrasar, ya que en ocasiones tiene que estar en una fecha sí o sí (compromiso de la organización, por la publicación de una determinada normativa, etc…), lo primero que hago es sopesar si realmente el retraso está justificado, es decir, si con los recursos destinados al proyecto es posible terminarlo en la fecha objetivo (no entro a valorar si el retraso pudo haberse evitado, eso es otro aspecto que es necesario tratar con el proveedor del servicio, con los usuarios o con ambos, pero que para mi es independiente de la decisión de si retrasar la entrega o no), si no es posible terminarlo en la fecha planificada, mi recomendación es buscar una nueva fecha más realista porque al final si se aprieta excesivamente y se exige la entrega en la primera fecha, en el caso de que el proveedor consiga llegar a la misma, muy probablemente sea a costa de la calidad del producto final y lo más probable es que no sea queriendo, sino simplemente porque es imposible hacer magia en el desarrollo de software y si se acortan los plazos, dará menos tiempo a revisar el código, a probar, a pensar soluciones más eficientes y crecerá la posibilidad en que se caigan en malas prácticas de programación con tal de avanzar más rápido.

¿Qué pasa si tampoco se llega a la nueva fecha? Estaríamos en una circunstancia similar a la anterior, ¿es esto dar carta blanca al proveedor? tampoco es eso, todo tiene sus límites y evidentemente si la culpa de los retrasos es achacable al mismo debe tener sus consecuencias, por tanto ante cada situación como digo siempre, hay que aplicar el sentido común y pensar en la solución que más convenga a la misma y por tanto habrá circunstancias donde sea factible seguir retrasando la entrega y en otras donde se decida que tras uno o varios retrasos la fecha que se establezca sea inamovible.

Más de una vez he comentado que a toda empresa de desarrollo de software le conviene tener alianzas con otras empresas del sector y con otras de fuera (hay proyectos mixtos), ya que andar siempre sólo es complicado en un mundo tan competitivo como este. Estas alianzas se pueden traducir en acuerdos y colaboraciones de todo tipo, pero no todo debe valer con tal de conseguir una alianza porque si hay algo peor que ir sólo es ir con malas compañías. A veces se conoce antes y se puede evitar la alianza y en otras te das cuenta después cuando el que se supone aliado se convierte en tu enemigo.

Evidentemente más vale tarde que nunca en darse cuenta, pero por regla general las alianzas que no funcionan terminan siendo tremendamente negativas sobre todo en aquellas donde la apuesta fuerte la hace tu organización y no la otra.

De todos es sabido que cuanto antes se solucione un problema en un proyecto de desarrollo de software, menos coste tiene para el mismo y de ello salen beneficiados tanto proveedor como cliente.

Por ese motivo resulta esencial que un proyecto sea sólido desde la base, siendo la misma el análisis funcional, lo que hace que sea muy importante la figura del analista que es la persona o grupo de personas (si el proyecto es grande) que se tienen que encargar de entender, interpretar y traducir lo que el usuario demanda, sentando las bases de los posteriores procesos de diseño y construcción del sistema de información.

Hacer un buen análisis es una tarea bastante compleja, ya que resulta muy complicado obtener todos los requerimientos del usuario desde etapas muy tempranas, ya que por regla general el usuario empieza a descubrir el detalle de todo lo que quiere cuando empieza a utilizar el producto ya construido con ejemplos reales de su día a día de trabajo (también suelen comentar nuevos requisitos o enmendar requisitos previos, en otras etapas conforme se le vaya presentando la evolución del proyecto, de hecho no es malo que se corrijan, ya que cuanto más avanzado esté el proyecto, el esfuerzo de hacer los cambios es mucho mayor). De hecho es prácticamente inevitable no hacer evolutivos que solventen esos flecos que no se detectaron en análisis para dejar el producto lo más próximo posible a lo que los usuarios necesitan y demandan. Como consecuencia de lo anterior, y como es lógico, se puede considerar que un análisis funcional es más bueno conforme sea menor el número de ajustes que haya que hacer en etapas posteriores del proyecto.

Es importante matizar que un proyecto de desarrollo de software no es una barra libre y que es importante que el usuario conozca sus responsabilidades en el proceso de definición del sistema y que no se pueden estar cambiando de requisitos continuamente, como tampoco podría estar cambiando frecuentemente de opinión si le están construyendo una casa. Todo lo anterior además hay que compatibilizarlo con que todas las partes están interesadas en el que el proyecto vaya a buen término, por lo que tampoco es una buena política ser inflexibles en la modificación del catálogo de requisitos, porque si el resultado final no es el que quiere el usuario, el sistema de información tendrá muchas papeletas para no ser utilizado. Equilibrio complicado: evitar que los usuarios modifiquen continuamente requisitos y tener un poco de mano izquierda cuando se planteen esos cambios. Como ese equilibrio es complicado de mantener y es fuente frecuente de conflictos, hay que intentar que el análisis tenga la mayor calidad posible.

Hacer un análisis funcional por tanto es una tarea compleja, a lo que hay que sumar que en muchos casos hay que aprender mucho sobre el proceso de negocio que se pretende informatizar, para entender de mejor manera lo que el usuario demanda, ya que resulta todo más fácil si el lenguaje que se utiliza es el mismo. En muchas ocasiones esos procesos de negocio son tremendamente complejos y además se dispone también de poco tiempo para entenderlos, teniendo en cuenta que por regla general y como he comentado muchas veces en mi blog, los proyectos informáticos suelen estar infravalorados (por el que contrata y/o por el que es contratado (para conseguir el contrato)).

Dado que el análisis funcional consiste en abstraer un conjunto de necesidades de los usuarios es muy importante la implicación de los mismos y eso no siempre se consigue. Si los usuarios no están implicados, por muy buen analista funcional que tenga el proyecto, las probabilidades de que este salga mal crecen exponencialmente. Evidentemente un buen analista puede paliar esos huecos que deja el usuario e incluso conseguir una mayor participación de los usuarios, pero más tarde o más temprano los problemas aparecerán y al final siempre termina pagando el proyecto (en primera instancia) y el que lo desarrolla (en segunda). Por todo lo anterior, se puede pedir que un analista funcional aprenda un proceso de negocio complejo, que consiga extraer de los usuarios lo que buscan y necesitan y que además lo haga en un tiempo record, pero lo que no se le puede pedir es que haga magia y resuelva problemáticas que le trascienden, como el caso que he comentado de la inacción de los usuarios en determinados proyectos, siendo esa falta la implicación la primera causa de que un análisis no salga bien y por tanto una de las causas más importantes del fracaso de un proyecto y no se trata en este caso de tirar pelotas fuera y ponerme del lado de mis colegas de profesión, se trata de algo que he podido vivir en diferentes proyectos de manera muy directa.

Nadie es infalible y un analista funcional tampoco lo es. Habrá errores (independientemente de que la causa de los mismos sea provocada por circunstancias adversas en el proyecto o no), puede que en este proyecto sean muy pocos y que en otros sean mayores, por eso es importante que el analista lo tenga asumido desde un principio, como también lo es que de esos errores se debe aprender y que resultarán fundamentales en la formación del mismo. Al final esos errores terminan curtiendo y permiten que cada vez los análisis que se realicen sean mejores. Por tanto, la experiencia resulta importante. En cualquier caso, suponer un análisis perfecto es suponer que en un proyecto se dan circunstancias ideales y que todas las variables que pueden influir en que las cosas vayan mejor o peor, están todas a favor.

De todo lo comentado en los párrafos anteriores se extrae que es importante que un analista funcional sea un buen comunicador, primero con el usuario ya que resulta fundamental que el usuario conozca todo lo que hemos entendido y cómo se pretende llevar a cabo (no conseguir eso es ir a ciegas) y segundo con el equipo de proyecto ya que tiene que trasladar a documentación y hacerles entender la interpretación de lo que el usuario quiere y cómo lo quiere.

Un buen análisis funcional no asegura el éxito del proyecto, ya que la ejecución técnica del mismo también tiene un peso importante, pero lo que sí es seguro es que si el análisis funcional no es bueno, la ejecución técnica difícilmente puede salvar las deficiencias del mismo y tocará corregir el producto una vez construido y además, por regla general, en diferentes evoluciones, lo cual es muy costoso y tampoco asegura que ese árbol que empezó torcido, termine por enderezarse.

Otra de las cosas que he aprendido en estos años, todavía escasos, de experiencia profesional, es que la Ley de Murphy castiga sin piedad a los proyectos de desarrollo de software en cualquiera de sus ámbitos (desarrollo, gestión, etc…) y quien piense lo contrario que recuerde todas aquellas demos donde todo parecía controlado y algo fallaba (no necesariamente el sistema de información que se iba a enseñar).

Por ese motivo, intento que en la medida de lo posible queden en los proyectos los menores cabos sueltos posibles, ya que una cadena es tan fuerte como su eslabón más débil. El hecho de intentar no dejar cabos sueltos, no quiere decir que no se sea consciente de que siempre se quedarán algunos sin atar, algunos de forma inconsciente y otros por no haber sabido detectarlos o haber tomados decisiones equivocadas. Lo importante de todo esto es que si se está en la mano resolver un problema en un proyecto, la decisión más adecuada desde mi punto de vista no es huir hacia adelante sino resolver el problema (independiente de que sea costoso o complejo) porque tarde o temprano pasará factura.

En cualquier caso, tampoco es conveniente tomar eso como una regla general sin pensar en las características del proyecto que se está desarrollando (técnicas, económicas, temporales, etc…), porque en un mundo tan complejo como el desarrollo de software, siempre habrá excepciones y circunstancias donde la solución más lógica no es la más adecuada o donde la solución que funciona en muchos casos no funciona en un proyecto concreto. Por tanto es importante siempre minimizar el número de cabos sueltos, resolverlos lo antes posible cuando son detectados y aplicar siempre el sentido común a la hora de priorizar la resolución de problemas y la propia evolución del desarrollo.