¿Qué necesidades debe cubrir una plataforma?
Cómo conseguir una plataforma equilibrada que beneficie a desarrolladores y la empresa
Dándole forma al capítulo Plataforma como producto del libro que ando escribiendo, he estado reflexionando sobre algo que parece trivial, pero que incorpora complejidad a la receta: ¿qué necesidades tiene que cubrir una plataforma?
Cuando hablamos de tratar la plataforma como un producto, repetimos hasta la saciedad ese mantra de que los equipos de desarrollo son nuestros “clientes”. Y no es una metáfora cualquiera. Un cliente no solo usa el producto, sino que decide si lo compra, opina sobre él, y puede influir en su evolución con feedback o peticiones de cambio. Son clientes, pero también usuarios, porque trabajan con la plataforma cada día. Yo los llamo clientes cautivos, que creo es más acertado. Si lo piensas, tampoco tienen otras alternativas donde ir — pero eso es harina de otro costal.

Hoy más o menos sabemos qué se espera de una plataforma, porque la disciplina se ha ido consolidando en muchas organizaciones. Pero esas necesidades no son universales. En algunos sitios, incluso son difusas, porque no siempre está claro qué hace o debería hacer el equipo de plataforma. A veces, incluso coexiste con otros equipos —infraestructura, SRE, IT— y las fronteras se mezclan. Esto genera confusión y fricción, porque los equipos de desarrollo terminan por no saben a quién acudir, y el propósito de la plataforma se difumina.
Sin entrar en detalle de las capacidades que debe de ofrecer una plataforma —eso me lo guardo para otro artículo—, podemos clasificar las necesidades en dos grandes grupos:
Explícitas: las que los equipos conocen y pueden expresar con claridad. “Necesito una base de datos”, “un pipeline de CI/CD”, “un entorno de staging”.
Implícitas: las que no siempre se perciben, pero son igual o más importantes: seguridad, escalabilidad, fiabilidad, regulaciones, optimización de costes, necesidades del negocio…
Una buena plataforma ha de buscar el equilibrio entre ambas. Si solo se cubren las explícitas, aparecerán problemas tarde o temprano. Por ejemplo, añadir segmentación a la infraestructura a posteriori puede ser un caos. Pero si se cubren solo las implícitas, la plataforma no resuelve su cometido. Los equipos de desarrollo no tienen lo que necesitan para avanzar y criticarán, con razón, lo inútil que es la plataforma.
El equilibrio es lo que marca la diferencia. La plataforma no solo debe cubrir lo que los desarrolladores necesitan, sino también lo que la empresa, en su conjunto, necesita.
Este cambio de mentalidad suele generar fricción. Los equipos de desarrollo quieren cubrir necesidades inmediatas, como desplegar, entregar, avanzar. La plataforma, en cambio, piensa más a largo plazo. Pero esa tensión es inevitable y es parte del proceso. Con el tiempo, a medida que los resultados se ven, la fricción se transforma en confianza.
El truco está en no trasladar las necesidades implícitas a los equipos de desarrollo. O al menos, disminuirlas al máximo posible. Es el equipo de plataforma quien debe asumirlas y resolverlas o abstraerlas de forma que no sean una carga para los desarrolladores —recuerda que uno de los objetivos de la plataforma es reducir la carga cognitiva. Esto se puede lograr de varias formas:
Implementación integrada: La plataforma se diseña para que los equipos no tengan que preocuparse por ciertos aspectos. Por ejemplo, aislamiento por equipos o regiones, escaneos de seguridad automáticos o backups integrados. Todo esto ocurre “debajo del capó”.
Golden paths: Hacer que los caminos más sencillos sean los correctos. Esto es, disponer de plantillas, pipelines, módulos o flujos que ya incorporan seguridad, monitorización, escalabilidad, control de costes, etc. Si los desarrolladores siguen el camino marcado (el de las baldosas amarillas) nos aseguramos que están implementando buenas prácticas.
Educación y evangelización: La plataforma (o mejor dicho el equipo de plataforma) también enseña. No basta con entregar herramientas y servicios. Hay que explicar su por qué mediante talleres, una documentación clara y sesiones de formación ayudan a crear una cultura compartida. También deben los ingeniero de plataforma abogar por las buenas prácticas en cualquier foro con los compañeros de desarrollo.
Feedback continuo: Ninguna plataforma es perfecta. Escuchar a los equipos nos ayuda a recoger fricciones y ajustar herramientas o procesos. Esto es parte no indivisible del trabajo del equipo de plataforma. ¿Estamos ofreciendo un buen equilibrio a la hora de cubrir necesidades o nos estamos escorando?
El objetivo de los equipos de desarrollo es entregar valor al usuario final. El objetivo del equipo de plataforma es hacer que eso ocurra con las mayores garantías posibles.
Una buena plataforma no complica, sino habilita.
No interfiere, acompaña.
Y (casi) no impone, sino que propone caminos que hacen la vida más fácil.
¡Muchas gracias por leerme!