Jummp’s Blog

Una de las pesadillas de las empresas de desarrollo de software es la confusión (queriendo o sin querer) que existe en muchas casos entre los conceptos de mantenimiento correctivo y evolutivo. ¿Por qué pesadilla? Porque la garantía de los desarrollos afecta sólo a los mantenimientos correctivos y por tanto no se facturan y en muchas ocasiones se “cuelan” evolutivos como mantenimientos correctivos y se convierte en trabajo adicional para las empresas, no previsto y que en muchas ocasiones requiere un notable esfuerzo y que, por supuesto, no se cobra.

Un mantenimiento correctivo es aquel que tiene como objetivo solventar una deficiencia en un componente del sistema de información (puede ser software o documental). Entiéndase deficiencia como algo que debería funcionar o estar correcto y que no lo está.

Un mantenimiento evolutivo es aquel que pretende modificar algo que funcionaba o estaba correcto, con el objeto de aumentar, disminuir o cambiar las funcionalidades del sistema, ya sea por las necesidades del usuario o por otras causas como pueden ser, por ejemplo, cambios normativos.

El problema está en la definición de qué es lo que debería funcionar o estar correcto en el sistema de información, es decir la delimitación clara de la frontera entre el correctivo y evolutivo. Y no es algo que esté nada claro en muchos casos, ya que por ejemplo, eso que esa funcionalidad que dice el cliente que debería estar y no contempla el programa, ¿es algo que se ha sacado ahora de la chistera o realmente se contempló en la definición y análisis del sistema de información?, ¿es algo que no se ha interpretado correctamente en el análisis?, ¿es algo que se suponía que se podía extrapolar del análisis aunque no aparezca explícitamente?.

Es cierto que hay muchos casos que las incidencias son de cajón y son correctivos y en la mayoría de las situaciones no dan problemas ni para el cliente, ni para el proveedor, que será consciente que son fallos suyos y los solucionará. También es cierto que hay evolutivos que son muy complicados de colar como correctivos, ya que una cosa es que la pared tenga que estar pintada de blanco o de color crema, que el pomo de la puerta sea plateado o dorado o que incluso el suelo sea de marmol o porcelánico y otra que te intenten comprar un piso de cuatro dormitorios por el precio de uno de un dormitorio. Sin embargo entre un caso (correctivos claros) y otros (evolutivos claros) hay todo un abanico de posibilidades que la mayoría de las veces dan lugar a conflicto (estos serán menos si el presupuesto del proyecto es holgado, el cliente es bueno, el proyecto se trata de una inversión para intentar conseguir más negocio con el cliente o a través del producto que se ha desarrollado, etc…).

Como ya he comentado en algún artículo en caso de conflicto casi siempre tiene las de perder el proveedor y lo más importante es tener asumida esa circunstancia. Eso no quiere decir que se deba decir a todo que sí, pero es más fácil negociar si no se pierde el tiempo en intentar remar a contracorriente.

Habrá negociación porque en los proyectos de desarrollo de software suelen cometer fallos las dos partes cliente y proveedor. Por esta razón siempre digo que las dos partes deben ser flexibles, ya que todos cometemos errores y además la naturaleza de los procesos de desarrollo de software no es rígida, sino en sí, un proceso evolutivo.

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.

Se puede ser un técnico o un gestor excepcional, contar con una gran bagaje profesional o poseer un altísímo cociente intelectual, pero difícilmente se pueden conseguir los objetivos sin la ayuda de tu equipo de trabajo.

Yo soy totalmente consciente que todos aquellos logros profesionales que he tenido hasta ahora y los que tendré en un futuro son gracias al trabajo del conjunto de personas que colaboran conmigo en los proyectos. Me refiero sobre todo a aquellas personas más próximas que, compartan o no mis decisiones, las respetan e intentan aportar siempre de forma constructiva y contribuyen con su esfuerzo que, va más allá del dinero que cobran, a que todo vaya hacia adelante.

Los equipos no se deben medir por lo que sucede en un día o en un proyecto concreto, sino que se tienen que valorar con el tiempo. En los equipos entran y salen personas, pero mantener el núcleo de personas que proporcionan ese valor añadido y en las que se puede confiar resulta fundamental, ya que cuando más difíciles se pongan las cosas son los que estarán contigo para sacar las castañas del fuego.

A los equipos hay que cuidarlos y eso se consigue tratándolos de manera justa y dando la cara por ellos cuando sea necesario. Esto no quiere decir que no se les exija, sino que exista una correspondencia y comprensión por el esfuerzo y por el trabajo que se realiza.

Si ya es difícil llevar a cabo un éxito un proyecto de desarrollo de software en el que existen dos partes (direccion técnica y proveedor o usuarios y proveedor) o tres partes (usuarios, dirección técnica y proveedor), nos podemos imaginar todos lo complicado que resulta su ejecución si en el proceso de desarrollo hay todavía más implicados.

De ellos los más complicados son aquellos en los que participan n organizaciones distintas, con proveedores, usuarios y direcciones técnicas diferentes, en los que además no existe una dirección común del proyecto que vaya estableciendo las directrices del mismo y solventando los distintos problemas que se puedan producir a lo largo de su ejecución. No obstante, cualquier combinación menos compleja que esta, incluso existiendo una dirección única, da lugar a proyectos con una gran dificultad de llevarse a cabo con éxito.

En este tipo de proyectos considero fundamental que exista de manera estable (lo cual no quiere decir que de vez en cuando no existan los típico tiras y afloja) una relación profesional y de respeto entre todas las partes, es decir, debe haber mucha mano izquierda, paciencia, diálogo e intentar resolver los malos entendidos cuanto antes, además es muy importante entender que además de este proyecto las diferentes partes participarán en otros, por lo que las prioridades, capacidad de absorver trabajo, etc… existentes en cada momento para cada uno de ellos pueden no ser coincidentes. Lo importante es que se consiga avanzar aunque sea muy lentamente por voluntad de los distintos participantes que intentar ir más deprisa forzando a parte de ellos, ya que lo mismo se consigue dar un paso hacia adelante y dos hacia detrás.

También es muy importante que cada parte tenga claro qué tareas tienen asignadas en cada momento y a ser posible que las mismas estén recogidas por escrito, además de existir reuniones periódicas en las que haya representantes de todos los implicados con capacidad de decisión.

Todo esto favorecerá el trabajo en equipo y que se reme en una sola dirección. Evidentemente estas no son soluciones magistrales, sólo son buenas prácticas. En cualquier caso si una o varias de las diferentes partes no quieren colaborar, por muy buenas artes que se intenten utilizar para atraerlas al proyecto, será complicado, por no decir prácticamente imposible (sobre todo si la parte o partes que no tienen voluntad de colaboración tienen que producir resultados o proporcionar información fundamental para la realización del mismo) que se llegue a buen puerto.

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 realicé un análisis sobre las variables compromiso y talento en los empleados de una organización.

En este post voy a introducir una variable más: el hambre. Entendiéndose el hambre como la ambición por conseguir objetivos personales.

Un ejemplo de todo esto lo podemos ver en el fútbol, donde muchos equipos que han conseguido títulos tienden a renovar parte del equipo, porque saben que además de la calidad y el compromiso de los jugadores necesitan ese empujoncito de más, ese Kers, que dan las ganas de conseguir las cosas, esas ganas que hacen meter el pie y arriesgar.

El hambre es una variable complicada de controlar, ya que los trabajadores que la tienen salvo que estén comprometidos con la causa, tenderán a ser complicados de retener si ven que no consiguen sus objetivos personales (lo podemos ver también en el fútbol), además, por regla general, serán trabajadores muy exigentes consigo mismos y con los demás, sean superiores, iguales o si tienen personas a su cargo, ya que tendrán siempre sus objetivos entre ceja y ceja y si esta exigencia no viene de la mano con una suficiente mano izquierda o se tiene la experiencia necesaria para saber controlarla, se producirán problemas que pueden resultar más negativos o menos productivos que si esa persona con hambre no estuviera en la organización.

Por tanto, los trabajadores con hambre son complicados de manejar, lo cual no quiere decir ni que sea imposible o que todos los casos puedan controlarse. No obstante, entiendo que es bueno y favorable que haya personal con hambre en la organización, porque la ambición en su justa medida permite conseguir metas que no serían posibles de otra manera (o por lo menos tardarían mucho más en lograrse). Como es lógico, la productividad y control de estas personas depende muy mucho de cómo sus superiores sepan tratarlos y obtener de ellos el máximo rendimiento posible.

No hay que confundir, desde mi punto de vista, el deseo de mejorar y superarse en la organización (lo cual es siempre positivo y necesario) con el hambre ya que ésta va un poco más lejos y más deprisa.

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.

¿Qué cualidad prefieres en un empleado?, ¿Compromiso o talento?.

Por mi forma de ver las cosas, no existen solo los tonos negros y blancos, sino que entre ellos existen una gran gama de grises, es decir, cuando tratamos de personas es difícil centrarse solo en valores extremos, ya que cada persona es un mundo complejo. Por tanto y llevando esto a una escala, cada persona tendrá un valor de 0 a 100 en la variable compromiso y otro en la misma escala en la variable talento.

Resulta evidente, en base a lo anterior que la situación ideal es una persona con la máxima puntuación posible en compromiso y talento y que la peor es el caso contrario. También es complicado encontrar ambos extremos (sobre todo en el de máximo compromiso y talento), aunque haberlos, los hay.

Quitando dichos casos, lo realmente complicado está en valorar más el talento o el compromiso. Habrá muchos que estéis pensando, ¿por qué hay que valorar uno por encima del otro? La respuesta que yo daría es que en primer lugar lo que hay valorar son aspectos objetivos y no son otros que los resultados que cada empleado ofrece a la organización, teniendo en cuenta las características de los proyectos en los que han participado y esos resultados se pueden obtener con compromiso, con talento o con ambas cosas. Pero no hay que olvidar que esa valoración mide el pasado (lo que se ha hecho) y no el presente y el futuro.

Y teniendo en cuenta ese aspecto, presente y futuro es por lo que valoro más el compromiso que el talento, sin olvidar que el compromiso sin el nivel suficiente de talento es como un vaso sin agua (lo mismo que al reves, es tener agua sin vaso) y que es fundamental para que una empresa progrese y subsista, existan personas con el talento suficiente (sea o no con compromiso) para marcar esa diferencia necesaria con los demás competidores y sean la chispa necesaria para que la organización siga avanzando.

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…

Ya he comentado en diversas ocasiones la necesidad de ponerle fechas a los objetivos y a los trabajos, porque de lo contrario se corre el riesgo de que la ejecución de determinadas tareas se conviertan en eternas, ya sea porque se tengan aparcadas (si no hay fechas siempre saldrán otras trabajos más prioritarios con duración determinada que provocarán que se retrase indefinidamente la realización de las que no tienen fechas) o porque se reduzca el ritmo (al fin y al cabo no hay presión por tenerlas listas). No se trata de crear presión, sino de marcar una línea de meta.

También es importante tener en cuenta que el objetivo no es poner fechas por ponerlas, sino de intentar que las mismas sean los más objetivas posibles al tipo de tarea que se va a realizar y a las características del equipo de trabajo a las que se les ha encargado. Otro aspecto que se debe tener en cuenta es la posibilidad de flexibilizar las fechas establecidas, cuando exista un motivo que lo justifique, realizándose en este caso la pertinente replanificación.

Si las tareas son de menor alcance, es decir, tareas secundarias o menos relevantes, todavía se corre más riesgo que caigan en el olvido si no se establece una fecha para tenerlas listas.

En ambos casos (tareas más relevantes y tareas secundarias), cuando se encargan a equipos de proyecto, no simplemente establezco una fecha, sino que además (siempre y cuando la tarea tenga un cierto alcance) convoco al responsable del equipo a la que la he encargado para que me muestre los resultados, de esta forma no sólo me suelo asegurar no sólo que no se olvide su ejecución sino que probablemente consiga que se mejore la calidad del resultado, ya que al fin y al cabo alguien da la cara por el trabajo realizado.

¿Todas las tareas deben tener una fecha? En el caso de que un grupo de tareas puedan agruparse en otra de índole superior, se podría perfectamente tomar como referencia esta agrupación, también puede haber otras tareas que no tengan ningún tipo de prioridad a las que tampoco haría falta poner fecha (cuando haya un hueco y si se puede, se hacen), etc… Dependerá mucho del gestor la forma en que se organiza el establecimiento de los plazos, en cualquier caso es importante que se tenga en cuenta que poniendo fechas, por regla general se consigue un mayor control de los distintos trabajos y tareas que se ejecutan.