Mostrando entradas con la etiqueta indicadores. Mostrar todas las entradas
Mostrando entradas con la etiqueta indicadores. Mostrar todas las entradas

domingo, 17 de mayo de 2015

Diseño de la Propuesta de valor

 Diseño de la Propuesta de valor


Es interesante ver como modelos y herramientas que tienen su origen en el “negocio” se adaptan a nuestra forma de descubrir, diseñar y probar la viabilidad de productos de software. 

Entre el cliente, inversor, usuario (interesado en general) y quien diseña y crea la solución, comienza a surgir un lenguaje común a través de modelos visuales que son comprendidos y compartidos por ambos. 

La intervención cada vez más importante de aspectos que ya no son sólo funcionales, sino emocionales –social y personal– que la solución debe contemplar es también un desafío para quien explora y diseña nuevos productos y servicios.

Nada de esto es nuevo, simplemente que ahora la tecnología y la inundación de propuestas que recibe el interesado nos lleva a la “nueva normalidad”: mejor, más barato, más rápido, más pequeño, más conveniente, más personalizable, hace que sea mucho más necesario tener estos temas en cuenta. 

Vamos despidiéndonos del famoso "usuario cautivo" de décadas atrás para construir soluciones para las personas que pueden elegirnos a nosotros o a otros. 

Ganará el mejor, quien comprendió más íntegramente los trabajos para los cuales el cliente "contrata" nuestro producto. 

Ya en la entrada de este blog Value Proposition Design - Comentarios sobre el nuevo libro de Alex Osterwalder comenté acerca del contenido del modelo propuesto por el autor.

Ahora, en la presentación más abajo mostrada amplío la descripción del modelo con algunos de los pasos que este recorre y las herramientas que utiliza.

Las láminas 15 y 17 del pdf corresponde a este video: https://www.youtube.com/watch?v=NMacTuHPWFI

Espero sea de utilidad y genere en Uds. inquietud y curiosidad para seguir explorando.

Saludos,
Raúl

@RaulMartinez582

miércoles, 6 de noviembre de 2013

Acercarnos al Negocio (Conclusión)



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: 

  1. 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.
  2. 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.
  3. 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


lunes, 4 de noviembre de 2013

Acercarnos al negocio (exploradores)


Finalmente llegamos al tercer grupo en el tema de acercarnos al negocio y su relación con la calidad del producto. 
Aquí el consumidor opera el producto, disponiendo de una cantidad de opciones, por ejemplo consultar, registrarse, comprar, pagar, publicar, etc.
Sus expectativas juegan un papel central.

La finalidad de la empresa: el servicio que se presta a través del producto es el negocio mismo de la empresa.

Los requerimientos: conocidos los requisitos básicos, éstos pueden estar especificados con cierta precisión por adelantado. Varios, sobre todo aquellos que harán diferencial al producto, se encontrarán explorando las demandas del consumidor, la forma en que utiliza el producto, sus expectativas y el comportamiento de los productos competidores. Esta exploración nos guiará en la funcionalidad a implementar y su prioridad.

Los usuarios: Muchos, desconocidos o no conocidos hasta que se identifican, recorriendo pasos totalmente aleatorios o especificados en el producto en algunos casos. Estos consumidores pueden agruparse y tomar decisiones conjuntas o bien operar individualmente. Volátiles, con la posibilidad de hacer la misma operación con otro producto competidor, sin mayores costos en el cambio.

Los modelos de trabajo: Tradicionales de desarrollo de software, y administración de proyectos para las partes conocidas.
Necesidad de modelos exploratorios para las partes más volátiles.
Los atributos de calidad deben tenerse en cuenta y su valor objetivo se definirá en parte por la pérdida/ganancia de negocios para la empresa al cumplir o no las expectativas del consumidor.

La calidad: en este contexto significa cumplir con los requerimientos básicos del producto y del proyecto con la tasa de defectos más baja posible, admitiendo errores y equivocaciones en aquellas funcionalidades detectadas por medios exploratorios donde la puesta en producción o el "time-to-market" es prioritario. El indicador accionable, ya mencionado en el post anterior, que une el resultado de una funcionalidad para el negocio, con la pieza de software que la implementa, es una guía para saber qué corregir y con qué prioridad.

Acercarnos al negocio: vale todo lo mencionado en las entradas anteriores sobre conocimiento de productos, tecnología, etc. si bien posiblemente parte de ese conocimiento esté más difundido en estas compañías dado el tipo de negocio en gran medida dependiente de la tecnología.

Contexto: predominantemente complejo y desordenado.


Para una explicación más amplia de estos contextos ver 
http://ideassobresoftware.blogspot.com.ar/2013/09/todavia-quiere-seguir-jugando.html 

Post relacionados




Saludos,
Raúl
TW: @RaulMartinez582


sábado, 1 de junio de 2013

Indicadores accionables

Indicador accionable. Qué es eso?

Pensemos en un indicador de negocio y pensemos también que su valor o tendencia indique que alguna parte de este negocio va bien o mal, traducido: estamos ganando perdiendo dinero.

No es sencillo imaginarlo. Los indicadores financieros de alto nivel, parecen de poca utilidad, ya que su variación depende de muchas variables, entre las cuales la pieza de software es sólo una más.

Difícilmente una persona cercana al producto de software pueda concluir de este tipo de indicadores de alto nivel algún mal funcionamiento o mejora y repararlo.

Entonces?
Varias preguntas a responder, desde qué rol cumplimos nosotros respecto a la Organización y a su negocio, hasta cuál es el negocio: 

Nuestra posición: Pueden presentarse al menos dos casos bien diferenciados, y pueden darse algunas cuestiones inherentes a la Organización que se relacionan fuertemente con lograr estos indicadores accionables:
Desarrollamos software para el negocio. Podemos ser externos o internos a la Organización. 

Caso 1: Somos proveedores externos. Fabricamos  y allí terminamos nuestra intervención. Los indicadores que interesan a nuestro negocio como organización proveedora, serán los típicos de los proyectos tiempo-costos-alcance. Cumplido esto, habremos entregado un producto de calidad de acuerdo a lo especificado.

Caso 2: En el segundo caso (internos a la Organización), estamos en la segunda categoría. Estamos dentro del negocio. Somos parte integrante de él.
El negocio no necesita ser el negocio completo de la Organización; por ejemplo, en un banco el negocio del que hablamos podría ser su área de home banking y aplicarse estas ideas a ese área. En este caso valen los primeros indicadores, pero se agregan otros indicadores de éxito. Aquéllos que relacionan el comportamiento del negocio de home banking con el comportamiento del software que lo soporta.


Otras preguntas: Relacionadas con cuestiones inherentes a la Organización que se relacionan fuertemente con lograr estos indicadores accionables:

En relación al negocio: 
Puede el negocio traducir su comportamiento (si gana o pierde) en indicadores que sean accionables, es decir que se pueda tomar una acción en base a ellos?. Y que tales indicadores a su vez estén relacionados lo más cercanamente posible al producto de software?
Esta es una pregunta difícil y el tema también lo es. La relación raramente es tan directa y los indicadores dependerán de qué podemos medir para determinar ese comportamiento. Por ejemplo: conversiones de visitas en ventas de otros productos bancarios, abandonos, incidentes, motivos de quejas de clientes.

En relación a la cultura de la Organización: 
Es capaz la Organización de abrir ese tipo de información (si gana o pierde como en el ejemplo anterior del home banking) a sus áreas normalmente consideradas técnicas y de servicio, o esa es información que no se difunde?.


Ejemplo de Indicadores por nivel de la pirámide.