🧐 What Am I Thinking This Week
🧐 這是本週我在想什麼

Have you ever crushed a task estimate, only to watch it spiral out of control?
你是否曾經估計一個任務需要兩點時間，卻看到它不斷失控？

Maybe you thought it would take a few days, but it stretched into weeks with endless testing and bug fixing. If so, you are not alone. In software engineering, task estimation is not about predicting the future. It is about communicating risk and reducing uncertainty.
也許你原本以為只需要幾天，但最終卻耗費了數週，進行了無盡的測試和錯誤修正。如果你是這樣，你並不孤單。在軟體工程中，任務估算並非預測未來，而是關於溝通風險和減少不確定性。

Why Do We Estimate?  我們為什麼要估計？

During project planning, estimating how long a task or feature might take helps the team understand the resources needed and the overall timeline. When multiple priorities compete for attention, estimation helps organize them and shift priorities as necessary.
在項目規劃中，估算一個任務或功能可能需要多少時間，有助團隊了解所需的資源和總體時間表。當多個優先事項競爭注意力時，估算有助於組織它們並根據需要調整優先順序。

Why Is Estimating Difficult?
估計有多困難？

Software development is not just about designing systems and writing code. It involves communication, reviews, and unexpected blockers along the way. When a project requires cross-team collaboration, you need to align on what you are trying to achieve, whether enough APIs are available, how to use them, and more. If a project involves a new system, you will also need time to read documentation and ramp up when estimating the effort.
軟體開發不僅僅是設計系統和撰寫程式碼，還涉及溝通、審查以及過程中出現的意外障礙。當一個專案需要跨團隊協作時，您需要就您想要達成什麼目標、是否有足夠的 API 可用、如何使用它們等進行一致。如果一個專案涉及一個新的系統，您還需要時間閱讀文件並在估計工作量時進行熟悉。

Remember: we cannot possibly know everything.
記住：我們不可能知道所有事情。

What Can Blow Up Estimates?
什麼會導致估計數字失準？

Hidden complexity  隱藏的複雜性

You thought you could set up an interceptor or callback, but the documentation says it is not possible. Now you need to find another solution.
你以為可以設定攔截器或回呼，但文件顯示這是不可能的。現在你需要尋找另一個解決方案。

Changing requirements or scope creep
變更需求或範圍擴張

Requirements and priorities change all the time. Estimates will need to adjust when new features are added. Sometimes seemingly small feature requests are non-trivial from an engineering perspective. Ask clarifying questions and voice your concerns early.
需求和優先順序不斷變動。新增功能時，估計時間需要調整。看似微小的功能請求從工程角度來看可能相當複雜。及早提出澄清問題並表達您的擔憂。

Dependencies on other teams or systems
依賴其他團隊或系統

If other teams’ priorities do not align with yours and they delay deliverables, the overall timeline will shift. You will need to communicate this with stakeholders and propose alternative solutions if necessary.
如果其他團隊的優先事項與您不符，且他們延遲交付物，則整體時間表將會延遲。您需要與利害關係人溝通此事，並在必要時提出替代方案。

Wrong assumptions  錯誤假設

You assumed a system would behave one way, but the documentation or real-world behavior says otherwise. What seemed small might now become a major blocker or even an epic on its own.
你假設系統會以某種方式運作，但文件或實際行為顯示不然。原本看似微不足道的事情，現在可能變成一個主要的障礙，甚至變成一個史詩般的項目。

Underestimating time for code reviews, testing, or QA
低估代碼審查、測試或品質保證所需時間

Always factor in time for proper testing, QA, bug fixing, and deployment. A project is not done until it is properly tested and delivered.
務必預留時間用於適當測試、品質保證、錯誤修正和部署。一個專案在經過適當測試和交付後才算完成。

How You Can Estimate Better
如何更準確地估算

Break down large tasks.  分解大型任務。

If a task seems too complex or large, break it into smaller, more manageable parts.
如果一個任務看起來太複雜或太大，請把它分解成更小、更容易管理的部份。

Call out risks and unknowns.
指出風險和未知之處。

Highlight uncertainties when making estimates. Others may have insights that help refine the estimate or suggest creating a spike ticket.
強調估計時的疑慮。其他人的見解或許能幫助精準估計，或建議創建一個「衝刺」任務。

Leave buffer for surprises.
留出緩衝空間以應對意外。

Especially when uncertainty is high, build in a buffer to handle the unexpected.
尤其在不確定性很高的時候，請預留緩衝空間以應對意外情況。

Remember, you are estimating to help the team plan, not to be right.
記住，你是在協助團隊規劃，而不是要正確。

Quick Mental Checklist Before Estimating
快速的心理檢查清單

• Do I have all the requirements?
  你有所有要求嗎？

• Are there any third-party integrations?
  有任何第三方整合嗎？

• Is this truly a “known known,” or am I guessing?
  這真的是「已知已知」嗎，還是我只是在猜測？

• Has something similar been built before?
  之前有類似的嗎？

• What could go wrong?  什麼可能會出錯？

• Should I prototype or spike first?
  我該先原型還是快速驗證？

Closing Thoughts  結語

Estimation is not about being right, it is about being real. The best engineers are not those who predict perfectly, but those who communicate uncertainty with clarity. Trust, not perfection, is what drives teams forward.
估計並非關於正確，而是關於真實。最好的工程師並非那些能夠完美預測的人，而是那些能夠清晰地傳達不確定性的工程師。信任，而非完美，是推動團隊前進的動力。

How do you approach estimates? I would love to hear your best or worst estimation and planning stories!

💡 The ONE Thing You Should Know

Interesting view about the future of web browsing. It reminds me of an anime called Mega Man Battle Network, where everyone has a digital agent that does work for them. We may no longer need browsers to navigate the web. Agents will find information, extract data, and act on our behalf. I wonder what the future of the advertising business will look like if no one actually browses the web anymore.