Gestión de la calidad en proyectos: criterios, checklists y una pizca de QA

Calidad en un proyecto no es «quedar bonito» ni «el mejor trabajo posible»: es cumplir los criterios que el proyecto acordó — ni más abajo, ni (ojo) mucho más arriba. La definición operativa importa porque desplaza la conversación de lo subjetivo («¿te gusta?») a lo verificable («¿pasa estos cinco criterios?»). Un entregable de calidad es uno cuya aceptación no depende del ánimo de quien lo recibe.

Y hay una segunda definición que suele faltar: la calidad tiene dos caras. La calidad del producto — el entregable funciona, cumple especificaciones — y la calidad del proceso — el trabajo se hizo de forma repetible, sin héroes ni suerte. La primera se ve; la segunda la produce. Un proyecto puede entregar algo bueno por esfuerzo heroico y seguir teniendo un problema de calidad de proceso: lo bueno salió, pero nadie sabe repetirlo. La documentación que convierte el milagro en método es la que describimos en cómo documentar procesos con SOPs.

Por qué le importa a un proyecto (y no solo a la fábrica): los defectos que se descubren tarde cuestan múltiplos. Un error de entendimiento que aparece en la demo del mes 3 obliga a rehacer trabajo ya pagado por el cliente; el mismo error, detectado en la semana 1 con una revisión de 20 minutos, costaba una conversación. La gestión de calidad no es el lujo de los proyectos grandes: es el seguro más barato disponible en los chicos.

Todo el edificio de la calidad se sostiene en una práctica: escribir los criterios de aceptación de cada entregable antes de producirlo. Un criterio de aceptación es una afirmación verificable sobre el entregable — «la web carga en menos de 2 segundos en 4G», «el manual cubre los 8 casos de uso del documento de requerimientos», «el logo viene en SVG, PNG y con versión monocromática».

Lo que distingue un criterio bueno de uno malo es lo mismo que distingue un hito real de un mojón decorativo (la lógica de hito vs entregable): la verificabilidad. «Que sea moderno y profesional» no es un criterio — es una sensación que nadie puede satisfacer con certeza. «Sigue la guía de marca v2 y pasa la prueba con 5 usuarios del público objetivo» sí lo es: o pasa o no pasa.

Tres reglas para escribirlos bien:

• Pocos y relevantes: 3–7 criterios por entregable. Una lista de 30 requisitos es una lista de 30 excusas para discutir al final.
• Acordados con quien acepta: un criterio que el cliente no vio no es un criterio — es tu interpretación. El lugar natural para acordarlos es el kickoff o la definición de cada entregable.
• Vinculados al nivel: los criterios de una landing de $2.000 no son los de una plataforma de $200.000. La calidad tiene presupuesto — definir criterios es definir cuánta calidad se compra, que es exactamente la decisión que el presupuesto debería explicitar.

En el día a día del equipo, los criterios de aceptación se convierten en la definition of done: el checklist que una tarea necesita tildarse para estar lista — no «terminé» sino «terminé y verifiqué contra lo acordado».

El segundo componente es la inspección: verificar contra los criterios en momentos elegidos, no al final. Cada método tiene su lugar:

El patrón correcto se lee en la última columna: empujar la detección hacia lo temprano y lo barato. Un proyecto que descubre sus problemas en la columna derecha no tiene QA — tiene un sistema que fabrica sorpresas caras. La revisión por pares y el checklist de salida cuestan poco y absorben la mayoría de los defectos; la demo quincenal absorbe el desalineamiento; el QA final queda para lo que se le escapó a todo lo anterior.

Uniendo criterios e inspección, el ciclo mínimo para un proyecto con clientes:

1. Definir criterios por entregable (3–7, verificables) en la planificación — no cuando el entregable ya está en vuelo.
2. Acordarlos con quien acepta — el cliente o el área receptora — y dejarlos por escrito junto al entregable al que pertenecen.
3. Inspeccionar temprano y en serie: checklist de salida en cada tarea, revisión de pares en las piezas críticas, demo visible cada 1–2 semanas.
4. Registrar los defectos que aparecen — no para culpar, sino para clasificar: ¿error de criterio poco claro, de proceso, de ejecución? La lista de defectos recurrentes es el mapa de dónde está roto el sistema.
5. Cerrar el ciclo en el final del proyecto: los defectos y sus causas se convierten en lecciones aprendidas, y las que se repiten se convierten en criterios por defecto y checklists del próximo proyecto. Ese es el punto exacto donde la calidad del proceso mejora de verdad.

• La calidad al final. «Primero terminamos y después probamos todo» produce el efecto peor de los dos mundos: defectos caros de corregir y correcciones que introducen defectos nuevos, a contrarreloj y con el cliente esperando. La inspección es un seguro de cuotas: barata si se paga temprano.
• Los criterios implícitos. «Se supone que sabías que quería responsive» — el supositorio de la calidad. Todo criterio que no está escrito y acordado vive en la cabeza de alguien y estalla en la revisión final. El costo de escribirlo es minutos; el de no hacerlo, semanas de re-trabajo.
• Cero defectos como objetivo. La calidad sin techo consume el presupuesto del proyecto: la última pulida absorbe las horas que el alcance siguiente necesitaba. Los criterios acordados son también el permiso para decir «esto está listo» — y avanzar. La perfección que el cliente no pagó es un sobrecosto silencioso, prima lejana del sobrecosto clásico.

Y una nota final sobre el tono: en equipos pequeños, la calidad se cuida con cultura más que con departamentos. Si revisar el trabajo del otro se vive como desconfianza, el sistema se evade; si se vive como «aquí nadie manda su trabajo a ciegas», se sostiene solo. Esa diferencia la marca el líder con su ejemplo — aceptando revisiones de su propio trabajo primero.

Si quieres que los criterios de aceptación vivan como checklists junto a cada tarea e hito — en un archivo local de tu carpeta, sin cuenta ni nube— Hito está pensado para equipos de 1 a 15 personas.

👉 Prueba Hito gratis — criterios y checklists junto al trabajo, local-first.