Lo que diez años de gestión comercial le hacen a cómo programás

Hay algo que los cursos de programación no enseñan: que las decisiones técnicas tienen consecuencias más allá del código. Aprender eso desde adentro del código hacia afuera es mucho más difícil que al revés.

Cuando arranqué a programar, ya tenía casi una década viendo cómo las organizaciones convierten — o destruyen — valor con sus decisiones. No las técnicas. Las otras: qué se prioriza cuando el tiempo se acaba, cómo se comunica algo que salió mal, qué se prometió que no debería haberse prometido.

Eso forma un tipo de criterio que no aparece en ningún roadmap de desarrollo. Y noto la diferencia cada vez que tengo que tomar una decisión técnica que tiene consecuencias más allá del sprint.

Este análisis no aplica a equipos de 50 personas con procesos formales de decisión. Aplica al momento específico de aprender a programar con experiencia previa en gestión — y a qué parte de esa experiencia transfiere directamente y cuál no.

Lo que se dice vs. lo que se necesita

En gestión comercial aprendés rápido que los requisitos casi nunca son lo que dicen ser.

En Distribuidora Gamma coordinaba ventas mayoristas de medicamentos a nivel nacional. Había clientes que pedían "más seguimiento de sus pedidos". El requisito literal era llamarlos más seguido. Pero cuando investigabas, lo que necesitaban era saber cuándo exactamente llegaba el pedido para coordinar su stock — no más contacto humano, sino certeza sobre el timing. La solución no era más llamadas, sino un punto de control en el proceso de despacho que permitía dar una ventana horaria concreta. Eso redujo los reclamos más de lo que hubiera reducido cualquier protocolo de llamadas.

La restricción era que ejecutar el requisito literal tenía un costo invisible: construías confianza en la dirección equivocada.

La decisión fue hacerme esa pregunta primero, antes de cualquier acción: ¿qué problema estoy resolviendo realmente?

La consecuencia: más tiempo al inicio, menos retrabajo al final. Y a veces, descubrir que el problema que te trajeron no era el problema.

En programación eso se llama entender los requisitos. Pero cuando lo aprendés en un contexto con costo real — no en un ejercicio — lo internalizás de manera diferente.

Decidir con información incompleta

En ventas nunca tenés todos los datos. Siempre hay algo que no sabés del proceso interno del otro lado. Y aun así tenés que avanzar — porque no avanzar también es una decisión con costo.

En 2017 acompañé la apertura de la sucursal de Naranja en Bolívar, coordinando la gestión comercial. No había datos históricos de esa plaza — era un mercado nuevo. Tenías estimaciones, algunos relevamientos, y la presión de que el primer año era el que definía si la operación se sostenía o no. La decisión de a qué segmento de comercios apuntarle primero la tomamos con información parcial y la fuimos ajustando mes a mes. Cerramos el año con más de 300 clientes activos. No porque el plan inicial fuera perfecto — sino porque el criterio de ajuste era claro desde el principio.

Eso genera una tolerancia específica al movimiento: la capacidad de comprometerte con una dirección sabiendo que vas a ajustar. No esperar certeza para arrancar.

En código, la misma lógica resuelve un tipo de parálisis que aparece seguido: el diseño perfecto antes del primer commit, la arquitectura definitiva antes de la primera feature. Esa parálisis tiene un costo — y ese costo se nota cuando el tiempo se acaba.

Los sistemas bien diseñados no emergen de pensar más antes de empezar. Emergen de iterar con criterio.

Cuánto cuesta esta decisión más adelante

En un entorno comercial, el tiempo es la restricción más concreta que existe. Cada semana que dura un proceso tiene un costo que podés calcular. Eso te hace pensar en términos de cuánto tiempo cuesta cada decisión — no solo si es correcta ahora.

La restricción siempre fue la misma: el tiempo invertido hoy no compra certeza mañana.

La decisión, en cada caso: antes de elegir cualquier camino, preguntarse qué va a costar en tres meses. No ahora. Después.

La consecuencia: la deuda técnica dejó de ser un concepto abstracto. Es el mismo mecanismo que cuando tomás un atajo que ahorra una semana hoy y cuesta tres en seis meses. Lo conozco de antes de programar — y eso cambia qué atajos estoy dispuesto a tomar.

Cambiar de dirección sin apego

Los proyectos comerciales cambian de dirección constantemente. Una propuesta que preparaste semanas puede quedar invalidada por una decisión que tomó alguien arriba. Lo que era urgente ayer ya no lo es hoy.

Ese entrenamiento tiene una consecuencia directa en cómo escribo código: no me apego a implementaciones. Si algo no está funcionando o los requisitos cambiaron, lo tiro y arranco de nuevo. Sin drama.

En negocios aprendés que resistirse al cambio porque "ya invertí tiempo en esto" es la definición de costo hundido. El trabajo pasado no cambia lo que conviene hacer ahora. En código funciona exactamente igual — y es más fácil saberlo si ya lo viviste en otro contexto.

Lo que no reemplaza

La gestión comercial no te enseña arquitectura de software. No te enseña a escribir código mantenible, a pensar en complejidad algorítmica, a diseñar APIs predecibles, ni a estructurar tests que aíslan comportamiento real.

Hay una sección que casi no escribo. Pero omitir el tradeoff más obvio en un post que habla exactamente de eso no tiene mucho sentido.

Esas cosas hay que aprenderlas igual — con el mismo rigor que cualquier developer que vino por el camino técnico. El criterio comercial no reemplaza las fundaciones técnicas. Se suma a ellas. Sin las fundaciones, el criterio no alcanza para construir nada sólido.

Lo que sí cambia es desde dónde encarás ese aprendizaje: en lugar de aprender a programar para saber programar, aprendés a programar para resolver problemas reales — con restricciones, usuarios, tiempo y consecuencias incluidas. Eso no hace el aprendizaje más fácil. Lo hace diferente.

Una tensión que no está resuelta

Lo que todavía no tengo claro es cuánto de esto escala cuando el contexto cambia.

El criterio para leer requisitos, para decidir con incertidumbre, para no apegarse a implementaciones — funciona bien con un solo operador tomando decisiones. No sé cómo se comporta en equipos grandes, con múltiples stakeholders y procesos de revisión formales donde el contexto se fragmenta.

En negocios ese mismo criterio se deforma a veces en estructuras complejas. No hay razón para asumir que en desarrollo va a ser diferente.

Eso es lo que quiero documentar a medida que lo vivo.

---

Este tipo de criterio — cómo se forma, cuándo falla, cuándo escala — es exactamente lo que analizo cada semana en El Radar. Si te interesa seguir esta línea, suscribite. Una nota por semana, directo en tu casilla.