Cómo tomar mejores decisiones técnicas
Una mejor decisión técnica rara vez es la que elige la tecnología más brillante. Es la que entiende el problema real, hace explícitas las restricciones, compara opciones honestamente y deja por escrito por qué se eligió. Decidir bien es un proceso, no un golpe de intuición.
Buena parte del trabajo de quien construye software no es escribir código, sino decidir. Qué base de datos usar, si partir un servicio o dejarlo entero, qué framework adoptar, cuándo reescribir y cuándo aguantar. Y sin embargo, casi nadie nos enseña a decidir. Aprendemos a programar, a diseñar, a probar; pero la habilidad de tomar una buena decisión técnica la dejamos casi siempre a la intuición y a la experiencia acumulada a fuerza de golpes.
La buena noticia es que decidir mejor no es un don. Es un proceso que se puede describir, practicar y afinar. No garantiza acertar siempre —ninguna decisión bajo incertidumbre lo hace— pero sí sube muchísimo la probabilidad de acertar y, sobre todo, mejora la calidad de las decisiones incluso cuando el resultado no es el esperado.
Primero el problema, no la solución
El error más común y más caro es empezar por la solución. Alguien llega con “usemos Kafka”, “migremos a microservicios”, “necesitamos un cache”, y la conversación entera gira alrededor de esa propuesta antes de que nadie haya articulado qué problema se está resolviendo.
Cuando se empieza por la solución, se cae en un sesgo brutal: se buscan razones para justificarla en lugar de razones para evaluarla. La tecnología deja de ser un medio y se vuelve el fin.
La disciplina más rentable que conozco es negarse a hablar de soluciones hasta que el problema esté claramente enunciado. ¿Qué duele exactamente? ¿A quién? ¿Con qué frecuencia? ¿Cuánto cuesta que siga doliendo? Muchas veces, al escribir el problema con precisión, la solución obvia se desinfla sola: resultó ser un dolor menor, o uno que se arregla con un cambio trivial, o uno que ni siquiera era el verdadero problema.
Un problema bien planteado es media decisión tomada.
Haz explícitas las restricciones
Toda decisión ocurre dentro de una caja de restricciones, y la mayoría de las malas decisiones vienen de ignorar las paredes de esa caja.
Las restricciones son de muchos tipos. Técnicas: el equipo domina Java, no Go. De tiempo: esto tiene que estar en producción en seis semanas. De operación: no tenemos gente para mantener otro sistema de mensajería a las tres de la mañana. De negocio: el costo mensual no puede pasar de cierto número. Humanas: nadie en el equipo ha operado esa base de datos en producción.
Estas restricciones no son detalles secundarios: muchas veces son lo que decide. La solución teóricamente superior que exige un equipo que no tienes, o una ventana de tiempo que no cabe, o una operación que no puedes sostener, no es la solución superior. Es la solución equivocada para tu contexto.
Escribir las restricciones antes de comparar opciones evita enamorarse de alternativas imposibles y enfoca la energía en el espacio de lo realmente viable.
No hay soluciones, solo trade-offs
Si tuviera que resumir la madurez técnica en una sola frase, sería esta: dejar de buscar la mejor tecnología y empezar a entender qué se gana y qué se pierde con cada una.
No existe la opción sin costo. La base de datos que te da flexibilidad de esquema te cobra en consistencia. El microservicio que te da autonomía te cobra en complejidad operativa. El cache que te da velocidad te cobra en invalidación y en datos potencialmente viejos. Cada elección compra algo pagando con otra cosa.
Quien decide bien no busca la opción sin desventajas —no existe—, sino la opción cuyas desventajas puede pagar en su contexto concreto. La pregunta correcta no es “¿cuál es mejor?” en abstracto, sino “¿qué precio estoy dispuesto a pagar, y cuál no?”.
Por eso ayuda tanto nombrar los trade-offs en voz alta. Poner sobre la mesa, para cada opción, qué gano y qué pierdo, convierte una discusión de gustos en una comparación honesta. Y muchas veces revela que dos personas que parecían estar en desacuerdo simplemente valoraban distinto el mismo trade-off.
Compara al menos dos opciones reales
Una decisión con una sola opción no es una decisión, es una racionalización. Si solo consideraste una alternativa, no elegiste: justificaste lo que ya querías hacer.
Obligarse a plantear al menos dos opciones genuinas —no una buena y un espantapájaros puesto ahí para perder— cambia la calidad del razonamiento. Aparece el contraste, y con el contraste aparecen los verdaderos criterios de decisión. A veces la segunda opción gana. A veces confirma que la primera era la correcta, pero ahora sabes por qué, y eso vale oro.
Una opción que casi nunca hay que descartar de entrada es la más aburrida: no hacer nada, o hacer lo mínimo con lo que ya tienes. Muchos problemas no justifican una solución nueva; se resuelven con un ajuste pequeño a lo existente. La tecnología que no introduces es la que nunca tienes que mantener, documentar, ni explicar a las tres de la mañana.
Ajusta el esfuerzo al peso de la decisión
No todas las decisiones merecen el mismo rigor, y gastar el mismo ceremonial en todas es su propia forma de desperdicio.
La distinción útil es entre decisiones reversibles e irreversibles. Una decisión reversible —el nombre de una variable, un endpoint interno, una biblioteca fácil de cambiar— se puede tomar rápido y corregir después si sale mal. Gastar una semana de análisis en algo que puedes deshacer en una tarde es un lujo absurdo. Deciden rápido, observa, ajusta.
Una decisión difícil de revertir —el modelo de datos central, un contrato público, la elección de un proveedor al que quedarás atado— merece toda la deliberación: más opciones, más análisis, más gente en la conversación. Aquí equivocarse es caro y corregir es doloroso.
Saber en qué cuadrante estás es, en sí mismo, una de las decisiones más importantes. Trata las decisiones baratas con ligereza para reservar tu energía y tu rigor para las caras.
Decide con la información que tienes, no con la que quisieras
Casi ninguna decisión importante se toma con información completa. Siempre falta un dato, un benchmark, una certeza sobre el futuro. Y ahí aparecen dos fallas simétricas: decidir a ciegas por impaciencia, o paralizarse esperando una certeza que nunca llega.
El punto medio es reconocer qué información falta, estimar cuánto costaría conseguirla y decidir si vale la pena. A veces un experimento de dos días —un prototipo, un benchmark pequeño, una prueba de carga acotada— elimina la mayor parte de la incertidumbre y cambia la decisión por completo. Ese pequeño costo casi siempre se paga solo.
Pero otras veces la información simplemente no está disponible a un costo razonable, y entonces hay que decidir asumiendo el riesgo de manera consciente. La clave es que sea consciente: nombrar el supuesto en el que te estás apoyando, para poder revisarlo si resulta falso. Decidir bajo incertidumbre no es adivinar; es apostar de forma informada y saber exactamente a qué le apostaste.
Deja por escrito el porqué
La parte más subestimada de decidir bien no es la decisión, sino su registro. Seis meses después, nadie recuerda por qué se eligió lo que se eligió. Llega alguien nuevo, ve la decisión sin su contexto, la juzga absurda y propone deshacerla —sin saber que ya se consideró su alternativa y se descartó por una buena razón que hoy nadie recuerda.
Escribir la decisión no tiene que ser un documento pesado. Basta con capturar cuatro cosas: el problema, las opciones que se consideraron, la que se eligió y por qué. Un Architecture Decision Record de media página cumple perfectamente. Lo valioso no es el formato, es que el porqué quede fuera de la memoria de las personas, que es frágil y se va con quien se va.
Ese registro tiene un beneficio doble. Hacia afuera, permite que el futuro entienda el pasado sin arqueología. Hacia adentro, el mero acto de escribir el porqué te obliga a articularlo, y muchas veces al escribirlo descubres que tu razonamiento tenía un hueco que la intuición había tapado.
Separa la decisión del resultado
Una última idea, quizás la más difícil de interiorizar: una buena decisión y un buen resultado no son lo mismo.
Puedes decidir impecablemente —buen análisis, opciones comparadas, trade-offs claros— y aun así salir mal, porque el mundo es incierto y a veces la carta que faltaba era la mala. Y puedes decidir pésimo —de puro impulso, sin considerar nada— y salir bien por pura suerte. Juzgar tus decisiones solo por el resultado te enseña las lecciones equivocadas: te felicita por la imprudencia afortunada y te castiga por la prudencia con mala suerte.
La forma de mejorar es evaluar el proceso de decisión, no solo su desenlace. ¿Entendí bien el problema? ¿Consideré las opciones reales? ¿Hice explícitas las restricciones y los trade-offs? Si el proceso fue bueno y el resultado malo, no había mucho más que hacer: aprende lo que puedas del azar y sigue. Si el proceso fue malo y el resultado bueno, no te confíes: la próxima vez la suerte puede no acompañarte.
Cierre
Tomar mejores decisiones técnicas no es acumular más conocimiento sobre tecnologías, aunque eso ayude. Es adoptar una disciplina: empezar por el problema, hacer explícitas las restricciones, aceptar que solo hay trade-offs, comparar opciones reales, ajustar el esfuerzo al peso de la decisión, decidir con lo que tienes y dejar el porqué por escrito.
Nada de esto garantiza acertar. Lo que garantiza es que, aciertes o no, hayas decidido por buenas razones y puedas explicarlas. Y a la larga, decidir por buenas razones de forma consistente es lo que separa a quien acumula años de experiencia de quien acumula el mismo año de experiencia muchas veces.
Pruébalo en tu próxima decisión técnica: antes de saltar a la solución, escribe el problema, las restricciones, dos opciones reales y sus trade-offs. No te robará más de veinte minutos, y la calidad de la conversación que sigue te va a sorprender.