DEV Community: Fernando Cañas

Prefiero invertir que estimar

Fernando Cañas — Sun, 03 May 2026 18:30:50 +0000

Estimar cuánto tiempo voy tardar en resolver un problema suele ser difícil, sobre todo si es un problema nuevo. Peor que eso es estimar cuánto se va a demorar otra persona.

Sin embargo, ahí sigue uno intentando estimar, fallando una y otra vez. Aferrado a la idea de que debe existir una forma correcta de estimar y lo único que le falta a uno es aprender a hacerlo bien.

Pero nada cambia. En unas tareas, uno estima un día entero pero realmente usa 2 horas. En otras, uno estima 15 minutos y usa toda una tarde.

Así que me cansé y decidí cambiar el problema. Ya no le dedico el tiempo a estimar, sino a invertir.

¿Cuál es la diferencia?

Estimar es una función en la que entran dos parámetros: la solución planteada a un problema y mi experiencia resolviendo problemas varios. La función retorna un tiempo en el que se supone puedo construir esa solución.

Defino aquí el término invertir como un presupuesto en tiempo que se asigna como restricción a cualquier solución de un problema. El diseño y construcción de la solución deberá satisfacer esta restricción.

Algoritmos fallidos

Esa función que estima ha tenido por dentro algoritmos diferentes:

Estimación medida en tiempo.
Estimación con puntos usando la secuencia Fibonacci que de alguna manera se convierten en tiempo.
Estimación con tallas tipo XL, L, M, S, que también de alguna forma se convierten en tiempo.
Estimación en grupo con cualquiera de las técnicas anteriores y promedios.

Todos algoritmos fallidos.

¿Seguimos probando a inventar más algoritmos? Yo prefiero replantear el problema para poder aplicar algo en lo que sí seamos buenos.

En qué sí somos buenos

Cuando nos dan un tiempo límite para alcanzar un resultado, de alguna forma encontramos la forma de lograrlo. Es la capacidad humana para lograr mucho con poco.

Pero para que este poder funcione, la creatividad tiene que estar disponible. Si podemos rediseñar, reorganizar, replantear, acortar, extender, reutilizar, etc., somos capaces de resultados que parecerían imposibles al principio.

En este terreno sí somos buenos. Usando nuestra creatividad en condiciones restringidas.

Restringir la inversión y no la solución

La creatividad humana es tan potente, que podríamos diseñar proyectos que nos tomaría siglos construir.

El problema es que tomamos un problema y diseñamos una solución usando toda nuestra creatividad. Luego imponemos el diseño como restricción y le pedimos a los constructores que estimen cuánto se van a gastar.

¿Por qué no le damos la vuelta? Decidamos cuánto estamos dispuestos a invertir, agreguemos esa conclusión como restricción y dejemos que la creatividad resuelva dentro de ese límite.

Nuevo punto de partida

¿Cuánto tiempo máximo estoy dispuesto a invertir en resolver este problema?

Hay que responder esa pregunta en días. Preferiblemente, la respuesta tiene que ser menor a 2 semanas, de lo contrario hay que partir el problema en partes más pequeñas.

Por qué 2 semanas máximo

Si el problema es preparar un almuerzo, máximo invierto una mañana sin importar qué vaya a cocinar. Un día ya sería mucho. Dos días, una exageración.

Si el problema es encontrar la cura para cualquier cáncer, podría estar dispuesto a invertir los años de vida que me quedan.

En el primer caso, apenas empiece el cronómetro a correr, yo me empiezo a mover. Sólo tengo la mañana, así que hay que decidir rápido qué voy a preparar, salir a comprar los ingredientes, poner las ollas, empezar a picar, etc.

Si fui al supermercado y olvidé comprar un ingrediente, puedo evaluar si alcanzo a ir a comprarlo o si resuelvo con lo que tengo.

En el segundo caso, apenas empiece el cronómetro a andar, no pasa nada. El problema es tan grande que no sabría ni por dónde arrancar. El tiempo que pienso invertir se ve tan largo que tampoco es como para afanarse. No hay movimiento.

Para mí, dos semanas es el tiempo máximo que puesto en un cronómetro crea movimiento.

Replanteando

El tiempo es un recurso escaso y muy valioso, deberíamos usar toda nuestra creatividad para usarlo eficientemente.

Siempre habrá muchos problemas por resolver y seguramente no el tiempo suficiente para resolverlos todos.

Dejemos de pedalear estimaciones. En su lugar:

Definamos bien el problema.
Acordemos qué significa resolver satisfactoriamente el problema (resultados esperados).
Acordemos cuánto tiempo estamos dispuestos a invertir en resolver ese problema con esas condiciones.
Usemos nuestra creatividad al máximo para hallar la salida.

Tablero kanban de flujo libre

Fernando Cañas — Sun, 26 Apr 2026 16:29:28 +0000

Luego de varias iteraciones creando tableros kanban para equipos de desarrollo, finalmente logré crear uno con el que me siento cómodo. No sólo yo como Product Manager, también mi equipo de desarrollo.

El tablero tiene 9 columnas, agrupadas en 5 estados.

Estados

Los estados por los que pasa una tarjeta son:

Análisis
Diseño
Ejecución
Revisión
Hecho

Análisis (Qué + Por qué)

Esta etapa se dedica al "qué" y el "por qué". Es decir, si se va a construir algo nuevo, hay que plantear en concreto "qué" se desea construir y "por qué" es importante.

Si hay un error del sistema que hay que corregir, hay que determinar en concreto cuál es el error y por qué está ocurriendo, en qué circunstancias. Por qué los tests no lograron captar el error en primer lugar.

Si se va a cambiar el diseño de una interfaz, qué se quiere cambiar y por qué es importante para la experiencia de usuario.

En conclusión, esta etapa permite pensar el problema para precisarlo y ser capaces de justificar la necesidad de resolverlo.

Diseño (Cómo)

Cuando un problema está definido, tanto en el qué es lo que se quiere resolver y por qué, ya se pueden empezar a crear posibles soluciones. Esto ocurre en la etapa de diseño.

En esta etapa se generan alternativas, que puedan ser evaluadas en conjunto por el equipo hasta escoger una.

Ejecución

Con un análisis claro del problema y el diseño escogido para resolverlo, esta etapa se dedica a construir la solución. Como su nombre lo indica, es el momento de ejecutar sobre lo analizado y decidido.

Revisión

Esta etapa no sólo revisa los resultados de la ejecución. También revisa los entregables de las etapas de análisis y diseño.

Una tarjeta en el tablero puede pasar varias veces por esta etapa de revisión.

Cuando un análisis se estima ya completado, pasa a revisión. Si la revisión considera que no es así y se requiere mayor detalle, que existen puntos de análisis faltantes, entre otros, la tarjeta regresa a la etapa de análisis.

Lo mismo ocurre con los diseños. Cuando se estima que están completos, pasan a revisión. Si la revisión concluye que no es así, la tarjeta regresa para extensiones o correcciones al diseño.

Con los entregables de la ejecución ocurre igual.

Hecho

Las tarjetas pasan a hecho cuando se han superado las 4 etapas anteriores o cuando en cualquier punto del camino se toma la decisión de no seguir adelante con una tarjeta. Esta segunda opción debería ir acompañada de su correspondiente justificación (el por qué no justifica la inversión, el alcance del proyecto se redujo, el diseño reveló restricciones que hacen inviable en el corto plazo la implementación, entre otros).

9 Columnas

El tablero tiene 9 columnas porque casi todas las etapas requieren dos columnas. Una de espera y otra de actividad.

Las columnas de espera es donde están las tarjetas que se encuentran en una etapa en particular, pero que no están siendo atendidas en ese momento por nadie. Es decir, están a la espera de ser resueltas.

Las columnas de actividad están las tarjetas que en ese mismo instante están siendo trabajadas por alguien del equipo. Al ver en el tablero qué tarjetas están en las columnas de actividad permite saber rápidamente qué tareas está trabajando el equipo en ese instante.

Por lo tanto, las 9 columnas serían:

🕐 Cola de análisis
🤔 Analizando
🕐 Cola de diseño
✏️ Diseñando
🕐 Cola de ejecución
💻 Ejecutando
🕐 Cola de revisión
🔎 Revisando
✅ Hecho

Sin orden estricto

Por lo general, una tarjeta primero se analiza, luego se diseña y finalmente se ejecuta. En el intermedio, va pasando varias veces por revisión hasta cumplir con cada etapa.

Sin embargo, el tablero no pretende que todas las tarjeta siempre deban pasar por este orden. De hecho:

Una tarjeta puede nacer en cualquier columna.
Una tarjeta puede pasar múltiples veces por la misma etapa.
Una tarjeta puede circular por las etapas en cualquier orden.

Lo anterior puede ocurrir porque las tarjetas pueden intentar resolver temas de distinto tipo. No es lo mismo construir una funcionalidad nueva que ajustar una configuración.

También puede ocurrir porque hay proyectos que son tan grandes que se decide crear tarjetas separadas por tema o inclusive tarjetas por etapa.

El tablero no obliga a que las tarjetas fluyan de una manera específica. El tablero es una herramienta para que el equipo piense y ejecute de forma ordenada, no una línea de producción industrial.

Cola vs. Actividad

Cuando una tarjeta está en la cola es porque no está siendo atendida. Es la persona que va a trabajar la tarjeta quien mueve la tarjeta a la columna de actividad.

Esto actúa como señal para todo el equipo, de tal forma que se sabe que acaba de empezar a trabajar en esa tarjeta.

Si por alguna razón ocurre un bloqueo que impide continuar la ejecución de una tarjeta, el responsable anota la causal del bloqueo y regresa la tarjeta a la columna de cola.

Reasignación

El responsable de asignar tarjetas puede asignar tarjetas con libertad cuando estas están en una columna de cola. No puede hacerlo cuando está en una columna de actividad.

Para poder reasignar una tarjeta que está en actividad, se requiere del acuerdo con la persona que está trabajando en ella.

Generalización

Este tablero me ha sido útil para tareas de desarrollo. Sin embargo, las etapas que presento no están estrictamente relacionadas con actividades propias del desarrollo de software: "desarrollo", "testing", "deployment", "qa", etc.

Por lo tanto, creo que este diseño puede resultarle útil a equipos que no sean específicamente de desarrollo de software. Puede serle útil a cualquier equipo cuya producción se base en el análisis de problemas y en el diseño e implementación su soluciones.