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 ovación de pie

Es cada vez mayor el componente social en los servicios y productos de software. El aspecto de procedimiento, que debe existir y operar correctamente, va camino a ser secundario.

Una simple intranet corporativa incorpora el botón “me gusta” en su diseño para poder mostrar nuestra aceptación o no sobre lo que leímos. 
Este comportamiento que parece simple, hacer  un click en un icono, analizado, puede revelarnos aspectos que nos interesan para diseñar un sistema competitivo.

Para explicarlo con palabras sencillas el ejemplo de la “Ovación de pie” ^{(ver 1,2)} es útil.

Imaginemos que queremos tratar de entender por qué la gente aplaude de pie en algunas circunstancias y en otras no.

Una primera aproximación sería que la gente espera un nivel de calidad del espectáculo. Superado ese nivel, se levanta y aplaude, no antes.

Esta aproximación es útil, aunque demasiado simplificada. Por ejemplo asume que la gente está ubicada en un único lugar puntual, lo cual no es real. Asume también que la gente no se conoce entre sí, es decir que cada uno actúa sin considerar a su vecino, lo cual tampoco tiene que ser así.

La realidad es más compleja. La gente se distribuye en la sala y, posiblemente, si reconoce una cara familiar y puede, tratará de sentarse junto a la persona conocida. Asimismo un grupo de personas que se conocía previamente podrían ir juntos a la función.

Todo esto hace que el comportamiento de la persona sea distinto en cada situación, y podría pensar:

•       No me levanto
•      No me iba a levantar pero como se levantó el de adelante y el del costado, me    levanto y aplaudo de pie yo también
•     Me levanto y aplaudo de pie porque mi amigo lo hizo
•     Fuimos juntos y nos pusimos de acuerdo previamente en ponernos de pie en      ciertos momentos de la función
•    ...........

Y así podríamos seguir.

Bien, ¿pero para que nos sirve entender todo esto?

Por ejemplo para diseñar una sala de espectáculos e influenciar en el comportamiento de los espectadores.

• ¿Me conviene poner más palcos? 
• ¿Me conviene poner gente “amiga” que se levante y aplauda en lugares visibles, por ejemplo los palcos, o en la primera fila y así inducir a que se levante el resto?
• ............

Tener a la gente aplaudiendo de pie, haría que la obra gane buena fama en la prensa y así vender más entradas para las funciones futuras y también más caras.

La conclusión: 

Nuestro trabajo no consiste en imponer un procedimiento estricto de comportamiento, que en el caso del espectáculo sería imposible. Sino proveer una plataforma para que los intervinientes desarrollen sus acciones y tratar que se genere el comportamiento que yo espero. Dirigir esas acciones hacia nuestro objetivo, por ejemplo que una visita se convierta en venta, es lo que debemos aprovechar.

Reglas simples, levantarse o no para aplaudir, presionar o no el “me gusta”, poner o no el HT, pueden desencadenar acciones complejas entre participantes, que se conocen o no, pero que están conectados.

La calidad del sistema, medida en un indicador como el antes mencionado (convertir visitas en ventas) sólo puede verse cuando el producto esté en uso, pero seguramente las formas de inducirlas pueden estudiarse antes. 

Podemos pensar "que no es mi caso....., que yo no hago sistemas así.....", tal vez, por ahora. Recuerdan el dicho de la luz al final del túnel, puede ser la salida ...o la locomotora que viene.

Saludos,

Raúl

TW: @RaulMartinez582

Referencias:

1. Complex Adaptive Systems. Page, Miller, 2007 Princeton Univ Press

2. Is Twitter a Complex Adaptive System?. Venessa Miemis 

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

Fotocopiadoras, calidad y negocio

La calidad sin entender ni ayudar directamente al negocio es sólo un  ejercicio intelectual que finalmente terminará por ser abandonado.

¿Cuántos proyectos de “mejora” se abandonan, se olvidan o simplemente se ignoran?

Difícil saber el número pero seguramente son más de los que terminan con éxito.

Evitando ser negativos veamos entonces los que concluyen exitosamente y se sostienen en el tiempo (como en todo lo importante no sólo es llegar sino mantenerse).

La calidad por la calidad misma es algo vacío. Puede ser de interés intelectual, pero de poca utilidad para la empresa. Podremos sobrevivir un tiempo, pero finalmente alguien pensará: ¿Por qué estamos gastando en eso? (“eso” es nuestra mejora) y nuestro presupuesto desaparecerá para ser reasignado a otras áreas.

¿Pero por qué ocurre esto? No les interesa la calidad (la excusa más fácil que tenemos a mano).

No creo que sea eso, que no les interese, simplemente no logran conectar nuestra propuesta de calidad con el negocio de la Compañía.

Entonces, excepto que la mejora, certificación o como sea que se corporice sirva para lograr un beneficio (por ejemplo una subvención, baja de impuestos, ingresar en mercados donde no nos conocen y el certificado/evaluación es requisito, etc.) caso en el cual ayuda al negocio, difícilmente se mantendrá. Es un gasto, por lo tanto tratará de reducirse.

Podríamos seguir pero creo que quedó claro.

¿Cuál es entonces el camino para que realmente un movimiento de calidad se instale y permanezca en la Organización?

Mi respuesta es: entendiendo el negocio en el que estamos (no siempre todos en la empresa lo tienen en claro) y diseñar las acciones de calidad para ayudar a ese negocio.

Podemos tomar modelos pre-hechos y  adecuarlos (CMMI, ISO 9000, ISO 25000 y otros) o desarrollar  algo propio siguiendo la idea de calidad que el negocio necesita.

Pero siempre, al menos en este razonamiento, el negocio está primero y la calidad es la que requiere para competir.

Finalmente la parte dura. Nosotros o nuestro sector seremos reemplazables cuando lo que ofrecemos es lo mismo que ofrece un tercero (y hasta posiblemente más barato), pero difícilmente nos podrán reemplazar si formamos parte del negocio, lo entendemos y lo ayudamos.

Pero eso hay que ganarlo, si seguimos encerrados en nuestra zona de confort técnica y pensando que la responsabilidad del negocio es de otro y no nuestra, finalmente nos van a reemplazar.

Que lo del reemplazo está lejos, puede ser, la fotocopiadora parecía y fue un excelente negocio durante bastante tiempo. Pero hoy, ¿invertiríamos en un negocio de fotocopiadoras?

               

Saludos,

Raúl

TW: @RaulMartinez582

Sobre Pruebas de software y Servicios de TI

Anteriormente comenté sobre nuestra misión como testers y sobre el enfoque del testing como servicio y como mitigador de riesgos. 
Entre lo que tenemos que hacer, obviamente es muy importante:

• Cuestionar y evaluar el producto que estamos probando.
• Focalizar los riesgos, entender y gestionar los cambios que ocurren en el proyecto o el contexto del negocio durante las pruebas.
• Entender qué es prioritario probar, qué funcionalidad y atributos de calidad son imprescindibles para lograr la satisfacción de usuarios y clientes, bases sin las que no se obtendrá un producto de software útil y exitoso.

También me parece interesante compartir un enfoque más amplio del tema, mirado desde el punto de vista de los Servicios de TI.

¿Pará qué está TI?

Para brindar Servicios al Negocio

Según los conceptos actuales, un servicio es un:

Donde los Servicios van mucho más allá de la infraestructura, se apoyan en ella, y deben brindar valor a las áreas del Negocio que los requieren.

¿Qué significa esto para los testers?

La mayoría de los servicios que TI provee al negocio, incluyen sistemas de información computarizados, o se brindan utilizando sistemas o productos de software, ya sean paquetes adquiridos y parametrizados / adaptados, o desarrollos a medida.  De hecho, hay servicios que no podrían existir sin un sistema informático detrás.  Por lo que, para que el cliente reciba el resultado esperado del servicio, el sistema informático tiene que funcionar “bien”, o sea, dentro de pautas de calidad establecidas y acordadas.

Las pautas de calidad del servicio tienen que ver con:

Y aquí es entonces donde debemos poner foco, en el adecuado funcionamiento de los servicios, según su utilidad y garantía. Por ejemplo:

Lo que implica que, las pautas de utilidad y garantía contra las que verifiquemos y validemos las aplicaciones, tienen que contribuir a la calidad del servicio, y provenir de su definición (las mostradas no son las únicas posibles).

¿Cómo se construye un servicio?

Las actividades que conocemos como formando parte del ciclo de vida de la construcción de software, están realmente insertas en el ciclo de vida de construcción del servicio, al igual que deben estarlo nuestras actividades de verificación y validación en cada proyecto o cambio que lo afecte, actividades que deberán permitir diagnosticar acerca de la utilidad y la garantía:

En este sentido, nuestros oráculos de utilidad y garantía, sin duda tienen que estar en línea con, y originarse en, los requerimientos de utilidad y garantía del servicio.

En otras palabras, las aplicaciones que contribuyen a la arquitectura del servicio, tienen que tener funcionalidad y atributos de calidad tales, que el servicio pueda proveer la utilidad y garantía acordada con el cliente y requerida por los usuarios.

Durante la vida útil del servicio, la aplicación de software sufrirá cambios, consecuencia de los cambios solicitados al servicio, que deberemos evaluar, probar e implementar oportunamente, y que operará en un contexto en que tendremos que saber cómo gestionar los incidentes y problemas (del servicio y de la aplicación),  y ejecutar proactivamente mejoras y nuevos proyectos que contribuyan a que el servicio comprometido no se degrade, y siga brindando valor al negocio.

Algunas conclusiones posibles

Creo que esta visión “macro” del servicio, y las buenas prácticas de la industria (ITIL u otros modelos) o los estándares internacionales relacionados (ISO 20000 y otros como ISO 25000), son fundamentales para entender nuestro trabajo de testers y colocarlo en el marco adecuado.

Según nuestra misión (por ejemplo hacer pruebas durante la construcción, pruebas de homologación, o colaborar en pruebas de aceptación de usuarios), estaremos trabajando en un nivel distinto del clásico Modelo V de prueba, y nuestras actividades estarán más focalizadas en la prueba de una aplicación particular, o en la prueba conjunta de las aplicaciones que aportan al servicio completo. 

Lo importante es que podamos entender esa misión, y comprender lo que implica respecto a las pruebas a ejecutar.

La visión del Servicio de TI al negocio también debe darnos ideas respecto a:

·         dónde buscar los requerimientos a testear

·         cómo obtener la cuantificación de los requerimientos de calidad a evaluar

·         cómo gestionar ambientes, configuración, versiones

·         cómo liberar software

·         cómo atender incidentes

·         cómo gestionar cambios

En definitiva, lo que hacemos siempre puede ser mejorado, y la visión del Servicio de TI y su calidad son una excelente e imprescindible guía para nuestro trabajo.
Como testers, tenemos que asumir nuestro pedacito de la responsabilidad.

Nota: Revisión del artículo originalmente publicado en excelza el 11/12/2009