Tiempo fijo, alcance variable

La semana pasada estuve intercambiando impresiones con un cliente sobre «las bondades de estimar»; el problema a tratar era que a veces, el alcance de los proyectos depende del tiempo que uno dispone para hacer la tarea en cuestión, y discutimos sobre cómo afecta a la calidad el tiempo que decidimos dedicar a cualquier objetivo que nos marcamos.

Cuando alguien se centra en estimar lo que se va a tardar en diseñar o desarrollar X funcionalidad se suele dar por hecho que esa petición es necesaria, o sea, que es un requerimiento del proyecto y hay que hacerla sí o sí.

En mi experiencia, y así se lo he recomendado a todos los diseñadores con los que he trabajado, si te llega una tarea, conviene siempre preguntarse si de verdad es necesario eso que piden, y si lo hace, si es necesario hacerlo de esa forma que está descrita.

Proponer soluciones o ideas es muchísimo más fácil que saber definir cuánto tiempo queremos disponer para hacer una tarea, y por supuesto, definir el problema de tal forma que el alcance de la solución cumpla con esos tiempos.

Para el que no tenga experiencia previa trabajando en empresas de producto, hace ya muchos años que es normal trabajar en sprints de 1 o 2 semanas, o sea, que un lunes te llega una tarea y el viernes se espera que esté ya subido a producción.

Y ahí llegamos al concepto de Shape Up, un libro escrito por Ryan Singer (desarrollador de 37signals) donde aborda buenas prácticas y procesos de trabajo; puedes leer el capítulo o el libro entero en su versión digital gratis.

«La diferencia es que una estimación pregunta: «¿Cuánto tardará esta solución?». El appetite pregunta: «¿Cuánto tiempo estamos dispuestos a dedicarle?» y luego da forma a una solución que quepa en ese tiempo.»

Después de muchos años y aunque ahora vayamos muy rápido, la clave está en la correcta descripción del problema, algunas veces se identifica claramente, pero viene acompañado de una solución limitante, por eso el siguiente punto es interesante: establecer un tiempo determinado y dejar que la solución la decidan siempre acorde a ese tiempo, si luego a esa solución le falta trabajo, se vuelve a dedicar más tiempo y se finiquita.

Aunque ahora con la IA parece que se puede hacer de todo, con más razón es probable que decidamos incluir más funcionalidades de las debidas, haciendo más difícil decir que no a esas tareas que nos van llegando.

Dicho esto, es importante saber cuánto tiempo estás dispuesto a dedicarle a cada problema o necesidad detectada, y es por eso que aunque este concepto se ideó cuando los tiempos en diseño y desarrollo se estimaban de otra forma, tiene más sentido que nunca para mi.

Y por último, también merece la pena perderse en un pozo de tiempo y pasarte semanas rehaciendo una interacción que estás explorando (este post de Paul es inspirador en ese sentido), pero de eso ya hablaremos en otra ocasión.