“Nos han vuelto a tirar para atrás el SALR, habrá que generar una nueva versión.”
“¿Para el departamento de imágenes hemos generado ya el DCLR?”
“Ya por fin tenemos el DCLR, a ver si la semana que viene podemos hacer el SALR para que nos lo validen”
Seguro que os habéis encontrado alguna vez con frases similares, variando las siglas, y resulta curioso que cuando preguntamos a la gente por el significado de las mismas, encontramos que posiblemente hace tiempo que se olvidaron. Han pasado a ser siglas que simplemente se usan, sin recordar su origen.
Podríamos seguir indagando hasta encontrar a alguien, posiblemente de los más antiguos de la organización y que vivió en sus carnes varias fusiones con otras marcas o varias reorganizaciones de la compañía, que esforzándose recuerde lo que representan. Descubriremos entonces que DCLR era el nombre oficial que se asignó en su día al “Documento con los Requisitos” y, de igual modo, la “Solución a los Requisitos” fue bautizada como SALR.
Quizá en algo tan simple hayamos encontrado el primer indicio de una organización aletargada, que no acostumbra a compartir conocimiento o a replantearse las cosas, o donde quizá sus miembros tienen miedo a admitir que hay cosas que desconocen.
Si queremos ayudar a impulsar un cambio en la organización, persiguiendo un trabajo más colaborativo y que ponga al cliente en el centro, os propongo investigar si esas siglas identifican a documentos que, poco a poco, han ido sustituyendo a la conversación. Comprobemos si sucede algo de lo siguiente:
Estamos trabajando para un proceso en lugar de tener un proceso que facilite la conversación de las personas:
– Oye, ¿y por qué tenéis que rellenar el DCLR?
– ¿Cómo que por qué? Porque hay que hacerlo así.
– ¿Pero os ayuda en algo? Porque veo que la plantilla tiene cientos de campos a rellenar…
– Pues bueno, es porque así hacemos exactamente lo que se nos pide y no nos están mareando, luego lo pasamos a aprobación donde el jefe valida el número de jornadas necesarias para llevarlo a cabo, y después irá a pruebas. Creo que ellos ya calculan las horas que harán falta para probarlo, etc. Y de ahí, ya se da la fecha de salida.
– Y en este departamento, ¿cómo saben lo que tienen que probar para su estimación?
– Se leen el documento y rellenan esta otra parte con el plan de pruebas. Es todo mejor así, nos evitamos estar hablando con unos y con otros, y así la solución que planteamos es la que se da. Además siempre lo hemos hecho así.
Estamos tratando estos documentos como contratos que ponen palos a las ruedas de la colaboración, creando silos:
– Entonces por lo que cuentas, hacéis lo que pone el documento nada más, ¿no?
– Claro, por eso ponemos tantos campos, para que venga bien definido el requerimiento, y si no está completo no lo hacemos.
– Y después contestáis con otro contrato…
– Sí, tardamos una semana en crear otro documento con la solución técnica, donde ya damos fechas de paso a producción.
– ¿Y ya con eso os ponéis a ello?
– Siempre que nos validen la solución, hay veces que tardan mucho, y en ocasiones después de esperar recibimos un mail diciendo que nos ha faltado algo.
– ¿Ahí tenéis tiempo para corregirlo?
– Normalmente no, porque la fecha que dimos en su momento va a misa, ahí es donde empiezan el estrés y las prisas.
Ejecutando un plan en lugar de adaptarnos a la realidad:
– ¿Y si por casualidad el que hizo el requerimiento se ha equivocado al escribir la petición?
– Lo tratamos como un cambio de alcance, el que se equivoca tiene que abrir otro documento con la corrección.
– ¿Preferís lanzarlo aunque sepáis que hay algo mal?
– No es tan grave, pero sí, normalmente acaba saliendo la versión mala, y luego ya se corrige. Es que si corregimos antes no llegamos a la fecha de lanzamiento, y la siguiente fecha es para dentro de por lo menos dos meses… por eso hacemos el truco de tratarlo después como error, que parece que así corremos más.
– ¿Entonces es por llegar a la fecha?
– En gran parte sí, hay que llegar con todo lo que se pidió, date cuenta de que el lanzamiento del producto contiene requisitos de un montón de gente, no podemos estar cambiando cosas sobre la marcha que pongan en riesgo el trabajo de los demás. Supondría que un montón de gente tendría que cambiar sus planes.
Tenemos documentación que describe genial un producto que no quieren nuestros clientes:
– Lo bueno es que tenemos una documentación completa, con la solución de todo lo que se va a hacer en cada proyecto.
– ¿Entonces la solución que documentáis siempre es la que acaba siendo?
– Qué va… ojalá, pero al final siempre surgen complicaciones y hay que modificar los documentos. Por ejemplo los de IT no paran de quejarse de que se pasan más tiempo cambiando documentación que escribiendo código, pero merece la pena por si viene una auditoría.
– Ya veo, ¿y cómo medís el impacto en el negocio?
– Hombre, antes de empezar a hacer nada se hace un Business Case del proyecto con lo que se va a conseguir.
– Me refiero a posteriori, a una vez que sale al mercado, ¿no lo medís?
– Es que cada nueva versión trae tantas cosas que realmente resulta imposible saber si el impacto (positivo o negativo) es por causa de una cosa o de la otra.
Si alguno de estos fragmentos os ha resultado familiar probablemente estéis detectando indicios de que el documento ha pasado a ser un sustituto del diálogo. Todo el mundo tiene aquí una oportunidad de aportar valor a la organización.
En nuestras intervenciones como agentes del cambio utilizamos la curiosidad, la conversación y el feedback para retar la capacidad del sistema de conservar su estado actual, ayudando a despertar en la organización su propio sentido de supervisión: “¿Esto nos está ayudando?” “¿Esto tiene en cuenta al cliente?”, “¿Para qué hacemos esto?”.
Me gusta mucho cómo se describe esta labor en el libro Por Un Scrum Popular: “[…] vino al mundo para quitarnos esa anestesia, para que vuelva a doler lo que siempre debió molestar, pero que hoy forma parte del paisaje cotidiano”.
Despertaremos este sentido mientras modificamos el entorno y promovemos conversaciones cara a cara, de forma que resulte obvio el beneficio del diálogo, así probablemente el documento pase a tener otra utilidad, aun valiosa, como recordatorio de aquello que hablamos.
