Cosas a tener en cuenta en el despliegue de software

Yo no soy militar pero no me cabe ni la menor duda de que la logística es un factor clave para ganar cualquier guerra. El software también tiene su logística y es tan fundamental para conquistar un mercado como para ganar una campaña militar. El Software Libre consiste en gran parte una disrupción en la forma en que se distribuye el código. Afortunadamente ya no hay que distribuir el software en CD-ROM ¡o en diskettes! Mediante el SaaS ya no hay ni siquiera que distribuirlo en absoluto, pero hasta los SaaS archiconocidos tienen despliegues, los cuales son el tema de este post.

Lo primero que hay que entender acerca de los despliegues es que cada empresa tiene su propia metodología que es la mejor, para ellos. Es la mejor para ellos porque cada aplicación tiene sus propias peculiaridades y, por consiguiente, la metodología que es fantastica para una aplicación puede ser desastrosa para otra.

Estrategias de incorporación de mejoras

Existen a grandes rasgos tres estrategias de despliegue e implantación:

1ª) Desarrollar un núcleo de producto y hacer las adaptaciones a medida por fuera mediante plug-ins o kits de desarrollo.

2ª) Incorporar las funcionalidades de los clientes dentro del producto principal.

3ª) Ignorar por completo las demandas de los clientes y convencerles a ultranza de que usen el producto «tal cual» porque ello es lo que aportará mayor valor a sus procesos de negocio.

La viabilidad de cada una de estas estrategias depende del tipo de software y del número de clientes. Para software de gestión financiera, por ejemplo, la tercera puede ser una opción porque la contabilidad y las finanzas se manejan, en general, de forma muy similar en todas las empresas. Pero en cambio si se trata de un CRM es imposible fabricar un producto de «talla única» porque los procesos de venta de un sector vertical no se parecen en nada a los de otro.

El número de clientes también importa, una empresa que tenga una decena puede posiblemente permitirse ir incorporando todas las mejoras en el producto principal pero en una que tenga varios centeneres de clientes eso es imposible por tres razones: a) el elevadísimo número de programadores que se requeriría; b) el lio que se armaría al estar tocando el núcleo todos a la vez y c) la complejidad inmanejable que adquiriría la aplicación.

La estrategia de incorporación de mejoras determina la estructura que deben tener los equipos de desarrollo y servicios. Si hay un único producto en el cual se incorpora todo entonces no es necesario contar con un departamento de servicios de implantación pues es posible asignar a los programadores directamente a proyectos de clientes e ir rotándolos en funciones de análisis, codificación y soporte. Si no es factible incorporar todas las mejoras en el producto principal entonces se requiere una política de gestión de los productos derivados generados a la medida de cada cliente por un partner o un departamento de servicios internos.

Fases de la Implantación

Todas las metodologías de implantación tienen más o menos las mismas fases y hablan de las mismas cosas: de la importancia de realizar un buen análisis, de la gestión del cambio, etc. Tratan de aspectos generales y, como el demonio está siempre en los detalles, no es infrecuente que gerentes y usuarios en el cliente acaben hasta las narices del nuevo software de marras. La mayoría de las metodologías específicas de software son adaptaciones de otras más generales como DSDM, Prince2 o Metrica3 que a su vez están basadas en estándares como ISO/IEC 12207 o TOGAF.

Análisis de Requisitos

Tras el presupuesto que, curiosamente, en muchos casos se ha hecho antes que el análisis, empieza el análisis y modelado de requisitos. Las técnicas de modelado también puedes ser propietarias del fabricante como el Dynamic Enterprise Modeling de BaaN, SAP ARIS u Oracle AIM. Las técnicas de modelado son principalmente de cuatro clases:

• Modelado de datos.
• Modelado de funciones y procesos.
• Modelado de flujos de trabajo.
• Modelado de estructura corporativa.

Antaño se modelaban primero los datos y luego los procesos. Ahora está más de moda usar herramientas de definición de flujos de trabajo algunas de las cuales son tan modernas que hasta generan dinámicamente el modelo de datos que supuestamente debería haber por detras.

No hay espacio en un post ni tan siquiera para arañar la superficie de todas las metodologías de modelado que existen, pero aquí lo que me interesa no son sus entresijos sino cómo se aplican en la práctica.

El primer paso suele ser hablar con los usuarios. A fin de cuentas se supone que lo más importante son los usuarios ¿no? Pues bien, sucede muy amenudo que los usuarios no saben lo que quieren o, si lo saben, entonces son incapaces de explicarlo de forma estructurada para que un analista lo entienda. Muy pocos usuarios tienen metaconocimiento acerca de cómo hacen su trabajo. No es infrecuente que los usuarios pidan funcionalidades que a la larga irían evidentemente en detrimento de la usabilidad del software. En esencia de los usuarios quieren introducir y buscar datos de cualquier manera pero luego obtener resultados perfectamente precisos en los informes y flujos de trabajo a prueba de errores.

Resistencia al cambio

Tan pronto como se entablan los primeros contactos con los usuarios empieza la resistencia al cambio. Este es un fenómeno natural porque incluso aunque el nuevo sistema sea mucho mejor que el anterior y además funcione perfectamente, los usuarios, como mínimo, tendrán que aprender a manejarlo. Lo que yo he aprendido a lo largo de los años acerca de la formación a usuarios es más o menos lo siguiente:

1º) No importa cuántas veces se les explique a los usuarios la teoría sobre cómo funciona un sistema, hasta que no hagan algunos ejercicios no lo van a entender. Para aprender acerca de algo, la verdad no puede ser dada, sino que debe ser descubierta.

2º) Nunca hay que reunir a más de 8 o 10 usuarios en una sala a la vez. Si el grupo de alumnos es demasiado grande pueden sindicarse para atacar en bloque al formador.

3º) Empezar la formación de forma temprana, antes de que el software esté listo para salir a producción puede ser una buena técnica para detectar necesidades no descubiertas durante el análisis, pero cuidado, porque si faltan funcionalidades durante la formación los usuarios se pondrán nerviosos y extenderan por los pasillos rumores terroríficos acerca del nuevo software.

4º) El mejor estilo de documentación para usuarios me lo mostró un gerente de proyectos que conozco desde hace años, se trata del documento GUIABURROS. El guiaburros es un PowerPoint con poco texto que explica paso a paso cómo completar una o varias tarea. La clave para un guiaburros exitoso es aturullar lo menos posible al usuario con explicaciones conceptuales y llevarle directamente a la resolución de la tarea que tiene pendiente en ese mismo momento.

Y cuidado porque el hecho de que un sistema genere eficiencias en la producción no implica para nada que los usuarios vayan a verlo con buenos ojos. Conviene recordar que la palabra saboteador parece ser que proviene de aquellos obreros de la revolución industrial que metían zuecos en las máquinas para averiarlas en señal de protesta.

Validación y control de calidad en cliente final

Para poder cerrar un proyecto hay que conseguir una lista de procesos de negocio documentados, validados y aceptados por el cliente. Al menos esa es la teoría, porque en la vida real los usuarios más que seguir siempre un conjunto de procesos tienden más bien a usar el software como les da la gana.

Por otra parte, es necesario disponer de algún sistema de tickets para hacer seguimiento de las incidencias y llevar el control de las horas empleadas. Yo personalmente uso Redmine o Jira, pero hay muchas herramientas de seguimiento y control Open Source, EULA o SaaS como Basecamp.

Precarga de datos y transición desde el sistema antiguo al nuevo

Las cargas de datos pueden ser algo muy complejo y traicionero. Nunca hay que subestimar el esfuerzo que puede requerir una carga de datos, ni siquiera con las mejores herramientas ETL (Extract, Transform, Load). Lo mejor con las precargas de datos es empezar con las pruebas tan pronto como se disponga del nuevo modelo de datos.

Cambiar de un sistema a otro puede ser extraordinariamente delicado. Muchos clientes simplemente no pueden permitirse ni una hora de parada de servicio. A veces se puede montar un Enterprise Software Bus (ESB) para sincornizar durante un tiempo los datos entre el sistema antiguo y el nuevo, pero en otras ocasiones hay que hacer simplemente el «cambiazo» entre un sistema antiguo y el nuevo.

Si se puede instrumentar desde fuera, el sistema puede servir en algunas ocasiones como medio de control, comparando la salidas que produce frente a las del sistema nuevo.

Actualizaciones y soporte post-venta

Entre los equipos Ágiles son muy comunes las herramientas de integración contínua como Maven o Jenkins. Lo que no es tan común es oirles hablar sobre cómo llevar el control de versiones en el cliente.

Cualquier software distribuible que no esté específicamente diseñado para volver loco al que lo mantiene debe necesariamente de disponer de un mecanismo para enviar un reporte de todos los componentes y versiones en uso al fabricante. Recalco en uso porque en una ocasión yo me encontré una instalación que tiraba de una DLL registrada en la papelera de Windows.

También es fundamental que el instalador lleve un control del orden en que pueden instalarse (o no) las actualizaciones.

Para el soporte post-venta hay dos opciones: que lo presten directamente los desarrolladores o que los preste un departamento de servicios especializado. Elegir una u otra opción depende de la estrategia de incorporación de mejoras que se haya seleccionado. Si todas las mejoras se incorporan en una única rama de código entonces tiene sentido que los programadores, por turnos rotativos presten soporte directo a los clientes. Es mejor que sean turnos rotativos bisemanales puesto que si la misma persona está desarrollando y dando soporte simultáneamente entonces cuando no cumpla los plazos de desarrollo argüirá que estuvo prestando soporte y cuando el cliente se queje de mala calidad de servicio alegará que tenía que desarrollar para llegar al último sprint. Si las mejoras se incorporan en plug-ins o módulos externos lo lógico es que el soporte de primer nivel lo preste quien ha creado dichos módulos apoyado por soporte de segundo nivel de los desarrolladores del núcleo. La gestión de expectativas y cabreos del cliente es toda una disciplina en sí misma que frecuentemente requiere de personas especialmente hábiles en reducir los niveles de crispación y frustración de otras personas.

Planes de contingencia

En un proyecto pueden ir mal esencialmente tres cosas:

1ª) Puede que sea imposible cumplir los plazos. Por culpa de quien sea, del implantador, del cliente o de los elementos. El caso es que el problema le tocará solucionarlo al implantador.

2ª) Que el sistema funcione mal, con demasiadas incidencias, lento o de forma funcionalmente limitada.

3ª) Que tras intentar su implantación esta se demuestre inviable y haya que cancelar todo el proyecto.

Seré muy breve a este respecto, es razonable pactar que el proveedor arreglará gratuitamente los defectos software que pudieren aparecer en un periodo de tiempo posterior a la puesta en producción. Pero lo que no hay que hacer es jamás ni por ningún motivo aceptar penalizaciones expresas por retrasos u otros incumplimientos en los contratos. Esto es debido a que las penalizaciones pueden convertirse, de hecho, en un incentivo para que al cliente le interese terminar tarde el proyecto y así impagar parte del precio.

Cierre de proyecto y entrega de medallas

Todo proyecto digno se cierra con una entrega de medallas y diplomas. Conviene recordar que hasta Hitler ascendió a Paulus a Mariscal de Campo justo antes de la caída de Stalingrado. Normalmente, Cuando un directivo propone la compra de un paquete de software ya no puede permitirse el lujo de criticar al proveedor pues al criticarle estaría admitiendo indirectamente que se ha equivocado y se convertiría en objetivo de los dardos envenenados de otros directivos (suelen ser así de majos entre ellos). Lo ideal es crear la historia de un caso de éxito que sea noticiable. La campaña de marketing posterior al lanzamiento puede ser incluso parte de la propuesta de proyecto inicial. El caso de éxito de le interesa a todo el mundo: a la empresa porque mejora su eficiencia y su imagen frente a los clientes, al responsable de la compra porque la fama supone una oportunidad de promoción y al proveedor porque es una referencia que puede utilizar para venderle el mismo software a otros clientes del mismo sector.