Entiendo tu frustración cada vez que te decimos: “voy a tardar dos horas” y nos toma dos días o hasta dos semanas. Créeme, entiendo tu frustración porque es mi credibilidad la que está en juego cada vez que intento responsablemente darte una respuesta que no sea ambigua. Sin embargo, tengo que informarte de un dato que, siendo el más importante, siempre se te escapa:

“Estimado: Cálculo o valoración anticipados, generalmente del coste de alguna cosa.”

¿Sabes por qué se hacen estimados de tiempo y no valoraciones con precisión? Porque, a diferencia de la manufactura y la construcción, donde se sabe cuánto tiempo  tarda un proceso, se conocen de antemano cuáles van primero y cuáles van al final, y se pueden anticipar  los factores que podrían alterar el tiempo de culminación, crear y mantener software es sumamente distinto. El proceso de escribir un código, que al final resulta en software, es uno de incertidumbres y de muchas variables (no pun intended), y un minúsculo cambio puede alterar el comportamiento completo de los sistemas. Esto no es una apología a la tardanza, más bien intento contextualizar cómo ambos nos beneficiamos de entender nuestras necesidades (las tuyas como cliente y las mías como programador).

Cuando me hablas de tu idea o de tu problema y me pides que te estime tiempo, lo primero que me viene a la mente es ese refrán en inglés que dice: “the devil is in the details”. Eso me lleva a mi primera sugerencia: mientras más detallada sea la idea o el problema, se genera menos incertidumbre y a la vez me lleva a poder ejercer mi expertise recomendándote alternativas que sean de mayor beneficio. Si la discusión es con un consultor con un equipo de programadores a su cargo, quiero que sepas que la cosa es levemente más compleja: solo el programador que va a ejecutar la tarea es quien puede con mayor precisión estimar el tiempo que puede tardar.

Cuando me hablas de tu idea o de tu problema y me pides que te estime costos, quiero que sepas que te estás enfocando en lo incorrecto. Si te estimo $25,000 dólares por hacerte una aplicación que te genera $100,000 dólares, ¿consideras eso una inversión que valió la pena? Por lo tanto: mejor coloca su enfoque en cuál es el Return On Investment que puede obtener del producto final en base a tu idea o descripción del problema. Las siguientes preguntas nos ayudarán a establecer si vale o no la pena: ¿Es posible la idea o solución al problema? ¿Cuánto cuesta no solucionarlo? ¿Cuáles son las ventajas de solucionarlo?

Habiendo estipulado los detalles que nos ayudarán a determinar con mayor precisión el alcance del proyecto, ¿qué podemos esperar en la fase de hacer el trabajo? Comunicación. Cuando digo comunicación, no me refiero a que me des follow-up de cómo va el proyecto (con mucho respeto, eso no ayuda). Me refiero a que establezcamos un diálogo de cuáles son los pormenores del proyecto a medida que progresa: limitaciones que surjan, dependencia de otros recursos, hasta cambios que hayan que hacerse en otros procesos para lograr el resultado que tanto quieres y necesitas.

Solo te pido un favor: si me atraso, no te decepciones. Dame la oportunidad de explicarte lo que estoy haciendo para que ambos podamos ajustar nuestras expectativas de cumplimiento.