Jummp’s Blog

Hace unas semanas tuve una reunión con un proveedor de software en la cual, entre otros temas, hablamos de una serie de evolutivos que había que hacer sobre un producto software que se había puesto en producción dos meses atrás. El proveedor me comentaba que si dedicabamos presupuesto a realizar esos evolutivos, podríamos quedarnos sin presupuesto para el desarrollo de algunos de los sistemas de información que estaban programados y que formaban parte de ese contrato (la famosa teoría de la manta: que si te cubres los pies te dejas la cabeza al aire y si te tapas la cabeza lo que dejas al aire son los pies).

Mi respuesta fue que dada la buena acogida que había tenido la aplicación entre los usuarios, que lo que habían solicitado no era algo desproporcionado en esfuerzo y además iba a permitirles mejorar la eficiencia y experiencia en el uso de la aplicación, se desarrollasen los evolutivos.

El motivo es que la aplicación es una realidad, ha pasado el durísimo proceso de desarrollarse e implantarse y además los usuarios se están adaptando a la misma, las otras aplicaciones son importantes también que se hagan, pero hasta el momento son proyectos, llegado el momento, si hiciera falta, se reduciría el alcance de alguna de ellas para que entrase en presupuesto, pero que lo importante es dejar la aplicación que se ha puesto en producción perfectamente rematada.

Algunos de los sistemas de información que gestiono dependen para su funcionamiento de su interacción con otros sistemas de información y componentes software. El problema con el que me estoy encontrando es que conforme se incrementa el número de elementos externos de los que depende más complicado me está resultando mantener un nivel de disponibilidad óptimo de los sistemas.

La explicación es sencilla, si la funcionalidad completa de la aplicación requiere de que otros n componentes software o sistemas de información funcionen a su vez correctamente, conforme ese n sea mayor, más posibilidades habrá de que alguno tenga algún problema e impacte sobre el sistema que interectúa con ellos. Y además hay que tener en cuenta otros factores que todavía complican la situación ya que cada uno de esos otros sistemas o componentes pueden necesitar la colaboración con otros sistemas para proporcionar su funcionalidad a lo que hay que sumar que además para que funcionen todo ese software serán necesarios a su vez otros tipos de software como servidores de aplicaciones, servidores de bases de datos, etc…, además de que toda la electrónica de red funcione adecuadamente. Es decir, al final, para que un sistema medianamente complejo funcione al 100% es necesario que otra cadena de elementos funcionen a su vez y puedo asegurar, por mi experiencia, que es difícil de mantener el equilibrio en la torre de naipes y que se producen, en demasiadas situaciones, circunstancias que afectan a la disponibilidad del sistema de información.

La solución más simple es que cada sistema sea una isla independiente con una infraestructura independiente (esto es un esquema de funcionamiento extremo, aunque hay otras combinaciones que pueden ser válidas para esta filosofía de funcionamiento), pero eso no es una solución, ya que aunque puede proporcionar una mayor disponibilidad a los sistemas, requiere mayores costes de mantenimiento de infraestructura (aunque siempre, y para ser justos, hay que valorar que cuesta más si estos costes adicionales de infraestructura o la pérdida de disponibilidad) y sobre todo tiene el inconveniente de que la información permanece aislada y no vinculada con terceros sistemas, lo que dificulta una visión, integración y una explotación global de la información, algo que no es natural al funcionamiento de una organización, donde los departamentos no son estanco, sino que por regla general para funcionar necesitan información de otros procesos de otros departamentos. Otro inconveniente es que el aislamiento de la información provocará muchas situaciones en las que se duplique, triplique, etc… un mismo tipo de datos, lo que dará lugar a incoherencias en los mismos, lo cual en muchas situaciones puede ser fuente continua de problemas al impedir incluso que exista una visión común sobre una determinada característica de la información. Por todos estos inconvenientes, no comparto una política de desarrollo basada en el aislamiento de sistemas que aunque permite afrontar con menos problemas el día a día, a nivel táctico y estratégico terminará haciendo aguas.

Por tanto y en base a lo anterior, se tiene que tender a buscar la interoperabilidad entre sistemas de información y componentes, pero para que la disponibilidad de los sistemas se vea afectada lo menos posible es necesario que se den una serie de premisas:

- Que la infraestructura hardware, software de base, software servidor y de comunicaciones sea lo más estable y óptima posible.
- Que los sistemas de información y componentes software (estando en este último grupo sistemas horizontales de servicios como por ejemplo, plataformas de firma y autenticación electrónica, gestores documentales, motores de tramitación, generadores de plantillas e informes, generadores de formularios, etc…) se encuentren lo más estables posibles y los cambios que se produzcan en los mismos provoquen el menor efecto posible tanto en el propio sistema como en el conjunto de sistemas con los que se comunica.
- Que se reduzca en lo posible el acoplamiento entre sistemas de información para evitar situaciones de pérdida de disponibilidad por efectos colaterales en los cambios que se produzcan en los mismos.

Evidentemente conseguir los tres factores que acabo de indicar (hay algunos más) resulta prácticamente utópico y de ahí los problemas de disponibilidad que nos encontramos con entornos de estas características. Que diga que es utópico no digo que sea imposible, pero el proceso para conseguirlo requiere un nivel importante de madurez en la organización en general en lo que a la gestión TIC se refiere (y digo en la organización, porque ésta debe ser consciente de la importancia de las TIC en su funcionamiento y que la gestión de las mismas debe planificarse con el mismo nivel de atención que cualquier otro proceso de la organización y que hay que dedicarle la atención y presupuesto acorde a lo crítico que resulta que esta actividad se ejecute correctamente) y además que los departamentos TIC y los sistemas de información alcancen también ese nivel de madurez. Para adquirir esos niveles se requieren tiempo, esfuerzo, dinero y paciencia. La principal ventaja es que si se consiguen alinear estos factores veremos cómo lentamente se van mejorando los resultados, pero mientras tanto toca sufrir en el día a día, los múltiples fuegos que provoca esta manera de concebir la estrategia de sistemas de información de una organización.

Aunque para muchas personas los conceptos sean iguales, para mi no lo son y voy a tratar de exponer las diferencias en este post.

Un jefe de equipo, lleva la gestión ordinaria de un equipo de trabajo (pudiéndo ser un componente más del mismo, como por ejemplo el analista funcional principal del proyecto): gestión ordinaria del equipo de trabajo, entre las que se encuentra el reparto y supervisión de las tareas, la resolución de cualquier conflicto que pueda haber entre los recursos, la solicitud de personal de apoyo, la sustitución de algún miembro del equipo por otro, la evaluación del rendimiento y productividad, además de poder llevar la interlocución con el cliente para la gestión de la demanda de tareas, etc…

Un jefe de proyectos (que a su vez puede ser jefe de equipo), además de lo anterior, debe ser el encargado del control de costes del proyecto, del cumplimiento de los hitos que se marquen, que se cumplan los estándares de calidad de la empresa y el cliente, de la renegociación con el cliente de los plazos, requisitos del proyecto, resulución de conflictos con el cliente, interlocución con los niveles superiores jerárquicos de la empresa, tener una visión más horizontal de lo que es la empresa, con el objeto de reutilizar trabajos, conocimientos, etc… de otros proyectos que se estén ejecutando o se hayan ejecutado, etc… en el caso de que sea necesario y además deben tener en primer o en segundo plano una visión comercial (de la misma manera que es importantísimo llevar un control de costes del proyecto es muy importante que tengan en la cabeza el concepto de continuidad, ya que si un jefe de proyectos desea mantener su equipo y que no se reparta entre otros proyectos necesita que exista trabajo asignado a los mismos, por no decir, que si desea seguir dirigiendo proyectos, es necesario que existan proyectos que dirigir).

Es decir, si un jefe de equipo tiene ya metido los pies en el fango y tiene ante sí una gran responsabilidad, que no es nada más ni nada menos que el proyecto vaya hacia adelante, el jefe de proyecto está lleno de barro hasta las rodillas, ya que es el que debe dar la cara con el cliente por un lado y por otro dar la cara a sus superiores en la empresa, además de realizar una supervisión general del proyecto, recibir las demandas del jefe de equipo y participar en la vida comercial de la empresa (elaboración de ofertas, creación o búsqueda de necesidades que pueda tener el cliente, negociar pagos adicionales si el proyecto ha superado el alcance inicial, etc…).

Como he comentado anteriormente un proyecto no tiene por qué tener jefe de proyecto y jefe de equipo, ya que una misma persona puede desempeñar ambas funciones, dependerá mucho de las características del proyecto y de cómo se organice la empresa.

Una de las cosas que he aprendido en mi todavía corta experiencia profesional es la importancia de dar las gracias y de pedir las cosas por favor.

Decir ambas cosas de forma oral o por escrito no implican esfuerzo y sin embargo los beneficios que se obtienen con ellas son muy importantes, en primer lugar porque de esta forma se valora y se respeta un trabajo que solicitas que se haga y por otra se valora y se respeta el resultado del mismo y desde mi punto de vista el respeto genera respeto, algo que considero muy importante.

Por ese motivo cada vez uso más ambas expresiones, aunque reconozco que todavía, en bastante ocasiones olvido utilizarlas y no porque no agradezca un trabajo bien hecho, sino porque tal vez son demasiados años en que no he utilizado ambos términos de manera suficiente, un error del que afortunadamente me he percatado.

Una cosa que he aprendido desde que comencé a trabajar es que la productividad crece si se consiguen introducir períodos de descanso y de desconexión a lo largo del día y de la semana. He tardado mucho en aprender la lección y todavía sigo cayendo en muchas ocasiones en el error de no parar y tener siempre en la cabeza tareas que tengo pendientes de realizar o problemas sobre los que hay que intentar buscar una solución. Cuando esto sucede la culpa es exclusivamente mía, aunque mi profesión dificulte en demasiadas ocasiones el proceso de desconexión.

Es necesario para poder renovar las ideas y para fomentar la creatividad tener períodos de descanso, no puedo dar una fórmula sobre cuando es más apropiado tomar esos descansos, ya que cada persona es un mundo y conoce cuáles son sus límites y cuáles son sus necesidades. Acumular horas y más horas de trabajo sin dedicarnos un mínimo de tiempo, termina tarde o temprano pasando factura y cada vez se es menos productivo debido al cansancio y porque el trabajo cada vez más genera más ansiedad y menos satisfacción.

Es cierto que no siempre somos dueños de nuestro tiempo y que las circunstancias laborales y el entorno pueden provocar que buscar esos oasis de tiempo sea complicado, pero aunque sea difícil necesitamos buscar ese resquicio de aire fresco que proporciona descansar y desconectar, ese oasis permitirá que al ser más productivos y saber valorar mejor el tiempo, se consiga cada vez encontrar con más facilidad ese paréntesis tan necesario para cada uno de nosotros.

La respuesta a muchos problemas que se presentan en el trabajo se resuelven a partir de la creatividad, si ésta se ve anulada por el cansancio quiere decir que no seremos capaces de resolver esos problemas, que los resolveremos peor o que tardaremos más en resolverlo, lo que a su vez genera más trabajo y se cae en un círculo vicioso de difícil salida. Si echar más y más horas no permite salir de esta laberinto, ¿por qué no probar a descansar y desconectar un poco más y ver cuáles son los resultados?.

Dentro del proceso de aprendizaje uno de los factores más importantes son los errores, siempre y cuando se sea consciente y se admita la equivocación (si se ha fallado y no se admite, no se habrá aprendido nada).

De la misma forma que nosotros nos equivocamos (y nos equivocamos todos, algunos con más frecuencia y otros con menos, porque nadie es infalible), tenemos que admitir que los demás, nuestros compañeros, nuestros superiores y las personas que están a nuestro cargo se equivoquen. Evidentemente ni todos los errores son iguales ni tampoco puede haber barra libre, el umbral estará en el impacto del error, en el número de errores previos, la responsabilidad de la persona en el mismo y el puesto que ocupe dentro de la organización.

Siendo conscientes de la existencia de límites si queremos que nuestro equipo de trabajo evolucione, hay que darle la oportunidad de que además de desempeñar su trabajo habitual asuman decisiones, realicen tareas de una complejidad mayor a las que venían realizando y/o efectúen actividades complementarias. Estos saltos, estas salidas de la rutina generarán sin dudas errores y equivocaciones, pero hay que entender que éstos son consecuencia de una evolución normal del personal en la organización y ya es tarea de los responsables de dichas personas impedir el error antes de que se produzca o paliar los efectos si no se detecta a tiempo. Si no se permite esta evolución por miedo a los errores se estará tirando, desde mi punto de vista, piedras contra nuestra propio tejado, ya que la experiencia también se mide en responsabilidades y en vivencias y si nuestro equipo de trabajo no las tiene, está condenado a madurar mucho más lentamente, a acomodarse y a tener menos posibilidades de crecimiento en la organización, ya que se tenderá a buscar en el mercado lo que no se ha podido generar dentro de la misma y en mi opinión debe existir un equilibrio entre los fichajes (muchas veces necesarios y otras porque el mercado permite acceder a un recurso o a unos recursos muy valiosos) y la promoción interna del personal, ya que si los trabajadores ven pocas posibilidades de evolucionar, surgirá desmotivación y una reducción de la productividad, además de una posible marcha de algunos de ellos buscando otras alternativas.

Todo lo que sea huir de métodos artesanales en los procesos de desarrollo de software supone tiempo y dinero o lo que es lo mismo dinero y dinero.

1) Intenta que todos los desarrollos de la empresa sigan un mismo framework siempre que sea posible (en ocasiones las imposición de una determinada arquitectura o tecnología por el cliente lo impide, pero en el resto de casos, siempre que se pueda, haz uso del framework). El framework además es recomendable que esté recogido en un libro blanco de desarrollo (que va más allá del framework, lógicamente) y mantener ese libro blanco actualizado. Este framework único facilita la movilidad de los programadores entre proyectos y la mantenibilidad de los sistemas. No tengas miedo en actualizar el framework o el libro blanco, si aparece o encuentras alguna librería, componente, arquitectura, etc… mejor que la que usas, más estable, más robusta y/o que te permite una mayor productividad no dudes en cambiar el framework, eso sí, debe hacerse con prudencia y con un espacio de tiempo razonable entre cambio y cambio.

2) Intenta que el framework se base en estándares.

3) Si además del framework base, se tienen componentes software concretos y completos que resuelven problemáticas cada uno de ellos en diferentes tipos de proyectos, mejor que mejor.

4) Si se tienen productos completos que simplemente requieren su personalización en función del cliente, todavía mejor.

5) Siempre se habla de reutilizar código, pero si se consiguen reutilizar requisitos de proyectos o lo que es lo mismo la experiencia, también resulta de gran importancia. Para esto hay que documentar y establecer mecanismos que permitan localizar en la documentación de proyectos lo que se quiere y de esta forma obtener conocimiento.

6) La documentación de los proyectos queda obsoleta por la evolución de los mismos y resulta muy costosa mantenerla, por lo tanto, lo mejor es tener poca documentación pero buena y mantenerla actualizada. Por otro lado, toda aquella documentación que se pueda automatizar bienvenida sea y toda aquella documentación que se pueda sustituir mediante la aplicación de ingeniería inversa sobre cualquiera de los elementos del programa, sustitúyase.

7) Si existe software de gestión de versiones, MAVEN y herramientas software para definir entornos de integración continua, utilícense. Eso sí, bien. De nada te vale tener los fuentes en SVN si no tienes una buena política de etiquetado, de nada te vale usar MAVEN si no estrujas su potencial para automatizarte tareas, etc…

Independientemente de que se definan buenas prácticas hay que verificar que se siguen. Si puedes ten uno o más arquitectos que vayan sondeando el estado tecnológico de cada proyecto.

9) Ten documentado como es el proceso de implantación de software en tus clientes, permitirá ahorrar mucho tiempo.

10) Nunca es una pérdida de tiempo cada minuto que dediques a probar la aplicación antes de entregarla al cliente.

Otro error muy común en el proceso de desarrollo de software (y en el que yo también he caído) es olvidar que el producto que se está implementando no es para nosotros sino para el usuario final e independientemente de que tengamos la sensación de que conozcamos perfectamente lo que quiere el usuario o que dominamos la materia, tenemos que buscar hasta donde sea posible la implicación del usuario, no solo durante el proceso de definición del sistema, sino durante el proceso de construcción.

Si los que nos dedicamos al desarrollo de software, que ya tenemos una cierta experiencia en abstraer problemas, nos encontramos con dificultades en numerosas ocasiones para llevar a un programa de ordenador un determinado proceso y nos damos cuenta muchas veces cuando se está construyendo que hay piezas que no encajan, ¿podemos pedir al usuario que tenga esa misma capacidad de abstracción?, algunos pensaréis: “era obligación del usuario leerse el análisis”, ¿de verdad pensáis que el usuario puede llegar mucho más allá del análisis de requisitos, de la descripción de casos de uso, de la revisión de las interfaces de usuario y su navegación?, salvo que el sistema no sea excesivamente grande, que los entregables que acabo de indicar se realicen de la forma más completa, exacta y clara posible, y que el usuario se esmere en repasarlos (y aún así), quedarán resquicios que cuanto más se tarden en corregir más costosos serán para el desarrollador.

Lo que acabo de comentar en el párrafo anterior no es un vale todo para el usuario, es decir, éste debe asumir su responsabilidad en el proyecto y de alguna u otra forma se lo tenemos que hacer ver. El desarrollo de software no se hace con una pizarra y una tiza, donde se puede borrar y volver a escribir libremente, es un proceso tan complejo en el que no vale la barra libre. Lo que vengo a comentar es que en el desarrollo de software se debe ser consciente de que cuanto más se tarde en detectar un error más vale corregirlo y que los usuarios en la mayoría de los casos no toman conciencia del programa y de los problemas hasta que se enfrentan a él. Como podéis ver se trata prácticamente de dos extremos, de hecho cuanto peor se hagan las cosas (por parte del desarrollador y del usuario (por no hacer frente, este último, a su responsabilidad)) se cumplirán ambos extremos, lo que provocará que el proyecto salga caro (lo cual puede repercutir sobre el usuario o sobre el desarrollador (más bien, sobre este último)) y que la calidad del mismo se vea muy perjudicada.

Por tanto, es importante que no olvidemos que las aplicaciones se desarrollan para los usuarios y que por tanto hay que buscar la mayor implicación posible por parte de los mismos en todo el proceso de desarrollo de software. ¿Qué el usuario no se implica? Hay que intentar que siempre quede patente este hecho (evidentemente hay que saber hacerlo con tacto), ya que más adelante si el proyecto no ha salido como debía y hay que empezar a parchear, que todo el gasto de ese parcheo no repercuta directamente sobre el desarrollador.

Desde hace años tengo la práctica de anotar las tareas que tengo pendientes de realizar y reconozco que a día de hoy no podría trabajar de manera adecuada sin hacer uso de esa técnica.

¿Qué me aporta?

1) Recibo peticiones de diferentes personas y temáticas, las cuales en su mayoría requieren un tiempo moderado para su realización. La anotación de las mismas permite, reducir el riesgo de que se me olvide hacer algunas de las tareas y me permite priorizarlas.

2) Tener las tareas anotadas y poder verlas en su conjunto favorece el proceso de priorización que he comentado en el punto anterior y además simplifica la agrupación de tareas y la reflexión sobre las mismas, lo que permite tomar mejores decisiones sobre las mismas.

3) La anotación de tareas y la señalización de las que están hechas, es un elemento de motivación muy importante.

4) Disminución del tráfico mental. Si tengo la tarea anotada, disminuye o desaparece la necesidad (sensación) de tener que recordar que hay que hacerla, ya que si se olvida está registrada en un sitio que voy a mirar seguro.

Me he referido en este post a lo que es el hecho de anotar las tareas sin indicar qué instrumento utilizar para realizar dichas anotaciones, ya que entiendo que lo importante es el hecho de la anotación en sí, por encima de la herramienta que se utilice, aunque el uso de una herramienta adecuada puede hacer todavía más productivo si cabe el proceso de la anotación de tareas.

En mi caso utilizo un método un tanto rudimentario, como es un cuaderno. He hecho algunas pruebas con algún software pero no han sido positivas por falta de disciplina por mi parte, ya que como me muevo mucho, me resulta mucho más cómodo anotar las tareas en mi cuaderno y no tener que trascribirlas a continuación a una aplicación. En cualquier caso reconozco que tengo que evolucionar en este sentido e ir más allá al uso del cuaderno, pero independientemente de eso, también tengo que reconocer que desde hace mucho tiempo, el uso del cuaderno me ha traído muy buenos resultados.

Otro aspecto que considero también importante es el repaso semanal de las tareas pendientes, ya que favorece esa visión global de las tareas que comenté anteriormente y por consiguiente ayuda a la priorización, agrupación y reflexión sobre las mismas.