Pages Menu
Categories Menu

Posted by on Abr 20, 2015 in General | 3 comments

¿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.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

3 Comments

  1. Estoy de acuerdo que los desarrolladores hablen con los usuarios, mas sin embargo es bueno establecer reglas, en nuestro caso no ha sido miedo si no realidad, el usuario y los programadores eran de la misma compañia, pero los usuarios solicitaban muchas cosas y muchas innecesarias, y muchas de ellas no eran aprobadas por la gerencia general y no aportaban valor lo cual hacia perder tiempo que se hubiera podido invertir en otros, entonces también debemos capacitar a ese usuario lider para que tenga en cuenta que se cuenta con recursos limitados y que los cambios o solicitudes que gestione con desarrollo agreguen valor a la compañia.

  2. En la empresa par la que trabajo, hasta hace poco los usuarios tenían vía libre para hablar con el programador que consideraran oportuno. Pr cisamente fui yo quién propuso acabar con esta práctica, o mejor dicho, canalizarla de otra forma. La premisa era evitar que el teléfono copara el tiempo de los programadores y rompiera la planificación que se hacía de las tareas. Era habitual que el listado de cosas a hacer, se viniera al traste por excesivas interrupciones teléfoicas. La propuesta fue designar que las coordinadoras del equipo recogieran las llamadas, apuntaran el objeto de la misma y la prioridad del cliente. Entonces queda a criterio del programador responder al cliente de la vía más adecuada, y si esta era elnteléfono, puede planificarse él cuando hacerla. El aumento de la productividad ha sido notorio y ha reducido el estrés de los “llamados” al no ver su trabajo interrumpido.

    El cliente no recibió bien el cambio inicialmente , pero es normal en un periodo de transición.

  3. En mi organización estoy actualmente con la primera experiencia Scrum, y tenemos 2 programadores y un tester desde desarrollo y dos usuarias que prueban la aplicación en coordinación con el tester, pero cuando se produce un error o interpretación “raro” hablan directamente con el programador más dedicado. Pero ojo hablan de lo que se está haciendo y está planificado; no de nuevos desarrollos ni funcionalidades. En este caso veo fundamental que SI hablen directamente usuarios-programadores. Crea cercanía y humanidad además.

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This