Algunas personas pueden pensar que la mejor manera de estimar un proyecto es tener requisitos detallados e información de diseño para cada característica. Pueden argumentar que esta es la forma más profesional y precisa de abordar el problema. Sin embargo, no estoy de acuerdo con esta opinión. Creo que es más importante poder tomar decisiones rápidas sobre el alcance del proyecto sin gastar demasiado tiempo y recursos en estimaciones detalladas. ¿Por qué? Porque las estimaciones detalladas a menudo resultan erróneas o irrelevantes más adelante, y crean un “inventario desperdiciado” que podría haberse utilizado para actividades más valiosas. Le sugiero que sólo haga estimaciones detalladas cuando el cronograma lo permita y cuando tenga una comprensión clara del valor y la prioridad de cada característica.

Uno de los problemas más frustrantes, generalizados y aparentemente francamente siniestros en todo el desarrollo de aplicaciones es el síndrome del “Sí, pero”, que consiste en la observación de la reacción de los usuarios ante cada pieza de software que he desarrollado.

Por alguna razón, siempre observo dos reacciones inmediatas, distintas y separadas cuando los usuarios ven la implementación del sistema por primera vez:

• “Vaya, esto es genial; realmente podemos usarlo, qué trabajo tan genial”. Atta boy", y así sucesivamente. • “Sí, pero, hmmmmm, ahora que lo veo, ¿qué pasa con esto…? ¿No sería bueno si…? ¿Qué pasó con…?"