Los tres modelos y sus costes reales
Cualquier análisis de este tema llega a las mismas tres estructuras. Son genuinamente diferentes y la elección es importante, pero el enfoque oculta que las tres responden solo a una de las tres preguntas de gobernanza.
| Cómo funciona | Qué cuesta | |
|---|---|---|
| Centralizado | Un equipo dedicado es el propietario del sistema. Los equipos de producto lo consumen y solicitan cambios | El equipo se convierte en un cuello de botella y los equipos de producto lo evitan para cumplir los plazos. La calidad es alta; el riesgo es la adopción |
| Federado | Colaboradores de diversos equipos de producto son propietarios de partes del sistema, bajo estándares compartidos | La coherencia se erosiona. Nadie es dueño del conjunto, por lo que las partes divergen y ninguna persona puede detectar que esto está ocurriendo |
| Híbrido | Un equipo central pequeño es dueño de los fundamentos y de la revisión; los equipos de producto contribuyen con componentes | La respuesta más común y la más difícil de mantener. Funciona exactamente tan bien como esté definida la frontera entre el núcleo y lo contribuido |
El modelo híbrido suele ser el correcto, y la razón por la que falla no es el modelo. Falla cuando nadie ha dejado por escrito qué pertenece al núcleo, por lo que cada contribución se convierte en una negociación y el núcleo absorbe elementos que no debería.
La pregunta que los modelos no responden
La gobernanza de la contribución decide cómo cambia el sistema. La gobernanza del cumplimiento decide si alguien lo sigue. El segundo es donde los sistemas mueren, y apenas se discute porque no es un tema glamuroso.
El síntoma es familiar: un sistema de diseño bien mantenido, un proceso de contribución activo y una base de código con cuatrocientos valores hexadecimales literales. Nadie violó una regla deliberadamente. Era viernes, el token no encajaba del todo y añadir un valor hexadecimal era más rápido que mantener una conversación, trescientas veces.
Nadie violó el sistema deliberadamente. Añadir un valor literal fue más rápido que mantener una conversación, trescientas veces.
Existen exactamente tres mecanismos de aplicación, y solo uno de ellos es gratuito:
| Mecanismo | Coste | Efectividad | |
|---|---|---|---|
| Documentación | Documentar lo que es correcto | Gratis | Casi tan efectivo como lo gratuito |
| Linting | Marcar infracciones en el editor y fallar en CI | Inversión real en herramientas, más un conjunto de reglas mantenido junto al sistema | Alta. La mayor parte del retorno del esfuerzo de gobernanza está aquí |
| Eliminar la capacidad | Hacer que lo incorrecto sea imposible de expresar | Cada necesidad nueva y genuina se convierte en una solicitud a los propietarios del sistema | Total, dentro del límite que cubre |
Ambas filas efectivas tienen precedentes publicados que merece la pena estudiar. Salesforce's SLDS 2 incluye un linter y un validador que escanean el marcado comparándolo con una base de datos de reglas y recomiendan correcciones: la fila central, a escala empresarial. El Stripe's app UI toolkit opta por la fila inferior: su prop css acepta design tokens nombrados y nada más, varios componentes rechazan cualquier anulación por completo y las restricciones de jerarquía de componentes limitan qué puede contener a qué.
Si solo puede hacer una cosa, añada un único chequeo de CI que falle ante un valor de color literal fuera de su archivo de tokens. Lleva una tarde y detiene permanentemente la forma más común de divergencia. Todo lo demás en la gobernanza es negociable; esto no.
La fila inferior solo está disponible en superficies que usted controla. Stripe puede eliminar la capacidad dentro de su propio panel de control, pero no puede hacerlo dentro de su checkout; por eso, allí implementa una escala de personalización. La postura sigue al límite, no a la preferencia.
Cuando un problema de gobernanza es un problema estructural
La lección de gobernanza más útil que se ha hecho pública es una que un equipo publicó sobre su propio error, y no trata en absoluto sobre las reglas.
Spotify's Encore se lanzó con un subsistema móvil deliberadamente flexible. Los equipos de producto solicitaban componentes cada vez más específicos y el sistema seguía aceptando. Para 2022, el equipo consideró que el péndulo se había inclinado demasiado hacia la flexibilidad y que era necesaria una recalibración.
La respuesta obvia de gobernanza habría sido endurecer el proceso: criterios de aceptación más estrictos, un listón más alto para los nuevos componentes, más revisiones. Hicieron algo distinto. Construyeron una nueva capa entre el subsistema flexible y la base, descrita como una primera línea de defensa que reduce la demanda sobre el subsistema especializado mientras aumenta la paridad de la plataforma.
Esto replantea un problema de gobernanza como un problema de arquitectura, y este replanteamiento se puede generalizar. Cuando una parte de un sistema se ve desbordada por solicitudes, estas no suelen ser específicas de esa parte: falta una capa compartida debajo. Rechazarlas empuja a los equipos a construir fuera del sistema, donde se pierde la visibilidad total del trabajo. Añadir la capa permite capturarlo.
| Parece | Suele ser | |
|---|---|---|
| Solicitudes constantes de nuevos componentes | Colaboradores que no respetan el proceso | Falta de una capa compartida entre el núcleo y el subsistema especializado |
| Equipos construyendo fuera del sistema | Poca disciplina en la adopción | El sistema dice que no más rápido de lo que dice que sí |
| Multiplicación de tokens de componentes | Contribuciones descuidadas | A la capa semántica le falta algo que todo el mundo necesita |
| Reglas que requieren excepciones constantemente | Reglas que se ignoran | Una regla que cubre dos superficies que difieren legítimamente |
La última fila merece una comprobación específica. Una regla con una salvedad —"espaciado generoso, aunque las tablas pueden ser más densas"— son dos reglas fingiendo ser una. Cada solicitud de excepción contra ella es correcta, y ninguna cantidad de gobernanza soluciona eso.
Qué cambia cuando el colaborador es un modelo
Los marcos de gobernanza asumen un ritmo: una persona propone un cambio, una persona lo revisa y la cadencia está limitada por la capacidad humana. Esa suposición ya no es segura.
Un agente escribe cuarenta pantallas entre revisiones. No tiene memoria de sus convenciones entre sesiones, no tiene incentivos para tomar atajos ni capacidad para preguntar a un colega qué gris es el correcto. De esto se derivan dos consecuencias que tiran en direcciones opuestas.
| Efecto | |
|---|---|
| Proceso de contribución | Menor carga. Los agentes rara vez proponen cambios al sistema en sí; lo consumen. |
| Cumplimiento de normas | Mucha más carga. El volumen de código escrito basándose en el sistema aumentó, pero la capacidad de revisión no. |
| Ambigüedad en el sistema | Mucho más costoso. Un humano que no sabe qué token usar pregunta; un modelo elige en silencio, en cada archivo. |
| Convención no documentada | Inútil. Cualquier cosa que resida solo en la cabeza de las personas ahora es, sencillamente, inexistente. |
La última fila es el cambio más drástico. La mayoría de los sistemas de diseño siempre han sido en parte escritos y en parte folclore, y el folclore funcionaba porque un desarrollador que había visto las diez pantallas anteriores lo absorbía. Ese mecanismo de transmisión no existe para un agente, por lo que cada convención no escrita se convierte en un vacío que el modelo rellena con sus datos de entrenamiento.
Analizamos 299 archivos DESIGN.md escritos específicamente para cerrar ese vacío. El 76% no contiene prohibiciones de ningún tipo, el 86% especifica los colores como hex raw sin rol semántico, el 69% no define modo oscuro y el 44% no indica ningún valor de tamaño concreto en ninguna parte. Son documentos de gobernanza que no gobiernan nada y, a diferencia de una wiki que nadie lee, este sí se lee, en cada solicitud.
Los kits de Identity Forge son el artefacto gobernado en este sentido: roles de color semánticos para modo claro y oscuro, escalas de tipografía y espaciado, motivos y una lista explícita de lo que se debe y no se debe hacer, serializados en un DESIGN.md que cada agente lee antes de escribir. Explore los kits o lea cómo documentar un sistema para IA.
Gobernanza mínima viable
La mayoría de los consejos de gobernanza publicados asumen la existencia de un equipo de plataforma dedicado, algo que la mayoría de los equipos no tienen. Así es como se ve el mismo trabajo sin uno.
- 1
Escriba qué pertenece al núcleo
Un párrafo. Qué no puede anularse nunca —roles de color, escala tipográfica, escala de espaciado, prohibiciones— y qué tiene libertad para variar según la superficie. La mayoría de las discusiones sobre contribuciones son, en realidad, discusiones sobre este límite, aunque nadie lo nombre.
- 2
Añada una comprobación de CI
Haga que la compilación falle si encuentra un valor de color literal fuera del archivo de tokens. Esta única comprobación hace más que un proceso de contribución y solo cuesta una tarde.
grep -rn --include='*.tsx' --include='*.css' -E '#[0-9a-fA-F]{3,8}\b' src \ | grep -v 'tokens\|globals.css' && exit 1 || exit 0 - 3
Nombre a un responsable, no a un comité
Alguien que pueda decir que sí en un día. Un sistema que tarda dos semanas en aprobar un cambio es un sistema que los equipos evitarán, y evitarlo es irreversible: el trabajo ocurre fuera, donde usted no puede verlo.
- 4
Revise por superficie, no por componente
Una vez al trimestre, abra tres pantallas de la misma superficie una al lado de la otra. La deriva es invisible archivo por archivo y obvia en comparación, razón por la cual la revisión por pull request nunca la detecta.
- 5
Rastree las solicitudes de excepción como defectos del sistema
Cada solicitud de excepción es evidencia de que una regla cubre dos casos que difieren, o de que a la capa semántica le falta algo. Gestione la solicitud y luego solucione la causa. Una regla que necesita tres excepciones es una regla que fue mal escrita.
El paso cuatro es el que los equipos omiten y el que más errores detecta. Revisar un pull request le indica si ese archivo es consistente consigo mismo. Solo comparar pantallas terminadas le indica si el producto es consistente consigo mismo, y eso es precisamente lo que el sistema existe para proteger.
¿Qué es la gobernanza de un sistema de diseño?
Las reglas que definen quién puede cambiar el sistema, cómo se proponen y aceptan las contribuciones y cómo se hace cumplir el cumplimiento. La mayoría de las discusiones abordan exhaustivamente los dos primeros puntos y apenas el tercero, lo cual es lamentable porque el tercero es donde los sistemas suelen fallar.
¿Cuál es la diferencia entre la gobernanza centralizada y la federada?
Centralizada significa que un equipo dedicado es dueño del sistema y los equipos de producto solicitan cambios: alta calidad, con riesgo de cuello de botella. Federada significa que los contribuyentes de varios equipos son dueños de partes bajo estándares compartidos: mayor rendimiento, con el riesgo de erosión de la coherencia. La híbrida divide ambos: un equipo central es dueño de los fundamentos y la revisión, y los equipos de producto contribuyen con componentes.
¿Cómo logro que los equipos sigan realmente el sistema de diseño?
Mecánicamente. Un linter que marque las violaciones en el editor y las rechace en CI hace más que cualquier documentación; y eliminar la capacidad de desviarse —una API de estilos basada únicamente en tokens, por ejemplo— es aún más fuerte cuando usted controla la superficie. La documentación por sí sola casi no tiene valor de cumplimiento.
Mi equipo del sistema de diseño está saturado de solicitudes. ¿Deberíamos decir que no con más frecuencia?
Primero, compruebe si falta alguna capa. Spotify se encontró con este problema con Encore y añadió una capa compartida entre el subsistema flexible y la base, en lugar de endurecer los criterios de aceptación, ya que las solicitudes no eran realmente específicas de ese subsistema. Rechazar solicitudes empuja a los equipos a construir fuera del sistema, haciendo que el trabajo se vuelva invisible.
¿Cambia la gobernanza ahora que la IA escribe la mayor parte de la UI?
El equilibrio cambia drásticamente. Los agentes rara vez proponen cambios en el sistema, por lo que la carga de contribuciones disminuye, mientras que el volumen de código escrito basándose en él aumenta sin que crezca la capacidad de revisión; por lo tanto, la carga de supervisión se incrementa. La ambigüedad también se vuelve más costosa: una persona que no sabe qué token usar pregunta, mientras que un modelo elige silenciosamente en cada archivo que toca.