Antes de escribir código, toma una decisión

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.

Vengo insistiendo en lo mismo: estabilidad, decir no a tiempo y leer bien las señales antes de comprometerse. Y en 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.

El Canvas también es un filtro

El Canvas no se llena por completar un trámite. Si llegás al final con campos vagos, evidencia thin o riesgos sin nombrar, eso no es un Canvas a medio terminar. Es la respuesta. El proyecto no está listo para ejecutarse.

Decir no a un proyecto que no debería arrancar es la decisión técnica más rentable que vas a tomar. Cada línea de código sobre una decisión confusa multiplica el costo del rollback. El Canvas convierte ese no en algo argumentable, no en intuición.

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.

Decir no requiere criterios. Tener claridad requiere estructura. Tomar decisiones de ingeniería requiere herramientas que las hagan explícitas.

Este canvas es una de ellas. Documenta la misma disciplina que permite construir bien y rechazar proyectos que comprometen la calidad del resultado.

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