基于猜测编码是发现需求理解错误的最昂贵方式。当请求模糊不清时，我的工作是在写代码之前将歧义转化为共享的书面理解，然后以低成本验证。歧义不是需要推回的阻力；它是工作中驱动理解的常见部分。 我如何澄清模糊之处 问为什么，而不仅仅是什么。 我们要创造什么结果？请求背后的原因通常会揭示一个比所述方案更简单或不同的解决方案。 找到真正的用户和成功指标。 谁感到了痛点，我们如何知道问题已解决？
