いつ終わるのでしょうか？ AI ありとなしの両方。

私たち全員に起こり、恥ずかしい思いをしないでください。 AI を使った場合と、使わない場合。誰かがいつか「いつ終わるの？」「いつ終わるの？」と尋ねます。「もう少し 3 週間です」と答えます。日付が到来しても終わらない新たな質問が生まれます。「もう 2 週間です」と答えるサイクルが繰り返され、最終的には信頼性を失うまで（「再び言いますよ」というネタ化）まで続きます。 それは見積もりを間違えているからではありません。見積もりそのものは幻想です。 誰も、全く理解していないものを、常に流動的に変化する文脈の中で、週ごとに能力が変動するチームに対して、完了にどれほどの時間を要するかは誰にも言えません。 では、どうしましょう？ 見積もりを放棄し、測定を始めましょう。 三つのステップ： 1. 特性またはストーリーを小さなタスクに分割 各タスクは ideally 1 日以内とする。1 日以上に見えた場合は分割し、それでも大きい場合は再度分割する。 結果：比較可能なタスクリストに加え、実行可能で洗練された計画が生まれる。 2. 毎週タスク完了数を記録する 各開発者が何件のタスクを完了したかを記録する。 週 1: 4 タスク 週 2: 7 タスク 週 3: 6 タスク ... 週 8: 収束 3. ベイズ更新を用いて予測する 8 週間経過後：各開発者の実際の能力分布を知っている。 現在のバックログには X 件のタスクがある。 これらの分布をベースに 10,000 通りのシナリオをシミュレーションする。 結果：「95% の信頼レベルで、Y 日以前には完了しない」 これほど複雑なものはない。 タスクが 1 日を超える場合でも、それを 1 日以内であるように試みさえすれば、分布は実際の能力へと収束する。理想の 1 日とは遠く離れていることを認め直そう。しかし法則の大数の法則が私達を援助し、最終的に実際の能力は収束する。 モデルを「研修」させるために 8 週間待っている必要はない。 週 1-3: 開発者 A は 20 件のタスク（単純な文脈）を完了 開発者 B は 5 件のタスク（学習中）を完了 変動は大きい 週 4-6: 複雑性が増大（アーキテクチャ、依存関係） 開発者 A は 12 件のタスク 開発者 B は 9 件のタスク 安定し始め 週 7-8: 分布が収束 開発者 A: 11 ± 2 タスク 開発者 B: 10 ± 2 タスク それが彼らの実際の能力である 手動調整を「行う必要」はない。データが自ら行う。 あなたがしているのは、自分の信念を証拠に合わせることである： 週 1: 「開発者が約 25 件をこなすと想定する」（事前分布） 開発者が 23 件をこなす（観測値） 週 2: 推定を 24 に調整（事後分布＝新しい事前分布） 開発者が 26 件 週 3: 25 へ調整 ...週 8: 実際の能力分布に収束 毎週、予測が自動的に改善される。 あなたはあなたのモデルを毎週の実況と同期させている。 *ソフトウェアの多くは推定して責任を回避するために使われる。 *データなし: 「3 週間で見通しします」（楽観的な期待） 失敗：「サプライズ、依存関係、スコープの変更」 *データあり: 週 1: 「データがない。6/7 ヶ月を見込んでいます」 週 4: 「70% の信頼レベルで、24 週間」 週 8: 「95% の信頼レベルで、17 週間」 週 12: 「更新中... 9 週間」 プロダクトマネージャーは楽観的な日付を約束しない。現実的な範囲を約束する。 顧客は何を期待すべきかを知っている。あなたは何を期待すべきかを知っている。開発者は何を期待すべきかを知っている。 それは証拠に基づく期待管理である。 これは予測だけではない。これらは私たちがどのように働いたかである： 1. 強制リファインメント 特性を分割する必要があるには、ステップを考えなければならない。 開発者は計画なしに「やります」とは言えない。 結果：サプライズが減り、実行がクリーンになる 2. 明確なデイリー 「どこへ？」 → 「タスク X を完了し、特性の完了のために Y を始めた」 「特性の作業中だ」とは違う（明確でない） 実際の可視性 3. 見えるブロック待ち 誰かがタスクを完了しないことは数字で見える。 能力なのか、外部のブロックなのか？データが言う。 プロマネが介入すれば、問題は解決し、ドรามエは起きない。 4. 混沌とした開発者は暴露され、学びます 一部の開発者はタスク分割が苦手です。 分布がそれを反映した（変動が大きく、速度が遅かった） 確信によって、彼らは改善するか、あるいは真の性能を示しました。 それは罪ではなく、現実でした。 私たちのためでも、正しいプロダクトのためでも、遅延や変更を避けるためでもありません。 1. 収束に 8 週間かかる もし混沌としたものであれば、収束に時間がかかります。 実際の 8 週間（56 日）が必要です。 その後は精度が向上し続けます。 2. チームが必要'

Nos pasa, a todos, no tengás vergüenza. Con IA y sin. Alguien en algún momento empieza a preguntar: "¿Cuándo esta? ¿Cuándo terminamos? Decimos: "En 3 semanas más". Llega la fecha, aun no terminamos. Surge la pregunta de nuevo. Surge la respuesta "2 semanas más." y ahí se repite el ciclo hasta ser un meme ("no de nuevo decía") con total pérdida de credibilidad. No es que estimes mal. La estimación es una ilusión. Nadie puede decir cuánto tardará en algo que no entiende completamente, en un contexto que cambia constantemente, con un equipo cuya capacidad varía semana a semana. ¿Entonces? Deja de estimar. Empezá a medir Tres pasos: 1. Divide característica/historia en tareas pequeñas Cada tarea ≤ 1 día ideal Si parece más grande de un día la dividís. Si sigue siendo grande, dividís de nuevo Resultado: tareas comparables y además un plan ejecutable y refinado. 2. Registra cada semana Cuántas tareas completó cada dev. Semana 1: 4 tareas Semana 2: 7 tareas Semana 3: 6 tareas ... Semana 8: converges 3. Predice con actualización Bayesiana Después de 8 semanas: sabes distribución real de cada desarrollador. Backlog actual tiene X tareas Simula 10k escenarios con esas distribuciones. Resultado: "con 95% de confianza, no terminamos antes del día Y" No es complicado. Las distribuciones convergen a capacidad real no importa si la tarea tomo más de un día siempre que hayamos intentado que tomara a lo sumo un día. Recordá que dije 'un día ideal', seamos honestos la mayoría de los días están lejos de ser ideales. Pero la ley de los grandes números está a nuestro favor, finalmente la capacidad real converge. No es esperás 8 semanas para "entrenar" el modelo. Semana 1-3: Dev A hace 20 tareas (contexto simple) Dev B hace 5 tareas (aprende) Variación alta Semana 4-6: Complejidad aumenta (arquitectura, dependencias) Dev A hace 12 tareas Dev B hace 9 tareas Se estabiliza Semana 7-8: Distribución converge Dev A: 11 ± 2 tareas Dev B: 10 ± 2 tareas Eso es su capacidad real No necesitas "ajustar manualmente". Los datos lo hacen solitos. Lo que estás haciendo es ajustar tus creencias a la evidencia: Semana 1: "Asumo que el dev hace ~25 tareas" (prior) Dev hace 23 (observación) Semana 2: ajusta estimación a 24 (posterior = nuevo prior) Dev hace 26 Semana 3: ajusta a 25 ... semana 8: converge a distribución real Cada semana mejora la predicción automáticamente. Estás sincronizando tu modelo con la realidad semanal. *La mayoría de software estima para evitar responsabilidad. * Sin datos: "Terminamos en 3 semanas" (esperanza optimista) Falla: "Sorpresas, dependencias, cambios de scope" Con datos: Semana 1: "No tengo datos. 6/7 meses creo." Semana 4: "Con 70% de confianza, 24 semanas." Semana 8: "Con 95% de confianza, 17 semanas." Semana 12: "Actualizando... 9 semanas." El PM no promete fechas optimistas. Promete rangos realistas. El cliente sabe qué esperar. Vos sabes qué esperar. El dev sabe qué esperar. Eso es gestión de expectativas con evidencia. No fue solo predicción. Fue cómo trabajábamos: 1. Refinamiento forzado Para dividir features, necesitas pensar en pasos Dev no puede decir "voy a hacerla" sin plan Resultado: menos sorpresas, ejecución más limpia 2. Dailies claras "¿Dónde estás?" → "Terminé la tarea X, empecé la Y para completar la feature" No,"estoy trabajando en la feature" (nada claro) Visibilidad real 3. Bloqueos visibles Si alguien no termina tareas, se ve en los números ¿Es capacidad? ¿Son bloqueos externos? Los datos nos dicen PM interviene, cero dramas, son datos 4. Devs caóticos se exponen y aprenden Algunos devs , le cuesta dividir en tareas. La distribución reflejaba eso (muy variable, baja velocidad) Con insistencia, mejoraron o mostraban su verdadero desempeño No fue culpa, fue realidad No hace por nosotros, ni el producto correcto, ni evitar retrasos o cambios. 1. Tarda 8 semanas Si son caóticos, tarda en converger. Necesitas ~8 semanas reales (56 días) Después la precisión mejora y mejora 2. Requiere equipo estable Si rotan gente cada 2 semanas, la distribución se rompe, podemos usar una priora informada, pero ya es más complicado. Cambio de contexto grande, producen redistribuciones Pero se ajusta automáticamente cada semana, si la historia es muy pesada podemos usar ventanas deslizables sobre los datos para reducir el peso de la evidencia histórica a cambio de mayor varianza 3. Depende de división clara Si dividís mal (tareas poco claras), los datos son ruido Pero el sistema lo expone: tareas que dicen ser "pequeñas" pero no terminan. 4. Backlog en movimiento Si el MVP crece 50% en la semana 5, la predicción se recalcula Eso es correcto, no fallo del sistema. 5. Bloqueos externos Si hay 2 semanas de bloqueo por infra/aprobaciones Velocidad baja esas semanas Se refleja en los números (correctamente) El software aplica técnicas sofisticadas para todo... menos para sí mismo. *Meteorología: * Recalcular predicciones cada hora. *Logística: * ETAs que se ajustan con datos. *Control de Calidad/Industrial: * Medir capacidad real. Como casi todo, es multi causal. Te digo algunas: Waterfall dejó cicatrices perpetuas "Medir y registrar" suena a viejo, rígido "Agile" mal entendido. Presión política Datos reales exponen problemas: "¿Por qué tan lentos?" Estimar es cómodo: Luego decir "pasaron cosas" para justificarse. Ilusión de control Un PM prefiere oír "2 semanas" (certeza falsa) Que "70% de confianza, 2-4 semanas" (realidad incómoda) El número da "certeza". La distribución da "responsabilidad". Herramientas Jira está diseñada para estimaciones (story points) Medir requiere disciplina Semana 1: Agarrar el MVP Tomar las features y dividirlas en tareas de un día. Contás tareas, digamos 120 tareas para el MVP Semanas 2-8: Cada semana: registrás tareas completadas Cada semana: recalculás predicción Semana 9+: Predicción confiable Recalcula cada semana (automático) Usa para decisiones de prioridad, scope, comunicación con stakeholders Si quieres hacer la simulación: import numpy as np # Datos históricos (semanas 1-8) dev_a_velocidad = [20, 22, 19, 21, 20, 23, 21, 22] # tareas/semana dev_b_velocidad = [15, 14, 16, 15, 17, 15, 16, 15] # Parámetros distribuciones, asumiendo normalidad velocidad_a = np.mean(dev_a_velocidad) # ~21 std_a = np.std(dev_a_velocidad) # ~1.2 velocidad_b = np.mean(dev_b_velocidad) # ~15.4 std_b = np.std(dev_b_velocidad) # ~0.8 backlog_tareas = 200 # tareas restantes # Simulación Monte Carlo simulaciones = 10000 dias_para_terminar = [] for _ in range(simulaciones): # para simplificar el ejemplo usamos una distribución normal tareas_semana_a = np.random.normal(velocidad_a, std_a) tareas_semana_b = np.random.normal(velocidad_b, std_b) tareas_por_semana = tareas_semana_a + tareas_semana_b semanas_necesarias = backlog_tareas / tareas_por_semana dias = semanas_necesarias * 7 dias_para_terminar.append(dias) # Resultado percentil_95 = np.percentile(dias_para_terminar, 95) percentil_50 = np.percentile(dias_para_terminar, 50) print(f"Mediana: {percentil_50:.0f} días") print(f"95% confianza (worst case): {percentil_95:.0f} días") Eso es. 20 líneas. Nada de magia. Estas distribuciones son las que convergen. Así se ven las distribuciones. Ajustadas, notá que no asumo normalidad. Mi versión productiva ajusta distribuciones antes del MC. Vemos el efecto de las tres distribuciones en las fechas de entrega. (100k simulaciones) "Esto es perfecto": No !! "Todos deberían hacerlo": Para nada. "Reemplaza a los devs estimando": Dividir en tareas es estimar. "Es Waterfall disfrazado": Nop. "Pero no puedo divi ...": Lo importante es dividir el elefante en pedacitos masticables. La idea es contar 'melones', onzas o kilos no te importan, a larga en el carro se acomodan. "Story Points": Si, podes aproximar la distribución o usar tus datos históricos como bootstrap para el Montecarlo. Esto no es innovación, ni hype. Es ingeniería clásica. En construcción, medicina, logística, manufactura, Miden. No estiman. y lo que estiman es a sus clientes por eso miden. Que software sea la excepción, no significa que la excepción sea correcta. ¿Estimas o medis? ¿Tus predicciones aciertan? ¿Usas algo similar?