¿Por qué las comunicaciones de TI fallan en comunicar?

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 especificación?”, preguntó.

Hace mucho tiempo aprendí, de la manera difícil, la sabiduría del adagio: “Cuando alguien pide consejo, generalmente busca un cómplice”. Así que 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. Así que quería tu opinión”.  Sí. Este dialogo provoca un ambiente de complicidad.

Aun así, miré las especificaciones. Era un documento razonable como suelen ser estas cosas. Pero como muchas especificaciones, era 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 de negocios 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 ida y vuelta.

Si bien a veces es inevitable, cuando se trata de lograr una comprensión compartida de casi cualquier cosa, es una pobre segunda mejor opción.

El problema comienza con cómo 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 prefiere comunicarse a través de la documentación, y alentar a todos en su organización a seguir su ejemplo, cuatro facetas de la comunicación se interponen en su camino.

1. Idioma: Cada 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 se definen con otras palabras, llevándonos por el camino de la recursión 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 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?
2. Desambiguación: No importa cómo 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 de estilo abogado, estilo contractual, que sus víctimas intentan dar sentido con toda la inutilidad de tratar de entender algo que nunca entenderán.
3. 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 control presupuestario de un CIO enfrenta desafíos similares.
4. Intermediación: “Desintermediación” es la palabra elegante para “eliminar intermediarios”, que es exactamente lo que la mayoría de las empresas de TI no hacen. En cambio, intermedian. Siguiendo con nuestro ejemplo de BA, el papel típico del analista de negocios es, lamentablemente, servir como intermediario, debido a la visión falaz 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 completamente absurda ha sido una doctrina aceptada durante décadas y ya es hora de ponerla a descansar. Si los profesionales técnicos no pueden conversar eficazmente 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 del 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, entrenar 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 los externos interactúen, básicamente, como si estuvieran invocando subrutinas, y asumen que todos los demás ejecutivos miran a la empresa de la misma manera. Pero, así como no hay un organigrama perfecto, tampoco hay una manera perfecta de prescribir los resultados de un departamento y las entradas requeridas de otros departamentos para que obtengan esos resultados.

La solución es la conversación

Lo que sale mal, por supuesto, no se limita a los documentos de diseño de TI. Estos solo ilustran el punto, que es que cuando confiamos en la documentación para comunicarnos, estamos buscando problemas, y generalmente nos encontramos en ellos.

Bienvenido a la solución. No es particularmente complicado. Es que cuando las personas necesitan entenderse, necesitan hablar entre sí, interactivamente, utilizando las (espero) pautas conocidas para la escucha activa. En particular:

• Interés expreso: La persona o personas a las que estás escuchando deben estar seguras de que realmente te importa lo que tienen que decir sobre su pensamiento.
• Deja que la otra persona hable: Incluso si no están hablando sobre el tema del que quieres que hablen, presta atención a lo que quieren hablar. Necesitan ser escuchados antes de que puedan concentrarse en lo que necesitas.
• Centro de atención: Dejarlos hablar es una cosa. Dejarlos hablar para siempre es otra cosa. En algún momento, anímelos a enfocarse en el tema sobre el que necesita hablar con ellos.
• Pregunte (1) — aclare: Si, con el objetivo del comunicador, no tienes claro lo que significa, pide una aclaración adicional.
• Pregunte (2) — vuelva a decir: Si, como comunicador, no estás seguro de que la persona con la que te estás comunicando te entiende, pídele que lo repita, en sus términos, no en los tuyos.
• Pregunte (3) — finalice: Como comunicador, pregunte cómo expresar cualquiera que sea la conclusión cuando llegue el momento de documentarla.
• Recordar: 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, tal vez 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, confiar en un documento puede ser más efectivo que intentar una conversación.

Así que al final tenemos que aceptar que a veces tenemos que confiar en la documentación para comunicarnos. Como, por ejemplo, ahora mismo mientras lees este texto.

EL EQUIPO DE GOSMART3R

FUENTE: Bob Lewis Columnista