- La modernización de software legado dificulta definir todo el alcance solo con la información visible antes de empezar, por lo que las estimaciones iniciales deben tratarse como una referencia ajustable, no como una fecha límite
- Como en la reparación de un auto, al principio es posible estimar algo como US$18,000 y 30 días, pero si tras desmontar e inspeccionar aparecen daños ocultos, se necesita una estimación complementaria y una nueva aprobación
- En los proyectos de modernización también aparece complejidad oculta, como fallas de integración o comportamientos inesperados; en ese punto, forzar el ajuste a la estimación original choca con la realidad
- Un liderazgo sano pregunta por la complejidad, las soluciones, los trade-offs y las alternativas, más que “por qué no lo vimos”, y decide si seguir adelante o detenerse
- En contextos complejos se requiere iterar entre intentos, experimentos y descubrimientos más que seguir un manual de reglas fijo; el líder debe crear un entorno donde emerjan patrones, más que imponer un control excesivo
Las estimaciones no son fechas límite, sino referencias para avanzar
- En una modernización de software compleja, tratar una estimación como si fuera una fecha límite confirmada entra en conflicto con la realidad que aparece durante el trabajo
- La estimación inicial se construye a partir de la información visible desde afuera y de la experiencia, pero una vez que el trabajo empieza puede aparecer nueva complejidad
- Una “estimación” es una aproximación al valor real, y en una modernización compleja es difícil predecir perfectamente todos los resultados antes de empezar
La analogía de la reparación de autos: daños invisibles y estimaciones complementarias
- En una reparación de autos, el perito del seguro primero envía una estimación de daños al taller, y el taller también entrega su propia estimación a la aseguradora
- Por ejemplo, el perito del seguro estima daños por US$15,000
- El taller estima daños por US$18,000 y un plazo de reparación de 30 días
- El perito del seguro y los especialistas del taller evalúan juntos los daños y, cuando la aseguradora aprueba la nueva estimación, comienza la reparación
- Durante la reparación pueden descubrirse daños que no eran visibles al principio
- Al desmontar piezas pueden aparecer daños adicionales
- Se puede inspeccionar el daño en el unibody frame con una máquina de alineación de chasis
- También hay que verificar si el impacto se transmitió no solo al punto de choque, sino hacia la parte trasera del chasis
- Si por los daños adicionales se necesitan US$20,000 más, el taller envía a la aseguradora una solicitud de reparación complementaria, y la aseguradora decide si continuar con la reparación o declararlo pérdida total (total loss)
- Que la aseguradora rechace los US$20,000 adicionales solo porque la estimación original era de US$18,000 no coincide con un proceso de reparación realista
En la modernización de sistemas legados también aparece complejidad oculta
- La modernización de software legado pertenece al ámbito del software complejo
- Se puede hacer una estimación inicial con base en problemas que parecen claros desde afuera, pero durante el trabajo real aparece más complejidad
- Así como en una reparación de autos pueden descubrirse daños ocultos o daños en el chasis, en una modernización pueden surgir problemas que no estaban en la estimación inicial
- En estas situaciones, en lugar de quedar atados a la estimación original, hay que definir los siguientes pasos mediante aprobaciones adicionales y una nueva evaluación
Las preguntas que hace un buen líder
- En un entorno saludable de desarrollo de software, cuando aparece un problema se hacen preguntas necesarias para decidir, en lugar de buscar culpables
- ¿Qué tan complejo es este problema?
- ¿Qué formas de resolverlo existen?
- ¿Cuáles son los trade-offs de cada alternativa?
- ¿Hay soluciones alternativas o caminos de mitigación?
- En cambio, si la conversación deriva hacia “por qué no vimos esta complejidad”, “por qué tarda tanto” o “por qué no se cumple la fecha estimada original”, el equipo queda atado a esa fecha estimada inicial
- En los proyectos de modernización puede ocurrir tanto que se continúe como que se detenga el trabajo
- Si se aprueba el costo complementario, se pasa a la siguiente etapa y, al repetir este proceso, el proyecto se acerca a su finalización
- Si el costo supera el valor, el proyecto puede detenerse
- La decisión entre avanzar y detenerse no es fácil, y pueden usarse frameworks y talleres de toma de decisiones para definir la dirección
La diferencia entre contextos complicados y contextos complejos
- En el Cynefin framework de A Leader’s Framework for Decision Making, la reparación de autos o el mantenimiento de motocicletas podrían estar más cerca de un contexto complicado (complicated context)
- En la reparación de autos, un experto escucha las circunstancias del accidente y analiza y prueba distintos factores —como daños invisibles o daños en el chasis— para decidir la mejor acción
- En un contexto complejo (complex context), solo después de intentar algo se puede juzgar si era correcto o no
- Una integración que se esperaba que funcionara puede fallar
- Puede descubrirse un comportamiento nuevo que no se conocía y que debe incorporarse
- En la modernización de sistemas legados complejos no hay una ruta fija ni un manual de reglas que seguir
- La modernización repite un proceso de intentar, experimentar, descubrir, resolver y pasar a la siguiente pieza
Las bolas curvas no son la excepción, son la realidad
- Si la modernización de aplicaciones está entre lo complejo y lo complicado, se necesita un tablero de control adecuado para juzgar el avance y el éxito
- Aplicar un proceso simple de estimación a un contexto complejo es como intentar resolver todos los tornillos y tuercas de rueda con un martillo
- Los cambios inesperados —las bolas curvas— en los proyectos de modernización son una realidad
- No se pueden predecir todos los resultados de antemano
- Por mucho análisis previo que se haga, no se llega a un modelo de datos perfecto
- En casi cada etapa ocurre un nuevo aprendizaje
- Según la complejidad descubierta, el modelo de datos debe cambiar
- Cuando la estimación cambia, en lugar de enojarse, culpar o aferrarse a análisis para forzar el calendario, hay que encontrar una forma de avanzar
Cómo la cultura organizacional maneja las bolas curvas
- El modelo de cultura organizacional de Ron Westrum distingue cómo una organización trata a las personas que informan bolas curvas y cómo maneja los fracasos
- Las organizaciones Power-Oriented disparan contra el mensajero que informa la bola curva, y el fracaso deriva en búsqueda de chivos expiatorios
- Las organizaciones Rule-Oriented ignoran al mensajero que informa la bola curva, y tratan el fracaso como un problema de implementación correcta
- Las organizaciones Performance-Oriented entrenan al mensajero que informa la bola curva, y convierten el fracaso en exploración
- Si el problema que se intenta resolver sigue siendo relevante y satisface las necesidades del negocio, hay que avanzar un paso a la vez
- El destinatario final del software que se quiere modernizar son los usuarios
Las áreas complejas requieren gestión experimental
- Un líder que no reconoce el área compleja puede impacientarse cuando los resultados buscados no aparecen rápido
- En un área compleja es importante la capacidad de tolerar el fracaso, y el fracaso es un elemento esencial de la comprensión experimental
- Controlar excesivamente una organización impide que aparezcan patrones útiles
- Los líderes que intentan imponer orden por la fuerza en un contexto complejo fracasan
- Los líderes que preparan el escenario, dan un paso atrás, dejan que los patrones emerjan y juzgan cuáles son los patrones deseables pueden tener éxito
1 comentarios
Comentarios de Hacker News
Me tocó vivir una época en la que la gerencia trataba las estimaciones como fechas límite, seguía cambiando las especificaciones y aun así no quería escuchar en absoluto por qué podían cambiar
En esos casos, ante cualquier cosa no trivial, optaba por una reacción tipo “venado frente a los faros”. Si decía: “Esto podría ser algo bastante grande. Creo que alguien del equipo debería dedicarle como una hora a ver qué se necesita realmente”, el gerente, como siempre, pedía “aunque sea una aproximación”. Entonces le daba un número lo bastante grande como para hacerlo saltar de la silla, y ese número se le quedaba grabado. Después de hacer una hora de diligencia debida, intentaba no dar ningún número distinto a esa aproximación y, al final, terminaba “antes de lo previsto”, quedando bien
Con buenos gerentes esta estrategia no hacía falta para nada, y eso era realmente agradable, pero con personas que no tenían intención de aprender las competencias de su propio puesto, uno terminaba respondiendo así. Las reuniones también se volvieron mucho más divertidas
El equipo de diseño, el de frontend, el de backend y el de QA inflaban cada uno así sus cifras; luego el gerente de proyecto volvía a aumentar la suma en 150~200%, y el administrador de cuenta y el equipo de ventas añadían otro 150~200% antes de calcular el costo
Como resultado, mantener un sitio web que un equipo dedicado de 8~10 desarrolladores web/full-stack decentes habría podido manejar perfectamente costaba cerca de 1 millón de dólares al mes. Quitando el soporte 24/7, creo que habría sido posible con unos cuantos buenos desarrolladores de Rails o Django, o incluso con uno solo y un diseñador gráfico de medio tiempo
Años después, el cliente se dio cuenta de la situación, y la dirección de la empresa arruinó todo por completo: unas 100 personas perdieron su empleo y derechos pendientes de pago. Ese día yo también perdí unos 26 mil dólares
La capacidad total era, por ejemplo, de 40 puntos, y cambiaba un poco cuando alguien salía del equipo o se incorporaba. La Velocity es el rendimiento promedio medido en puntos por persona-día de trabajo
La Volatility indica cuánto cambia el sprint. Quitar un ticket de 5 puntos y meter uno de 3 y otro de 2 puede estar bien, pero si haces eso 12 veces en un sprint de 2 semanas, no terminarás el sprint aunque el total siga siendo de 40 puntos o menos
Tomábamos una instantánea diaria del sprint para ver la cantidad de tickets agregados y eliminados, y pudimos mostrarle a la gerencia que, cuando la volatilidad era baja, casi siempre terminábamos, pero cuando era alta, fallábamos independientemente de si superábamos o no la Velocity. La razón es que no hay tiempo para planificar bien ni aclarar requisitos. Lograr que el equipo de producto mirara más allá de 2 semanas ayudó hasta cierto punto
También era más probable que un ingeniero que daba estimaciones exageradamente infladas para tareas simples fuera de bajo rendimiento. Puede funcionar con alguien que no juzga las entregas lentas o con un gerente que no conoce la situación, pero un gerente que sí la conoce se da cuenta rápido
En vez de un único valor fijo, hay que dar también un margen de error, como “3 meses, ±4 semanas”. La mayoría de los ingenieros sabe que sus estimaciones tienen un margen de error, pero por alguna razón han sido condicionados para olvidar decirlo
Desde el punto de vista de gestión, el tamaño del margen de error también muestra de inmediato cuánta confianza hay en la estimación y permite hablar de riesgos. Se vuelve posible una conversación como: “Ahora tenemos un error de 30% en ambos sentidos; ¿cuál es la causa principal y podemos investigar unos días para reducir una o dos?”
No entiendo cómo una profesión de ingeniería puede no hablar correctamente de riesgo, probabilidad e intervalos de confianza. Esto tampoco es responsabilidad exclusiva de los gerentes
Se puede entender en gerentes sin experiencia o en alguien que está cubriendo temporalmente el puesto de otra persona, porque no están acostumbrados a la incertidumbre, pero fuera de esos casos no hay excusa
Este artículo trata sobre proyectos de modernización, y estos proyectos tienen fechas límite flexibles porque el software existente sigue funcionando mientras se desarrolla el reemplazo
Puede haber presión presupuestaria, compromisos y expectativas de los usuarios sobre nuevas funciones, pero si el reemplazo se retrasa un día no pasa nada grave
En cambio, si lanzas una sonda espacial y la posición del planeta deja de ser adecuada para una asistencia gravitatoria, la nave no llegará a su destino. Si un pequeño fabricante de herramientas con ingresos anuales de 100 millones de dólares firma un contrato con Ford para entregar en marzo moldes para la línea de producción de la F150 2026, con una multa de 20 mil dólares por minuto si se retrasa, no puede decir en febrero: “Surgió algo inesperado, así que no se va a poder”. Solo debería firmar cuando esté seguro de poder hacerlo
A Ford o a NASA no les sorprende que preparar una cotización cueste decenas de miles de dólares. Te dan una ECO, y aunque una pieza parezca algo que podrías hacer a mano en 30 minutos, si dices que requiere 3 semanas y 8 mil dólares, ellos saben que ahí están incluidos el riesgo de plazo, la etapa de recepción, la etapa de inspección, planes de contingencia, etc.
Pero si en el grupo de modernización del OP alguien dijera: “Por información incompleta, una tarea de 30 minutos para cambiar el texto de un botón podría tardar hasta 3 semanas y costar 8 mil dólares”, lo sacarían a patadas. Las estimaciones optimistas se recompensan, las pesimistas se desalientan y las precisas dejan de importar. Al final, siempre se termina atrasado y nadie se sorprende demasiado
Eso puede incluir mantenimiento por cambios de hardware, actualizaciones del sistema operativo o soporte para nuevas funcionalidades. He visto proyectos que siguen en paralelo así durante más de 10 años
En 1505, Michelangelo estimó que tardaría 5 años en terminar la tumba del Pope Julius II
En realidad tardó unos 40 años, por pequeños trabajos secundarios como el techo de la Sistine Chapel
Al no cumplir la fecha límite basada en la estimación, el alcance del proyecto se redujo mucho. Pope Julius II murió antes de que se terminara, y hubo solicitudes de cambio del cliente, Julius, y de sus herederos; problemas de cadena de suministro; renegociaciones de contrato; conflictos laborales; escasez de trabajadores calificados; y agotamiento de fondos por la larga duración
Así que, al menos desde 1505, estas cosas ya pasaban. Lo curioso es que el papa ni siquiera está enterrado en esa tumba
Aprendí algo importante al inicio de mi carrera. El primer número que das es el que queda en la memoria
Lamentablemente, en la práctica suele ser así, y la gente sigue diciendo: “¿No dijiste X al principio?”. “Sí, pero obtuvimos información nueva” no siempre funciona
Un efecto secundario es que quienes saben esto terminan evitando dar números
Scotty: “Por supuesto, capitán. Así mantengo mi reputación de hacer milagros”
Por ejemplo, de días→semanas, semanas→meses, meses→trimestres. Si algo tomaría un día, digo 3 semanas. Parece mucho, pero al final, por burocracia, procesos y deuda técnica, casi siempre termina por ahí
Hay una parte que dice: “¿Te imaginas a una aseguradora discutiéndole al taller que el presupuesto original era de 18,000 dólares, así que no pagará otros 20,000 dólares? ¿No suena absurdo? A mí también. Por suerte, la realidad no funciona así”, pero en seguros eso pasa todo el tiempo
No solo en seguros de auto y vivienda, también en seguros de salud. Muchas veces se negocia hasta un punto razonable, pero no siempre; sorprende el tono tan seguro de “la realidad no funciona así”
Aunque declarar pérdida total pueda salir más caro, tiene un tope claro y permite cerrar el reclamo. A las aseguradoras no les gustan los reclamos abiertos
Lo segundo, que en seguros de auto también se llama “tarifa preferente”, es un contrato marco para cobrar ciertos tipos de trabajos a una tarifa negociada fija
Eso es muy distinto de una cotización vinculante. Una cotización vinculante suele ser una cotización única para un trabajo específico, donde quien estima asume el riesgo y promete completarlo a esa tarifa aunque resulte mucho más complejo de lo esperado
Un truco es, siempre que sea posible, estimar solo sobre un alcance fijo y excluir los elementos desconocidos que no se pueden conocer
No estimar “implementar la función X”, sino “el motor de la función X”. Si descubres trabajo adicional, hay que sumarlo como hitos descubiertos, como “refactorizar el código existente” o “integrar las funciones X+Y”
Pero esta nomenclatura y esta comprensión tienen que escalar hacia arriba para que funcione. Si alguien cambia el hito “motor de la función X” por “función X terminada” con la misma estimación, estás perdido
También he visto un problema relacionado: liderazgo que cree que las fechas límite son “motivación”. Es como la gente que quiere calentar una casa a 72F y pone el termostato en 80F “para que llegue más rápido”
Una vez, en una reunión de liderazgo, los demás asistentes olvidaron que yo, un ingeniero de bajo rango, había sido invitado. Cuando alguien reconoció que sería muy difícil cumplir la fecha límite X y preguntó si había que cambiarla por una fecha más realista, un PM sénior respondió: “¡Nosotros nunca movemos las fechas límite! ¡Ingeniería siempre usa todo el tiempo que se le da!”
En ese caso, ingeniería devolvió el tiempo cuando me fui de ese equipo
También es cierto que muchos equipos de ingeniería usan todo el tiempo que se les da
Pero los gerentes deberían preparar a la organización para posibles excesos, en vez de convertir estimaciones y planes en fechas límite rígidas frente a los ingenieros. Si, al acercarse la fecha prevista de finalización, el desarrollador puede explicar qué parte tomó más tiempo y por qué, eso debería entenderse razonablemente
Los gerentes también deberían evitar que clientes, ventas y directivos superiores traten la fecha prevista de finalización como una fecha límite. Si hay que hacer una promesa, la fecha límite de cara al cliente debería estar bastante después de la fecha prevista de finalización
También puede funcionar en la práctica con radiadores eléctricos, porque no se apagarán de inmediato solo porque el aire cerca del radiador se haya calentado
Después de ver demasiadas “estimaciones a ojo” convertirse en fechas límite duras, estoy impulsando el enfoque No Estimates con las partes interesadas
Al principio, por supuesto, hay resistencia. Para resolver las preocupaciones, ayuda explicar que las estimaciones lo bastante precisas como para usarlas legítimamente en la planificación en realidad solo son posibles en dos casos
A) Cuando el trabajo restante se parece mucho a una copia del trabajo pasado. Por ejemplo, aprovisionar por segunda vez un centro de datos del mismo sistema
B) Cuando el equipo considera que el trabajo restante de nuevas funcionalidades ya entró en el último cuartil y está bien definido, incluidos los riesgos restantes que podrían impedir el éxito
Las microestimaciones habilitan la microgestión. Un equipo sano identifica el trabajo de mayor prioridad según los riesgos para el éxito del proyecto y lo ejecuta en ese orden
0 - https://www.youtube.com/watch?v=MhbT7EvYN0c
1 - https://www.goodreads.com/book/show/30650836-noestimates
Me llamó la atención una fórmula interesante que vi antes en HN. Se ve elaborada y elegante, pero, como otros métodos de estimación, no tiene validez formal; es solo una fórmula arbitraria basada en experiencia personal
https://news.ycombinator.com/item?id=37965582
Mi matemática de estimación: R = t × [1.1^ln(n+p) + 1.3^X]
R es el tiempo real que toma, t es el tiempo mínimo posible cuando no se necesita comunicación, n es la cantidad de personas que participan en el proceso, incluyendo al cliente y la organización de desarrollo, p es la mayor distancia de comunicación dentro del proyecto, y X es la cantidad de herramientas, bibliotecas o técnicas nuevas usadas en el proceso
Por ejemplo, si un proyecto en el que un solo desarrollador escribe código toma 2 semanas (t=2), participan 5 personas en total (n=5), hay 1 herramienta nueva (X=1) y la mayor distancia de comunicación es 4, entonces 2×(1.1^ln(5+4) + 1.3^1) = 4.5 semanas
Hay que sumar cantidades de X no solo por las incógnitas conocidas, sino también por las incógnitas desconocidas
Tristemente, una estimación es una negociación. La persona que da primero un número por lo general pierde por la “mueca”
“¿Cuál sería la estimación?” “No estoy seguro.” “Aunque sea aproximada.”
“Entonces, ¿para cuándo la quieren?”
Esta es la trampa en la que caen siempre los gerentes nuevos. Si das una respuesta, bingo. Ahí muestran la “mueca”. Aspiran entre los dientes, fruncen el ceño y dicen: “Ah, eso es completamente irreal. ¿De dónde salió ese número?”, y luego dan una cifra varias veces más alta o proponen reducir el alcance del trabajo. Algo como: “Uy, con ese tiempo, con suerte y recortando la función Y de otro proyecto, solo podríamos hacer la función X”
Hagas lo que hagas, lo importante es no dar primero un número. Como en el póker o al comprar un auto, toma algo de tiempo desarrollar el instinto. El tiempo también es dinero en las grandes empresas, y hay que tratarlo como tal. Es un juego de suma cero
Donde trabajo, en nombre de la eficiencia, las estimaciones siguen bajando y tampoco se permite arrastrar trabajo pendiente
Llevamos más de un año en un estado cercano al crunch, sin tiempo de recuperación. Seguí esperando que mejorara, pero más bien parece estar empeorando. Además, todos rotan constantemente a otras áreas del producto, sin opción de elegir. Todavía sigo corriendo, pero mentalmente me siento completamente agotado