Migración de costes (o el castigo de Sísifo)

Muchos conoceréis el mito de Sísifo, castigado a empujar una piedra hasta la cima de una montaña, tras lo cual, la piedra volvía a rodar hacia abajo, debiendo repetir el proceso eternamente.

Como el de Sísifo, existe otro mito en el desarrollo de software, que sin ser tan antiguo, es seguro que atormenta a muchos desarrolladores desde hace mucho, mucho tiempo.

Si aún no lo conoces, te recomiendo que te informes sobre "la migración de costes".

En realidad (no puedo asegurarlo) el concepto original de "migración de costes" proviene de las prestidigitaciones que los gurús contables hacen para convercer al personal que cuatro menos tres son seis, o lo que es lo mismo, que no es que las pérdidas alcancen x miles de euros, sino que se han obtenido beneficios por z miles.

Pero, la acepción que me interesa traer a colación, es aquella que básicamente, podría enunciarse así

... la migración de costes, consiste en conseguir que tu trabajo lo haga un pringao ...

Bueno, bueno, podríamos expresarlo de una forma más cool diciendo que realmente "cost migration es un antipatrón de diseño que persigue trasladar los gastos de un proyecto, departamento, socio, cliente, proveedor, ... a otro más vulnerable".

Admitirás conmigo que, salvando eufemismos, mi primera definición es más corta, clara y contundente que la segunda.

No creas que se trata de la consabida y popular estratagema de todo trabajador (sobre todo si es español) de "que lo haga otro".

No, no, no. La migración de costes es mucho más sutil y destructora. Su ámbito de actuación no tiene límites y es muy fácil no darse cuenta que estás bajo la maldición de Sísifo.

Tampoco se trata exactamente de la también archiconocida expresión "el pez grande se come al pequeño", pero es verdad que, sólo en algunos casos, el pez grande migrará costes descaradamente al pez pequeño.

Una migración de costes puede realizarse de forma tan sencilla como un "poyaque" de un cliente, en el que el cliente quiere trasladar el coste que le supone obtener una funcionalidad al hecho de que a ti puede "costarte poco".

Una variante más sutil de la anterior es cuando la otra parte (ej. el cliente) aprovecha un resquicio (ej. una ambigüedad, un "yo creía que", ...) en las especificaciones/trabajo pactadas.

Pero las mas sutiles son aquellas en las que la migración de costes se hace sin que nadie tenga que pedir nada. Nadie te pide que hagas nada que no te corresponde, nadie te pide que hagas nada de más, etc... y aun así, te está migrando costes.

Un ejemplo sencillo podría ser aquel en el que debes implementar la lógica de cierta interfaz de usuario, un compañero ha maquetado el diseño (supongamos HTML) y visualmente se ha ceñido perfectamente al diseño solicitado pero, el marcado, jerarquías, posicionamientos utilizados, identificadores y nombres de clases de estilo, etc... son un auténtico galimatías.

Tú tienes claro que tu compañero no tiene ni idea de maquetar un diseño, y debes ser tú quien invierta unos costes en poner orden al caos anterior.

Similar situación se produce cuando dos empresas quieren interconectar ciertos sistemas (ej. facturación electrónica, inventarios, etc...), si una de las partes tiene un nivel de calidad técnica deficiente, la otra parte deberá equilibrarla aumentando unos costes que no necesitaría cubrir si la otra parte fuera competente.

Por ejemplo, si tú debes conectar contra un servicio y no haces más que tener problemas porque no sabes cómo funciona el protocolo, incumples las indicaciones de la documentación aportada, tienes fallos en los parámetros de configuración, etc... no harás más que "molestar" a la otra parte con tus dudas y problemas siendo la otra parte, la que tiene que dedicar recursos a revisar qué falla y explicártelo (o al revés si el deficiente es el otro).

Si la otra parte es "un pez grande" es muy posible que directamente él no dedique los recursos que sí debería dedicar, para que su sistema ofrezca un nivel de calidad adecuado (buen análisis, estabilidad, documentación, ceñido a estándares, entorno de test, etc...) porque sencillamente, sabe que tú necesitas mucho más que él esa interacción.

Es realmente frecuente, ver "peces grandes" que de puertas para afuera ofrecen una visión de calidad y excelencia, invirtiendo en ello unos costes mayores (marketing, acuerdos comerciales, etc...) al reducirlos de otras estructuras (donde los costes son migrados "al pez pequeño").

En el ejemplo anterior, bien puede ser que "el pez grande" dedique más recursos de desarrollo a la interfaz pública de usuario y menos a los sistemas de integración con terceros, sabiendo que serán éstos (los terceros) los que dedicarán los recursos que sean necesarios para llevar a buen puerto la integración (aunque tengan que lidiar con una documentación obsoleta y llena de ambigüedades e incoherencias, haciendo pruebas sobre un protocolo críptico y sin notificación de errores).

Si aderezamos situaciones como las anteriores con agentes adicionales involucrados en la relación (ej. un cliente, un contractor y dos proveedores tecnológicos ¿quién le está fallando al cliente?, ¿él mismo porque no delega decisiones (al contractor) que él no sabe tomar?, ¿el contractor porque no sabe analizar y especificar sus necesidades?, ¿alguno de los proveedores tecnológicos?, ...) entonces la migración de costes se diluirá sutil y mortalmente en una sopa de vetes y diretes.

Pero, ¿que puede hacerse frente a la migración de costes?.

Obviamente si cada una de las partes hace razonablemente bien su trabajo y respeta el trabajo de los demás, consiguiendo una dinámica de trabajo en equipo, pueden existir ciertas "saludables migraciones de costes" (porque nadie somos perfectos), pero cada una de las partes encontrará más fáciles de resolver sus problemas o, al menos, no más difíciles de lo que resulta el trabajo en sí.

En el ejemplo del compañero maquetador, es posible que necesites migrar unos pocos de tus costes para explicar al compañero la mejor forma de maquetar tal o cual cosa, pero si éste lo aprende y aplica en el futuro, esa "piedra de Sísifo" sólo la habrás tenido que subir una vez.

Desgraciadamente, bien por dejadez, incompetencia, ignorancia o abuso, no es infrecuente que la migración de costes "se vaya de madre" y en esos casos (si puedes), deberías actuar.

Desafortunadamente, no hay fórmulas mágicas (yo al menos no las conozco), sólo la experiencia "y don de gentes" te nutren de las habilidades necesarias para tomar las adecuadas decisiones en cada caso.

Ser cuidadoso en verificar la validez y correctitud de la información que envías a terceros, revisar hasta la saciedad que tus configuraciones son correctas y tus sistemas funcionan como se espera y de forma correcta (ej. emitiendo adecuados mensajes de error allí donde corresponde), que la documentación que suministras es acorde al perfil de a quien va destinada o, en la otra dirección, que si reportas un error indiques información adecuada y completa para poderlo reproducir (o seguir la pista si no es reproducible), que si haces una pregunta estés seguro que no está respondida anteriormente, en alguna documentación o que no forma parte de los estándares y prácticas que deberías conocer, etc... son sólo algunas indicaciones de sentido común (pero que no muchos siguen).

En cuanto al trato personal (don de gentes) la cosa es mucho más complicada, por supuesto lo primero es reconocer sin tapujos cuando detectamos que hemos fallado nosotros, pero por ejemplo, si se trata de un pez grande, muchas veces la estrategia menos mala es "partirte los cuernos" para "molestarle" lo menos posible, hasta el punto, que en lugar de preguntarle cual es el puñetero código que se le ha "olvidado" pasarte, ataques al servicio con miles de llamadas para escanearlo tu mismo (por poner un ejemplo). Si por el contrario no es un pez grande sino "un igual", tener paciencia ante sus errores (notificándoselos de la forma más cordial posible) suele ser suficiente para "que se ponga las pilas", si ésto falla... ¡sácale los colores! (cosa que con el pez grande nunca debe hacerse).

Ni que decir que registrar (y poder recordar y/o recuperar) notificaciones, correos, documentaciones, logs, mensajería de servicios, etc... aun cuando a priori no parezca necesario, son una herramienta vital para no tener que subir, eternamente, la piedra de Sísifo...