- Una organización de ingeniería de unas 45 personas detiene cada trimestre el roadmap, el diseño y las reuniones durante una semana para realizar una “semana de Fixit”, enfocada en resolver bugs menores y problemas de productividad
- En este Fixit se corrigieron 189 bugs, participaron 40 personas y el promedio mediano fue de 4 cierres por persona, con un máximo de 12
- Reglas como la de resolver en un máximo de 2 días, un sistema de puntos y leaderboard y recompensas con playeras ayudan a motivar y elevar la moral del equipo
- El uso de herramientas de IA aceleró la exploración del código y las propuestas de corrección, reduciendo el costo del cambio de contexto
- Fixit contribuye a mejorar la calidad del producto y fortalecer la cohesión del equipo, y se valora como una cultura que revive la alegría de resolver problemas pequeños
El concepto de Fixit y cómo funciona
- Fixit es una semana intensiva de corrección de bugs que se realiza cada trimestre, en la que se detiene por completo el trabajo regular del roadmap, el diseño y las reuniones
- Los ingenieros resuelven errores pequeños o factores que reducen la productividad y que incomodaban a usuarios y desarrolladores
- Ejemplos: un mensaje de error poco claro que llevaba 2 años sin resolverse, un glitch al usar scroll y zoom al mismo tiempo, retrasos en CI por pruebas lentas
- Hay dos reglas
- Ningún bug debe tomar más de 2 días
- El trabajo debe enfocarse en mejoras para el usuario final o en aumentar la productividad de los desarrolladores
- Se usa un sistema de puntos y leaderboard para visualizar la participación, y se entregan playeras de recompensa en distintas categorías, como “primer bug corregido” o “bug más molesto corregido”
Resultados de Fixit
- Resultados de este Fixit
- 189 bugs corregidos, 40 participantes, mediana de 4 por persona, máximo de 12
- Casos destacados
Efectos de Fixit
-
Desde el producto: detalle y acabado
- Una característica de un buen producto es la atención a los detalles y la consistencia
- Fixit es una oportunidad para elevar la calidad del producto un nivel más, al eliminar pequeñas fricciones que quizá los usuarios no identifiquen de forma explícita
-
En lo personal: satisfacción centrada en la ejecución
- Permite recuperar la sensación de logro inmediato de los primeros años de carrera: “detectar un problema → corregirlo → desplegarlo”
- Durante Fixit, el enfoque está más en “cómo mejorar” que en “qué construir”, acumulando logros en ciclos cortos
-
En el equipo: más ánimo y colaboración
- 40 personas en dos zonas horarias corrigiendo bugs al mismo tiempo elevan la energía de toda la organización
- Hay mucho intercambio en tiempo real en el chat: compartir correcciones, publicar capturas de pantalla, hacer demos
- Cada mañana se comparten la cantidad de correcciones, el número de participantes y la posición en el leaderboard, reforzando la motivación
Requisitos para que Fixit funcione bien
-
Preparación previa
- Durante el año se etiquetan bugs como “good fixit candidate”, y la semana previa a Fixit se clasifican en pequeños, medianos y grandes (0.5, 1 y 2 días)
- Según el tamaño, se asignan 1, 2 y 4 puntos, y se crea una lista priorizada de bugs
- Este proceso de preparación es clave para evitar el caos del primer día
-
Regla del límite de 2 días
- En el pasado hubo un caso en que un bug resultó mucho más complejo de lo esperado y consumió toda la semana de Fixit
- Después de eso, se introdujo la regla de detenerse y moverlo al backlog si supera los 2 días, con el objetivo de mantener una sensación continua de avance
-
Escala de participación
- Al inicio, con un equipo de 7 personas, sí hubo resultados, pero faltó sintonía en toda la organización
- Con unas 40 personas se alcanza la masa crítica, maximizando la energía colectiva y la sensación de inmersión
-
Gamificación
- Los puntos están pensados más para la diversión que para la precisión (1/2/4 puntos)
- Se reconocen logros de forma amplia: primera corrección, bug más molesto, etc.
- Está separado de la evaluación de desempeño, para mantener una motivación de participación genuina
- Gracias a las normas sociales y al tamaño del equipo, casi no hay casos de abuso del sistema
El papel de las herramientas de IA
- La IA alivia la carga del cambio de contexto, uno de los retos centrales de Fixit
- Encuentra y resume archivos relacionados con rapidez, lo que reduce la carga cognitiva
- Ejemplos
- Como resultado, se acelera la llegada al punto de partida y, en algunos casos, se puede corregir de inmediato
Críticas a Fixit y cómo se responden
-
“¿No significa esto que normalmente ignoran los bugs?”
- En parte sí, pero sirve para compensar la realidad de que las pequeñas molestias (papercut bugs) suelen quedar fuera de prioridad
- Fixit es una forma de reservar tiempo de manera explícita para resolver “problemas menores pero importantes”
-
“¿No es un desperdicio detener el trabajo del roadmap?”
- Dedicar una semana de 40 personas es un costo grande, pero se compensa con mejoras en la calidad del producto y mayor satisfacción de los usuarios
- Los beneficios en productividad, como pruebas más rápidas, mensajes de error más claros y workflows más cortos, se mantienen a largo plazo
-
“¿No es algo que solo pueden hacer las grandes empresas?”
- Los equipos pequeños también pueden adaptarlo con formatos como “Fixit Friday” o un mini Fixit de 2 días
- La clave está en asegurar tiempo protegido y concentrado y en una actividad colectiva de mejora
El valor esencial de Fixit
- Su objetivo oficial es mejorar la calidad del producto y la productividad de los desarrolladores
- La razón no oficial es “la alegría de arreglar algo”
- Se considera un elemento esencial para recuperar la satisfacción de tiempos más simples y mantener una cultura de creación de productos cuidadosa y detallista
2 comentarios
Me recuerda a la cultura de Pitstop de Baemin. Escuché que ahora ya no existe.
Comentarios en Hacker News
Me gusta la idea, pero la frase “un bug no debería tomar más de 2 días” se siente rara
En la práctica, antes de corregir un bug es casi imposible predecir cuánto va a tomar
Aun así, creo que si no hace falta un refactor grande, casi nunca debería llevar más de un día
Yo normalmente manejo los bugs según su gravedad o prioridad. Muchas veces, mientras más grave es el bug, más fácil termina siendo encontrarlo
Una vez que encuentras la causa, resolverlo suele ser rápido
Analizamos logs durante años sin encontrar la causa, hasta que descubrimos que se reproducía al 100% con cierta combinación de estado de la DB y commits
Firmamos un NDA, armamos un binario mínimo reproducible y lo automatizamos con un script de PowerShell; al mes, MS ya lo había corregido
Internamente daba la impresión de ser algo tipo buffer overflow, pero no puedo asegurarlo
Si te pasabas toda la semana corrigiendo bugs y no sumabas story points en Jira, empezaban a aparecer varios managers preguntando por qué ibas tan lento
Así que la lección que aprendí fue que conviene evitar los bugs difíciles y abandonar temprano el trabajo que no da puntos
No sabes si el problema está en el código, el compilador o el hardware, y los bugs compuestos que surgen por varios factores a la vez ni siquiera se pueden reproducir de forma aislada
En esos casos, si se acumulan parches rápidos, después una corrección bien hecha del bug termina convirtiéndose en un rework masivo
Además, en entornos de baja confianza, a veces ni un bug menor se puede arreglar de inmediato por los procesos de Jira
Cuando trabajaba en Meta hacíamos Fix-it Week cada trimestre
Al principio pensé que al liderazgo le importaba la calidad, pero en realidad era una licencia para acumular deuda técnica
Durante una semana intentábamos corregir bugs, pero con toda la deuda ya acumulada casi no se resolvía nada
La idea es que, si no lo haces, código nuevo se va apilando encima del bug y termina creando una base inestable
En una charla de John Romero también se enfatiza esa misma filosofía
Los desarrolladores resolvían TODOs viejos y aumentaban el LOC, y algunos hasta escribían código incorrecto a propósito para luego “corregirlo” y así inflar artificialmente la cantidad de diffs
Es decir, un tiempo para atender problemas que no son urgentes pero sí molestos
Sería más importante que el liderazgo explicara con honestidad las prioridades de negocio y mostrara claramente el impacto de los bugs en los usuarios
Me ha tocado vivir el círculo vicioso de incendios urgentes y cambios de prioridad repetidos durante el desarrollo de nuevas funciones
Al final el sistema queda lleno de workarounds, y tanto clientes como desarrolladores terminan insatisfechos
En una situación así, a veces pienso que habría sido mejor detenerse desde el principio y hacer una corrección de fondo
La comunicación se rompe y los líderes corren de un lado a otro como gallinas sin cabeza, dando órdenes sin parar
Los desarrolladores terminan convertidos en bomberos de todos los problemas, y al final la única salida es irse
Mientras más baja la velocidad, más entra en pánico el líder y más empieza a reacomodar el proyecto sin control, alimentando el caos y una cultura tóxica
Yo siempre he trabajado con la filosofía de “primero corregir bugs”
Si las funciones existentes no trabajan bien, no desarrollo nuevas
Eso ayuda a mantener una codebase sin bugs y también mejora la productividad del equipo
Sobre todo en frontend, por la variedad de entornos, un estado completamente libre de bugs es casi imposible
Además, como la definición de “bug” es ambigua, a veces una funcionalidad que quiere el manager termina clasificada como bug
Por ejemplo, un error en una página de API que casi nadie usa puede ser menos importante que una funcionalidad nueva
La mayoría son problemas menores, así que el liderazgo suele preferir nuevas funciones
Manejo un producto SaaS pequeño y sigo la regla de “corregir primero los bugs”
Resuelvo antes los bugs reportados por los clientes que desarrollar nuevas funciones
Eso hace que cada vez aparezcan menos bugs nuevos y que corregirlos sea más fácil
Desde el punto de vista del negocio puede ser ineficiente, pero en términos de calidad y confianza del cliente es la mejor estrategia
A los clientes realmente les encanta cuando el bug que reportaron se corrige en cuestión de horas
Instituciones como Fix-it Week más bien fomentan el retraso en la corrección de bugs
Se crea la excusa de “lo vemos después en Fix-it Week”
En cambio, me parece mejor incluir explícitamente tiempo de mantenimiento en la planeación del trimestre o del sprint
Así los desarrolladores tienen un fundamento para corregir bugs de inmediato y se consolida una cultura de mejora continua
Fix-it Week funcionaría mejor como una especie de mini hackatón para mejoras pequeñas o POCs
En una empresa anterior siempre repetían el mismo ciclo
Ese patrón era una señal de una cultura organizacional defectuosa. Si no se aparta tiempo para corregir bugs de forma habitual, eso nunca cambia
Me acordé del Joel Test que propuso Joel Spolsky
La quinta pregunta era: “¿corrigen bugs antes de escribir código nuevo?”
Incluso 25 años después, sigue siendo un criterio vigente
Enlace al texto original
Soy de la idea de no ponerles puntajes ni estimaciones de tamaño a los bugs
Si de verdad hace falta un puntaje, se les pone 2 a todos y en promedio va a salir bien
La corrección de bugs se puede manejar con Kanban, resolviéndolos por orden de importancia y terminándolos dentro del tiempo disponible
Soy el autor. Me alegra que se haya generado una discusión tan activa
No era un sustituto de la higiene técnica ni de resolver problemas grandes