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

www.rmya.com.ar / Ideas sobre el software / Twitter: @RaulMartinez582

Equipos multidisciplinarios

En el post anterior  Una visita al supermercado mencioné el tema de los equipos que están compuestos por personas que dominan diferentes disciplinas.  Para no que no quede en un enunciado, detallo un poco el tema. 

Como lo que buscamos es la mejor experiencia de usuario posible que lleve al éxito del negocio, el equipo que se conforme debe estar compuesto por todas aquellas personas que puedan colaborar a lograrlo y verificar que realmente se logró. Esto significa que tiene que estar el que hace y el que ve en el campo el resultado de lo hecho. 


Entonces, el equipo multidisciplinario deberá, al menos idealmente:

• Encargarse de un flujo de valor. Esto es entenderlo, diseñarlo, implementarlo y medir su resultado en operación.  Para poder responder ¿qué le aporta/aportó al negocio esta operatoria?
• Ser responsable por ese flujo de valor, es decir tomarlo como propio, no descargando responsabilidades en uno u otro sector. Lo que se construye es de todos y todos en el equipo son responsables por su éxito o su fracaso.

Estos dos puntos nos llevan a que al equipo multidisciplinario lo deben componer entonces: 

• personas del negocio que entiendan qué se requiere y qué se espera del producto/servicio y del flujo de valor en particular, 

• personas técnicas que tenga capacidad para llevar adelante la ejecución 

• y personas de la primera línea de contacto con el usuario que informen el resultado del producto en operación de modo de adecuarlo donde se requiera.

No todos deben saber hacer de todo en el equipo. Si bien sería ideal, también sería poco óptimo y utópico. Pero sí todos deben saber qué se hace y por qué y para qué.  

Ventajas, muchas: sentido de pertenencia, objetivos definidos, indicadores de negocio relacionados a indicadores técnicos, etc.

Obstáculos, bastantes: organizaciones funcionales que no aceptan, por cultura o desconocimiento, otras alternativas de organización; pequeños “caciques” que no ceden su territorio; negocio e implementación separados por fronteras funcionales, etc.; “secretos” del negocio no accesibles a personas técnicas; vivir en urgencias continuas y no encontrar  proyecto ni tiempo para implementar la idea (que entonces nunca aparecerá). 

Resumiendo, como todo primer paso es complejo, no exento de caídas y vueltas a empezar.

Pero en muchas organizaciones que ofrecen productos exitosos, se trabaja en equipos multidisciplinarios.

Viene de Una visita al Supermercado

Sigue en  ¡Hoy volvemos al Super!

Saludos,

Raúl

TW: @RaulMartinez582

Nota: la imagen muestra un momento del rescate de los 33 mineros chilenos de la mina de cobre San José durante agosto 2010.

Una visita al supermercado

Imaginen un sábado por la mañana y Uds. entrando al supermercado cercano a su casa.

Allí hay góndolas que exhiben los productos, encuentran las marcas habituales, los precios no parecen fuera de lugar.

Todo parece normal, pero hay algo que los incomoda, los pasillos estrechos, la limpieza en alguno de los exhibidores  no es la mejor, cierto desorden en la mercadería, etc.

Efectúan la compra, hacen fila en la caja, abonan y se retiran.

Al salir les queda una sensación que podría expresarse así: “Compré lo que necesitaba pero no volvería, o sólo lo haría en caso de necesidad; prefiero caminar más y pagar algo más caro pero sentirme mejor comprando”. Con esto termina este relato cotidiano.

Hagamos una analogía entre lo dicho y nuestra tarea de crear productos y servicios de software.

Los requerimientos o requisitos están cumplidos, las góndolas, la mercadería y los precios. Esa necesidad del consumidor la cubren. Sin embargo,  a pesar de ello:

Las expectativas, es decir aquello que el consumidor esperaba al entrar al supermercado (que puede o no ser realista) basado en experiencias previas, no fueron satisfechas. Encontró pasillos angostos, falta de limpieza, desorden, etc.

Su experiencia como consumidor, la suma de lo físico (góndolas, productos, precios) y lo emocional, no fue buena. Por lo tanto, a menos que tenga necesidad o le convenga por motivos por ejemplo económicos, probablemente no vuelva.

¿Adónde va todo esto?

Se trabajó y trabaja mucho en el área de requerimientos, su  definición, precisión, modelización, que sin duda son importantes. Pero el usuario/cliente/consumidor cada vez tiene más experiencia, utiliza más productos, y sus expectativas aumentan. Su experiencia de usuario incluirá lo que el producto hace, y cómo se esperaba que lo hiciera (lo funcional y parte de lo no funcional) y las expectativas cumplidas o no por el producto en su entorno real de ejecución.

¿Tenemos en cuenta esto también en nuestros desarrollos? ¿Qué ayudaría a considerar más estos temas?

Una propuesta  rápida y seguramente incompleta es:

Trabajar en equipos multidisciplinarios. Cada vez más importante para el éxito de los productos de software y servicios apoyados en ellos. Debemos entender no sólo cómo definir requisitos sino también cómo evaluar  comportamientos de los usuarios / consumidores ante el producto.

Evaluar la experiencia de usuario que trasciende por mucho a la usabilidad aunque la contiene. Suele medirse en algunos casos la usabilidad, pero no es todo lo que importa.

Obtener realimentación proveniente del producto en operación (calidad en uso).  Es fundamental ya que únicamente analizando esta información podremos llegar a entender cómo se siente el usuario interactuando con el producto o servicio.

Definir indicadores relacionados al negocio que muestren el comportamiento del producto / servicio desde su construcción hasta su comportamiento en Producción, además de los puntuales relacionados con la calidad de su construcción. 

Algunos podrán considerar que los puntos enunciados no son de su responsabilidad. Tal vez sea así. Pero… ¿Nuestra responsabilidad es lograr la calidad constructiva y conforme a requerimientos? ¿Sólo eso? ¿O es más amplia y comprende  que además el producto sea exitoso para el negocio?.  Para pensar al menos.


Continua en Equipos multidisciplinarios 
Y en ¡Hoy volvemos al Super!

Saludos,

Raúl

TW: @RaulMartinez582

Pequeños logros

Grandes cambios producen generalmente grandes rechazos. 
La idea de buscar pequeños logros intenta mejorar esta situación.

Los pequeños logros son una serie de objetivos que se consiguen, cada uno pequeño, que vistos por sí solos son poco significativos, pero que en conjunto tienden a producir una mejora importante.

Estas son algunas de sus características:

     Visibles, concretos e implementados, completos ^{(1 y 2)}

Es fácil reconocer su resultado, resuelven algo concreto y están terminados.

     No necesariamente ordenados

            No siguen una secuencia ya que no están implementando un proceso en partes, sino que el orden lo marca la nueva demanda creada por el logro recién  implementado.

     Unidireccionales – van todos en la misma dirección

No se contradicen y van todos detrás de un objetivo identificable.

      Muchos y pequeños

            Resuelven temas puntuales, tienen objetivos modestos, se pueden hacer varios (muchos) de ellos en corto tiempo.

     Tienden a propagarse

            Entusiasman y tienden a ser copiados por otras áreas de la Organización al ver los resultados obtenidos.

     Se festejan

            Como todo objetivo que se consigue, debe festejarse.

Tienen además la ventaja de ser comprensibles por la mayoría de las personas, ya que el objetivo es cercano y visible.

Son “políticamente correctos”, es decir no resuelven un gran problema, que también indica un gran error, sino que apuntan a cosas a primera vista inofensivas o menores, disminuyendo la resistencia a los cambios propuestos.

Reducen la ansiedad, muestran avance y evitan el estrés de un gran cambio cultural profundo. No se requiere un re-entrenamiento importante dado que son localizados.

Riesgos que genera este enfoque

- Expectativas propias o de los interesados mayores a los logros.

- Mejoras puntuales en un área pueden producir cuellos de botella en la performance de otros sectores.

Saludos,

Raúl

TW: @RaulMartinez582

(1 y 2) Referencias:

Weick, K. “Small Wins: Redefining the Scale of Social Problems,” 1984
¿Cambio qué cambio? Complejidad de un cambio

La Calidad en Uso debe verse con cuidado (ISO/IEC 25010)

La ISO 9126 y la ISO 25000 describen el concepto de calidad en uso.

Tal vez por simple cercanía de nombres, algunas veces se asocia calidad en uso a usabilidad, que si bien es importante y puede definirse a través de otras características como efectividad, eficiencia y satisfacción del usuario, no es el único criterio que propone, ni necesariamente el más importante.

La idea de calidad en uso es la más cercana al resultado final del proyecto, desde el punto de vista del negocio.

Para evaluarla deberemos averiguar, a través del usuario utilizando el sistema en su ambiente real de trabajo, cosas como las siguientes:

• ¿Confía el usuario en el sistema?
• ¿Hace más cosas en menos tiempo?
• ¿Está satisfecho el usuario 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?
• ........

Para ello necesitamos valores objetivo, y así poder comparar. Aquí las expectativas juegan un papel fundamental. 

Como vemos excede y en gran medida el aspecto usabilidad y se acerca más al resultado de negocio de la adopción del sistema/software por el usuario.

De acuerdo a lo que desarrollamos en post anterior sobre  "Acercarnos al negocio", tendremos mayor o menor responsabilidad en este aspecto tan fundamental de la calidad.

Saludos,

Raúl

TW: @RaulMartinez582

Acercarnos al negocio (Cuando el negocio es el desarrollo)

En la primera entrada mencionamos aquellas compañías cuyo negocio es desarrollar software para terceros.

Los modelos de trabajo: 

Tradicionales de desarrollo de software, y administración de proyectos si se trabaja sobre requerimientos conocidos.

La aplicación de un modelo exploratorio llevaría a que el desarrollador permanezca asociado al producto una vez que éste está en la calle, de modo de ir incorporando las funcionalidades que se van descubriendo como necesarias. Cosa que no siempre sucede.

La calidad: en este contexto significa cumplir con los requerimientos en tiempo y forma ante el cliente, y cumplir con los objetivos de negocio ante la propia compañía de desarrollo.

Además, en este caso, no formalizar los requerimientos implica un riesgo importante ya que el desarrollador tratará de aplicar un modelo de tipo “fábrica”, es decir trabajar contra requerimientos. Si éstos no están explicitados o hay que descubrirlos, el modelo mencionado no aplica, y se gasta tiempo y dinero inútilmente, atentando contra las expectativas de calidad que se tenían del proveedor.

Contexto: complicado y ordenado.

Saludos,

Raúl

TW: @RaulMartinez582

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

Saludos,

Raúl

TW: @RaulMartinez582


Post relacionados

http://ideassobresoftware.blogspot.com.ar/2013/10/acercarnos-al-negocio-back-office.html

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/09/todavia-quiere-seguir-jugando.html 

http://ideassobresoftware.blogspot.com.ar/2013/06/indicadores-accionables.html

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

http://ideassobresoftware.blogspot.com.ar/2013/10/acercarnos-al-negocio-back-office.html

http://ideassobresoftware.blogspot.com.ar/2013/11/acercandonos-al-negocio-con-el-cliente.html

http://ideassobresoftware.blogspot.com.ar/2013/06/indicadores-accionables.html

Saludos,

Raúl

TW: @RaulMartinez582

¿Hace falta un terremoto?

Al leer tiempo atrás conceptos de BCM (Business Continuity Management) y de ITSCM (IT Service Continuity Management), no pude dejar de relacionar el tema con algunos aspectos de las pruebas de software, la evaluación y mitigación de riesgos y la gestión de servicios en general. 

Esos aspectos están relacionados también con las características / sub-características / métricas de calidad de producto descriptas en los estándares ISO/IEC 25000 SQuaRE de calidad de productos de software y su predecesor ISO 9126, el que pueden evaluarse según el proceso descripto por la norma ISO 14598, con los estándares ISO 20000 que especifican los requisitos de implementación de la gestión de servicios de TI y con la evaluación de expectativas vs percepciones de la calidad de los servicios que analiza ServQual (Ver Referencias [5]).

En definitiva, esos aspectos se relacionan con los requisitos o requerimientos no funcionales (RNFs) de las aplicaciones que construimos y probamos, que deberían reflejar las expectativas de clientes y otros interesados y deberían ser posibles de cumplir vía el diseño de las aplicaciones. 

Lamentablemente, en muchas ocasiones, estos aspectos son ignorados o postergados en los proyectos de construcción de software, hasta que ocurren desastres, accidentes, ataques u otros incidentes más o menos críticos, que no siempre necesitan ser de la gravedad de un terremoto, pero que afectan a la disponibilidad de los servicios de TI, o incluso a la posibilidad o forma de restaurar esos servicios luego de algún evento que ha afectado a su continuidad.

¿Por qué digo que lamentablemente estos aspectos son ignorados o postergados?

Porque suele ocurrir que:

·         Los RNFs no están especificados, detallados y/o cuantificados.
·         Se considera que no es momento de probarlos, porque se puede hacer más adelante, o no son riesgosos, o no hay tiempo antes de salir a producción.

·         Se considera que no es momento de incluirlos en el análisis o diseño de la solución, porque se pueden agregar más adelante.
·         No se ha considerado qué puede ocurrir en ambientes productivos, con mayor interacción de componentes de HW / SW que en los ambientes de prueba.
·         No se ha previsto qué pasa con el crecimiento de tamaño de entidades de datos, y/o no se han previsto mecanismos de depuración de las mismas.
·         No se han previsto mecanismos de recuperación ante caídas, o lo más grave aún, no se ha analizado o diseñado para gestionar transacciones en las aplicaciones que lo requieren. También se considera que esto es algo que puede agregarse más tarde, o que lo provee el software.
·         No se ha planificado quién, cuándo, cómo se actúa ante algún incidente o desastre, o cómo se restaurará la operación normal del sistema, o en qué condiciones de pérdida de información podrá hacerse, o se desconoce incluso si toda la información necesaria está respaldada.
·         No se ha analizado si en función a las características y tipo de solución de software o de servicio ofrecido, existen disposiciones legales o regulatorias que apliquen a la misma.
·         Se considera que todo se resuelve agregando más o mejores servidores / disco / memoria / hardware de comunicaciones.
·         … y seguramente cada uno tiene un conjunto más de ítems que agregar a esta lista, a partir de su experiencia en diversos proyectos y organizaciones…

Mi opinión

Desde nuestro rol en las áreas de Calidad o como líderes de práctica, líderes de equipos, o como testers, es nuestra responsabilidad llamar la atención sobre estos temas al líder de proyecto, cuando consideramos que pueden haber sido descuidados, o no los encontramos representados en los planes de proyecto y/o de prueba. Al menos preguntar. 
Hacen a la calidad de los productos y servicios que estamos colaborando a entregar, y finalmente a la satisfacción de las expectativas de los interesados. 

Está claro que los requerimientos no los ponemos nosotros, ni podemos constituirnos en los "guardianes de la calidad" impidiendo que se entreguen a producción productos que creemos no están totalmente probados o todavía presentan defectos… por algo hablamos de pruebas basadas en riesgos, de entregar productos con un nivel suficiente de calidad, de priorizar defectos y no corregirlos, de involucrar a referentes usuarios en esa priorización, etc…

Pero también considero que está totalmente en línea con nuestra misión como testers, capacitarnos y "evangelizar" sobre estos conceptos… antes de que nos golpee algún terremoto.

Post originalmente publicado en http://excelza.blogspot.com.ar/ - 11-10-2011

Referencias

1.    www.iso.org

2.    ISO/IEC 25000 SQuaRE
Software Engineering - Software product Quality Requirements and Evaluation

3.    www.itil.org

4.    Implementing ISO/IEC 20000 Certification - The Roadmap (ITSM Library) - Van Haren Publishing

5.    SERVQUAL: A Multiple-Item  Scale for Measuring Customer Perceptions of Service Quality  

6.    ISO/IEC TR 9126-3:2003 - Software engineering — Product quality — Part 3: Internal metrics.