
Durante mucho tiempo, el software ha sido un producto que había que adquirir, instalar y operar en nuestros equipos. Pero desde hace unos años, gracias en gran medida a la tecnología de la virtualización y otras tecnologías de internet, cada vez hay una mayor oferta de software como servicio o Software as a Service (SaaS).
Muchas empresas de software tradicional y un buen número de inversores, han percibido el potencial de negocio de esta nueva forma de proveer software a otra empresas y usuarios, por lo que está habiendo una interesante transición en la que hay varios puntos a tener en cuenta.
Una única instalación
La ingeniería de software tradicional es muy rigurosa pues, una vez que se lanza una versión, ha de ser suficientemente fiable y con un número mínimo de defectos para evitar una continua emisión de parches y la frustración de los clientes que van a llevar relativamente mal la espera hasta una nueva versión que corrija los errores.
Sin embargo el SaaS tiene un único usuario que ha de realizar la instalación: tú. Y eso lo cambia todo. En vez de ser un software robusto y asentado, debe ser ágil y reversible, pues ahora lo que importa es que los usuarios que acceden a él como servicio, obtengan en cada momento las mejores prestaciones. La mentalidad del cliente es otra, y también lo va a ser su capacidad para admitir errores o esperar pacientemente a la siguiente versión.
Ya no eres una compañía de software
Dejas de ser una compañía de software para pasar a ser una compañía de operaciones, o más claramente, de servicios. De hecho, la mayoría de los usuarios serán igualmente felices pensando que la aplicación que utilizan es obra de unas pequeñas y mágicas hadas tanto como si es fruto de una cuidada y potente ingeniería de software.
Y esto también afecta a nivel agenda. A tus clientes no les va a encajar nunca bien las paradas técnicas para mejoras, backups u otras tareas de mantenimiento. Ellos van a esperar tener un servicio permanente y disponible siempre que necesiten acceder a él. Te van a pagar por tener operativo el sistema, y eso implica que hay que trabajar como una empresa de ingeniería enfocada en las operaciones más que en el producto. Esto es todo un desafío, que va a afectar los distintos roles y puestos de trabajo de la empresa.
Desarrollo continuo
Esta es, precisamente, una de las grandes ventajas del SaaS. No hay que preocuparse de si los clientes y el mercado van a aceptar mejor o peor el sacar una nueva versión y si los usuarios instalan o no esta o aquella actualización. El servicio evoluciona con fluidez y al ritmo que marca la propia empresa. A los usuarios no les cuesta adaptarse a ésto, pues sucede de una forma mucho más cómoda y natural que cuando ellos deben realizar acciones concretas para tener su software al día.
De hecho, una de las mayores hazañas de las empresas proveedoras de SaaS hoy en día, es contar con una ingeniería de procesos que pueda lidiar con éxito agendas de desarrollo rápido y cientos de actualizaciones, en casos extremos, en un sólo día. El desafío es poder hacer este desarrollo manteniendo la disponibilidad, sin cortes en el servicio.
Garantía de calidad o QA
En la ingeniería de diseño, la QA (Quality Assurance) juega un papel fundamental. En muchos casos, se trata de automátizar al máximo el proceso QA, pero en el caso del SaaS, hay que tener en cuenta que la automatización es un proceso relativamente lento si lo comparamos con los tiempos que se manejan en el uso continuo y escalado día a día de todos tus clientes. Éstos van a detectar los fallos y carencias a una velocidad mayor que tu propio plan de QA. Por eso, es importante hacer partícipes a tus usuarios de esta realidad: forman parte de tu sistema de QA. Su feedback es una forma indudable de mejorar el servicio y de crear una comunidad en comunicación y con experiencias positivas. Por un lado, logras una forma de mejorar tu servicio de manera flexible y actualizada, y por otro, se crea un colchón amigable que aumenta la tolerancia de tus clientes hacia los fallos.
Diseñar para la multitud
En la ingeniería de software tradicional, sólo hay que preocuparse de los parámetros del equipo y del entorno de un único usuario. E incluso si el softwware va a ser instalado en una intranet de una empresa, siempre va a tratarse de un entorno acotado. Sin embargo, el SaaS comprende una escala totalmente distinta. Estamos creando un software para “muchos usuarios”, podríamos decir para “todos los usuarios”. Esto implica una filosofía de proyecto radicalmente distinta y que constituye el mayor desafío a la hora de pasarse al negocio del SaaS.
Esto no solo implica que el software pueda multiplicar la carga que pudiera soportar en la versión para un único usuario, sino que es de vital importancia habilitar protocolos elegantes ante los fallos del sistema. Una comparación bastante clara sería la diferencia entre diseñar un coche y diseñar el complejo sistema de tráfico de una ciudad importante. Lo ideal va a ser que un incidente en un punto de la ciudad afecte al menor número de vehículos posible. Esto, trasladado a la realidad del SaaS, se traduce en una eficiente forma de aislar los componentes del sistema que estén fallando en un momento dado o un número lo más reducido de usuarios.
Dos libros a recomendar a este respecto son Scalable Internet Architectures (Theo Schlossnagle) y The Art of Scalability (Abbott and Fisher).
Respondiendo a las expectativas…
Aunque tú no te arriesgues a prometer a tus potenciales clientes demasiadas cosas acerca de lo que tu servicio va a hacer posible, no hay que olvidar que el propio ecosistema que se ha creado entorno al SaaS ya lleva aparejadas ciertas expectativas creadas en los usuarios. Es importante conocer a fondo el deseo general y mayoritario para enfocar adecuadamente toda la ingeniería del software a desarrollar.
Sin comentarios »