¿Deben los usuarios hablar con los programadores?

Es muy curioso ver como se establecen en empresas y equipos eso que se suele llamar “culturas organizativas”, es decir, ciertas pautas, reglas de comportamiento, maneras de comportarse, cosas que se ven mal y cosas que se ven bien, etc., que no están escritas en ningún lado, pero que con los años se han establecido como Ley en ciertas empresas y llegan a marcar su identidad.
Después de haber pasado por un número considerable de proyectos y empresas (después de pasar por 80 empresas, datos detallados de situaciones encontradas), uno acaba viendo un número considerable de esas pautas, que, para más curiosidad, en algunos sitios son Ley de obligado cumplimiento y, esas mismas, en otros sitios su uso supone pena “de cárcel”.
En varios post te habré contado alguna de estas “reglas” de comportamiento y hoy quiero hablarte de una bastante curiosa: la relación de los programadores con los clientes.
En un número considerable de organizaciones está terminantemente prohibido que desarrollo hable con algún cliente o usuario. “Pena de cárcel”. Mal. Toda comunicación entre usuarios desarrolladores debe pasar por un gerente, comercial, jefe de proyectos o similar.
Sobre las justificaciones a ese comportamiento, quienes hacen uso del mismo argumentan que si los usuarios acceden a desarrollo, si hablan directamente con los programadores… los programadores acabarán haciendo trabajo no planificado, no facturado, etc.
También están las razones sobre controlar “la calidad del proceso”, que suelen ser del tipo a “-si los programadores hablan con los usuarios incluso pueden acabar metiendo en desarrollo cosas que nadie nunca sabrá-“, el clásico de que alguien de que desarrollo mete algo en producción sin que nadie más lo sepa, para parchear algo.
Y, además, en ocasiones, tras ello hay, intuyo yo, miedo, miedo por parte de ciertos “jefes” a perder el control de la situación.
Creo yo que en gran parte de las ocasiones podríamos decir que la razón para que los programadores no puedan comunicarse con los usuarios viene del miedo, ojo, justificado en ocasiones, o no, ya sabes el miedo, un peligro mayor que cualquier mala práctica de gestión software. Miedo a perder el control, miedo a no ser informado, miedo a no facturar algo…. miedo.
Pero, por otro lado, hay quien, siendo menos numerosos los casos que yo me he encontrado, respecto al anterior, propugna la comunicación de los programadores con los usuarios.
Y en este punto hay quien lo hace descontroladamente, lo que conlleva a problemas, dejando al libre albedrío la comunicación usuario – programador, que acaba muchas veces en auténticos abusos por parte de los usuarios sobre los programadores.
Y hay quien lo hace controladamente (siendo aún menor el número de veces que yo me lo he encontrado), designando un único representante de los usuarios con canal libre hacia los programadores, muy del estilo de la filosofía “product owner” en agilidad.
Quien argumenta esta última manera de trabajar, la fundamenta en que para los programadores es muy frustrante no saber para quien están trabajando, para qué, y que así se evitan tiempos muertos y perdidas de información, eliminando intermediarios que puedan desvirtuar la información, lo que en terminología Lean vendría a ser… eliminar desperdicios.