Nunca confunda documentación con comunicación. El propósito de la documentación es recordar, no comunicar.
Uno de los analistas de negocios de mi cliente solicitó mi opinión: “¿Es este un buen documento de especificaciones?”, preguntó.
Hace mucho tiempo aprendí, de la manera difícil, la sabiduría del adagio “cuando alguien pide un consejo, generalmente está buscando un cómplice”. Entonces respondí a su pregunta con una pregunta propia, preguntándole por qué había preguntado.
“Le di esto a un desarrollador, quien me dijo que era una mala especificación. De modo que quería tu opinión”, me explicó?”.
“Mmmm… Cómplice sí es”, pensé.
De cualquier modo, miré la especificación. Era un documento razonable sobre cómo iba el desarrollo. Pero a pesar de tener muchas especificaciones, era un documento malo por una simple razón: el analista de negocios lo había usado para comunicar las especificaciones al desarrollador.
Es un error común y no se limita a los analistas comerciales y las especificaciones de la aplicación. Los CIO, los gerentes de TI y, para el caso, las personas de una empresa típica también lo hacen: intentan comunicarse entre sí enviando documentos de un lado a otro.
Si bien a veces es inevitable, cuando se trata de lograr una comprensión compartida de casi cualquier cosa, es una pobre segunda opción.
El problema comienza con la manera en que el uso de la documentación para comunicarse ignora la naturaleza fundamental de la comunicación.
Los cuatro defectos fundamentales de la documentación
Si usted prefiere comunicarse a través de la documentación, y alentar a todos en su organización a hacer lo mismo, existen cuatro facetas de la comunicación que se interpondrán en su camino.
Idioma: todo idioma natural, ya sea inglés, latín o incluso esperanto, es impreciso en el mejor de los casos. Los sinónimos son aproximados, no exactos; las palabras son definidas por otras palabras, llevándonos por el camino de la recursividad infinita; diferentes personas aportan diferentes vocabularios y suposiciones a sus intentos de interpretar lo que están leyendo.
A menos, por supuesto, que el lenguaje que usan para escribir la especificación sea un pseudocódigo. Esto es lo suficientemente preciso e inequívoco. Pero entonces tendríamos analistas de negocios escribiendo código en lugar de especificaciones y entonces, ¿cuál sería el punto?
Desambiguación: no importa cuánto lo intenten incluso los mejores escritores, nunca crearán un documento que esté completamente libre de ambigüedad y lógica enredada. Al hacer el intento, muchos se encuentran caminando penosamente por el camino literario de una profesión diferente para la cual la ambigüedad y la probabilidad de mala interpretación son igualmente problemáticas: escriben prosa al estilo de los contratos, que sus víctimas intentan encontrarle sentido con toda la inutilidad. de tratar de entender el EULA promedio.
Desacuerdos: no importa qué tan bien un analista de negocios (volviendo a nuestro ejemplo de desarrollo de aplicaciones) describa su diseño, las partes interesadas con las que han trabajado para crearlo no siempre estarán de acuerdo en todos los puntos. Los desacuerdos de las partes interesadas inevitablemente se convierten en compromisos de diseño y, lo que es peor, en especificaciones inconsistentes.
El documento de defensa del presupuesto de un CIO enfrenta desafíos similares.
Intermediación: “Desintermediación” es la palabra costosa para “eliminar intermediarios”, que es exactamente lo que la mayoría de los departamentos de TI no hacen. En cambio, intermedian. Siguiendo con nuestro ejemplo de BA, el rol típico del analista de negocios es, lamentablemente, servir como intermediario, debido a la visión errónea de que los profesionales técnicos no son capaces de tener conversaciones productivas con las partes interesadas del negocio de sus proyectos.
Esta proposición absolutamente absurda ha sido doctrina aceptada durante décadas y ya es hora de dejarla de lado. Si los profesionales técnicos no pueden conversar efectivamente con seres humanos no técnicos, ¿cómo es que se casan con cónyuges que no son profesionales técnicos, crían hijos cuyas primeras palabras son “¡Mamá!” (o, a menudo, “¡No!”) y no “<p>Texto de párrafo</p>”, disfrutar de barbacoas en el patio trasero con vecinos que (¡jadeo!) podrían ganarse la vida en marketing o contabilidad, o, para el caso, capacitarse perros para responder a sus comandos de voz?
No es raro que los CIO caigan en la misma trampa. Tratan su organigrama como una colección de módulos de software, con formas bien definidas para que personas externas interactúen, básicamente, como si estuvieran invocando subrutinas, y asumen que todos los demás ejecutivos ven la empresa de la misma manera.
Pero así como no existe un organigrama perfecto, tampoco existe una manera perfecta de prescribir los resultados de un departamento y los insumos requeridos de otros departamentos para que obtengan esos resultados.
La solución es la conversación
Por supuesto, lo que sale mal no se limita a los documentos de diseño de TI. Estos sólo ilustran el punto, que es que cuando confiamos en la documentación para comunicarnos, estamos buscando problemas y, por lo general, nos encontramos en ellos.
Bienvenido a la solución. No es particularmente complicado. Es que cuando las personas necesitan entenderse, necesitan hablar entre sí, de manera interactiva, usando las (espero) bien conocidas pautas para la escucha activa. En particular:
Exprese interés: la persona o personas a las que está escuchando deben estar seguras de que realmente le importa lo que tienen que decir sobre su forma de pensar.
Deja que la otra persona hable: incluso si no está hablando del tema que quieres que hable, presta atención a lo que quiere hablar. Necesitan sacarlo del camino antes de que puedan concentrarse en lo que necesita.
Enfoque: dejarlos hablar es una cosa. Dejarlos hablar para siempre es otra cosa. En algún momento, anímelos a centrarse en el tema del que necesita hablar con ellos.
Pregunte (1) — aclare: si, como destinatario del comunicador, no tiene claro lo que significan, solicite una aclaración adicional.
Pregunte (2) — repita: si, como comunicador, no está seguro de que la persona con la que se está comunicando lo entienda, pídale que lo repita, en sus términos, no en los suyos.
Pregunte (3) — finalice: como comunicador, pregunte cómo expresar la conclusión cuando llegue el momento de documentarla.
Recuerde: cuando la documentación esté completa, revísela, cara a cara, con las partes interesadas clave para confirmar que refleja las conversaciones que ya ha tenido con ellos.
Si esto parece un poco idealizado, quizás lo sea. No siempre se puede estar cara a cara con todas las partes interesadas, y cuanto más grande es el tema, más difícil es.
También hay problemas lingüísticos con los que lidiar: si usted y la otra persona no tienen un idioma en común que ambos dominen con fluidez, confiar en un documento puede ser más efectivo que intentar una conversación.
Entonces, al final, tenemos que aceptar que a veces tenemos que depender de la documentación para comunicarnos. Como, por ejemplo, ahora mismo mientras lees estas palabras.
