Jan 13, 2026 | Design system team sync

Planificación y Estructura de Tareas

Introducción a la discusión

• Se inicia la reunión con un enfoque en la planificación utilizando problemas, tareas y épicas. Paul lidera la discusión tras mencionarlo en Slack.

Mejora de la planificación

• Se busca mejorar la precisión y acción de la planificación, abordando iniciativas como el problema de planificación.

• Se identifican problemas al intentar realizar tareas que no son fácilmente alcanzables dentro de un hito, lo que lleva a una revisión del proceso.

Desglose del trabajo

• La necesidad de descomponer el trabajo para que sea realizable en un hito es fundamental; se evita tener tareas que se extiendan por años sin criterios claros de finalización.

• Los problemas únicos que abarcan múltiples tipos de trabajo complican el cierre efectivo dentro de un hito, dificultando también su asignación.

Uso de subtareas

• Se discute si crear problemas secundarios o tareas para trabajos que requieren múltiples flujos. Esto podría facilitar el seguimiento y cierre eficiente.

• La decisión sobre dónde llevar a cabo las discusiones relacionadas (en tickets secundarios o en el ticket principal) es crucial para mantener visibilidad.

Consideraciones sobre diseño e ingeniería

• Aunque se menciona diseño e ingeniería, se aclara que otros roles pueden estar involucrados; por ejemplo, exploraciones en un hito seguidas por implementaciones en otro.

• Completar tareas individuales permite avanzar sin depender completamente del ticket principal, evitando confusiones.

Estructura y Dificultades en Planificación

Experiencias pasadas

• Dan comparte su experiencia previa donde los problemas funcionan bien con alcance claro y responsables designados (DRI), pero menos efectivamente cuando hay decisiones interrelacionadas entre equipos.

Desafíos en la creación de tickets

• Las dificultades surgen al intentar dividir actividades complejas en tickets claros debido a las interrelaciones entre diferentes aspectos del proyecto.

Conclusión sobre estructura

• La claridad del alcance es esencial; sin embargo, cuando todo impacta todo, definir DRIs puede volverse complicado.

Estructuración del Trabajo en Equipo

Filosofía General de Estructuración

• Se busca establecer una filosofía que permita descomponer el trabajo en tareas temáticas, aunque no se espera implementar una estructura rígida de inmediato.

• La idea es crear un sistema donde cada miembro del equipo pueda asignarse tareas y cerrarlas, promoviendo la participación activa de todos.

Creación y Gestión de Tareas

• Si un miembro identifica una tarea adicional que necesita ser creada, debe hacerlo, incluso si es solo un boceto con un nombre. Esto ayuda a mantener la visibilidad dentro de iniciativas más grandes.

• Se propone que el 60% del tiempo esté claramente definido en la planificación, mientras que el 40% restante se reserve para revisiones y solicitudes entrantes.

Flexibilidad y Control

• El enfoque es dividir el trabajo en partes discretas; si surge la necesidad de más detalles, se puede discutir cómo estructurar las tareas parentales o épicas.

• La meta es lograr que las tareas sean alcanzables por una sola persona dentro de un hito específico.

Cambio Cultural en la Asignación de Tareas

• Se sugiere adoptar una práctica cultural donde cada tarea tenga un responsable y un hito asignado. Si alguien considera que el alcance es demasiado grande, debe colaborar para descomponerla.

• En lugar de imponer reglas estrictas desde el inicio, se propone comenzar desde la situación actual y fomentar cambios culturales graduales.

Propiedad Compartida sobre las Tareas

• Los miembros deben revisar los problemas asignados a ellos y determinar si necesitan subtareas. Esto fomenta la colaboración y evita que los líderes gestionen todo.

• Se enfatiza que todos son responsables del proceso; deben identificar necesidades como tareas de diseño para mejorar la claridad en los tickets existentes.

Ejemplo Práctico: Desglose de Tareas

• Un ejemplo mencionado fue "arreglar problemas UX en el selector de fechas", lo cual no es alcanzable sin especificar qué problemas resolver. Es necesario crear subtickets claros para abordar estos temas.

• La importancia radica en entender lo que realmente implica cada tarea antes de asumirla; esto incluye desglosar trabajos complejos en subtareas manejables.

Discusión sobre Tipos de Tareas

• Se plantea si usar "issues" o "tasks" para gestionar el trabajo. La experiencia previa con "tasks" ha sido limitada entre algunos miembros del equipo.

• Algunos han utilizado "tasks" brevemente pero no hay consenso claro sobre su efectividad comparativa frente a "issues".

Este formato proporciona una visión clara y organizada sobre cómo estructurar mejor las tareas dentro del equipo, fomentando tanto la responsabilidad individual como la colaboración colectiva.

Discusión sobre la gestión de tareas e issues

Enfoque en la gestión de tareas

• Se sugiere cerrar una tarea después de realizar pruebas rápidas, tratándola como un problema ligero sin necesidad de discusión adicional.

• La interfaz de usuario ha cambiado desde entonces, lo que podría haber afectado cómo se gestionan las tareas y los issues.

Comparación entre Issues y Tareas

• Existe un debate sobre si se pueden realizar ciertas acciones con tareas; sin embargo, se confirma que todas las funcionalidades están disponibles para los issues.

• Aunque las tareas son útiles para desglosar el trabajo personal, no siempre se utilizan en un contexto colaborativo.

Proceso de asignación y seguimiento

• Se anima a los participantes a revisar lo que tienen asignado y dividirlo si es necesario, manteniendo la flexibilidad en el uso de tasks o issues.

• Al crear subissues para diseño e ingeniería, surge la pregunta sobre dónde mantener las descripciones y discusiones relevantes.

Estrategias para mejorar la comunicación

• Es natural tener conversaciones sobre decisiones en el issue específico del diseño, pero también es importante compartir resúmenes relevantes con el issue principal.

• Se sugiere que al cerrar un issue, se utilice una herramienta como Duo para resumir resultados y pegarlos en la descripción principal.

Importancia del registro centralizado

• Un enfoque exitoso observado fue el uso de un registro de decisiones en un wiki, donde cada decisión discutida quedaba documentada.

• La implementación requiere compromiso por parte del equipo; si no funciona bien, será necesario evaluar qué ajustes son necesarios.

¿Cómo mejorar la planificación de hitos?

Planificación y Flexibilidad

• Se discute la importancia de seguir el "método correcto" para asegurar que el trabajo sea completo, flexible y utilizable.

• Se planea hacer la planificación de hitos más robusta y clara, ajustando fechas en el mapa de ruta debido a nuevas responsabilidades del equipo.

• Se solicita a los miembros del equipo que verifiquen que los tickets asignados sean alcanzables dentro del hito actual.

Movimiento del Trabajo en el Grupo

• Dan menciona su incertidumbre sobre cómo debería fluir el trabajo dentro del grupo, sugiriendo una revisión futura.

• La discusión se centra en evitar perder impulso en el componente CRUD tras las vacaciones, buscando mantener la continuidad.

¿Qué decisiones necesitamos tomar para avanzar?

Identificación de Necesidades

• Se plantea la pregunta sobre qué es necesario para avanzar con el componente y si hay decisiones pendientes.

• Dan y Thomas comparten un resumen previo a las vacaciones, lo cual es útil para enfocar la discusión en lo que falta consenso.

Nombres y Consenso

• Se debate sobre el nombre "index container", con un acuerdo general entre algunos miembros pero dudas por parte de otros.

• A pesar de algunas preocupaciones sobre el nombre, se siente confianza para avanzar con él.

¿Cómo proceder con las migraciones?

Estrategia para Avanzar

• Paul sugiere que están cerca de abrir una solicitud de fusión (MR) contra el sistema de diseño, pero necesitan probarlo primero.

• La necesidad de identificar usos en producto se vuelve crucial para validar cambios antes de implementarlos formalmente.

Ajustes Necesarios

• Surge la cuestión sobre si ajustar las especificaciones para facilitar migraciones o seguir adelante sin ellas.

• Thomas señala que algunos usos en producto son muy cercanos al nuevo componente CRUD, sugiriendo posibles ajustes.

¿Cómo mejorar la interacción con formularios en componentes?

Diseño de formularios y su accesibilidad

• Se discutió el esfuerzo puesto en que al hacer clic para agregar un nuevo elemento, el formulario aparezca de manera alineada y accesible. Sin embargo, se observó que muchos componentes tienen más botones además del botón de agregar.

• A veces hay razones para no mostrar los formularios en línea debido a su tamaño. Esto llevó a cuestionar si el diseño era demasiado rígido o si intentaba abarcar demasiadas funcionalidades a la vez.

• La migración de ciertos usos hacia un nuevo formato puede ser compleja, lo que plantea la pregunta sobre si se debe adaptar el componente al producto existente o viceversa.

Flexibilidad y uso de componentes

• No se desea fusionar un componente con la capa central si no hay uso evidente, ya que esto resultaría en mantener algo inútil.

• Se propuso utilizar "slots" en lugar de botones fijos como el botón de agregar, lo cual podría permitir una implementación más rápida pero también podría llevar a problemas similares a los anteriores.

Confianza en las implementaciones

• La diversidad en cómo se utilizan los slots puede generar incertidumbre sobre cambios futuros, como ajustes estéticos o funcionales.

• La falta de claridad sobre qué contenido se encuentra dentro de estos slots dificulta realizar modificaciones sin conocer su impacto visual final.

Evaluación de candidatos para migración

• Se planteó la posibilidad de identificar lugares dentro del producto donde la versión actual pudiera ser fácilmente intercambiada por otra solución más adecuada.

• Aunque hubo uno o dos candidatos potenciales, estos eran principalmente listas solo lectura, lo cual no encajaba con el objetivo principal del proyecto.

Desafíos técnicos y soluciones propuestas

• Al revisar objetivos de migración, se encontró que algunos componentes estaban escritos en HAML, limitando las capacidades interactivas necesarias para una implementación efectiva.

• Si bien eliminar completamente el formulario podría simplificar las cosas, mantener cierta inteligencia dentro del componente es crucial para su funcionalidad futura.

• Se sugirió trabajar con equipos del producto para evaluar si ciertas implementaciones podrían adaptarse mejor sin requerir modales adicionales.

¿Cómo abordar la migración de componentes en el producto?

Estrategias para la iteración y migración

• Se discute la necesidad de definir un camino claro para integrar y iterar sobre el nuevo componente en el producto, considerando si es necesario realizar esta iteración ahora para facilitar más migraciones.

• Se plantea si la falta de candidatos para migrar debería ser un obstáculo para lanzar el componente, sugiriendo que podría ser mejor trabajar con los usuarios después de tener una versión inicial.

• La idea es entregar una nueva base para este patrón sin forzar a los usuarios a adaptarse a un sistema inconsistente que han estado utilizando previamente.

Confianza en las soluciones propuestas

• Se menciona que se necesita algo más que solo migraciones para tener confianza en la implementación del nuevo componente, buscando razones concretas que justifiquen su inclusión en el producto.

• Se identifican alrededor de 80 usos en la implementación de JavaScript y entre 85 y 90 en HAML, sugiriendo que hay más candidatos potenciales para ser migrados.

Desafíos documentales y variabilidad del uso

• Existe una preocupación por cómo los usuarios encuentran o no la documentación del componente actual debido a su exclusión del sistema de diseño, lo cual ha llevado a implementaciones inconsistentes.

• La introducción inicial del componente fue bien recibida, pero las modificaciones realizadas por diferentes equipos llevaron a múltiples variantes no deseadas.

Control sobre las implementaciones futuras

• Se cuestiona si se puede garantizar una única implementación del nuevo componente, dado el historial problemático con el componente anterior donde se permitieron demasiadas adaptaciones.

• La flexibilidad excesiva puede resultar riesgosa; aunque permite diversas aplicaciones, también complica futuros cambios al afectar múltiples implementaciones existentes.

Limitaciones y consideraciones técnicas

• Para avanzar con la migración, deben alinearse varios factores; no todos los componentes son adecuados debido a sus diferentes configuraciones e iconos asociados.

• La discusión incluye ejemplos específicos donde se han utilizado componentes dentro de formularios inline, lo cual genera confusión sobre su uso correcto.

• Las limitaciones técnicas surgen cuando intentamos hacer cambios significativos sin afectar negativamente las experiencias previas de usuario.

¿Cómo mejorar la flexibilidad en el uso de componentes?

Necesidad de aumentar los usos de componentes

• Se discute que muchos usos actuales no están cubiertos, lo cual es problemático. La pregunta es cómo incrementar este número y si se necesita añadir más flexibilidad antes de fusionar cambios.

• Se plantea la posibilidad de trabajar con consumidores para eliminar cambios adicionales o si es mejor proceder con la fusión actual sin quedar estancados.

Interacciones complejas y consistencia en UI

• Se enfatiza la importancia de ayudar a los equipos a manejar interacciones complejas donde los usuarios buscan completar tareas, enfrentándose a una interfaz que parece igual pero actúa diferente.

• Se aclara que el objetivo del nuevo componente no son las migraciones CRUD, ya que hay muchos casos que no encajan en esta categoría.

Confianza en la API y pasos hacia adelante

• Se cuestiona si se debe identificar problemas antes de fusionar o si se tiene suficiente confianza en la API actual para proceder con la fusión inmediata.

• La discusión gira en torno a evitar fusiones sin un uso claro y resolver problemas de confianza mientras se identifican 40 componentes relevantes.

Planificación y documentación

• Para avanzar, se sugiere acordar un nombre definitivo para el componente y evitar futuros cambios, lo cual facilitaría su integración al sistema de diseño.

• Se propone adoptar un enfoque basado en documentación para asegurar que el desarrollo del componente sea claro y útil, sugiriendo realizar pruebas directas con usuarios potenciales sobre su funcionalidad.

Discusión sobre Implementaciones y Retroalimentación

Estrategia de Alcance Directo

• Se sugiere un enfoque más directo hacia áreas cercanas en lugar de buscar una retroalimentación amplia. Esto podría facilitar la implementación de cambios necesarios.

• Se menciona que hay trabajo en curso, lo que indica que no es necesario limitarse a las implementaciones existentes.

Proyectos en Desarrollo

• Se observa que algunos proyectos están casi listos y esperan la llegada de nuevas directrices o decisiones para avanzar.

• El grupo de trabajo sobre configuraciones está trabajando en patrones relevantes, lo cual es crucial para el desarrollo futuro.

Resolución de Comentarios y Acciones Futuras

• Es importante ayudar a resolver los comentarios realizados por Thomas en la solicitud de fusión (MR), asegurando que se aborden adecuadamente.

• Se planea resumir la discusión y agregar puntos de acción al problema original para mantener un seguimiento claro.

Agradecimientos y Cierre

• Thomas agradece a Chris por el resumen y por liderar la discusión hacia un resultado positivo.

• Se expresa gratitud a todos los participantes por su involucramiento, destacando la importancia del trabajo colaborativo.