Esta tabla es una conclusión de los posts anteriores sobre el tema del negocio y la calidad.
Definitivamente incompleta y simplificada, creemos que permite entender la calidad desde varios puntos de vista que actúan simultáneamente sobre el usuario/consumidor, el negocio y el equipo que desarrolla.
Atarse a un modelo de trabajo, a una situación determinada (usuario cautivo por ejemplo) o a una única definición de calidad es peligroso, para el negocio y para nosotros.
Otras conclusiones:
- Si bien puede parecernos que es lento y que no es posible que el negocio mute de un tipo a otro, lo que sí puede y va a mutar es la forma en que la tecnología va permitiendo resolver los problemas y ofrecer nuevas oportunidades de servir al usuario. Esto hace que con el tiempo los límites entre los tipos de negocio vayan haciéndose más tenues, en lo que a los servicios prestados vía la tecnología se refiere.
- El cambio entre columnas es costoso, en ambos sentidos. En un negocio donde se debe explorar el comportamiento del consumidor no podemos esperar requerimientos escritos, al menos al inicio. Del mismo modo, en un negocio donde el objetivo del producto es conocido, explorar no tiene demasiado lugar y no recibir los requerimientos razonablemente definidos en este caso sólo agrega tiempo y defectos.
- En lo referido a contextos. El contexto complejo y desordenado no es un lugar para vivir. A medida que las expectativas del cliente se detecten y se cumplan, debemos esforzarnos para pasar al ordenado y complicado. Y prepararnos para una nueva tanta de expectativas a explorar y así siguiendo.
A considerar |
Backoffice |
Usuario adelante |
Exploradores |
La finalidad de la empresa
|
No relacionada con el software
|
Productos de sw vitales para su
negocio, sin ser el negocio mismo
|
El negocio es la prestación de un
servicio a través del producto de software
|
Los requerimientos
|
Conocidos
|
Conocidos; mayor cuidado en los atributos de
calidad de cara al cliente
|
Conocidos los básicos; a explorar el resto según
demandas del usuario y competencia
|
Los usuarios
|
Conocidos y cautivos
|
Conocidos internos y externos. Costo
de cambio es alto para el cliente
|
Variados, muchos, desconocidos
hasta la identificación. Comunidades, decisiones
conjuntas, no controlables. Bajo costo
de cambio para el consumidor.
|
Los modelos de trabajo
|
Tradicionales en desarrollo y PM
|
Tradicionales en desarrollo y administración. Parcialmente exploratorios
de cara al cliente
|
En lo básico, en parte tradicionales. En lo competitivo, modelos exploratorios.
|
La calidad
|
Cumplir los requerimientos
|
Cumplir los requerimientos y
prestar atención a la calidad en uso
|
Cumplir los requerimientos básicos
se da por hecho. La calidad se mide en el cumplimiento de expectativas de los
consumidores.
|
Acercarnos al negocio
|
Apoyo tecnológico y soporte
|
Idem anterior sumando algunos indicadores
accionables de negocio/producto
|
Indicadores accionables que permitan analizar en los
tiempos del negocio la relación negocio/producto y corregir desvíos.
|
Contexto |
Complicado - ordenado
|
Complicado - ordenado
|
Complejo - desordenado
|
Saludos,
Raúl
TW: @RaulMartinez582Post relacionados
http://ideassobresoftware.blogspot.com.ar/2013/11/acercandonos-al-negocio-con-el-cliente.html
http://ideassobresoftware.blogspot.com.ar/2013/11/acercarnos-al-negocio-exploradores.html
http://ideassobresoftware.blogspot.com.ar/2013/11/acercarnos-al-negocio-exploradores.html
Un aspecto complementario que también puede considerarse esta relacionado con la criticidad del producto. Usando el modelo de Geoffrey Moore las aplicaciones pueden ubicarse en cuatro cuadrantes diferentes. En un eje se considera si el producto o aplicación es misión crítica, o sea aquellas donde existe una dependencia clave para el valor de la compañía; y no críticas que son el resto. Y en el otro eje las aplicaciones centrales, aquellas que crean la diferenciación para ganar clientes y las aplicaciones de contexto que son las restantes. Es bastante razonable asumir que el requerimiento de calidad de una aplicación central y misión crítica va a ser diferente de una aplicación no misión crítica y de contexto.
ResponderEliminarEs una visión complementaria al planteo presentado.
Marcelo
Qué tal Marcelo.
EliminarEntiendo que este modelo permitiría ampliar y enriquecer el cuadro mostrado arriba.
Si bien la empresa no hace del producto de software su negocio, hay software que le permitirá diferenciarse de la competencia. Esto sería misión crítica. Hay que monitorear continuamente las expectativas del usuario/consumidor e ir adecuando el producto para que cumpla esas expectativas.
Buen aporte. Ampliaría la columna “Exploradores” o crearía una nueva pero de tipo similar. Debería ser construido y operado por la organización ya que es su herramienta para competir.
El resto del software es de soporte para la empresa. Estaría definido con razonable precisión a nivel de requerimientos y se asemejaría a lo puesto en las columnas 1 y 2 de la tabla pudiéndoselo dar a un tercero para su desarrollo y operación.
Entendí bien?
Saludos,
Raúl