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

martes, 5 de julio de 2016


Si me estrella contra el muro, es de calidad?... sigue la saga


A riesgo de ser pesado, sigamos con el tema anterior, que ha causado cierta reacción en Twitter, aquí y sobre todo en mí.

Imaginemos 2 stakeholders típicos (entre muchos) para un producto como el coche con su software.
La Autoridad de aplicación, por ejemplo la Autoridad de la ciudad y el Interesado. Por ejemplo yo, comprador del coche.

La Autoridad de aplicación le impone al constructor del coche/software, de aquí en más llamémoslo sistema (coche + software) sus requerimientos, que son restricciones de seguridad. Por ejemplo, ante una situación de riesgo, el sistema debe elegir el mal menor. Un caso, estrellar el coche contra el muro en lugar de atropellar a la anciana o la embarazada.

Obviamente, el otro interesado, Yo el comprador, pongo como requerimiento que el coche sea seguro y que no me mate, para decirlo rápidamente.

Ahora bien, el constructor del sistema como se manejaría con dos requerimientos tan enfrentados?

Por ejemplo que diría la promoción de su producto: “Compre este coche que es el más seguro y en la letra pequeña diría: tomaría la mejor elección para Ud. y el entorno que lo rodea.” Firme aquí. 

Leído entre líneas dirá, Ud. acepta que el coche lo estrellará contra el muro si eso es o que más conviene al entorno.

Qué le pediría seguramente su Product Manager. ”Haz esto, lo que pide la Autoridad, pero no mucho. Haz esto sin que se note. O saltéalo y si se da será un error de software”. Caso en el cual Ud. Desarrollador irá preso, pero el habrá logrado la promoción.

Bueno comparado con esto, nuestra tarjeta de crédito alcahueta mencionada en la entrada anterior será cosa de niños. :=)

Saludos,
Raúl

Nota 1: quién se atreve a opinar como uno de los 2 stakeholders????
Nota 2: el futuro nos aplasta, vean esta nota del diario El País de España:http://tecnologia.elpais.com/tecnologia/2016/07/01/actualidad/1467337732_779288.html

sábado, 21 de marzo de 2015

Value Proposition Design - Comentarios sobre el nuevo libro de Alex Osterwalder et al.

No es sencillo hacer comentarios y críticas sobre una obra que nos atrae y cuyas ideas en su gran mayoría se comparten. Aún así trataré de ser objetivo y expresar el resultado de la lectura del libro.

La propuesta


Value Proposition Design (VPD) continúa desarrollando la idea planteada en su primer libro por Alex Osterwalder et al., Business Model Generation(1) (BMG).

Si bien VPD puede leerse en forma independiente del primer libro, es útil leer BMG, dadas las referencias y el hecho de que VPD desarrolla en particular dos bloques de los nueve del modelo BMG, correspondientes a la generación de la propuesta de valor (VP) y el análisis del segmento de clientes (CS).

Como en el libro anterior, los autores plantean la explicación en una posible secuencia, por etapas: Canvas, Diseño, Prueba y Evolución, y también como en BMG, el trabajo real es altamente iterativo.

El libro elabora sobre algunas ideas conocidas y otras nuevas, empaquetadas de forma amigable y legible.

Las etapas

Canvas

Trafico tomado del sitio con material que acompaña al libro VPD

En el Segmento de Clientes (círculo del gráfico) se desarrolla la investigación de quién es el cliente, qué quiere hacer, qué le impide hacerlo y qué resultados lograría haciendo lo que quiere, y qué contexto social y emocional tiene el trabajo.


Este análisis es muy interesante en los ambientes actuales de desarrollo de productos, por ejemplo los tecnológicos, que están altamente relacionados con la persona cliente / consumidor y su circunstancia emocional y social.

La inclusión de los temas sociales y emocionales, además de los funcionales, denominados “trabajos” recuerdan la propuesta de Clayton Christensen para segmentación basándose en la circunstancia(2).

En la Propuesta de Valor (cuadrado del gráfico), se desarrolla la idea de qué resultados le permitiría lograr al cliente el utilizar el producto y qué obstáculos le ayudaría a eliminar para lograrlos.  

Los resultados que el usuario lograría – gains – se clasifican desde aquellos requeridos (sin ellos el producto no sirve) hasta aquellos no esperados (sorprende positivamente que los tenga). Una clasificación similar a la de Kano(3).

El ejemplo que los autores utilizan varias veces, es el análisis de la persona que lee libros de negocios. Interesante y sencillo de seguir.

Todo lo anterior, es decir el análisis del CS y de la VP se hace para determinar el ajuste, encaje o “fit” de nuestro producto/servicio a las necesidades reales del cliente.

La recomendación es que los análisis del CS y la VP se hagan por separado y luego buscar el encaje entre nuestra oferta y la necesidad del cliente de modo de ver su cobertura.

Diseño

El diseño es la actividad que intenta convertir las ideas de la VP en un producto/servicio tangible para el cliente.

La propuesta se basa en prototipar -- investigar la reacción del cliente -- volver a dar forma a la idea y probar de nuevo.

Los prototipos deben ser baratos, hacerse rápidamente y ser aproximados a la oferta que queremos hacer para validar su factibilidad y desarrollar VP alternativas.

Los autores proponen desde Diagramas en papel hasta el Producto Mínimo Viable (MVP) siguiendo a Steve Blank (4).

Es interesante determinar el origen de nuestra VP:

Podrá ser Push, resultado de una tecnología o una innovación que encontramos (la solución en busca del problema) o 

Podrá ser Pull, por una necesidad manifestada por el cliente (un problema en busca de solución).

Otro análisis que se hace comprueba cómo encaja la VP en el modelo de negocio. 

Teniendo en cuenta que para crear valor para el negocio hay que crear valor para el cliente y para seguir creando valor para el cliente, se necesita crear valor para el negocio (sustentabilidad). 

Prueba

Para una idea nueva, y dada su incertidumbre, el enfoque de experimento es más conveniente que el plan de negocios tradicional.

Todas las ideas deben ser probadas con el cliente y el resto de interesados como socios, canales, etc.. 

Integrando los principios de lean start-up, se comprueba primero la viabilidad del producto y la empresa se crea al final.(5)

Gran parte de la propuesta se basa en trabajar basados en evidencias. Antes de enfocarnos en cómo ayudar al cliente, debemos validar que el cliente necesita que lo ayuden en ese trabajo, que encuentra obstáculos para hacerlo y como se beneficiaría si lo logra.

También debe comprobarse que al cliente le interesa nuestro producto, y lo ve como un medio para evitar esos obstáculos y lograr los resultados.

Se proponen modelos de Tarjetas de prueba y  Tarjetas de aprendizaje, como registro de lo hecho y obtenido.

Una idea interesante es la del “call to action”, es decir, proponer al cliente que él realice una acción que puede ir desde tocar un botón en la pantalla hasta completar una encuesta o enviar un mail. Prueba un principio de interés en el producto, con una evidencia comprobable. Evitaríamos el "creo que le gustó" tan subjetivo.

Una lectura imperdible de este capítulo es el caso Owlet y el video de su presentación. Allí se materializa lo explicado en el libro.

Evolución

Esta parte final trata quizás el aspecto más complejo de la propuesta de valor: Lograr el alineamiento y compromiso de todos los interesados, explicando qué se quiere lograr, y proveer indicadores que muestren el progreso hacia ese objetivo.

Los modelos utilizados, BM y VPD, son muy útiles para comunicar y analizar avance basado en evidencias. Brindan indicadores objetivos de medición. Pero disponer todas estas herramientas no simplifica el problema, sólo ayudan.


Mis consideraciones

El libro continúa con la modalidad de ilustraciones y texto con diseño atrayente, muy útil por la claridad, aunque su estilo fresco y transgresor no cae bien a todos los lectores de estos temas. Los gráficos son claros, quizás algo más claros que en BMG (cuestión de gustos).

Los casos desarrollados en el libro en forma de ejercicios, son de ayuda. Los ejercicios que están en el sitio de apoyo son en varios casos preguntas y una calificación.

Hay todavía partes sin desarrollar del material de apoyo. Dado el tiempo en que se publicó deberían esperarse a la brevedad.

El sitio no es demasiado claro para navegar. La mezcla de soporte y propuestas comerciales no favorece. Son temas diferentes, el libro ya se compró y si se quiere ofrecer un seminario o software sobre VPD, la vía debería ser totalmente independiente.

Conclusión

El libro es interesante y completo. No aporta tremendas novedades pero ordena algunas conocidas, como hemos mostrado en las referencias.

Puede tener varias aplicaciones  aparte de crear/pensar un producto nuevo. Por ejemplo, como un modelo de análisis para manejar la incertidumbre en las aplicaciones de software actuales.

En mi opinión, hubiese convenido agregar más fuentes para quien quiera profundizar, y evitar algunas partes que se repiten.

Mi conclusión final es que: a quien ha leído y practicado BMG seguramente le aportará valor completando el detalle de dos importantes bloques, Propuesta de Valor y Segmento de Clientes.

A quien no leyó el libro anterior de estos autores, les puede ser de utilidad también por el orden, el lenguaje sencillo que aporta y la visión práctica de cómo crear productos con mayor probabilidad de que a la gente le interesen.

Si hay otras visiones y opiniones, bienvenido el debate.

Saludos,
Raúl


Raúl Martínez 



Referencias

(1) Business Model Generation, Osterwalder, Pigneur, 2009
(2) The Innovator's Solution: Creating and Sustaining Successful Growth, C. Christensen and M. Raynor 2003
(3) Kano Noriaki, Attractive quality (Kano method/Kano model)
(4) The four steps to epiphany. Steve Blank, 2013
(5) The Startup Owner’s Manual. Blank , Dorf, 2012

Nota

-Estos comentarios fueron hechos tomando la edición en inglés del libro
-Donde dice producto, equivale a producto/servicio

domingo, 8 de marzo de 2015

Acercarnos al Negocio (Conclusión) -No hay lugar para los débiles- Re-edición

Acercarnos al Negocio (Conclusión)

-No hay lugar para los débiles-



Este artículo es la conclusión sobre el tema del tipo de negocio, la relación entre el área de tecnología (IT), los Clientes / Usuarios y la calidad percibida por ellos, desarrollada a través de las notas anteriores (1), (2) y (3).

La tabla mostrada, definitivamente incompleta simplificada, creemos que permite entender el contexto de los productos de software desde varios puntos de vista. Los temas que muestra actúan simultáneamente sobre el usuario / consumidor, el negocio y el equipo de IT. 
Atarse a un modelo de trabajo, a una situación determinada  que onsideremos estable (impacto del sw en nuestra industria, usuario eternamente 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, va a mutar es la forma en que la tecnología permite hoy resolver los negocios y ofrecer nuevas oportunidades de negocio. Con el tiempo, los límites entre los tipos vayan haciéndose más tenues, en 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 ni debemos 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 permanecer. A medida que las expectativas del cliente se detecten y se cumplan, debemos esforzarnos para pasar al complicado pero ordenado. Y prepararnos para una nueva tanda de expectativas a explorar y así siguiendo.  
Tema a considerar
Lo más importante es el sw de backoffice
Importa el sw de backoffice pero hay sw que interactúa con el cliente
Hay interacción continua del sw con el cliente y además sw backoffice

La finalidad de la empresa
No relacionada con el software
Productos de sw importantes para su negocio, pero no son su negocio
Su 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 funcionales 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. Baja movilidad de clientes.
Variados y gran cantidad, desconocidos hasta la identificación. Comunidades, decisiones conjuntas, no controlables. Bajo costo de cambio para el cliente/consumidor.

Los modelos de trabajo
Tradicionales para el desarrollo de sw y administración de proyectos
Ídem anterior más, parcialmente exploratorios de cara al cliente
En lo funcional básico, en parte tradicionales. En lo competitivo,   modelos totalmente 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.

Formas de acercarse IT al negocio
Apoyo tecnológico y soporte
Ídem anterior, más  algunos indicadores accionables de la performance negocio/producto de sw
Indicadores accionables que permitan analizar en los tiempos del negocio la performance negocio/producto de sw y corregir desvíos.

Contexto
Complicado pero  ordenado
Complicado pero ordenado
Complejo y desordenado

Como se dijo más arriba, la mutación y mezcla entre las columnas de la tabla está en curso, más lenta en algunos casos, más rápida en otros pero siempre presente.
Difícilmente podamos imaginar en pocos años más una industria que no haya incorporado software como una herramienta más para competir. Aún en aquellas industrias que parecen más alejadas de este tipo de tecnología. De allí la importancia para el sector de IT de preverlo y administrarlo hoy, o será tarde.
Aquí aplica una vez más la frase, lo único permanente es el cambio
Raúl Martínez
TW: @RaulMartinez582


Post relacionados


jueves, 26 de febrero de 2015

La Persona detrás de El Usuario


Al tratar de entender un problema a resolver o la solución a proponer, hablamos habitualmente de El Usuario. Eso es correcto según toda la literatura y es quien en última instancia utilizará nuestro producto/servicio.  

Bastante tiempo atrás nos preocupaba que este usuario recibiera un producto funcionalmente correcto, luego en la medida que la tecnología lo permitió sumamos cada vez más la idea de usabilidad y finalmente hoy debemos sumar algo más abstracto de definir que es la persona que está detrás de ese usuario.

Así como la propuesta Ágil nos muestra, entre varias otras cosas, la Persona que está detrás del Recurso en el Equipo de Trabajo y lo útil que es considerarla, deberíamos examinar cómo nuestro modelo de análisis de los problemas contemplan a la persona detrás del usuario y no sólo la funcionalidad que utilizará en la operación del producto.

Hay varios factores además del funcional, como el social o el emocional, que pueden finalmente transformarse en requerimientos tal como cualquier otro requerimiento funcional que conocemos.

En mi opinión este tipo de análisis es un movimiento imparable debido a la presión y difusión de las tecnologías que hoy ya están totalmente incorporadas al plano social y personal.

Sobre el tema, hay literatura interesante que si bien pertenece a lo que llamaríamos habitualmente libros de negocios, creo que son necesarios para el analista de negocios, el product manager , el arquitecto / desarrollador senior y por supuesto el emprendedor.

Los libros son estos:

--Business Model Generation, Osterwalder, Pigneur, 2009
--Value Proposition Design, Osterwalder, Pigneur , Bernarda, 2014
--The four steps to epiphany. Steve Blank, 2013
--The Startup Owner’s Manual. Blank , Dorf, 2012

Ninguno trae ideas revolucionarias, excepto el formato gráfico de los dos primeros utilizado para plantear temas áridos de negocios. Hay ideas de Christensen, Kim, Ries, etc. Bien condensadas y presentadas.

Conviene empezar por el primero Business Model.

Hay que tomarse un tiempo para leerlos, desprenderse del preconcepto de “eso es un  tema del negocio, no mío” y recordar siempre la frase de Steve Blank  -- get “outside of the building” -- que las cosas ocurren fuera de nuestro lugar de trabajo. Con la lectura no basta.

Hasta la próxima.

Raúl Martínez
rmartinez@rmya.com.ar


viernes, 10 de octubre de 2014

¿Los sistemas y productos de software actuales y el estándar ISO 25000 son compatibles?

Normalmente las normas y estándares parecen alejadas de los productos tan cambiantes que vemos hoy y las asociamos más con sistemas estables y en alguno casos críticos. ¿Es así? ¿Sólo sirven  para eso?. Trataremos de mostrar que no.

Cuando vemos un producto como una red social, un sitio de comercio electrónico, un juego, u otros de alta interacción con el consumidor cliente / usuario, nos cuesta asociarlo con un estándar que habitualmente lo tenemos por algo burocrático, rígido, y pesado. Por ejemplo la familia de normas ISO 25000 de calidad de sistemas y productos de software, sucesora de la ISO 9126.

Sin embargo antes de descartar estas normas, deberíamos explorar si no contienen guías que nos permiten validar si estamos haciendo lo correcto, si contemplamos todo lo requerido, y fundamentalmente, si podemos hacer algo que luego podamos trasladar a otro producto de software o familia de productos  de software.


De todo esto trata esta presentación la presentación que adjuntamos.

Siguiendo brevemente un ejemplo, en este caso de comercio electrónico veremos como, las distintas consideraciones que tuvieron los diseñadores del software, son contempladas por la norma ISO 25000. 

Asimismo, veremos las novedades que hay a la fecha, octubre 2014, en esta importante norma.

La presentación se encuentra aquí:

Sistemas actuales e ISO 25000

Esperamos debatan y compartan estas conclusiones.

Saludos,
Raúl

viernes, 21 de marzo de 2014

¡Hoy volvemos al Super!

Continuemos con nuestra aventura en el supermercado  iniciada en un post anterior (Una visita al supermercado).


Como sus propietarios notaron una caída en las ventas se propusieron averiguar de cuánto era y a qué se debía dicha caída.

Más allá del indicador del monto de la caída, que era un indicador tardío, les interesaba saber si había alguna otra observación que les permitiera adelantarse a los problemas.  

Descartaron primero las obvias, precio, variedad, ubicación del local, etc., ya que en todas ellas estaban en iguales condiciones que la competencia.

Quedaba por entender entonces algo que estaba ocurriendo dentro del local, entre el cliente y la oferta de nuestro supermercado.  Pensaron varias alternativas, entre ellas:

  •       Contar cuánta gente entraba y cuánta salía sin comprar nada.
  •      Ver los tickets y entender en qué góndolas la gente compraba menos,  a igual precio e igual mercadería que la competencia, habría otros factores que no les convencían.
  •      Detectar cuántos clientes vuelven a comprar luego de la primera compra (licencia poética).
  •      Entender el tipo de cliente que normalmente atraemos y entender sus expectativas (qué le encanta y qué le disgusta).
  •       .……

Podríamos seguir enumerando indicadores que le pongan valor al comportamiento del cliente y tratar de deducir de allí la experiencia  de compra que tiene.
--

Dejemos aquí al supermercadista preocupado y nuevamente hagamos una analogía entre lo dicho y nuestra tarea de crear productos y servicios de software.

Comencemos por la definición de requerimientos o exploración de las necesidades.
Si el comportamiento del usuario es más conocido y manejable nos permitirá la definición de requerimientos algo más precisa, si es menos conocido y manejable nos obligará a explorar.

Para ordenar el trabajo puede ser útil aquí el modelo Kano (1), que nos dice habrá funcionalidad que el producto deberá tener, ya que si ellas nuestro usuario/consumidor ni siquiera lo considerará, habrá otras características que entre más tenga de ellas, más apreciará el producto y finalmente habrá otras que al descubrirlas le encantarán y eso hará que lo considere de calidad superior, y tal vez esté dispuesto a pagar más por él. Es una ayuda, al menos nos acercará a descubrir necesidades y algunas expectativas.

Pero qué ocurre cuando el producto está en operación durante algún tiempo. ¿Cómo podremos descubrirlas? Es una situación parecida a la de nuestro personaje del supermercado que quería verificar la experiencia del consumidor en su local. Buscaba medidas e indicadores que lo orientaran a qué cambiar y mejorar y a qué mantener. Nosotros también.

Dependiendo del tipo de producto/servicio que estemos tratando, algunos indicadores pueden ser parecidos, por ejemplo cantidad de visitantes convertidos en ventas.
Algunas alternativas de qué medir cuando el producto/servicio está operando las plantea la idea de calidad en uso propuesta por la ISO 25010, hoy con poco detalle todavía, pero ayuda. 

Nos hace preguntar por ejemplo:

  • ¿Confía el usuario en el sistema?
  • ¿Hace más cosas en menos tiempo?
  • ¿Está satisfecho con el sistema?
  •  ¿Se logró/mejoró el objetivo económico con la adopción del sistema?
  • ¿Logró lo anterior, confiabilidad, efectividad, satisfacción, en los diferentes contextos de utilización?


En estas entradas: La calidad en uso e Indicadores accionables hay algo más sobre esta idea.

Posiblemente nuestro caso necesite algunos indicadores distintos, o más detallados, o de mayor precisión. Pero esta es una buena aproximación.

Dejamos entonces a nuestro supermercadista de la historia viendo cómo mejorar la experiencia de usuario de sus visitantes y, como él, entendamos que las expectativas al entrar al local, superadas o no, son lo que va a definir finalmente el futuro del negocio.

Viene de Equipos Multidisciplinarios
y de Una visita al supermercado

Saludos,
Raúl
TW: @RaulMartinez582


Referencias:














Kano, Noriaki; Nobuhiku Seraku, Fumio Takahashi, Shinichi Tsuji (April 1984). «Attractive quality and must-be quality»