El dilema de la transparencia informativa en desarrollo de software

Groucho sanity clauseUna de las obligaciones complejas para un líder técnico en un proyecto de desarrollo de software es la provisión de información a los gerentes de cuenta y a los clientes. En principio, las metodologías ágiles abogan por la transparencia total. Desafortunadamente, la transparencia total no siempre es factible en la práctica y hay que llegar a soluciones de compromiso que describiré a continuación.

Lo primero que un programador debe tener en cuenta cuando le piden una explicación detallada es que el interlocutor no puede entender detalles técnicos. En decir, si te pones a hablar en jerga informática acabarás hablándole a una persona que no sabe lo que le estás contando. Esto es así incluso cuando al técnico le piden una explicación pormenorizada porque tal petición realmente significa «una explicación suficientemente pormenorizada pero que aún resulte entendible sin conocimientos técnicos». El problema de una explicación real y sin edulcorantes es que cómo el que escucha no la entiende entonces empieza a imaginarse cosas. Puede que tú le hayas dicho que el viernes por la tarde recibísteis una alerta de que la cuota en disco estaba al 90% y, simultaneamente, los tiempos de ping a las máquinas virtuales empezaron a superar los quinientos milisegundos. Debido a que tal galimatías es imcomprensible para el receptor del mensaje, y a que la imaginación es una herramienta muy traicionera, inmediatamente el desdichado oyente empezará a imaginarse que lo que significa es que la Tierra dejará de girar y se propagarán terribles epidemias. La clave estriba en que la información hay que proporcionarla siempre en términos de negocio. Lo que a un gerente de cuenta o a un cliente le importa en el fondo es cómo va a impactar la incidencia en su negocio. En el ejemplo anterior lo que es entendible es algo estilo “durante unas horas entramos en riesgo de sufrir una parada de servicio y los clientes experimentaron una ralentización en los tiempos de respuesta del 50% respecto de lo habitual”. Todo lo demás sobra.

En el caso de que se trate de una explicación entre dos programadores, conviene tener en consideración que la informática se diferencia de otras ramas de la ingeniería en al menos dos aspectos importantes: 1º) un programador puede darle a otro una explicación que es –simultáneamente– perfectamente plausible y totalmente falsa; y 2º) no existe –en principio– la responsabilidad civil, el software se entrega “tal cual”, si te hunde el negocio y te arruina la vida, pues lo máximo que el programador hará es decirte que lo siente y que te acompaña en el sentimiento.

A veces los clientes designan a sus propios técnicos para controlar al proveedor y entonces sí puede ser posible proporcionarles justificaciones detalladas aunque incluso en esos casos con matices. Es posible que los acuerdos de nivel de servicio contengan cláusulas con penalizaciones económicas expresas que el cliente pueda intentar usar para no pagar incluso aunque el déficit del servicio no lo justifique realmente. O puede que simplemente la sensación de incertidumbre creada erosione la relación cliente-proveedor innecesariamente. Lo esencial es la honestidad. Hay que ser siempre honesto con los clientes, lo cual no implica necesariamente explicarles lo que sucedió en la cocina minuto a minuto especialmente si no se conocen las cláusulas contractuales.

Un caso particular es cuando el auditor/controlador de proyecto es otro subcontratista. Los subcontratistas puede tener su propia agenda oculta, que en algunos casos puede incluir intentar reemplazar al proveedor por otro más de su conveniencia. Y en casos menos extremos simplemente apretarle las clavijas al proveedor para comprar el máximo de trabajo por el mínimo precio para incrementar el margen de intermediación respecto del total de lo que paga el cliente.

Una situación especialmente compleja son las reuniones de chiriguito total donde algo ha salido mal y se ha organizado una caza de brujas. A los programadores habitualmente no se les permite asistir a ese tipo de reuniones porque incluso aunque no abran la boca se pasar todo el rato mirando hacia el lado izquierdo y derecho de su cerebro cómo si estuviesen buscando una solución sin encontrarla y eso pone muy nervioso al cliente. En los casos en los que al programador sí se le permite asistir, la primera regla es no puentear al jefe, no hablar a menos que se le pregunte y antes de responder mirar al jefe para ver si éste está de acuerdo con permitir una respuesta o prefiere alegar que es preciso demorarla. En determinados situaciones, es posible que al jefe le estén acribillando y le venga bien una mano espontáneamente. Lanzarse al ruedo a rescatar a un torero que está siendo corneado por el toro debe hacerse con gran cautela. En primer lugar, cómo ya he argumentado, hay que evitar justificaciones técnicas. En segundo lugar hay que evitar proclamar inocencia cuando ya se ha sido hallado culpable a menos que se disponga de una cantidad abrumadora e incuestionable de pruebas y a veces ni aún así porque no es buena idea culpar al cliente aunque no tenga razón. Cuando la bronca no está justificada suele ser mejor aceptar el balazo a priori y seguidamente enviar por escrito un relato con los hechos y la verdad de manera que la otra parte pueda dar su brazo a torcer sin resultar humillada. Muchas veces la forma más fácil y eficaz de poner fin a un conflicto es ofrecer una disculpa aunque no se sea realmente el culpable.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Esta entrada fue publicada en Casos Prácticos, Organizando la Comunidad. Modelos de Desarrollo. Guarda el enlace permanente.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

 

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.