- Cuando desde fuera del equipo de desarrollo se presiona para bajar una estimación sin hechos nuevos, la estimación se convierte en algo negociable, y con ello empeoran tanto la confianza como la calidad de la planificación ágil
- La carga real de trabajo, en su mayor parte, no es algo que el equipo de desarrollo pueda reducir a voluntad, y el equipo calcula el esfuerzo esperado con base en la velocidad del equipo, los datos de historias completadas y el rendimiento actual
- Si se omiten procesos o se baja la calidad para hacer que una estimación más baja encaje, puede parecer que el calendario se acorta en el corto plazo, pero es muy probable que luego regrese como un costo mayor
- Una conversación más productiva no es “bájenlo más”, sino revisar en conjunto el presupuesto, las partes que consumen más tiempo, las grandes incógnitas, las alternativas, la división de historias y la validación temprana
- Si solo se bajan los números manteniendo fijo el alcance funcional, se crean expectativas equivocadas sobre cuándo se entregará al cliente, y hace falta discutir la eliminación de funciones de alto esfuerzo y bajo valor
La distorsión que provoca presionar estimaciones sin hechos nuevos
- Con frecuencia ocurre que partes interesadas externas al equipo de desarrollo, con conocimiento técnico o comprensión del codebase limitados, intentan bajar la estimación diciendo: “No, eso requiere aún menos esfuerzo”
- En apariencia piden una “mejor estimación”, pero muchas veces lo que realmente quieren es una estimación más baja
- Cuando la estimación se trata como un número negociable, tanto las partes interesadas como el equipo de desarrollo terminan llegando a un acuerdo insatisfactorio, y el negocio se queda con malas expectativas sobre cuándo podrá entregar el software al cliente
- Como cita relacionada, se enlaza Is tasking developers with creating detailed estimates a waste of money?
La estimación se parece más a un pronóstico que a un control
- Hay casos en los que sí se puede cuestionar una estimación
- Cuando el equipo de desarrollo discute la historia internamente
- Cuando existen hechos nuevos que afectan la carga real de trabajo
- Que una parte interesada externa que no entiende los detalles de implementación ni aporta información nueva exija una estimación más baja se parece a decirle a un meteorólogo: “Tu pronóstico de mañana está mal y va a mejorar”
- El meteorólogo no controla el clima; hace un pronóstico con base en su conocimiento y en los datos observados
- El equipo de desarrollo tampoco controla realmente la carga de trabajo, y calcula el esfuerzo esperado con base en conocimiento y datos
Lo que el equipo de desarrollo puede y no puede controlar
- El equipo de desarrollo estima usando una velocidad de equipo ya establecida, datos de revisión de historias completadas y procesos que mejoran en cada sprint
- Sí puede reducir la carga aparente de trabajo saltándose partes del proceso y entregando software de baja calidad
- No es una práctica recomendada
- A menudo termina costando mucho más después
- El equipo puede tener margen para mejorar su velocidad, pero al momento de estimar debe basarse en el rendimiento actual, no en un rendimiento futuro esperado
- Si en la empresa aparece una conversación del tipo “solo tienen que trabajar más horas”, ese entorno se parece más a una receta para el desastre
- Se enlazan tres comentarios de Reddit como experiencias relacionadas:
Qué conversación tener en lugar de regatear números
- El desarrollo de software es complejo, y muchas veces toma más tiempo de lo que la gente imagina
- Si las partes interesadas consideran que solo pueden gastar hasta cierta cantidad, en vez de bajar la estimación deberían discutir lo siguiente
- Cuánto se puede gastar en esta historia
- Qué parte de la historia consume más tiempo
- Dónde están las mayores incógnitas
- Qué alternativas existen para abordar las partes costosas y las incógnitas
- También hay que revisar opciones para cambiar la forma de validación y entrega
- Dividir la historia y entregarla en varias partes
- Validar cada parte lo antes posible
- Si es posible, validar con un prototipo
- En especial, hay que buscar cómo sacar de la historia las funciones que requieren mucho esfuerzo pero aportan el menor valor
Cómo convertir una pregunta de calendario en algo más útil
- Más que preguntar por una estimación más baja, es más productivo hacer preguntas que aclaren la relación entre funciones, calendario y alcance
- En otro artículo se enlazan las siguientes preguntas
- ¿Cuándo se puede entregar la Feature A?
- ¿Qué se puede entregar antes de que termine el próximo trimestre?
- ¿Se puede entregar la Feature A antes de que termine el próximo trimestre?
- Artículo enlazado: converting story points to hours
2 comentarios
Así queda si traduces el título original del artículo con DeepL:
¿Hay alguien que diga: "No, ¡requiere menos esfuerzo que eso!"?
Opiniones de Hacker News
La analogía de que “presionar a un vendedor para que aumente sus ventas/cuota es como exigirle sol a un meteorólogo” no parece tan injusta en este contexto
En realidad se parece más a pedirle que trabaje de forma más eficaz para terminar el mismo trabajo más rápido
Si le pides a un vendedor que fije su propia cuota, como cerrar contratos implica mucha complejidad e incógnitas, probablemente elegirá una cifra alcanzable sin problemas para no parecer que fracasó
Pero esa cifra puede estar por debajo de lo que necesita el negocio, y por eso se plantea una cuota más alta para que la alcance aunque tenga que esforzarse un poco de más
Esto es especialmente importante si la compensación está directamente vinculada al cumplimiento de esa cifra
Pero los vendedores no se la pasan escribiendo artículos diciendo que “las cuotas autoestablecidas son sagradas, que solo los vendedores deben fijarlas y que la dirección que exige resultados por encima de eso es ignorante”
Una analogía más cercana sería que el equipo de ventas dijera sobre un acuerdo concreto: “70% de probabilidad de cierre, unos 5 millones de dólares de ingresos recurrentes anuales”, y que la dirección respondiera: “¿Podemos llevarlo a 80% y 7 millones?”
Tal vez sea posible aumentar la probabilidad de cierre y también el precio, pero, como terminar una funcionalidad en la mitad del tiempo, exige cambios grandes o concesiones en algún punto
Pero en vez de convertir las estimaciones en metas deseadas, es mucho mejor terminar antes de lo estimado
Lo ideal es ordenar el trabajo reflejando prioridades y prerrequisitos, asegurar suficientes historias listas para desarrollo y, cuando hay urgencia, asignar tickets estratégicamente aun asumiendo el costo de que a largo plazo la capacidad del equipo quede sesgada
Si hay presión de tiempo, hay que eliminar de todas las funcionalidades lo que sea “nice to have” o moverlo al fondo del backlog, y poner límites de tiempo estrictos a las consultas con otros equipos o expertos externos
Hay que eliminar reuniones e interrupciones innecesarias, permitir que los desarrolladores rechacen reuniones o bloqueen su calendario, y subir el estándar para hacer refactorizaciones a los casos en que el costo-beneficio antes del deadline sea claro, tratándolo como tomar prestado del futuro
Eso sí, hay que tener mucho cuidado de no convertir esta forma de trabajar en el modo estándar
Si puedes convertir el 10% de los leads, cuando necesitas 5 conversiones en vez de 4, más o menos basta con llamar a 10 personas más
Una mejor comparación con el software sería construir un tipo nuevo de edificio, por ejemplo una casa con domo geodésico, sin experiencia y sin saber bien qué problemas vas a enfrentar
Y aun así te piden una estimación precisa, y luego te presionan para reducirla aún más
Lo más importante es engañar a los clientes, y no me refiero simplemente a una “exageración común que beneficia a la empresa”
Es prometer cosas que la empresa no puede cumplir, o vender funcionalidades futuras que exigen una marcha de la muerte sacrificando calidad y sostenibilidad
Aunque el nivel C no lo vea, las consecuencias ocurren
Eso no significa que haya que creer ciegamente las estimaciones de los desarrolladores, pero ese es un agujero de conejo más grande y ahora da pereza meterse ahí
Solo vuelve más irrealista la comprensión del calendario
Es totalmente posible buscar otras soluciones creativas para resolver el mismo problema, o entender qué alcance se puede recortar para cumplir el objetivo
Pero eso es completamente distinto de “hacer exactamente lo mismo, solo que más rápido”
Cuando surge el tema de las estimaciones, muchas veces los desarrolladores casi nunca se ponen en el lugar del negocio ni intentan entender por qué se necesitan las estimaciones y por qué las más cortas siempre son mejores que las más largas.
En cambio, intentan proteger el santuario del desarrollo de software y agrandan aún más la diferencia entre los ingenieros y “los demás”.
Ahí aparecen el cinismo y el sarcasmo, y eso termina llevando a estimaciones poco realistas.
He sido desarrollador, PO, gerente, director y CTO, pero todavía me sorprende lo desconectada que está la mayoría de los desarrolladores de la realidad de entregar valor y del factor tiempo.
Como desarrollador, que te pregunten cuánto va a tardar algo y te den la oportunidad de explicarlo, debatirlo y defender tu estimación es, más bien, una suerte.
La triste realidad es que muchas veces los desarrolladores no son buenos para participar en conversaciones a nivel de negocio y expresar pensamientos, ideas, preocupaciones y propuestas para que PM y gerentes vean la complejidad del trabajo y tengan una discusión sana de costo/beneficio.
Hay que ver si el desarrollador líder participa en reuniones de negocio, si el equipo de desarrollo ve números y presupuestos, participa en el roadmap y hace investigación de usuarios y brainstorming de funcionalidades junto con la gente de negocio/UX.
Si no, es difícil esperar que los desarrolladores entiendan el negocio.
La separación entre desarrollo y negocio hace que cada quien esté en su silo y espere que otros especialistas conozcan bien sus problemas, y eso lleva a sacralizar el desarrollo de software.
Muchas empresas simplemente siguen funcionando a pesar de tener roles extremadamente aislados en silos, pero como el dinero sigue entrando, parecen creer erróneamente que esa forma de trabajar está bien.
Por lo general, alguien solo quiere poner un número en un PowerPoint para política interna.
A veces se trata de decidir si hacer A o B, y en ese caso lo único que se necesita legítimamente nunca es una estimación absoluta, sino una estimación relativa.
De vez en cuando hay una fecha límite real, pero incluso ahí lo que se necesita no es una estimación, sino “¿podemos cumplir con esta fecha?” o, más útil todavía, “¿qué tenemos que hacer para cumplir esa fecha?”.
Está bien trabajar lo más cerca posible del negocio, y la razón para usar software desde el inicio suele ser resolver una necesidad de negocio.
Pero en lo que respecta a las estimaciones, de verdad muchas veces ellos están equivocados y nosotros tenemos razón.
Si lo corto siempre es mejor, entonces digamos ahora que todas las estimaciones son de 1 día; ¿eso es mejor?
Si un desarrollador puede escribir código, estimar y entregar ajustándose al calendario del negocio, esa persona no es un empleado, es un fundador.
Lo que quieren es gente ingenua que entregue como fundador, pero sin recibir participación en las ganancias.
Por mucho esfuerzo que pongamos tú o yo, el bebé no va a salir más rápido.
No hay nada ambiguo ahí.
La queja está en la forma de preguntar, como si los desarrolladores pudieran saber cuándo algo estará terminado.
La capacidad de alguien para entregar valor rápido es independiente de su capacidad para estimar cuánto tiempo tomará.
Puedes entregar mucho valor aun equivocándote por completo en la estimación.
Si realmente existiera una forma de estimar el tiempo de trabajo de software, las empresas contratarían estimadores profesionales, igual que tienen equipos de producto.
No habría razón para encargárselo a los desarrolladores.
Claro, los demás tampoco pueden hacerlo, y los desarrolladores al menos aciertan el límite inferior, así que los siguen molestando, pero el proceso en sí es evidentemente tonto.
Para saber cuánto va a tardar algo, hay que enumerar todos los pasos necesarios para hacerlo, y en el desarrollo de software eso es imposible.
Un desarrollador puede dar un límite inferior para los requisitos dados, y si no ocurre absolutamente nada inesperado quizá la estimación sea exacta, pero en el 95~98% de los proyectos la estimación resulta más corta que la realidad.
Al final, la “estimación del desarrollador” se convierte en una medida de cuánto colchón quiere incluir el desarrollador en ese proyecto.
Pedir una estimación encuadra la conversación de forma totalmente equivocada.
La verdadera pregunta debería ser pedir la opinión del desarrollador sobre el problema que tiene el negocio ahora, los problemas que probablemente tendrá en 6 meses y la relación costo-beneficio de resolverlos.
Luego habría que tomar decisiones cualitativas orientadas a reducir el riesgo.
El mejor resultado de una estimación de software es que todos la ignoren y la olviden; cualquier otro resultado destruye valor de negocio.
Entiendo el punto, y en organizaciones donde hay partes irresponsables el riesgo real también es grande
Pero la analogía con los meteorólogos no me convence
Para un meteorólogo, predecir el clima es la parte central del trabajo, mientras que un desarrollador común es la persona que trabaja dentro de ese clima, y tiene relativamente poca experiencia haciendo predicciones precisas
Lo que frustra como stakeholder no son estimaciones que empiezan en el tiempo de trabajo y terminan en un plazo realista, sino estimaciones absurdas que no empiezan ni en lo uno ni terminan en lo otro
Eso pasa especialmente a nivel de microtareas: trabajos de hasta 30 minutos que, si uno tuviera acceso, podría hacer directamente más rápido, pero vuelven con estimaciones de semanas
Incluso cuando generan un costo operativo grave y entran en la categoría de “hay que detener todo y resolverlo”
Claro que un trabajo de 30 minutos no tarda realmente solo 30 minutos por pruebas y documentación, pero mientras más se acerque la estimación a un disparate, más se daña la relación de confianza
No es lo mismo preguntar por el tiempo real de trabajo que requiere una tarea específica que preguntar por el tiempo transcurrido desde ahora hasta el momento en que queda desplegada
En casi todos los equipos, en ambos casos domina el tiempo que el trabajo pasa esperando algo, pero en el segundo caso es especialmente fuerte
El tiempo real tecleando suele ser casi un error de redondeo comparado con la coordinación y la planificación
Si el equipo no ha invertido en formas de trabajo contraintuitivas, el ticket promedio espera muchísimo más de lo que se trabaja en él
Además, el equipo ni siquiera ve ese desequilibrio, ni se da cuenta de que importa
Uno quiere arreglarlo rápido y pasar página
El problema es que, si no hay despliegue continuo completamente automatizado, 30 minutos no son 30 minutos
Ese trabajo de 30 minutos debe revisarse para ver si no afecta a otros departamentos, requiere coordinar agenda, avisar y desplegar, y puede involucrar a 2 o 3 personas más
Si es un trabajo programado, se acerca a 2 horas repartidas entre varias personas; si es un hotfix o un ticket de soporte, cuando hay un proceso de QA más allá de las pruebas automáticas, implica una pérdida de productividad de 4 a 6 horas
Si a eso se suman otras 6 personas pidiendo “trabajos de 30 minutos” cuyo impacto sobre otros dentro de la empresa no está claro, no se termina nada
Nuestro equipo tiene un flujo de hotfixes, pero tiene que ser una emergencia real que detenga la operación de la empresa
Salvo en casos clarísimos, debe solicitarlo alguien de nivel jefe de departamento o superior
El daño de una corrección para una sola persona que causa problemas a varias, o de no terminar proyectos grandes estratégicamente importantes, es mucho mayor que el daño de no atender todos los tickets urgentes de inmediato
En la organización debería haber una forma de otorgar los accesos necesarios
Si la respuesta se parece a “no es mi trabajo”, entonces esa organización valora una estructura de piezas interconectadas con responsabilidades estrictas
En una organización así, es natural que el costo de comunicación domine por completo el rendimiento de producción
Si está bien coordinada, la calidad puede ser buena, y si los roles están claros, el throughput también puede ser alto, pero nunca se obtendrá baja latencia
El tiempo de respuesta se sacrifica en favor de otras cosas
Que una tarea trivial reciba una estimación de 1 semana también es esperable en una estructura así
Con una agenda llena, es probable que una tarea nueva recién se asigne dentro de varias semanas, y si por las responsabilidades fragmentadas se necesitan dos o más personas, los tiempos de espera se van acumulando
Si eso no encaja con el trabajo, entonces la organización misma no encaja con ese trabajo
Es ineficiente para todos los involucrados
Nuestro equipo tiene mucha autonomía, y no nos cronometran ni miran la productividad desde afuera, pero cuando hace falta no hay tiempo para pulir el código
Cuando veo un trabajo de “30 minutos”, lo llevo a la revisión de la mañana y, cuando vamos a tocar ese tema, pregunto si también conviene hacer algo adyacente
Aunque no haya nada, reservo un día; si es un proyecto que conozco muy bien, reservo medio día
Medio día es para recorrer el código, y la otra mitad para pequeñas actualizaciones como comentarios, upgrades de versión, mejoras de código o cambios de nombres de variables
Creo que empujar a los contribuyentes individuales a trabajar así también es más eficiente en términos de tiempo
Para un contribuyente individual nuevo, ese tiempo sirve para aprender código antiguo y, al final, mientras no haga cambios grandes, también reduce los problemas de legado
La única varita mágica en el desarrollo de software es la simplificación de requisitos
Los requisitos siempre están mal
Son demasiado amplios, demasiado vagos o se basan en suposiciones incorrectas
La capacidad realmente sobresaliente es descartar algunas suposiciones y proponer una solución simplificada
Es la mejor y única forma de acortar los plazos
Si los requisitos son simples, es más fácil que sean completos y precisos, pero puede que los requisitos reales no se puedan simplificar
En ese caso, lo que se necesita es una mejor especificación
“They write the right stuff”, sobre el grupo de software del shuttle, básicamente cuenta una historia de ese tipo: https://www.fastcompany.com/28121/they-write-right-stuff
La mayoría de los bugs de software son en realidad bugs de requisitos, y cuando hay buenos requisitos, la velocidad para construir software se vuelve absurdamente alta
He visto un proyecto pasar de un repositorio vacío a producción en 2 meses con requisitos completamente claros y estables
En cambio, también he visto una funcionalidad de unas 30 líneas tardar meses por requisitos vagos y en cambio constante
Dicen que ahora solo hay unas decenas de elementos, pero que en unos años habrá miles
El diseñador diseña todos los flujos de búsqueda a partir de un documento de requisitos de producto de 20 páginas, y recién después de que todos los planes y preparativos están listos llaman a ingeniería para escribir historias y estimar el trabajo
Normalmente tienen suficiente conocimiento del dominio y saben qué se necesita para construir algo en este contexto
Vale la pena discutir cómo cambiar el alcance para lograr un equilibrio costo/beneficio adecuado para las partes interesadas
He visto casos en los que los desarrolladores suponen que se necesita demasiado trabajo, y también casos en los que personas no desarrolladoras ignoran las partes clave que alargan los tiempos
A veces se intenta crear una solución generalizada, pero lo que realmente se necesita podría ser que alguien se siente un día frente a una hoja de cálculo y lo resuelva
El problema de que muchas veces se cuestionen las estimaciones por ser demasiado altas, pero casi nunca por ser demasiado bajas, es justamente lo que el planning poker intenta abordar
La idea es que todos digan la dificultad del trabajo sin influenciarse entre sí, y luego se discuta cuando las expectativas no coinciden
Es muy probable que alguien se esté perdiendo algo
La razón por la que yo considero que algo es simple también puede ser que me perdí la parte compleja del problema, o que puedo ver una solución más limpia
Un buen ejemplo es cuando un cliente hace una solicitud imposible matemática o físicamente
Podrías pasar todo el día haciendo planning poker sobre ese deseo y aun así llegar a un compromiso imposible
Cuando trabajaba como freelance, prefería escuchar una explicación minuciosa del problema y, si hacía falta, mirar por encima del hombro de la persona que actualmente lo resolvía; luego desaparecer unos días y volver con el diseño que me parecía más elegante y confiable
Salvo que alguien tenga mucha experiencia con problemas complejos, la mayoría puede explicar bien su problema, pero no proponer soluciones
Porque las soluciones siempre se modelan a partir del conjunto limitado de cosas que uno conoce
He visto muchos requisitos raros construidos pegando suposición tras suposición de varias personas, cuando en realidad nadie los había pedido
Por ejemplo, construir una arquitectura de microservicios infinitamente escalable y una aplicación completa de página única solo para que doce usuarios internos puedan descargar datos como una hoja de cálculo de Excel
Requiere asumir que el equipo está lo bastante familiarizado con todo el conjunto de funcionalidades y que entiende cómo usar el sistema para manejar la diferencia inevitable de que A lo haga en X y B en X*3
Basta ver las discusiones sobre cómo se ejecuta mal Scrum para notar que esas premisas no están garantizadas en absoluto
Tampoco considera que, por rotación de personal y nuevas funcionalidades, el equipo puede salirse de esas premisas en cualquier momento
Con demasiada frecuencia todos terminan solo levantando las cejas unos a otros, hasta que se vuelve “lo hará X, así que la estimación de X es el valor”, o se elige el promedio/el mínimo y solo sale perjudicada la persona que estimó más alto
Si va a ser así, no entiendo para qué hacer poker desde el principio
Esto es más maquiavélico que eso
El intermediario quiere un trato en el que si sale cara gano yo y si sale cruz pierdes tú
Quiere beneficiarse presentando una cifra baja para convencer a su contraparte
Por eso usa todo tipo de técnicas para lograr que el desarrollador diga el número que él quiere, pero sin que parezca una orden o una imposición
Si se ve así, ese número pasa a ser suyo y se arruina la jugada
Pero si inevitablemente toma mucho más tiempo, puede señalar el número que dio el desarrollador y decir que él solo transmitió lo que escuchó, sin responsabilidad alguna
El único lenguaje que entiende este tipo de persona es enviar el mensaje haciendo que el resultado de cualquier solicitud de “revisión” de estimación siempre suba
Primero, las estimaciones deberían ser útiles para que el negocio se adapte, pero en la realidad no hay ninguna adaptación
El PM recibe presión de su jefe para terminar para una fecha límite aproximada
Si de todos modos no le importa mi estimación, ¿para qué estimar?
Segundo, el equipo no tiene incentivos para estimar de forma realista
¿Te dan una medalla si aciertas? En la práctica, todos los incentivos empujan a inflar la cantidad de trabajo mediante las estimaciones
Tercero, todo este baile y ritual de estimaciones no es más que algo que los managers aceptan para parecer más eficaces e influyentes de lo que realmente son
Cuando era ingeniero, decía con firmeza: “No hay forma de hacer esto más rápido, así que no me presiones para obtener el número que quieres oír”
Mi postura era que estará listo cuando esté listo, y que lo dejaré sólido y en buen estado, así que no estorben
Pero cuando, como manager, presioné por una estimación más pequeña, fue porque en la realidad del negocio era clave entregar algo dentro del plazo fijado
Aunque hubiera que levantar un castillo de naipes y recortar esquinas, al menos teníamos que sobrevivir lo suficiente para poder lidiar con ese problema después
En ese momento, desde ingeniería surgió la misma resistencia que yo probablemente habría puesto si hubiera estado en esa posición
Que era una idea terrible, que nos preparaba para fracasar en el futuro y que, para evitar dolor más adelante, había que hacer el trabajo pesado ahora
Volví a ser ingeniero, pero la experiencia como manager me ayuda bastante a manejar este tipo de brechas
Son personas que “llegan hasta 11”
Si, como el amplificador de Spinal Tap, ajustas tu potencia máxima habitual en 9, queda margen para subir un punto más cuando ellos lo quieran
Claro que entonces trabajarás más lento de lo que habrías hecho originalmente
Pero si quieren un desarrollador que “llegue hasta 11”, está claro que solo hay una forma de que funcione
Mi manager y el manager de arriba son exactamente así: imponen fechas límite arbitrarias no porque el cliente esté esperando, sino para quedar bien con sus propios jefes
Cuando la estimación inevitablemente falla, todos levantan las manos y empiezan a poner a la gente en planes de mejora de desempeño por culpa de sus propias malas estimaciones
Como ingeniero, ¿qué se gana viviendo bajo este estrés constante y perdiendo incluso el tiempo que debería pasar con familia y amigos?
Solo hacer que las estimaciones incompetentes de tu manager se vean bien
Uno de los trucos más viejos es crear una visión, prometerla y luego decir: “Yo ya hice mi parte; ahora solo falta que ingeniería haga la suya”
Me recuerda a un manager que añadía funcionalidades sin avisar mientras estábamos cerrando un release, a veces apenas unas horas antes
También solía pegar funcionalidades a releases que ya estaban terminados
En su cabeza, parecía que bastaba con pegar una funcionalidad a un release para que quedara lista de inmediato
La mayor dificultad es que la gente pide estimaciones de inmediato cuando el proyecto apenas tiene una descripción de un párrafo.
Además, siempre se siente como “depende de cuánta deuda técnica haya después de revisar el código”.
La única respuesta razonable que he dado hasta ahora fue: “necesito 1 o 2 días para presionarte a concretar bien los requisitos, y para detenerme antes de empezar a auditar el codebase y buscar riesgos”.
¿Hay algo que se pueda hacer mejor que eso?
El objetivo no es crear tarjetas perfectas, sino hacer al menos un ticket por cada cosa que parezca que hay que hacer en el proyecto.
Así terminas con varias tarjetas de una línea, como “crear endpoint de API para creación por lotes” o “migrar datos de una tabla existente a una tabla nueva”.
Si hay 5 tarjetas o más, estimo con
((cantidad de tarjetas / cantidad de desarrolladores) * días hábiles estimados por tarjeta) + días de vacaciones estimados.No será exacto, pero hace que el PM y su jefe sientan que la estimación fue pensada y razonable en ese momento.
Si más adelante hace falta retrasarse, también es fácil explicar: “asumimos que todas las tarjetas tomarían una cantidad de días similar, pero estas dos resultaron ser valores atípicos más grandes de lo esperado”.
Es parecido al proceso normal de sprint, pero no hace falta seguir la velocidad del sprint con más que una intuición.
El liderazgo de la empresa pide estimaciones con muy poca información, y cuando dices que necesitas investigar más y mirar el codebase, responden que “solo” necesitan una estimación para decidir si aprueban este trabajo y si hacen el proyecto.
Así dan vueltas hasta que terminas dando una estimación grande, porque incluye todas las incógnitas, incluso las cosas cuyo alcance ni siquiera conoces.
Entonces para el liderazgo queda como algo demasiado grande y demasiado caro.
En términos Agile, es un ticket spike de 3 puntos, y el entregable son requisitos detallados, entregables y estimaciones, junto con los compromisos considerados.
Es una forma completamente normal de trabajar.
Puedes dar una estimación antes del spike, pero debe ir con tantas advertencias como sea posible.
Por ejemplo: “con 60% de confianza, menos de 3 semanas; con 80% de confianza, 5 semanas; con 90% de confianza, 6 semanas”.
En general, rechazo estimaciones de fecha límite de más de 1 o 2 semanas y prefiero estimar por partes siempre que sea posible.
Por ejemplo: “este proyecto se compone de 7 entregables, cada uno con 1 o 2 días de trabajo”.
Algo puede requerir 10 días de trabajo de ingeniería, pero por cambios de prioridad y motivos similares, calcular una fecha límite se vuelve prácticamente inútil.
Si los “gerentes” no entienden esto, lamentablemente es difícil que haya paz.
No preocuparte por la deuda ni la calidad del código, y sacar apurado algo que apenas funcione.
Entonces ellos estarán satisfechos.
La típica escena de hackeo en una película de acción es así:
Líder: “¿Cuánto tardas en hackear el mainframe?”
Técnico: “El hacker rival es realmente bueno, así que al menos 2 horas”.
Líder: “Te doy 1 hora. Hazlo”.
Luego vuelan por un sistema de archivos 3D.
Cada vez que veo una escena así, le pongo una narración interna al técnico:
“La estimación real eran 20 minutos. Probablemente termine a los 50, y luego me conviene seguir volando ocupado por el sistema de archivos 3D otros 10 minutos para que el líder no tenga ideas raras”.
No es del todo cierto.
Muchas funcionalidades se pueden construir en varios niveles, desde algo muy esquelético hasta algo completamente bañado en oro.
A veces un colega desarrollador estima 2 semanas para una funcionalidad que a mí me parece de un día como mucho, porque asumió muchas funcionalidades adicionales que en realidad no se pidieron, o porque sabe de partes que yo no sabía que eran necesarias.
Si te piden cambiar una estimación, conviene verlo como una invitación a discutir un poco más los requisitos y la implementación propuesta.
Puede haber una solución mucho más simple que llegue al 90% y sea aceptable.
Un meteorólogo no tiene esa opción.
La diferencia entre meter un combo box/select box básico y crear un elemento de UI personalizado mucho mejor adaptado a la situación no se comunica bien a gente de fuera de IT.
Puedes explicarlo con dibujos, pero como los stakeholders no lo ven ni lo tocan, siguen sin saber qué está pasando.
Por eso, en general, hay que construir algo que funcione y mostrárselo.
Hay clientes que piden “hazlo lo más simple posible”, y cuando les muestras una GUI de prototipo, una GUI con diseño terminado y luego el prototipo, aprueban sin mirar siquiera las dos primeras.
Si los presionas, tocan el prototipo y aun así dicen “bien, sigamos”, pero después de tocarlo funcionando de verdad en el servidor de pruebas dicen “esto no era lo que queríamos”.
Me pasó desde tiendas familiares de dos personas hasta empresas Fortune 500 donde opinaban directores regionales y el CTO global.
Esto es hablando del frontend; backend y DevOps son problemas completamente distintos, pero ahí también hay una gran diferencia entre hacer el esqueleto y bañarlo en oro.
Ahora ya conozco este juego, y hoy en día gano mucho dinero con este proceso roto.
En 1975, Fred Brooks escribió:
“Tener un bebé toma 9 meses, sin importar cuántas mujeres le asignes”.
No hay una mejor forma de expresarlo.
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Cada persona adicional que agregas hace que tarde más.
La entrega más rápida es no interrumpir al desarrollador solo y simplemente dejarlo trabajar.