Blog ·
Estimar cambios en código que toca dinero
El código suele ser un día. Lo que lo rodea — entender el comportamiento actual, fijarlo con tests, validar con el negocio, la ventana de deploy — es la estimación.
Alguien pregunta cuánto tarda cambiar cómo se imputa un pago. La respuesta honesta no es sobre el código — y las primeras veces me equivoqué por un factor de tres.
El código suele ser un día. Lo que lo rodea:
Lo que rodea al cambio
Entender el comportamiento actual. No lo que el sistema debería hacer: lo que hace, incluidos los casos que nadie documentó. Acá viven las sorpresas, y es impresupuestable por adelantado — lo cual es, en sí mismo, información.
Tests de caracterización. Fijar el comportamiento de hoy antes de tocar nada, contra una base de datos real. Muchas veces lleva más tiempo que el cambio.
Validar con el negocio. Si el cambio altera un número que alguien ya vio, alguien tiene que confirmar que el número nuevo es el correcto. Eso es una conversación, y las conversaciones ocurren en la agenda de otro.
La ventana de deploy. El código que toca dinero no sale un viernes a las cinco de la tarde, y generalmente tampoco sale en horario de operación. Entre “el trabajo técnico está terminado” y “el cambio está en producción” hay un problema de calendario, no de código.
El período de observación posterior. El cambio no está “listo” cuando se deploya: está listo cuando pasó suficiente operación real por encima.
La estimación tiene forma, no número
El cambio es chico, la verificación es el trabajo, y el calendario es la restricción.
Dos cosas que ahora hago al principio. Digo en voz alta de qué parte estoy inseguro — casi siempre, del comportamiento actual — en vez de inflar un número único que lo esconde. Y parto toda estimación en dos: “cuándo puede estar hecho” y “cuándo puede estar deployado”, porque en un sistema en producción son preguntas distintas con respuestas distintas.
Equivocarse en cuánto tarda el código es normal. Equivocarse en lo que lo rodea es lo que te vuelve poco confiable.