“Usuario descontento” o “descontento íntimo”?

En numerosas ocasiones hemos tenido la virtud de resolver inconvenientes a nuestros bien aventurados clientes, usuarios de nuestros sistemas en distintos niveles. Ellos agradecidos de nuestras prontas respuestas e inteligentes resoluciones, toman vigor en el uso y recomendación de las nuevas funcionalidades, se adentran en las opciones que ofrecen nuestras soluciones y generan nuevas propuestas de cambios que inyectan un flujo de trabajo a nuestras empresas.

Sin embargo a veces sucede lo contrario, nuestro cliente esta insatisfecho y todas las acciones en las que podamos incurrir le Featured imageparecen pocas o de “soluciones facilistas”. No es necesario pensar en “el cliente” como la masa corporativa que adquirió nuestro producto, sino en sujetos individuales que en algún punto del mapa organizacional provocan una suerte de ruido nocivo.

Independientemente de que se trate de un grupo de usuario o un único usuario, nuestra organización se moviliza en múltiples aspectos. Desde que “suben los incidentes” y hasta que “bajan las soluciones”, el hilo conductor del descontento de nuestro usuario, pasa por las distintas áreas provocando diferentes reacciones que a su vez producen diferentes resultados.

Los primeros resultados son “conversaciones” con demandas poco constructivas, con acusaciones sin sentido práctico y respuestas reactivas poco esclarecedoras. Este comportamiento primario e inicial denota la inmadurez del grupo, del área, de conjunto gerencial y finalmente de la empresa completa. En un ambiente así nadie muestra el más ínfimo ápice de satisfacción. 

Featured image

Es posible que no se acepte que los fallos y defectos existirán indefectiblemente y que no hay proceso, metodología o técnica que eviten su llegada al usuario final, sin embargo una mentalidad rígida e inflexible solo lastima a la organización y sus equipos. Así, bajo un formato de miedos insensatos contagiados por los clientes, las organizaciones prestadoras de servicios se adentran en una ficción de “el cliente siempre satisfecho”.

No pasará mucho tiempo hasta que vean su reflejos adormecidos hasta el punto de herir a sus propios equipos ya sin soluciones, provocará un “sangrado interno” que dudosamente cicatrice con rapidez.

Posturas inflexibles hacia adentro y la dogma de “hacer lo que sea” para mantener la ficción de “el cliente siempre satisfecho”, crea nebulosas que rodean al conjunto de las personas, fabrican desconfianzas infundadas y desvalorización el capital humano y profesional, aunque nuestras acciones no caigan ni una millonésima en la realidad.

Finalmente debemos reflexionar si el peligro es nuestro “usuario descontento” o somos nosotros mismos con nuestro “descontento íntimo”, quizás por falta de madurez.

Advertisements

Open Space Learning Workshop con Liza Helf – Open Space Technology World Community

Open Space Learning Workshop / Taller de Aprendizaje sobre la Tecnología de Espacio Abierto – Open Space Technology World Community.

Hoy a sido un gran día para mi, no solo por participar de este hermoso evento, sino por que descubrí que mis ideas e intuiciones realmente tienen valor, solo hay que encontrar quien las sepa valorar… es cuestión de tiempo de ahora en más.

También vi que debo integrar toda la información que vengo acumulando y darme el tiempo que necesito para reflexionar, pensar, movilizarme, todo esto sin dejar de dialogar, principalmente conmigo mismo.

Liza me ofreció su tiempo sin que se lo pidiera, solo vino y comenzó a hablarme y con bastante timidéz le conté mis asuntos y ella me dió mucho aliento.

Hoy siento cosas nuevas que en realidad están dentro mío desde siempre. Hoy vi las cosas que siempre veo pero desde una perspectiva alentadora.

Si alguna vez puedes hacer este taller, no lo dudes, hazlo.

La calidad es siempre negociable

La calidad es negociable y en Agile es tan negociable como que la misma es escalable y varia indudablemente con cada iteración, a medida que una historia de usuario emerge como un motor de trabajo para el equipo.

Que “La Calidad No Es Negociable”  lo he leído inclusive en el famoso libro “scrum-y-xp-desde-las-trincheras”, pero queda claro allí que podemos hacer distinciones entre cosas que pueden evolucionar desde diseños y modelos básico, hasta un entregable de avanzada, y cosas que necesariamente deben tener un grado de calidad mínimo y suficiente para garantizar trabajos futuros.

Entre ambas cosas, podemos distinguir para el primer caso, interfaces en general, botones, comandos, scripts, webservices y hasta funciones que son implementadas como soluciones de base y pueden evolucionar completamente en futuras iteraciones. Para el segundo caso, nos referimos a elementos de diseño y arquitectura que mal implementados atentan contra factores de calidad como la mantenibilidad, modularidad, escalabilidad, seguridad, integridad, disponibilidad, etc., e inclusive contra la testeabilidad.

En Agile tenemos presente que la potestad de la calidad la tiene todo el equipo de trabajo y no un “grupo de QA” y para un mejor aseguramiento, preferimos el “testing temprano y colaborativo”, el que nace desde el primer día en que se conversa con dueños de productos (PO), Analista de Negocios, usuarios y otros interesados, el que continúa en nuestras mesas de análisis y continua con las decisiones del equipo y que facilitan que cada involucrado pueda agregar valor a favor de un desarrollo de calidad.

Un principio que sostenemos y nos ayuda en esta cadena iterativa y evolutiva de la calidad del software, es que los equipos Agiles no se dividen en Desarrolladores y Testers (aún cuando hay especialistas en ambas cosas), sino que se mancomunan en la figura de Team Members.

En Agile sabemos que una actividad de testing, exhaustiva o no, al final de la cadena de desarrollo no aporta calidad, aún cuando pueda dar índices y métrica.

Sin embargo esto que suena tan lindo, de ninguna manera se obtiene en los primeras iteraciones, sino que en futuros Sprint, el esperado de calidad comienza a tomar la forma negociada. En nuestras discusiones de proyecto, constantemente evaluamos alguna posible falta de funcionalidad o funcionalidad pobremente desarrollada y la enorme mayoría de la veces, se logra determinar que mientras futuros Sprints darían la cobertura esperada, en el actual contamos con una calidad “lo suficientemente buena”, sin descartar que en cada Sprint finalizamos y demostramos un incremento “potencialmente entregable” Utilizamos un concepto que se llama “good enough quality”, lo cual nos da los límites suficientes y necesarios para el testing que aplicaremos en cada nivel del desarrollo. Lo más importante, negociamos con el PO el grado de calidad de cada incremento.

Puedo decir  a estas alturas de mi experiencia, que cada vez más, y más empresas de cualquier envergadura  migran a Agile, inclusive para sus productos más críticos. Ya lo se, las empresas maduras no buscan “la bala de plata” pues ya saben que no existen, y quien adopte Agile o cualquier otro framework por moda solo está destinado al fracaso rotundo, de hecho atribuyo el fracaso de CMMI a la tendencia fashion de quienes consiguieron una evaluación positiva y luego encajonaron el proceso.

Justamente, sucede que hasta el día de hoy no han podido lidiar con los tiempos de respuesta exigidos cada vez más cortos, los cambios de requerimientos cada vez más demandantes y mayor diversidad de servicios asociados a productos, por lo que vienen dejando enormes “huecos de calidad” que sus metodologías tradicionales facilitan.

No intento debatir sobre metodologías, pero si tal vez un paradigma y éste que a muchos trato de explicar nos dice que “la calidad es siempre negociable”, pero podrás con esta negociación o no, dependiendo de tu paradigma de gestión de proyectos y mucho más que eso, dependerá del paradigma cultural de las organizaciones.

Por eso podremos ver que los managers se entorpecen en intentar modificar sus procesos para adecuar sus organizaciones a las nuevas corriente, pero al carecer de los principios correctos del paradigma al que intentan imitar, solo logran confundir a su plantel y no pasa mucho tiempo en que prefieren retroceder debido a los intensos fracasos.

La evolución es para todos, para algunos de una forma, para otros de otra forma, pero bueno, insisto, no se puede tener cuerpo sin espíritu.

calidad

¿Qué es un Patrón de Diseño?

Ayer a la tarde nos cayó una evaluación sorpresa en nuestra empresa.
La hoja de evaluación estaba totalmente en blanco y la consigna fue:
“Por favor, escriban lo que saben de Patrones de Diseño. Solo necesito nombres, clasificación, Intención (que problema pretende resolver). Escriban solo si pueden completar los tres ítems”.
Para sorpresa de todos, nadie pudo escribir más de un único patrón de diseño que conocía básicamente, pero que nunca utilizó, o al menos concientemente!
Entonces sumido en la vergüenza me pareció que lo más lógico era investigar un poquito y creo que al menos por ahora, estos dos enlaces me serán útiles.
Espero les sea útil a ustedes también.

"Juegos Agiles": Próxima reunión de la Comunidad AGILE Córdoba

“Juegos Agiles”

Juego de Cartas

Los juegos y simulaciones proveen una excelente plataforma para aprender conceptos y nuevos comportamientos.
De hecho esa es la forma en la que aprenden los chicos. Los que tienen hijos lo pueden observar en ellos, los que no, podemos recordar nuestra infancia y la de nuestros hermanos.
Así, en esta ocasión, vamos a poner en práctica los principios ágiles en un entorno seguro a través de algún(os) juego(s) ágil(es).

(no te decimos que juegos vamos a realizar para no arruinar la sorpresa!)

Próxima reunión: Jueves 5 de agosto, 18:30 hs.
Sede:  INTI Córdoba, Av. Vélez Sársfield 1561 (frente a Plaza De Las Américas)

Nota Importante:

  • Por razones de seguridad en sede y espacio, inscribirte para participar
  • Debido a la naturaleza de la actividad, rogamos ser puntuales para facilitar la organización y poder participar y aprovechar los juegos en su totalidad.

Lectura sugerida: http://www.dosideas.com/wiki/Juegos_Agiles