miércoles, 29 de mayo de 2013

¿La bala de plata o el eslabón perdido?


Realmente lo que voy a plantear no creo que sea ninguna de esas dos cosas. Pero preocuparnos por el producto, más allá de la visión de su proceso de manufactura en mi opinión es crucial.

No estoy diciendo nada nuevo, sin embargo vivimos bastante inmersos en nuestro proceso de producción, cómo administrarlo,  mejorarlo, optimizarlo, etc. En mi opinión está  muy bien. Pero la apuesta es mayor, mucho mayor.

Tal vez por el lenguaje, tal vez por el desinterés en nuestro proceso por parte de las áreas interesadas, no es ese un tema que arrastre multitudes. Guardando las distancias es cómo me puede interesar a mí el proceso de fabricación del queso blanco de Danone siendo consumidor del mismo. Como curiosidad lo veré una vez, si lo hago, pero luego quiero probarlo y decidir si me gusta o no. Vuelvo a repetir, guardando las distancias del ejemplo,  que es sólo para escenificar el tema.

El producto y no me refiero sólo a la entrega (delivery) del mismo, sino a su descubrimiento, es lo que nos acercará más a los interesados, incluyendo entre ellos a los usuarios, nos dará un lenguaje compartido, nos incluirá en el negocio, y finalmente hará que el negocio sea exitoso, donde el producto será un vehículo más en ese éxito.

Tal vez así pasemos de desarrollar “conforme a requerimientos” a desarrollar productos útiles y que hagan al negocio exitoso, creo que esa debe ser la guía. La primera posición nos hace intercambiables con alguien que desarrolle igual o mejor que nosotros los mismos requerimientos. Lo segundo nos hace imprescindibles.

No abandonemos los procesos pero tampoco ignoremos qué fue de la vida del producto luego de salir a Producción. Allí se juega el partido. 

Hemos entregado... ¿Y?

Aun luego de finalizar un proyecto "en tiempo y forma", cumpliendo compromisos y dentro de las restricciones, podemos encontrarnos con algunas sorpresas desagradables, incluso el rechazo o las objeciones del cliente o algunos usuarios.
Esto se relaciona con que el proceso de construcción afecta a la calidad del producto de software, pero no la asegura.

El primer indicio de su calidad en uso aparece en muchos casos recién en las pruebas de aceptación, cuando el mismo está a nuestro criterio listo para pasar a producción. ¡Es muy tarde! ¡Es una visión incompleta respecto a la utilización real que tendrá!

lunes, 20 de mayo de 2013

Lecciones de Pixar

“Debes dejar que las cosas fracasen

con la idea de que es mejor corregir los errores 

que intentar prevenir todos”




En ciertas industrias se considera estratégica la capacidad de tomar decisiones basadas en el riesgo.
Aplicado al software y a ciertos negocios, la pregunta sería: tomo mayor riesgo si tengo un error en producción versus si no implemento a tiempo un cambio o nuevo desarrollo?
La respuesta a esta pregunta en algunos casos será parte de la supervivencia del negocio en el tiempo.

domingo, 19 de mayo de 2013

Calidad y Casualidad

Esas palabras Calidad y Casualidad (en español) sólo difieren en tres letras.

En un producto se podría interpretar así: se logró Calidad por Casualidad, es decir se acertó una vez con los gustos de los interesados, se obtuvo un producto útil y exitoso y allí terminó. El segundo no lo es, ni el resto, si hay resto. 

Tal vez se logró la calidad  por casualidad. 
No estaba pensada, mucho menos planificada. Sin embargo fue exitoso.

Creo que hay varios casos de productos muy conocidos, sobre todo sociales, que han recorrido o están recorriendo este camino. Fueron premiados por los inversores que piden más de lo mismo, y el producto se ramificó pero sin cambiar su esencia. Es una empresa de un solo producto y un solo modelo.  
Pero en un punto ya no alcanzan las ramas y comienzan a aparecer competidores más ingeniosos que finalmente logran desplazarlo.

Se podrá crear otro? O ese fue obra de la Calidad por Casualidad? 

Posiblemente nadie lo lamente hasta tener necesidad de crear el segundo producto...


Nota: es cierto que hay descubrimientos puntuales que revolucionaron el mundo, pero debe darse también la casualidad de que ese sea nuestro caso.

sábado, 18 de mayo de 2013

Cómo avanzar hacia ser protagonistas de la calidad

En línea con el post de Rodrigo y con uno anterior de Raúl sobre la comunicación, ésta última ayuda sin duda a ser protagonistas.

A efectos de completar el proyecto entregando un producto útil y exitoso (para todas las partes), es fundamental una buena comunicación y relación con todos los interesados por parte del equipo de proyecto, así como lo es entender el beneficio que brindará al negocio.

Esa buena comunicación ayudará a lograr que los interesados transmitan mejor sus necesidades, se involucren más en el día a día, y reciban finalmente un producto de calidad, sin tantos tropiezos.

viernes, 17 de mayo de 2013

Víctimas o Protagonistas de la Calidad?


Un maestro entra al aula sosteniendo en su mano una pelota de golf.
Se para frente a la clase, estira su brazo al frente, abre su mano y la pelota cae al suelo.
Mira a sus alumnos y les pregunta: Alguno de ustedes puede explicarme por qué cayó la pelota al suelo?
Luego de unos minutos de murmullo, un alumno levantó su mano y respondió: Maestro, es muy simple, claramente la pelota de golf cayó al piso atraída por la fuerza de la gravedad. 
El maestro validó la respuesta y pidió nuevamente que alguien más diera una explicación de lo sucedido.
Al rato, otro alumno levantó su mano y respondió: Maestro, la pelota cayó al piso porque usted abrió su mano.
El maestro validó también la respuesta y luego de un silencio le dijo a sus alumnos:
Si bien ambas respuestas son correctas, existe una sutil pero muy poderosa diferencia.
La primer respuesta me dejó fuera del problema y por lo tanto de la solución. La "culpa" es de la gravedad y no puedo evitarlo.
Por el contrario, la segunda respuesta me colocó en el centro del problema y por lo tanto de la solución dándome el poder de solucionarlo: si no abro la mano la pelota no cae al piso.
Luego concluyó: hay dos tipos de personas, los que eligen ser víctimas o los que deciden ser protagonistas. Ustedes deciden todos los días con cuál de los dos paradigmas eligen vivir.

Algunas preguntas para reflexionar:

  • Qué tipo de organización tenemos: víctima o protagonista de la calidad?
  • En mi organización los defectos y falta de calidad son atribuibles siempre a una persona, sector o proceso? (ley de gravedad!)
  • Cómo nos definimos frente a la calidad, dentro o fuera del problema?
  • Cuál es la dinámica organizacional que se visualiza frente a problemas de calidad? (búsqueda de culpables?)
  • La calidad es siempre una decisión de la "alta dirección"? 
  • Cuánto influye en la calidad mi tarea diaria?
  • Cuántas cosas puedo hacer/cambiar de mi tarea diaria sin necesidad de pedir permiso y que contribuyen a la calidad? (decido no abrir la mano!)
  • Es más cómodo ser víctimas de la calidad (QA no testea bien)?
  • Las organizaciones que son protagonistas vs las que son víctimas de la calidad tienen una cultura y diseño organizacional diferente?.
  • Ser protagonistas genera resultados mucho más rápido y de tamaño mayor que los de ser víctima?
  • Los clientes perciben experiencias distintas de una organización protagonista de las de una víctima?
  • Es una ventaja competitiva ser protagonistas de la calidad?

Siguiendo con la calidad "partida"

Respecto a los ítem c y d que menciona Raúl, como testers hemos observado (y sufrido) muchas veces las consecuencias de estos aspectos (que son sólo unos pocos de los muchos que pueden dificultar el éxito de nuestro trabajo):

  • Características de calidad no especificadas o no cuantificadas con metas claras.
  • Dificultades para lograr que el cliente o su representante definan cuáles son los requerimientos, casos de uso o escenarios funcionales prioritarios para su aplicación, según la especificación de la que se parta.
  • Dificultades para lograr que el cliente o su representante entiendan la necesidad y conveniencia de priorizar los defectos para su corrección, y la lleven a cabo oportunamente.
  • Escasa o total ausencia del cliente o su representante hasta que el producto es finalmente entregado para aceptación.
Esto resulta en mayores riesgos en el proyecto, mínimamente respecto a:

  • Poder pensar, planificar y luego controlar, qué conviene probar del producto de software dado, para mitigar adecuadamente los riesgos identificados en relación al producto, a su contexto y a su devenir.
  • Ajustar los planes a lo importante y a las restricciones existentes.
  • Poder negociar alcance (y no tener que hacer recortes / "negociación" de la calidad).

Inclusive, dado que "riesgo" no es una palabra bien recibida en muchos casos, ... "de eso mejor no hablar en este proyecto o con este cliente".

Muchos de estos aspectos afectan también a quienes lideran proyectos, diseñan, analizan y desarrollan específicamente, ya que se encuentran con muchas indefiniciones, y pueden tomar decisiones incorrectas o inconvenientes que afectarán a lo esperado por el cliente y a los resultados del proyecto.

Calidad Partida????




-El desarrollador externo, o interno pero que opera como un sector que produce y mantiene software, considerará su trabajo de calidad si cumple con las especificaciones para su fabricación, no hay desperdicio, cumple en tiempo y costos.

-El cliente, externo o interno, considerará el producto de calidad si cumple con su meta de tener un producto exitoso, medido en $$$ o cualquier otra medida del éxito.

a. Son compatibles estas dos visiones de la calidad?
b. Se puede dividir de esta forma sin perder la calidad?
c. Puede un desarrollador sin conocer cómo mide el éxito final su cliente fabricar software que sea exitoso?
d. El cliente, cómo explica un indicador de éxito (o no) de su negocio para que un desarrollador, al que no le fue informado qué es finalmente éxito, repare o mejore un feature determinado?

Tal vez poco claro todavía pero para pensar.


Ref:
La pirámide interpretada por mi está aca:
Redefining-software-quality; http://gojko.net, 2012, Gojko Adzic.


jueves, 16 de mayo de 2013

Llamaríamos a esto un problema de calidad?

Ambos casos reales por supuesto.

Caso 1. 
Tweeter cae por el volumen de mensajes intercambiado durante el último debate presidencial.

Puede haber varias conclusiones, algunas técnicas pero otras no....

Estamos ante un problema de calidad?
Qué piensa / opina el usuario de tweeter?

Como vemos algunas interpretaciones que originan estos posibles problemas de calidad (no manejar el volumen) pueden ser de lo más curiosas.



Caso 2.
La secuencia que se ve abajo.
Problemas de calidad?
De cuántos?

a. Tweeter nuevamente
b. Associated Press y un problema de seguridad?
c. La bolsa y la utilización de robots que no distinguen informaciones falsas de verdaderas?

Para pensar....

El Jefe de Proyecto y la Comunicación

En realidad el tema de la comunicación es bastante más amplio pero en ese rol de Jefe, Gestor o Responsable de un Proyecto es donde más se hace notorio.

Hasta donde se capacita el Jefe de Proyecto para comunicar?
Si atendemos a algunas cifras que hay circulando, más del 70% de su actividad consiste en comunicar.
Sabe hacerlo?


Creo que no se arregla el tema con un curso de "Presentaciones Eficaces", es mucho más profundo.

Es natural en el? Aprecia la importancia de la actividad de comunicación?


Entiende que el Informe de Avance, con todo lo importante que es es algo inanimado y que el vehículo que le da sentido es la presentación del mismo?.

 Y esto es sólo un ejemplo.

Demasiadas preguntas y no muchas respuestas.



miércoles, 15 de mayo de 2013

Composición tema: La vaca (violeta)

Es difícil ver la relación entre una vaca y un producto de software. Más aun si la vaca es violeta.

Leyendo un articulo de Seth Godin, conocido por sus libros (ver abajo) y artículos sobre marketing muy interesantes, se llega a la conclusión que normalmente nuestro software es como una vaca tradicional, blanca con manchas negras por ejemplo. Quizás comenzamos pensando que sería distinta, pero en muchos casos termina siendo igual a la mayoría, blanca con manchas negras.

La pregunta es, eso alcanza?
Posiblemente el producto provee lo necesario, por ejemplo implementa toda la funcionalidad o gran parte de ella, es rápido, tiene pocas fallas, etc. 

Pero es suficiente?
Tal vez "construimos" la vaca tradicional, la que se puede cambiar por otra vaca tradicional sin demasiado problema, o más aun por una vaca estándar prehecha. 

Pero que hubiese pasado si en lugar de ello hubiésemos logrado una vaca violeta, notoria, distintiva, difícil de cambiar, ya que pocas o ninguna otra vaca se le parece?.

Dejando de lado las vacas y volviendo al software, posiblemente los atributos de calidad sean en gran medida los que transformen nuestro software bueno pero estándar en algo que le da una experiencia superior al usuario y otros interesados.

Es decir habríamos logrado nuestra vaca violeta



------
http://www.sethgodin.com
Purple Cow: Transform Your Business by Being Remarkable 
 
  • Seth Godin

  • martes, 14 de mayo de 2013

    La Calidad (no?) se negocia

    Hoy participe en una reunión muy interesante donde se discutió el tema de costos de un proyecto y surgió el tema de la Calidad asociada a la rebaja de costos.

    La primera impresión que me dieron los participantes es que la calidad no es algo negociable para la rebaja de costos. Entendible.

    Sin embargo, es realmente así?

    Qué significa negociar la calidad?

    Vayamos en orden. Si negociar la calidad es eliminar pruebas necesarias y comprometidas con el cliente, evidentemente allí no se debe negociar.

    Entonces?

    Una propuesta es: podemos revisar la rigurosidad de la prueba y ver si es necesaria la establecida o se puede disminuir en algo, pero sin perder la calidad necesaria/esperada del producto. Esto debe surgir de un debate compartido con todos los interesados afectados por la flexibilización de esa rigurosidad. Y allí "negociar" la rigurosidad mínima necesaria.

    Esto no disminuye la calidad esperada sino que ajusta las pruebas a lo necesario para superar el problema puntual de los costos, dejando para más adelante, si es conveniente, volver a la rigurosidad original especificada o no.


    Los testers y la zona de confort

    Ayer tratando de transmitir a un auditorio de estudiantes y profesionales con experiencia algún concepto mínimo sobre evaluación de producto de software según ISO 25000, y luego pensando en nuestra zona de confort como testers, quedé con la idea de no haber dicho lo importante.
    Como testers hemos leído, escuchado o enseñado muchas veces, que el rol del tester es encontrar defectos y su misión dar una evaluación sobre el estado del producto respecto a los requerimientos. O llegamos a decir, como Bolton, Kaner, Bach y otros, seamos el faro en el sentido de mostrar un camino para que otro tome decisiones informadas[1]. Y eso está muy bien. Es una parte fundamental de nuestra misión, aunque falta un aspecto:
    También debemos involucrarnos y comprometernos con el negocio para ayudar a que el producto sea útil a los interesados no negativos, no lo sea para los interesados negativos, y ayude al éxito de la Organización.  Lo que hará que seamos exitosos profesionales nosotros mismos.

    El problema es que hay que involucrarse como el cerdo, no como la gallina:

    “Había una vez una gallinita emprendedora que quería montar un negocio en la granja.

    Como había cada vez más animales en la granja tuvo la gran idea de montar un restaurante. Para llevar a cabo su idea necesitaba un socio. Así que se dirigió hacia el animal que más confiabilidad le daba: el cerdito.

    - Hola Cerdito – le dijo la gallina. Quiero abrir un restaurante en la granja y he pensado que tal vez querrías ser mi socio.
    - No sé – respondió el cerdito. ¿Y cuál sería el plato estrella del restaurante?
    - ¡Qué te parece “huevos con jamón”! – respondió la gallina.
    - No gracias. Creo que tú estarías involucrada pero yo tendría que estar comprometido."

    Y para eso tenemos que salir de nuestra zona de confort técnica.
    Y el negocio tiene que darnos buenas pistas de qué necesita para ser exitoso. Podemos para eso colaborar con otros interesados en la discusión de las políticas de calidad.



    [1] Testers keep the lights shining – This is our role. http://www.developsense.com/presentations/twofuturesofsoftwaretesting.pdf

    La línea cada vez más tenue

    Disciplinas diferentes, actividades diferentes, competencias diferentes.

    Sin embargo, en cierto punto del análisis de un producto de software se unen la administración de proyecto,  el análisis de requerimientos, la arquitectura, etc.,  y necesita pensarse como un todo. 

    No es nuevo, sin embargo, las divisiones que hacemos de estas disciplinas las hacen parecer como totalmente independientes entre ellas cuando no lo son.

    El desafío profesional es unir, ante una situación dada, todos estos conceptos.



    lunes, 13 de mayo de 2013

    Consumidor - Usuario

    ¿Estamos desde hace ya unos años ante una nueva categoría de usuarios?

    Aquel que no sólo utiliza nuestro producto de software, sino que consume otros en su vida diaria, en su smartphone, su tableta o cualquier otro dispositivo.

    ¿Cambió eso, como profesionales de la construcción de software nuestra forma de ver los productos que creamos?

    Para pensarlo.

    ISO 25000 y otras - Calidad en Uso

    Posiblemente una de las ideas más interesantes introducidas por la ISO 25000 y publicaciones anteriores, 9126, etc. sea la de Calidad en Uso.

    Si bien no es un concepto nuevo, suena como hacerse cargo del producto una vez que éste se liberó a los interesados: usuarios, personal de infraestructura, auditores  personal de mantenimiento, seguridad, etc.  y verificar si los objetivos de calidad que nos propusimos al construirlo se están cumpliendo cuando el producto está en funcionamiento.

    Podríamos decir que nuestro proyecto termina con el software "entregado y funcionando", cosa que posiblemente sea verdad. Eso sería sólo la "visión de la Producción de la calidad", esto es producir de acuerdo a especificaciones, sin desperdicios  sin re-escritura de código, etc.  

    ¿Pero qué pasa con el resto de las visiones de la calidad?: el producto es útil al interesado, fascina, es entendible, colabora con la imagen de la marca de la empresa, etc. 
    Tal vez pensemos que eso no es problema nuestro, entregamos siguiendo un proceso, anduvo todo bien y ya está.

    Bueno, completando la entrada anterior del blog, quizá sea eso una de las cosas lo que nos aleja del negocio, entre otras. Esa visión compartimentada entre "lo técnico y lo del negocio", cuando en realidad estamos hablando de lo mismo. El éxito de un producto.



    Una lectura clásica antigua pero buena es:

    Software Quality: The elusive target;, I E E E , 1996, B. Kitchenham & S. L. Pfleeger.
    What does “Product Quality really mean”?; Sloan Management Review, Fall 1984, D. Garvin.

    Zona de Confort

    Cada vez que se habla de mejora de proceso en el caso de Informática, escuchamos la frase "necesitamos el apoyo de la Gerencia, de otro modo nada podremos hacer".

    Estoy bastante de acuerdo con ella, pero agregaría además "necesitamos nosotros salir de la zona de confort  técnico" en la que habitualmente estamos.

    Con esto me refiero a atrevernos a acercarnos al negocio, compartir sus  expectativas, hacernos cargo de algún indicador que nuestro producto de software pueda influenciar, resumiendo, tratar de acortar la brecha entre lo técnico o "el servicio" y el negocio.

    Empezar a entender más la calidad del producto que construimos, no sólo desde el punto de vista de técnico sino como valor para la Organización ayuda a ello, es más fácil de explicar y digerir para los no técnicos, comienza el desarrollo de un lenguaje en común, etc..