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

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 prueba y el contexto del producto

Más allá de los procesos y los aspectos técnicos de la prueba de un producto de software (planificar o no, escribir o no casos de prueba, a qué nivel de detalle, tipos de prueba que conviene realizar, ambientes, herramientas, buenas prácticas, modelos de calidad, …), están los equipos de trabajo que llevan adelante estas actividades. Las personas que los forman. Sus intereses y expectativas. Sus conocimientos. Su sentido ético y profesional. Podríamos seguir la lista.

Quedarse sólo a este nivel pensando que la prueba del software es meramente algo técnico y repetitivo que hace un equipo de trabajo, nos hace perder de vista muchos aspectos del contexto que impactan en la calidad del producto de software percibida o “vivida” por los interesados.
Puede conducir al fracaso del producto cuando es recibido por ellos, o a su éxito.
Las expectativas de los interesados se satisfarán o se frustrarán. 
Los requerimientos explícitos e implícitos estarán cumplidos o no, probados o no, se irán corrigiendo los defectos remanentes y evolucionando el producto según nuevos requerimientos aparezcan o se detecten otras necesidades o tendencias, o aparezcan nuevas tecnologías.

Y los interesados son muchos, diversos, internos o externos a las organizaciones que construyen o proveen el producto de software, conocidos o desconocidos, sujetos a control respecto a la forma en que interactúan con el producto o no, interrelacionados de alguna forma, simple o compleja, … 

Los productos (tanto tangibles como intangibles), además de ser de diferentes tipos, se utilizan de diversas maneras, en diferentes ambientes y lugares, por diferentes personas.
Los productos de software actualmente se ejecutan en plataformas complejas, se interconectan, y se regulan en muchos casos.

Los productos existen porque brindan algún valor, son parte de algún servicio que los contiene, o incluso son el centro del servicio.
Por ejemplo, escribimos con un lápiz, pero también podemos hacerlo con otros productos; podemos elegir y cambiar, según el valor que nos brinde el producto en un contexto dado, como el material sobre el que queremos escribir, en qué color, cuán permanente queremos que sea lo escrito, qué tenemos a mano en el momento en que queremos escribir.

El valor es percibido o no por los diversos interesados, a lo largo de su construcción y su vida útil, y el servicio tiene también evolución, aspectos de calidad, y hasta posibilidades de desaparecer la necesidad que le dio origen.
Los productos pueden contribuir a reducir los riesgos o preocupaciones de los interesados, o a su éxito en algún aspecto. O no aportar valor en esos sentidos.

También la cultura de las organizaciones en que los productos y servicios se construyen y/o se brindan, ocupa un lugar preponderante en el contexto del producto y el servicio. Y su facilidad o aversión a encarar cambios de ser conveniente, respecto a la calidad, la fluidez del conocimiento, la estructura, procesos, herramientas, valoración de su personal, entre otros aspectos. ¿Está realmente la organización dispuesta a mejorar la calidad para ser más exitosa? ¿Querrá transmitir a su gente qué es lo que aporta valor al negocio, y cuándo lo está perdiendo? ¿Querrá analizar por qué y emprender un camino de cambios?

¿Tenemos posibilidades de aportar como testers algún valor al negocio sugiriendo pequeños cambios que muestren beneficios en el corto plazo? ¿Estamos dispuestos a hacerlo saliendo de nuestra zona de confort técnica?

Los aspectos más relevantes en el contexto de la calidad del producto de software mencionados están resumidos en este gráfico:

Pero vayamos otra vez a lo técnico. ¿Y con la prueba qué hacemos?

Fundamentalmente, no olvidar que todo ese contexto existe. Si no lo consideramos, pueden quedar aspectos importantes no cubiertos por las pruebas, aunque hayamos pensado, elaborado, ejecutado y/o automatizado cientos de casos de prueba. La identificación de amenazas y riesgos del producto quedará incompleta. La utilización del producto más allá de su construcción podrá tener defectos más o menos fáciles de corregir, pero lo que es más grave, no habremos brindado un buen servicio: proveer a los interesados información valiosa para tomar decisiones respecto al producto de software.  

Las pruebas exploratorias y las planificadas, en cualquier tipo de proceso, pueden alimentarse del contexto para elaborar las ideas y estrategias de prueba. Independiente de nuestra misión específica respecto a un producto dado.

Considerar el contexto nos permitirá brindar un servicio de testing valioso y perdurable, que nos motive a seguir brindándolo, y que motive a nuestros clientes, internos o externos, a seguir comprándolo.

También nos dará la satisfacción de haber contribuido no sólo a elaborar un producto estándar o bueno, sino que deleite.