El primer gran cliente revela los límites del producto SaaS
Un ejemplo hipotético de aprobación adicional de pedidos relaciona las variantes por cliente, el mantenimiento común y el alcance del producto.
Un cliente empresarial pide una aprobación adicional mientras otros usan el flujo existente. Para el equipo SaaS aparece una decisión de producto: ¿pertenece esta variante a la oferta común y cómo puede mantenerse dentro de ella?
El siguiente ejemplo es completamente hipotético. No describe una función realmente contratada ni un resultado de proyecto medido.
Describir la variante mediante una regla trazable
Supongamos que el producto procesa pedidos de las empresas C10 y C20. El nuevo cliente necesita la aprobación de otra persona autorizada. Quien realiza el pedido no puede aprobarlo. El otro cliente debe conservar el recorrido existente.
Empresa | Flujo deseado | Comprobación esperada en una actualización común |
|---|---|---|
| Esperar una aprobación independiente tras el envío | Se rechaza la autoaprobación; solo la otra persona autorizada puede aprobar |
| Procesar el pedido sin aprobación adicional | El flujo existente continúa y no recibe la obligación de aprobación del otro cliente |
Que un ajuste gestionado por cliente pueda admitir esta variante depende del modelo de producto. En el ejemplo sería comprobable: están definidos la regla, su alcance y el comportamiento esperado para ambos clientes.
La solución particular también tiene un futuro
Una copia de código diseñada solo para un cliente también necesitará correcciones, pruebas y actualizaciones. Por ello, examinaríamos primero si el requisito es sostenible como variante claramente delimitada del producto común. Es una recomendación condicional, no una obligación de convertir toda excepción en un ajuste.
Si el cliente necesita un proceso radicalmente distinto con mantenimiento y asistencia propios, una solución separada puede ser una decisión deliberada. Deben acordarse expresamente alcance y responsabilidad. Los recursos dedicados o despliegues separados no exigen automáticamente una base de código distinta.
Separar función, derecho al servicio y acceso a datos
Una bandera de funcionalidad puede ayudar durante una introducción limitada en el tiempo. Un derecho al servicio acordado de forma permanente necesita, en cambio, gestión y aplicación adecuadas. Activar una función tampoco sustituye comprobar quién puede aprobar por cada empresa.
En el ejemplo, una actualización debería probar la variante de aprobación y el flujo sin cambios. Importan la regla de producto trazable y el esfuerzo de mantenimiento; la primera petición no determina por sí sola la arquitectura.
Fuentes
Escrito por
- Katharina WeberRedactora de software y tecnologíaKatharina Weber se encarga en ASES de los artículos sobre desarrollo de software. Escribe sobre las cuestiones que se plantean las empresas al elegir software, desarrollar nuevas aplicaciones y modernizar sus sistemas existentes.
Seguir leyendo
Todos los artículos
Desarrollo de software con ASES
Software a medida, aplicaciones web y móviles