La plataforma interna también tiene clientes

Imagina que una empresa lanza una herramienta para facilitar el trabajo. Hay anuncio, capacitación y fecha límite para empezar a usarla. Después, alguien le pregunta a un compañero cómo hacer una tarea, y la respuesta empieza así: «Primero, no le hagas caso al manual».

No hace falta trabajar en tecnología para reconocer el problema. Piensa en un sistema de gastos que todavía exige llevar una hoja de cálculo aparte, o en un portal de compras que obliga a perseguir la solicitud por correo. La herramienta registra el trabajo; quienes la usan completan lo que falta.

En el desarrollo de software, una plataforma interna reúne herramientas y servicios compartidos para que los equipos puedan crear, probar y poner en funcionamiento aplicaciones sin tener que montar todo por su cuenta. Puede ofrecer un espacio para probar un cambio, una forma de publicarlo o ayuda para averiguar por qué algo falló. Todo eso es útil. Pero una plataforma puede estar bien construida y aun así complicar una tarea de todos los días.

La pregunta, entonces, es quién se hace cargo de esa dificultad. Llamar «clientes» a quienes usan la plataforma debería obligar a sus responsables a entender ese trabajo y a mejorarlo. Trabajar en la misma empresa no vuelve gratis el tiempo de nadie.

Quien aprueba la herramienta quizá nunca tenga que usarla

Pensemos en una desarrolladora que necesita probar un cambio antes de que llegue a los clientes. Es ella quien usa la plataforma; su equipo carga con el esfuerzo de aprender a manejarla y de cambiar su forma de trabajar. Quizá un director aprobó la inversión, y el equipo de seguridad fija requisitos que todos deben cumplir. Cada uno ve una parte distinta de la misma decisión.

Por eso me resulta útil distinguir a quien realiza la tarea, al cliente interno que depende del servicio y a quienes lo financian o fijan sus condiciones. A veces son la misma persona. Lo que importa es que quienes lidian con las dificultades todos los días tengan voz, sobre todo cuando quien declara el éxito de la plataforma nunca tiene que usarla.

Algunos equipos pueden elegir otra opción; otros deben usar el estándar de la empresa. Una plataforma obligatoria puede ser buena, pero que se use mucho dice poco sobre si la gente la prefiere. Cuando no hay libertad para elegir, se necesitan otras vías: poder influir en las prioridades, recibir una explicación cuando se rechaza una solicitud y contar con un procedimiento para necesidades que el estándar no cubre. Pedir opiniones sirve de poco si nadie contesta.

Ese compromiso incluye el primer intento de usar la plataforma, la ayuda cuando algo falla y el esfuerzo que exige cada cambio. Quien pone el dinero tiene que pagar también esa parte. Aprobar que se construya y dejar el soporte y las migraciones para cuando alguien tenga un rato libre es prometer algo que el equipo difícilmente podrá cumplir.

Que esté disponible es apenas el comienzo

Una función puede estar terminada para quien la construyó y seguir siendo inutilizable para quien la necesita. Quizá las instrucciones dan por supuesto un conocimiento que esa persona no tiene. Quizá el nombre solo les dice algo a sus creadores. O conseguir acceso depende de encontrar a la persona adecuada en un chat. Nada de eso se ve en una demostración técnica que sale bien.

Volvamos a la desarrolladora que necesita probar un cambio. Yo mediría el tiempo desde su primer intento hasta que logra ejecutar una prueba, contando la búsqueda de instrucciones, los permisos, las esperas y la ayuda. Empezar a contar cuando ya se aprobó el acceso hace que la plataforma parezca más rápida, porque deja fuera parte de lo que vivió esa persona.

La atención que consumen todos esos detalles tiene un nombre técnico: carga cognitiva. En este caso, es todo lo que un equipo tiene que aprender y tener en la cabeza solo para poder hacer su trabajo. Una plataforma se gana su lugar cuando le quita parte de esa carga. Una lista larga de funciones no demuestra que lo haya logrado.

Una forma de ayudar es ofrecer un camino guiado: una manera ya preparada de resolver una tarea común, con controles de seguridad, información para detectar fallos y una forma de recuperarse si algo sale mal. La ventaja es práctica: el equipo puede usarlo sin volverse experto en todos los sistemas que hay detrás.

Pero esa promesa tiene que cumplirse en la práctica. Si cada solicitud rutinaria sigue esperando a que alguien la resuelva a mano, el formulario solo habrá mejorado la forma de entrar a la fila. La fila sigue ahí. Llamar autoservicio a ese paso no acorta la espera.

Hay tareas que sí requieren criterio humano. Un acceso fuera de lo habitual o un cambio de alto riesgo pueden necesitar revisión. Ese límite tiene que quedar claro: qué necesita aprobación, quién decide y en cuánto tiempo va a responder. El problema es cuando una tarea que se anunció como automática termina en buscar a alguien que quiera ayudar.

Escucha el problema antes de aceptar la solución

Tratar a los compañeros como clientes no significa construir todo lo que pidan. Lo que piden merece atención porque dice algo del trabajo que tienen que hacer; la solución que proponen, en cambio, hay que analizarla. Una plataforma compartida se vuelve inmanejable si cada equipo recibe su propia versión de todo.

Supongamos que varios equipos necesitan generar un informe cada noche. Piden herramientas distintas para programarlo, pero quizá buscan lo mismo: que se ejecute a tiempo, avise si falla y permita volver a intentarlo sin causar problemas. Un servicio común podría cubrirlas. Si uno de los informes tiene un plazo estricto o maneja información que exige otra protección, vale la pena entender esa diferencia antes de descartarla como resistencia al estándar.

Un «no» útil explica el límite: esto corresponde a tu aplicación; no podemos mantener esta variante; esto debilitaría una garantía de la que dependen otros equipos. Y deja un siguiente paso posible. Decir que no es parte de administrar un servicio compartido. Dejar una necesidad real sin salida también es una decisión, tiene un costo, y alguien tiene que hacerse cargo de él.

Para saber si la plataforma está ayudando, miraría estas señales en conjunto:

• Elección y continuidad de uso. ¿Los equipos la eligen cuando tienen alternativas y la siguen usando para el trabajo en el que les sirve? Quedarse también puede deberse a lo que cuesta irse; conviene preguntar por qué.
• Tiempo hasta un resultado útil. ¿Cuánto tarda una tarea real, incluyendo esperas y ayuda? Compara tareas similares antes y después de adoptar la plataforma, también cuando ya pasó el aprendizaje inicial.
• Trabajo que se hace por fuera. ¿Qué siguen resolviendo los equipos en una hoja de cálculo, otra herramienta o una conversación privada? Averigua qué necesidad cubre ese trabajo extra.
• Excepciones recurrentes. ¿Varios equipos piden la misma función que falta, o la plataforma intenta atender necesidades demasiado distintas con una sola opción? Cada caso exige una decisión diferente.
• Solicitudes de ayuda que se repiten. ¿Dónde se atasca la gente? Puede haber instrucciones poco claras, un diseño confuso, falta de permisos o una tarea que la plataforma no permite resolver.

Estas señales se miran junto con la confiabilidad, la seguridad y el costo. Una interfaz agradable no compensa un servicio que pierde trabajo. Del mismo modo, un servicio puede estar disponible todo el mes mientras sus usuarios pasan horas esperando permiso para hacer algo. Las dos cosas cuentan.

Se puede empezar con algo pequeño: observar a alguien ajeno al equipo de plataforma mientras realiza una tarea habitual, sin guiarlo en cada paso. Anota dónde se detiene, a quién recurre y qué hace fuera de la herramienta. Corrige un obstáculo recurrente y vuelve a observar la tarea. Así el equipo tiene un problema concreto que resolver y una forma de comprobar si la solución sirvió.

Hacerla obligatoria no resuelve la pregunta

Una empresa puede tener buenas razones para exigir una plataforma común: proteger la información de forma consistente, poder darle soporte o dejar de pagar varios sistemas que hacen casi lo mismo. Esas razones merecen explicarse con claridad, y tienen que seguir en pie después de reconocer lo que cuesta adoptar la plataforma.

Si los equipos siguen necesitando herramientas paralelas para terminar el trabajo, hay que contar ese esfuerzo. La organización puede estar pagando por mantener la plataforma y por compensar sus carencias. Pasar esos costos a otros departamentos no los hace desaparecer. Lo mismo ocurre con el tiempo de capacitación y migración: alguien tiene que hacerle lugar entre los compromisos que ya tiene.

Vale la pena entender un atajo, pero que exista no lo hace mejor. Puede saltarse un control necesario, depender de una sola persona o dejar problemas de mantenimiento para después. Conviene comparar lo que cada camino exige y protege. El objetivo es una ruta común en la que se pueda confiar, con excepciones justificadas cuando esa ruta no alcance.

Esa responsabilidad sigue cuando hay que retirar una función, ya sea porque existe una opción mejor o porque dejó de ser posible mantenerla con seguridad. Hay que identificar a quienes dependen de ella, explicar qué la sustituye y acordar una transición que puedan llevar a cabo. Una fecha de retiro sin apoyo para migrar deja el costo en manos de personas que quizá no participaron en la decisión.

Cuando la gente no puede dejar de usar un servicio, su silencio no quiere decir que esté conforme: a quienes lo administran les toca salir a buscar las dificultades. El compañero de la escena inicial, el que explica cómo se hacen las cosas en realidad, está haciendo ese trabajo de manera informal. Al equipo de plataforma debería interesarle escuchar el resto de esa conversación.

Notas de fuentes

Estas fuentes fundamentan la explicación de las plataformas internas y la carga cognitiva. Las escenas de trabajo y el ejemplo de los informes son hipotéticos. Las preguntas, las distinciones entre roles y las recomendaciones son una interpretación práctica del autor, no hallazgos de un estudio.

• La plataforma interna como producto. El Platforms White Paper del CNCF App Delivery Technical Advisory Group describe el diseño centrado en usuarios, el autoservicio y la evaluación mediante la experiencia de uso y los resultados del trabajo.
• Servicios compartidos y carga cognitiva. Team Topologies, de Matthew Skelton y Manuel Pais, relaciona el trabajo de plataforma con facilitar las entregas de otros equipos. Sus conceptos principales explican los equipos de plataforma y los límites de la complejidad que un equipo puede manejar.