Antes de escribir código, toma una decisión
Después de hablar de estabilidad, claridad, decir no y deuda técnica, este es el siguiente paso lógico: una herramienta concreta para decidir si un proyecto de software debería construirse o no.
En los posts anteriores he insistido en una idea simple pero incómoda: la mayoría de los problemas en proyectos de software no aparecen en el código. Aparecen antes, en decisiones poco claras, supuestos implícitos y compromisos que nunca se discuten explícitamente.
Hablamos de estabilidad como decisión de ingeniería. De por qué decir no es una responsabilidad técnica. De qué señales hacen que un proyecto valga la pena. De cómo la deuda técnica es, en realidad, una decisión de negocio.
Todo eso apunta al mismo punto: decidir bien antes de escribir código importa más que escribir código rápido.
El problema que se repite
En la práctica, muchos proyectos comienzan igual:
- El problema no está del todo claro.
- El éxito se define de forma ambigua.
- Las restricciones se descubren en el camino.
- Los trade-offs aparecen bajo presión, no en frío.
- El alcance se expande sin que nadie lo decida explícitamente.
Cuando eso ocurre, incluso buenos equipos terminan construyendo cosas que funcionan, pero que nadie quiere mantener. El costo aparece después, en forma de deuda técnica, frustración y pérdida de foco.
La necesidad de una herramienta concreta
Durante años he visto el mismo patrón: las conversaciones importantes se postergan porque "ya las veremos más adelante". Ese "más adelante" casi siempre llega cuando ya es caro cambiar de rumbo.
La solución no es más procesos ni más reuniones. Es estructura mínima aplicada al momento correcto: antes de comprometer tiempo, dinero y capacidad técnica.
Project Clarity Canvas
Por eso creé el Project Clarity Canvas: una herramienta de una página que fuerza a responder, de forma breve y honesta, siete preguntas básicas antes de construir.
- Cuál es el problema real
- Cómo se define el éxito
- Qué restricciones existen
- Qué trade-offs se están aceptando
- Qué no se va a construir
- Qué riesgos son evidentes
- Y, finalmente, cuál es la decisión
Si alguna de esas partes no puede responderse con claridad, eso ya es una señal. No es un framework, proceso pesado ni promesa de éxito; es una estructura mínima para tomar una decisión informada.
Cómo funciona
El canvas funciona porque fuerza conversaciones que normalmente se postergan. En lugar de "ya lo veremos más adelante", obliga a definir límites, restricciones y trade-offs antes de comprometerse.
No reemplaza diseño técnico ni discovery. No garantiza éxito. No es para justificar decisiones ya tomadas ni para vender proyectos a toda costa. Es para decidir antes.
Cómo esto se relaciona con lo que he escrito
Este canvas no es un producto aislado. Es una extensión natural de todo lo que he venido escribiendo en este blog.
Si hablamos de decir no, necesitamos criterios. Si hablamos de claridad, necesitamos estructura. Si hablamos de decisiones de ingeniería, necesitamos herramientas que las hagan explícitas.
Este canvas es una de ellas. Documenta la misma disciplina que permite construir con estándares enterprise y rechazar proyectos que comprometen calidad.
Escribir código es relativamente fácil. Decidir qué debería existir es lo difícil.
El Project Clarity Canvas no promete eliminar la incertidumbre. Pero ayuda a enfrentarla con criterio, antes de que se transforme en deuda.
Si te resulta útil, puedes descargarlo aquí:
Project Clarity Canvas (PDF)Herramienta de una página para evaluar proyectos antes de construirlos
Guía para usar el Project Clarity Canvas (PDF)Documento breve que explica cuándo usarlo, cómo interpretarlo y cómo reconocer señales saludables y de alerta