Checklist antes de construir una funcionalidad
Una lista de verificación para asegurarse de que una funcionalidad merece el esfuerzo de construcción antes de comprometer el equipo de desarrollo.
Antes de comprometer el desarrollo
Sobre el problema
- El problema está definido desde la perspectiva del usuario, no de la solución.
- Hay evidencia de que el problema existe y tiene impacto suficiente (datos, entrevistas, observación).
- Se sabe a qué tipo de usuario afecta y con qué frecuencia.
- Se entiende qué hace el usuario hoy para resolver este problema (workaround actual).
Sobre la solución
- Se han explorado al menos dos o tres alternativas de solución antes de elegir esta.
- La solución más simple posible está siendo considerada, no solo la más completa.
- El equipo técnico ha revisado la solución y confirma su viabilidad en el tiempo previsto.
- El equipo de diseño ha validado la solución con al menos un usuario o prototipo de baja fidelidad.
Sobre el valor
- Se puede articular claramente qué métrica mejorará si la funcionalidad funciona bien.
- El impacto esperado está calibrado: no es “aumentará las conversiones un 100%”, es una estimación razonada.
- El coste de no hacerlo está considerado (coste de oportunidad).
Sobre la implementación
- Los criterios de aceptación están definidos de forma clara y verificable.
- El alcance está delimitado: hay una versión mínima que puede lanzarse antes de la versión completa.
- Hay un plan de medición: cómo se sabrá si ha funcionado después del lanzamiento.
- Se ha considerado el impacto en otros sistemas o funcionalidades existentes.
Cómo usar este checklist
No todos los ítems necesitan estar marcados para avanzar. El objetivo no es cumplir al 100% sino hacer las preguntas de forma sistemática y ser explícito sobre lo que se sabe y lo que no.
Los ítems sin marcar son áreas de incertidumbre que hay que tener en cuenta durante el desarrollo o que hay que resolver antes de empezar.