- La estimación o delegación de un proyecto empieza por convertir una solicitud grande como “hacer esto” en una lista clara de tareas, y cada elemento debe mostrar el cambio deseado y el estado de finalización
- El proceso de desglose consiste en anotar los pasos necesarios a partir de una idea, boceto o lista inicial, y subdividirlos recursivamente hasta que cada elemento quede suficientemente definido
- El ejemplo de un streak tracker para actividades al aire libre se divide gradualmente en modelo de datos, vista de calendario, registro de actividades, cálculo de streaks y streak freeze, revelando también los puntos de incertidumbre
- Una “tarea suficientemente definida” es aquella en la que se puede responder sí al cambio deseado, cómo se ve terminada, todos los pasos para completarla y la información necesaria para empezar de inmediato
- Como el desglose de tareas es una habilidad que requiere reconocimiento de patrones basado en la experiencia, los equipos principiantes necesitan oportunidades seguras para practicar la planificación y recibir retroalimentación
Convertir un gran proyecto en una lista de tareas
- Las discusiones previas sobre estimación de proyectos ya asumían que existía una lista clara de tareas, pero en la práctica primero puede hacer falta la etapa anterior: el desglose del trabajo
- El desglose de tareas es el proceso de dividir un gran proyecto en trabajos que lo componen, y para estimar o delegar se necesita un nivel más fino que una sola tarea como “hacer este dibujo”
- Si es un proyecto personal hecho en solitario, un boceto puede ser suficiente, pero si se va a encargar a otra persona o se necesita estimar tiempos, hace falta más detalle
Ejemplo: streak tracker personal
- Se usa como ejemplo un streak tracker personal para registrar los días en que se realizaron actividades al aire libre
- Se quiere algo similar a la app Streaks
- Se quieren incluir opciones de actividades al aire libre como correr, ciclismo y esquí
- También se quiere incluir la función de streak freeze de Duolingo
-
1ra etapa: empezar con un boceto
- Un mockup visual es un buen punto de partida porque muestra con facilidad lo que se quiere construir
- Si es un proyecto hecho por una sola persona, con un boceto de este nivel incluso se podría empezar a programar de inmediato
- Si el objetivo es estimar o delegar, hace falta una lista de tareas más desglosada que “hacer este dibujo”
-
2da etapa: dividir por funciones grandes
- En el primer desglose, el proyecto se divide en componentes generales
- Modelado de datos
- Vista de calendario que muestra las fechas de la semana actual
- Calendario interactivo donde se hace clic en un ícono para registrar una actividad y marcar esa fecha como completada en el seguimiento de streaks
- Cálculo y visualización de la longitud del streak actual
- Implementación de streak freeze
- Para simplificar el ejemplo, se excluyen tareas operativas como despliegue o configuración de base de datos
- En un proyecto real, especialmente si participan varias personas, suele ser más apropiado separar despliegue, frontend y backend en elementos distintos
- Incluso en esta etapa ya se puede hacer cierta estimación, pero siguen quedando incertidumbres como la forma de acumular y rastrear freezes, el historial pasado o agregar y eliminar tipos de actividad
-
3ra etapa: dividir más para que se vea el criterio de finalización
- El modelo de datos se divide en tipos de actividad, actividades registradas, freezes y streaks
- Para los tipos de actividad, basta con una lista hardcodeada como run/bike/ski/climb
- Las actividades registradas tienen fecha y tipo
- Los freezes tienen fecha de obtención y fecha de uso
- Los streaks tienen fecha de inicio, fecha de fin e información agregada por tipo de actividad
- La vista estática del calendario se divide en vista semanal, pantalla principal, vista mensual, navegación y entrada para moverse entre fechas
- Para moverse entre fechas se puede usar un widget HTML5 de fecha sin necesidad de una entrada compleja de fecha difusa
- El calendario semanal dinámico no mete entrada dinámica en la vista mensual, sino que registra la finalización al hacer clic en el tipo de actividad de una fecha específica
- El cálculo y la visualización del streak recorren los registros de actividad para calcular el streak, muestran el streak actual en la UI y recalculan el streak cuando se registra una actividad desde la UI
- El streak freeze incluye acumulación, prevención de acumulación duplicada, y visualización en la UI de su uso y de la cantidad restante
- El criterio de X días para obtener un freeze puede quedar hardcodeado por ahora
- Los freezes pueden transferirse al siguiente streak
- Al recalcular el streak tras modificar actividades pasadas, hay que evitar la acumulación duplicada al volver a obtener freezes
Procedimiento iterativo de desglose
- El desglose de tareas no es un diseño que se termina de una sola vez, sino un proceso repetitivo
- Se empieza con una lista de tareas o con un proyecto grande
- Se piensan y anotan los pasos necesarios para terminar esa tarea
- Se verifica si cada paso está suficientemente definido
- Si no lo está, ese elemento se vuelve a desglosar
- Cada iteración no necesita ser completa ni exacta; basta con que amplíe aunque sea un poco la lista anterior
- El mismo proceso se repite hasta que todas las tareas queden suficientemente definidas
Criterios de “tarea” y de “suficientemente definida”
- En desarrollo de software y estimación de proyectos, una tarea es una unidad de trabajo suficientemente definida, completa y capaz de producir un cambio
- “work on stuff” no es una tarea porque no perfila ningún requisito
- “cortar un árbol” no es una tarea completa si solo se llevó la motosierra
- En un contexto laboral, una tarea solo tiene sentido si algo cambia después de hacerla
- Para saber si una tarea está suficientemente definida, se evalúa si quien la realizará puede responder “sí” a todas las siguientes preguntas
- ¿Entiende cuál es el cambio deseado?
- ¿Entiende cómo se ve “terminado”?
- ¿Puede definir todos los pasos necesarios para completarla?
- Suponiendo que no haya bloqueos ni dependencias, ¿tiene toda la información necesaria para empezar ahora mismo?
- Según el contexto organizacional, observadores como el project manager, stakeholders principales o auditores también podrían necesitar responder “sí” a estas preguntas
- Hay tareas, como corregir bugs, que tienen incógnitas difíciles de subdividir más
- En esos casos se pueden usar técnicas como timeboxing
El criterio de desglose que se forma con la experiencia
- Desglosar tareas es una habilidad que requiere práctica, y es normal que al principio no se sienta fácil
- En el ejemplo, el modelado de datos aparece primero no por un algoritmo claro, sino por intuición basada en la experiencia
- Ha existido la experiencia de que, al crear herramientas parecidas, el trabajo fluye mejor si primero se define el modelo de datos
- Django ofrece affordances que encajan mejor con un flujo centrado primero en los datos del modelo
- Si falta experiencia viendo o realizando proyectos diversos, puede ser difícil decidir por dónde empezar
- Para que un equipo desarrolle esta capacidad, necesita crear planes de proyecto en un entorno seguro, intentar desglosarlos y recibir retroalimentación
- Si no se castiga que los planes iniciales estén muy equivocados, esos errores se convierten en datos de experiencia útiles para el siguiente reconocimiento de patrones
Resultado de la estimación del proyecto de ejemplo
- En la estimación extra, después de desglosar las tareas se asignan complejidad, incertidumbre, días estimados y días en el peor caso
- El total estimado se calcula en 15.5 días, y el peor caso en 23.5 días
- Entre los elementos principales, el cálculo del streak y la acumulación de freezes tienen complejidad media e incertidumbre moderada, con una estimación de 3 días y un peor caso de 4.5 días cada uno
- La prevención de acumulación duplicada de freezes tiene complejidad small pero incertidumbre extrema, con 1 día estimado y 5 días en el peor caso
- En la práctica, se completó en alrededor de doce noches y un vuelo largo, pero se omitió gran parte del diseño y es posible que el algoritmo de freeze tenga bugs que aparezcan más adelante
1 comentarios
Opiniones de Hacker News
Primero, casi nunca he llevado a cabo los pasos reales hasta el final tal como los planeé. Después de apenas unos pasos, uno se da cuenta de algo nuevo, descubre algo que se le pasó o ve una forma más fácil, así que deja de seguir el plan.
Segundo, siento que todo el esfuerzo creativo de pensar cómo construirlo queda concentrado al principio, y por eso no me gusta trabajar así. El resto sigue siendo la mayor parte del trabajo, pero solo queda la parte más aburrida; me parece más divertido mezclar creatividad y tedio de forma más pareja, y por eso también es más rápido y da mejores resultados.
Probablemente ambas cosas estén relacionadas, y tampoco descarto que yo tenga TDAH.
Si estás explorando o creando tu propio proyecto y no tienes una estructura de responsabilidad particular, no hace falta planear tanto, salvo que te guste planear en sí.
Pero en el momento en que tu jefe pregunta “¿cuánto va a tardar?, ¿quién hace qué?, ¿por dónde empezamos?”, necesitas algún marco.
A mí también me molesta ajustarme a sistemas arbitrarios o demasiado rígidos, pero un sistema debe ser simple y flexible, y los sistemas de productividad existen para ayudar a las personas.
No creo que el autor lo haya planteado como una receta detallada, sino más bien como una forma de mostrar su enfoque para que otras personas saquen sus propias ideas.
A veces es incluso peor que decir “el plan nunca se sigue tal cual”. Si durante la ejecución sigues agregando tareas, al final queda una lista desordenada de tareas incompletas que se mezclan con las creadas durante la planificación y que ya no hacen falta.
Esas tareas se crearon sin el contexto completo que solo aparece durante la ejecución.
Lo divertido de programar es que es una actividad creativa flexible y fluida. Uno va construyendo sobre la marcha y la experiencia se da de forma orgánica.
En un entorno laboral, como se necesitan supervisión y responsabilidades claras, esa organicidad suele eliminarse.
La próxima vez que planees algo igual o parecido, el plan futuro será mejor.
Los gestores de proyectos también tienen el lema: “fallar en planear es planear el fracaso”.
Porque a menudo me doy cuenta de que se me escapan muchas cosas entre todo lo que tengo que recordar.
Un plan es solo una forma de recordarle a mi yo futuro el resultado ideal que mi yo del pasado había imaginado, en vez de cambiar el plan sin parar persiguiendo luciérnagas.
“Dividir tareas” es un tema tan grande que podría convertirse en un género de libros o de podcasts. Muchos libros de autoayuda u organización parecen asumir que dividir tareas es una capacidad humana primaria que los lectores ya poseen.
Pero por mi experiencia y por lo que he escuchado en sesiones grupales, dividir tareas es muy difícil y puede generar evasión o desesperanza.
El consejo más ampliamente aplicable que he visto es seguir dividiendo la tarea hasta tener un 90% de confianza en que puedes completarla con éxito. Ese nivel de confianza varía según la autoconfianza y la tolerancia al riesgo: algunas personas podrían dividirla hasta llegar a algo con un 70% de probabilidad de éxito.
En un día tienes unas 6 horas disponibles; cuando alguien dice con confianza que algo tomará “medio día” y le señalas que eso son unas 3 horas, de pronto se muestra mucho menos seguro o se molesta. Y tres días después sigue trabajando en eso.
Este método resultó sorprendentemente preciso para estimar tiempos, pero visto en el total; las estimaciones individuales se equivocan por mucho.
Al final es una estimación probabilística. Después de muchos eventos, converge hacia el promedio.
El problema que la mayoría no entiende es que el desarrollo de software es, ante todo, más parecido a una actividad creativa. Claro que tiene aspectos técnicos serios, pero como el problema en sí es virtual y no está atado a restricciones del mundo real como la ingeniería civil, no existe una única solución óptima.
Si intentas definir la solución antes de examinar bien el problema, solo terminas limitando el resultado final. La mayor parte de la exploración ocurre recién después de empezar a programar.
En software no es tan importante que el resultado final y el tiempo no estén claramente definidos, porque no hay costo por unidad. Los gerentes sin formación en ingeniería de software no entienden bien esto.
Un producto de propósito general puede venderse a varios clientes sin costos adicionales de desarrollo.
Pero como la mayoría de las empresas operan como fábricas, todos los procesos terminan produciendo productos muy limitados dirigidos a un cliente específico. Eso es precisamente lo que las grandes empresas tecnológicas evitaron.
Parece que toda la industria aceptó este patrón.
Pero, sinceramente, creo que lo que nos frena a la mayoría es más bien la falta de capacidad para no hacerlo. Si hay algo que quieres construir, no planees todas las piezas: simplemente construye lo más pequeño que pueda tener valor.
En el ejemplo, bastaría con empezar por la pantalla de “hoy” y cuatro botones. Hoy podrías construir algo que muestre cuatro botones de ejercicios para pulsar cada día. No necesitas rachas, congelamientos ni vista de calendario.
Todas esas ideas son buenas y seguramente las harás después, pero primero necesitas impulso. Tal vez unos días más tarde decidas que esa vista de calendario no te convence.
Más proyectos necesitan ese empujón de “hazlo aunque sea en pequeño”. Termina algo hoy y, desde ese punto, mira cuál es el siguiente trabajo. Es muy probable que sea distinto de lo que pensabas en la etapa de planificación
Claro que esto tampoco es fácil. Encontrar lo más pequeño y decidir lanzarlo sin distraerse requiere reflexión y disciplina. Aun así, vale la pena practicarlo
Es el principio de que, frente a la incertidumbre, hay que concentrarse en “lo siguiente correcto que hay que hacer” [0]
No pretendo trivializarlo. Descubrir lo siguiente correcto que hay que hacer es difícil y, desde mi punto de vista, es la parte más valiosa de la planificación
0: https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis
Por ejemplo, una persona crea el método de comparación para pruebas, otra prueba un enfoque, otra prueba otro enfoque y una tercera prueba otro más; luego, al cabo de un plazo definido, todos los evalúan
Claro que solo tiene sentido cuando no hay ya un enfoque preferido o claramente superior
En el desarrollo real, la modularización puede ser una forma de paralelizar: que cada persona o equipo se encargue de un componente
En mi trabajo, sobre todo cuando todavía estoy tratando de encontrar la dirección, me gusta alternar entre la parte orientada a las personas y el interior técnico. Si desarrollas solo la tecnología sin saber cómo se usará, fuerzas las formas posibles de uso en cierta dirección; y diseñar solo la interfaz sin conocer la tecnología también tiene sus trampas
Pero en trabajos que, como la investigación, requieren experimentos creativos y pruebas de concepto para validar cosas que no pueden conocerse de antemano, la descomposición del trabajo en sí se viene abajo
Por eso adquirí el hábito de hacer la mayoría de los trabajos de prueba de concepto en privado y no decírselo a nadie
Si sale bien, lo puedes hacer público; si no, puedes descartarlo y seguir adelante sin quedar mal ni escuchar que tienes que hacerlo funcionar de algún modo aun después de haber confirmado que no deberías continuar
Basta decir: “Dediquemos 3 horas a investigar X, 3 horas a Y y 3 horas a Z, y luego hagamos una reunión de planificación para decidir qué hacer después”
Hay cuatro resultados: el primero lo resuelve, el segundo lo resuelve, el tercero lo resuelve o ninguno lo resuelve
Si es un problema que puede resolverse con un poco de esfuerzo, la probabilidad de resolverlo en el segundo intento, es decir, dentro de 6 horas, es del 50%
Y en algún momento, simplemente hay que hacerlo
Descomponer el trabajo y estimarlo son casi lo mismo. Una vez hecha la descomposición, alguien con algunos años de experiencia tiene estimaciones estándar para tareas pequeñas, así que asignar una estimación a cada pieza toma apenas unos minutos
En mi caso, divido el trabajo en bloques que puedo estimar, y para las partes que no puedo estimar pido la opinión de otras personas
Sin embargo, no creo que el verdadero camino hacia la maestría sea la descomposición del trabajo. Cualquiera puede crear una mala descomposición
La verdadera maestría está en notar cuándo la evidencia muestra que esa descomposición está lo suficientemente equivocada como para causar problemas, y en comunicarlo o reestimar [0]
También es importante aceptar con tranquilidad que eso va a pasar, para no estresarse desde el principio al presentar un cronograma con altas probabilidades de cambiar
Los gerentes suelen querer desde el inicio una hoja de ruta precisa, pero eso es pedir algo imposible. Creo que una buena gestión consiste en la flexibilidad y en entender que, con el tiempo, a medida que los desarrolladores aprenden, cambia la naturaleza del trabajo que se esperaba
El pequeño ejemplo del final del artículo también vale la pena pensarlo. Aunque alguien hubiera dado una estimación exacta, es decir, “se termina con unas cuantas cenas durante viajes en avión”, él la habría rechazado por ser demasiado riesgosa
Eso muestra que estimar no es solo una cuestión de precisión. Hay muchos factores que no se expresan por completo con palabras como gestión de riesgos, gestión de expectativas o familiaridad con el trabajo
[0] https://jacobian.org/2021/jun/8/incorrect-estimates/ - También hay un artículo sobre este tema
Son buenos nuevos profesionales de software, pero a veces el área es nueva para ellos y realmente no saben cómo construir funcionalidades básicas. Según mi experiencia, quieren tareas de las que puedan aprender y salir adelante, y eso se traduce en crecimiento
Lo que hay que recordar siempre es que el costo del proceso es un continuo que se ajusta al equipo. Los jugadores de la NBA no aprenden a lanzar la pelota en un huddle durante el partido, pero los niños de tercer grado de primaria sí
La planificación y el coaching de ambos enfoques son adecuados cuando encajan con cada equipo
Quizás esa sea la verdad central de la ingeniería de software. Puede que ya exista una versión open source de la app Streak que el autor quiere crear, y que esté reinventando la rueda
Al cerebro no parece gustarle las listas de tareas. Hacer listas puede ser agradable, pero la mayor parte de emprender o programar es exploración
Y las listas de tareas bloquean la exploración
Si no, ¿qué cambia en el desarrollo de software para que en nuestra profesión “no sé” sea una respuesta razonable?
A veces eso es correcto y a veces no. “El mapa no es el territorio”
Para dividir el trabajo en tareas más pequeñas, hay que hacer trabajo duplicado, y el truco está en minimizarlo
Si intentas no hacer ningún trabajo innecesario, al final tienes que hacerlo todo de una vez
Por ejemplo, supongamos que vas a refactorizar un programa con los módulos A y B, donde B depende de A. La forma con menos desperdicio es refactorizar ambos módulos juntos. Pero eso es lo más riesgoso y también lo más difícil de estimar
La forma en que se dividió fue refactorizar A y adaptar B para que funcionara con el A refactorizado. Luego, si se vuelve a refactorizar A, aparece el riesgo de que ese trabajo de adaptación hecho antes se descarte rápidamente
Si quieres que el trabajo desechable sea cero, muchas veces no se puede dividir el trabajo. Incluso con 20 años de experiencia, todavía dudo con frecuencia al hacer trabajo temporal que se va a descartar para poder dividir las tareas
En cambio, suelo terminar haciendo trabajos de varias semanas y afeitando todos los yaks pendientes sin dejar ni un solo pelo
Tiene sentido pensar en el problema que se quiere resolver antes de empezar, y los hitos aproximados también son importantes. Pero la mayoría de las veces hay demasiadas incógnitas desconocidas, así que desglosarlo por completo es totalmente inútil o imposible
Siento que, si el tiempo que se dedica a dividir el proyecto se hubiera usado simplemente para encontrar o construir la solución, se habría terminado mucho más rápido. Al menos así se siente
Yo normalmente lo abordo de otra manera. La idea es estimar el esfuerzo necesario para decidir, desde el principio, si conviene construirlo o no. Es decir, la primera razón es ayudar a hacer un análisis costo-beneficio
También puede ser muy beneficioso para el equipo. Sobre todo cuando se trabaja con personas con menos experiencia, se puede dividir mucho el trabajo y paralelizarlo
Supongo que Jacob tampoco hizo mucho este tipo de descomposición al implementar su app Streak, y por eso parece haber usado un ejemplo recursivo para explicarlo
En esos casos fue útil dividirlo en tareas más pequeñas e ir terminándolas una por una. Así se genera avance incluso cuando estás trabado o sin ganas de trabajar, y ese avance crea el impulso para seguir
Que los managers puedan estimar la velocidad claramente también tiene valor. El problema es que, una vez que le toman el gusto, realmente dejan de entender cuando uno dice “no estoy seguro”
Yo también soy consultor, así que, aunque trabajemos de forma “ágil”, es muy importante poder decir “entregaremos esto dentro de este plazo”