{ }  surprise-first.md #003 · Sorprende siempre, nunca después  archivo
El Diario de AlpacaTech
// edition: 003 · sunday, 03 may read: ~6 min

Sorprende siempre, nunca después.

Imagina que eres senior (quizás ya lo seas, felicidades ;)).

Un día le pides a alguien de tu equipo una feature para el viernes. El miércoles por la tarde te llega un mensaje: «Oye, ya está lista para que la revises cuando puedas».

Tu primera reacción es alegrarte.

La segunda, pensar que habías estimado mal.

¿La tercera? Darte cuenta de que da igual: esa persona te ha sorprendido.

Y eso es lo único que importa.

No porque la feature sea mejor de lo esperado. Es exactamente lo que habíais acordado. Pero llegó antes de lo que pensabas que llegaría, y eso cambia por completo cómo lo percibes.

De repente esa persona te cae mejor. Confías más en ella. Y seguramente la estima que tenías de ella haya subido.

Molaría ser esa persona, ¿verdad?

Pues resulta que hay un truco para conseguirlo.

Sobrestimar los plazos.
Sí, así de simple.

Ya, suena fatal dicho así. Como si estuvieses engañando a la gente que confía en ti. Pero espera, que el trasfondo es bueno.

Hay una cosa que todos los que llevamos tiempo programando sabemos: las estimaciones en software son puro meme.

Cada pocas semanas aparece en Internet un meme nuevo de «serán dos semanas» que se convierten en tres meses, y todo el mundo se ríe porque es una situación que hemos vivido.

Meme de estimaciones en software

Nadie en este sector ha clavado una estimación dos veces seguidas. Es una realidad.

La incertidumbre es inevitable, así que lo único que podemos controlar es qué hacemos con ella.

Hasta ahora todos hacíamos lo mismo: estimar ajustados.

Te preguntan cuánto tardas, dices lo que de verdad crees que vas a tardar, y cruzas los dedos para que esa semana no se rompa nada y llegues al plazo que tú mismo pactaste.

A veces llegas. A veces no.

Y cuando no llegas, da igual que hayas estado currando hasta las tantas: la otra persona solo ve que no cumpliste el plazo.

Así que el truco que te propongo es... añadir más tiempo.

Añade una semana a lo que crees que tardarás de verdad.

No te hablo de estimar holgado. Ese consejo ya lo conocerás porque ya hemos visto que eso de estimar no funciona. Siempre pasa algo: un bug que sale de la nada, una dependencia que alguien actualiza sin avisar, un día en el que simplemente no sale nada.

Eso es inevitable y proteger la estimación es lo mínimo que deberíamos hacer.

Pero yo te hablo de ir un pasito más allá.

A esa media semana, súmale otra media para poder sorprender.

fórmula
// el truco
tiempo_real:    "X semanas"
tiempo_que_doy"X + 0.5"
// efecto
↳ entrego antes
→ sorpresa
confianza++

Piénsalo. Si te dicen que algo va a tardar una semana y te llega en una semana, pues bien. Es lo que esperabas. No te cambia la vida.

Pero si te dicen que va a tardar dos semanas y te llega en una, te alegras. Sientes que estás recibiendo más valor del que habías comprado. Y eso, aunque sea una percepción, funciona.

Funciona mucho.

Cuando entregas antes de lo esperado de forma consistente, la gente empieza a fiarse de ti. «Este siempre entrega antes». Así de simple. No has cambiado tu ritmo de trabajo, ni tu calidad, ni tu esfuerzo. Lo único que has cambiado es el punto de referencia del otro.

Aunque podrías pensar que si siempre entregas antes, la gente acabará subiendo sus expectativas y te darán plazos más ajustados.

Puede pasar. Pero en la práctica no funciona así. Si dices dos semanas y entregas en una, nadie te va a pedir que la próxima lo hagas en tres días. Te van a ver con mejores ojos, y eso es justo lo que queremos.

Además, si este es tu miedo, simplemente puedes espaciarlo en el tiempo.

No lo hagas siempre, cada par de semanas, una vez por proyecto... cuando tú lo veas bien.

// tip esto no va de trabajar menos. Si sabes que puedes hacerlo en una semana, hazlo en una semana. Tu ritmo es tuyo.

Lo que cambia es que le has dado a la otra persona la capacidad de sorprenderse. Le has dejado ese hueco para alegrarse cuando le entregas el resultado antes de lo que esperaba.

Y con el tiempo, eso se acumula. Se empieza a hablar bien de ti. No porque hayas cambiado cómo trabajas, sino porque has cambiado cómo se percibe tu trabajo.

Haciendo exactamente lo mismo que hacías antes.

Si esto te parece bueno, piensa que puedes aplicar la misma mentalidad a otros aspectos: al valor que produces, al detalle que le pones a las cosas, a lo que el otro recibe frente a lo que esperaba recibir.

Si en un pull request te piden corregir un bug y de paso limpias el código de alrededor, eso se nota. Lo mismo cuando en una reunión puedes decir «ya está hecho», o entregas una landing con los textos ya ajustados a móvil. Alguien va a pensar «qué maravilla trabajar con esta persona».

Al final es eso: deja margen para superar la expectativa, no para quedarte corto. El esfuerzo extra muchas veces es mínimo. La diferencia en percepción, enorme.

Y antes de que pienses «vale, pues pido el triple de tiempo para todo»: no. Así no.

Si dices tres semanas para algo que cualquiera haría en cuatro días, vas a generar desconfianza. La gente va a pensar que eres lento o que no tienes ni idea. El punto está en ese margen razonable. Una media semana, una semana como mucho. Lo justo para absorber lo imprevisto y llegar antes sin que parezca ciencia ficción.

Siempre antes.
Nunca después.

Dale una vuelta. ¿Qué pasa cuando prometes algo y no llegas? Aunque hayas trabajado el doble, la sensación que queda es de decepción. Porque no alcanzaste la expectativa que se tenía de ti.

Y esa sensación pesa más que cualquier explicación.

Así que la próxima vez que te pregunten cuánto tardas en algo, antes de responder, hazte la pregunta. ¿Quieres que esa persona se quede igual cuando le entregues el resultado, o quieres que se sorprenda?

Porque el trabajo va a ser el mismo.

Elige siempre sorprender antes que defraudar.

// appendix
$ weekly.log

Tres apuntes de la semana

+
funcionó
Claude Design.
No sé si has tenido oportunidad de probarlo, pero es una maravilla. Tiene un sentido de la estética que a mí me faltaba. Estoy encantado.
~
aprendí
Montar una newsletter no es escribir.
Elegir plataforma, configurar el dominio, probar el welcome flow... toda la infra se come más horas que el copy. De largo.
me bloqueó
El estrés.
Me voy de viaje y quería dejarlo todo antes de ir. Demasiados frentes a la vez. Acabé poniéndome malo. A ver si me recupero pronto.
$ picks

Te recomiendo

book
The Clean Coder — Robert C. Martin
author"Robert C. Martin"
// por qué
↳ de los primeros que leí
↳ y de los pocos que sigo recomendando
↳ las herramientas cambian, la actitud no
↳ y cuanto antes la trabajes, mejor
video
Programar con IA es una BURBUJA
// nuevo en el canal
title: "Programar con IA es una BURBUJA"
$ inbox

De la comunidad

Comentario destacado de la comunidad

Además de la deuda técnica, tenemos deuda de conocimiento ☠️

// tu turno

Y a ti, ¿cuándo fue la última vez que un plazo te explotó?

Escríbeme y me lo cuentas. Leo todo, aunque a veces tarde un poco en contestar.

$ reply --to=newsletter@alpacatech.dev 
↳ cuéntame
// firma
~/alpacatech $
$ subscribe

¿Te ha gustado? Cada domingo escribo una así.

Acabas de leer una edición de El Diario de AlpacaTech. Si quieres recibir la próxima en tu bandeja, apúntate.

// ~6 min de lectura · domingos a las 09:00