¿Son compatibles los productos de software actuales con la norma ISO 25000?

Dada la velocidad con que se producen hoy los cambios en la tecnología, y consecuentemente en el software que las maneja, los tiempos de proyectos cada vez más cortos, la complejidad de determinar en forma precisa sus requerimientos y resultados, surge una pregunta: 

¿Puede ayudar un estándar de calidad de producto como ISO 25000 a una mejor comprensión del problema y a resolverlo teniendo en cuenta el contexto antes mencionado?

¿Son compatibles los productos de software actuales con la norma ISO 25000? from Raúl Martínez

Saludos,
Raúl
@RaulMartinez582

Desarrollar software hoy

Desarrollar software hoy. Sólo controlamos lo encerrado en el círculo.
Partes tomadas de bi-modal IT del Gartner Group.


Raúl Martínez‏@RaulMartinez582

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 y 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

⁽¹⁾ 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

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

“Secretos”  detrás del éxito

 Esta presentación explora algunos de los “secretos”  que hay detrás del éxito de ciertos  productos de software y/o servicios para comprender si con acciones similares, podremos tener éxito con nuestros productos y servicios.

Cuando nos proponemos crear un producto de calidad, de alto impacto y exitoso para nuestro negocio, siendo nosotros:

Un emprendedor o

Alguien que desarrolla en forma interna o para terceros

en algunos casos nos preocupa el proceso que seguimos, los defectos que encontramos, o bien el aspecto de usabilidad del  producto, estética y cantidad de funciones que provee.

Sin embargo nada de esto parece alcanzar,

¿Por qué?

¿Faltó ingeniería?

¿Faltó organización?

¿Fue útil al negocio?

A menos que veamos todo como una unidad difícilmente alcanzaremos el éxito.

De todo esto trata esta presentación.

Las propuestas son prácticas, y surgen después de haber visto, discutido y expuesto todos estos temas en los últimos años con los responsables de este caso y otros casos, no siempre exitosos, en otras empresas.

Esperamos debatan y compartan estas conclusiones.

La presentación se puede encontrar aquí:

Seminario de Calidad de producto



Saludos,
Raúl
@RaulMartinez582

El producto de software Calidad y contexto

Está publicada la nueva versión de nuestro seminario sobre Calidad de Producto (Mayo 2014).

Allí podrán ver un caso real, una nueva línea de negocios de Mercado Libre, y la posible aplicación de distintas herramientas o prácticas, todas conocidas (Kano, mapas de empatía) pero no necesariamente utilizadas en nuestros desarrollos.   

En el tipo de desarrollo que se presenta, además de los requerimientos “debe estar” utilizando la terminología del modelo Kano, aparece la necesidad de buscar aquello que “diferencien” al negocio del  resto de la competencia.

También se ve la identificación de diversos interesados, dado que todos ellos evaluarán la calidad del producto desde su punto de vista.

La presentación plantea a lo largo de su desarrollo la necesidad de ver a la calidad no como un conjunto de herramientas y prácticas aisladas y sumadas, sino como una composición donde los aspectos: Producto y sus características, Interesado y sus expectativas, Organización y su visión de la calidad y la Cultura de la organización que tratamos, colaboran a potenciar la satisfacción del cliente y el valor para su negocio.

Al final de la presentación hay una serie de preguntas que creemos es interesante tratar de responderse y que entendemos son las dudas que habitualmente se tienen al encarar el tema calidad.

Esta presentación fue actualizada en setiembre 2014, ver http://www.slideshare.net/rmartinez582/el-producto-de-software-negocio-calidad-y-contexto 

Saludos,

Raúl

Twitter: @RaulMartinez582

¡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 ⁽¹⁾, 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»

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