Acercando el producto de software al negocio

Este trabajo resume los pasos seguidos por una empresa en un ambiente híper competitivo como es el comercio electrónico y las decisiones técnicas y organizacionales que tomaron para mejorar su desempeño. Se analizan éstas luego para extraer conclusiones aplicables a cualquier empresa.

El escenario previo

Arquitectura técnica. Originalmente la plataforma de e-commerce fue monolítica y cerrada. Su base de datos y su código estaban centralizados. El diseño de esta arquitectura fue pensado para generar ventajas competitivas, pero con altos costos en pérdida de flexibilidad y riesgos ante cambios.

Impacto de las fallas. En este esquema monolítico, centralizado y cerrado, un defecto producto de un error en el desarrollo, tenía una alta probabilidad de impacto cruzado en distintas partes de la aplicación con su consecuencia directa e importante en el negocio. El riesgo asociado a un defecto latente era muy alto y los efectos no deseados sobre el negocio podían ser significativos. El foco estaba puesto en corregir los defectos.

Procesos de desarrollo. Los procesos se diseñaron bajo la premisa de evitar errores resultando en ciclos de desarrollo y pruebas extensos, difíciles de escalar y con un “time-to-market” poco acorde a la industria de e-commerce. Los ciclos de desarrollo-liberación eran extensos, con semanas/meses en pruebas, frecuencia de liberación – “release”- quincenal y en ocasiones mensual.

Organización. Se generó una dinámica organizacional poco tolerante a los defectos, con incentivos alineados a evitar y prevenir cualquier tipo y magnitud de defecto. Equivocarse no era bien visto, por lo tanto la capacidad de innovar e iterar tendió a reducirse. El concepto de calidad de producto era elemental y estaba definido en términos de cantidad de defectos. Las métricas y objetivos a lograr se diseñaron bajo ese concepto y se enfocaban en medir y controlar cantidad de fallas en producción.

Este escenario puede visualizarse como a base de una pirámide. En él, el esfuerzo estaba puesto en un producto sin defectos y con el resto de las características cumplidas. Los indicadores de éxito estaban referidos a un producto con baja tasa de errores. Ver Figura 1.

Figura 1. Escenario visto como una pirámide.

El nuevo escenario

Arquitectura técnica. Se produjo un cambio radical cuando la plataforma dejó de ser un sitio web para convertirse en una plataforma abierta de e-commerce. Se rediseñó la arquitectura para abrir la plataforma y descentralizar tanto la base de datos como el código fuente, permitiendo distribuir la aplicación en distintos departamentos de la organización.

Impacto de las fallas. La nueva arquitectura eliminó fricciones y dependencias funcionales y técnicas existentes entre los módulos en el modelo monolítico. El riesgo se distribuyó y esto obró como factor de cambio en la organización y en el negocio.

Procesos de desarrollo. Se establecieron procesos ágiles de desarrollo y prueba permitiendo aumentar la frecuencia de pruebas, cantidad y paralelismo de los cambios, mejorando la velocidad de implementación y corrección de defectos. Se pasó de tener una única implementación quincenal a tener casos de más de ochenta pasajes a producción en un mismo día.

Organización. La nueva perspectiva introdujo un cambio radical en la dinámica organizacional, enfocando y alineando a los equipos de trabajo con la mejora continua y el cambio constante, no tratando de prevenir todos los defectos, sino de lograr un producto con la calidad suficiente para no afectar los indicadores del negocio.

El impacto de los defectos en el producto no es ya la fricción principal en el negocio: Esto permite manifestarse al resto de las variables que afectan al negocio y que antes no formaban parte explícita de la definición interna de la calidad del producto.

Indicadores. Los nuevos indicadores e incentivos definidos requieren un comentario adicional. Ya no es suficiente evitar errores en el producto, o asegurar el funcionamiento y la disponibilidad de la plataforma; se trata de dar a los usuarios lo que necesitan y como lo necesiten, satisfaciendo sus expectativas y logrando una experiencia que diferencie a la empresa de la competencia. Hay espacio para equivocaciones, pero existen mecanismos sensibles de alertas y procesos de cambios y corrección muy agilizados.

Para monitorear el comportamiento de las nuevas variables se consideraron varios niveles de indicadores, como muestra la pirámide de la Figura 2. Este escenario puede visualizarse completando la pirámide de la Figura 1 con otros dos niveles: producto útil para el usuario y, si esto se cumple, producto exitoso para el negocio. Los indicadores de éxito se relacionan en la base con la baja tasa de errores, y hacia el vértice, se definen en relación a los KPI’s que interesan al negocio, no olvidando además la satisfacción de los clientes.

Nivel 1 (base) - Escalabilidad
Nivel 2 (base) - Funcionamiento Core
Nivel 3 (base) - Usabilidad
Nivel 4 (medio) - Customer Satisfaction
Nivel 5 (vértice) - Rentabilidad
Nivel 6 (vértice) - Competitividad

Figura 2. Pirámide completa

Análisis del caso

Tratando de interpretar las decisiones más importantes tomadas surge: Interesados y sus expectativas.

Los siguientes aparecen como interesados principales:

• La Empresa, que requiere un producto ágil y ampliable, competitivo en funcionalidad, con costos aceptables de desarrollo y operativos, medido mediante indicadores que relacionen el comportamiento del producto y el del negocio.
• El Visitante/usuario, que requiere un producto confiable y maduro, completo en funcionalidad, sencillo de utilizar, seguro y de buena performance.
• El Grupo de Desarrollo que requiere un producto construido de modo tal que les permita satisfacer el Time-to-market, mantenible, posible de ser probado y auditable.

Para satisfacer al universo de interesados, la Empresa encaró cambios radicales en la arquitectura del producto, los procesos de negocio y técnicos, y la organización que los soporta.

Analicemos los cambios

Arquitectura. El cambio tuvo como finalidad que ésta no fuera una traba para cumplir las expectativas de la Dirección y grupos responsables del producto en cuanto a agilidad en los cambios y clara responsabilidad de los intervinientes. Los visitantes/usuarios observan un comportamiento estable y similar en el producto, o mejorado en algunas funciones. El costo de lograr este comportamiento es menor, algo no visible al visitante, pero sí a la Organización.

Procesos de desarrollo. El proceso convencional de desarrollo y mantenimiento, adecuado para un producto monolítico y altamente acoplado, se cambió por prácticas ágiles.

Organización. La organización original evolucionó en paralelo con los nuevos procesos, para satisfacer expectativas de time-to-market, responsabilidades, costo de cambios, e indicadores de comportamiento producto / negocio. Se formaron equipos pequeños, descentralizados y multifuncionales responsables desde la definición y planificación de nueva funcionalidad o cambio, hasta su puesta en Producción y posterior evolución. Se disolvió el QA centralizado reasignando sus integrantes a los nuevos equipos.  Se implementó la función de Business Assurance, que controla el producto en operación y analiza el impacto de su comportamiento en el negocio mediante indicadores.

Indicadores. El producto y organización originales, no mostraban cómo los indicadores técnicos se relacionaban con los del negocio (ver Figura 1). No existía una relación directa entre las acciones a tomar en el producto para corregir o potenciar situaciones de negocio.

Los distintos niveles de indicadores (ver Figura 2), permiten ahora detectar la calidad en uso del producto para los interesados y efectuar mediciones que delimitan sobre qué parte del producto accionar si fuera necesario. Estos indicadores accionables, en forma indirecta, establecen si se cumplen los objetivos de negocio dependientes del producto, posibilitando dar incentivos a los responsables de las distintas partes de la plataforma de la Empresa en función al cumplimiento de dichos objetivos.

Próximos pasos

Interesados. Continuar la detección de interesados, además de los visitantes y comerciantes, ampliando a otros con expectativas sobre el producto: comunidad de desarrollo externa, auditores, seguridad informática, etc. Entendiendo la influencia y comunicación con cada uno.

Detección y priorización de expectativas. Realizar encuestas o consultas instantáneas a los visitantes/compradores y comerciantes para entender sus expectativas. Utilizar herramientas como el Modelo Kano y los Mapas de Empatía para detectar y priorizar requerimientos y expectativas.

Modelo de calidad y evangelización. Formalizar en la medida necesaria y posible, el conocimiento tácito de calidad para la Organización y transmitirlo a los equipos propios, a terceros y a otros interesados mediante reuniones y eventos. Ejemplo, al desarrollador que amplía el producto de la Empresa mediante APIs, la formalización le permitirá comprender la calidad esperada, y a la Empresa, evaluar la calidad ofrecida. El software será visto entonces como homogéneo, ya sea el producto base o sus extensiones. Aquí resultan aplicables los modelos establecidos en la industria de calidad de sistemas y de productos de software.

KPIs del negocio. Continuar midiendo “features” del producto por los resultados sobre el negocio. Las medidas deben ser accionables, y se debe poder relacionar el KPI del negocio con el producto, para intervenir si es necesario.

KPIs del producto. Desarrollar nuevos KPIs que midan la calidad técnica del producto, para pronosticar su calidad final. Como se mencionó anteriormente, aquí aplican los modelos de calidad de software y las métricas que proponen.

Mejora continua. Compenetrar al personal técnico del producto cada vez más en el negocio, ya que el negocio se basa en el producto, completando así un ciclo para mejorar la calidad del producto haciéndolo más competitivo y exitoso.

Conclusiones

Se mostró cómo esta Empresa:

• Colocó en el centro al cliente y al producto y no a la tecnología.
• Relacionó el negocio con el producto de software y el éxito en el negocio con la calidad de dicho producto.
• Cambió su organización y modelos de trabajo para adecuarlos a los tiempos y necesidades que demandaba su mercado.
• Dio, intuitivamente, los pasos necesarios para considerar todo el contexto en el que el producto de software estaba inserto y reaccionó ante ese contexto.
• Los próximos pasos propuestos intentan hacer más visibles y analizables estas decisiones consolidando aún más la calidad del producto que se está logrando.

Si bien este análisis es de un caso en particular, permite extraer conclusiones aplicables a otras organizaciones que quieran lograr una mayor y mejor relación entre sus productos de software y el negocio en el que se aplican.