早些年在我刚开始工作时，我认为“需求分析”就是听一听产品经理提的需求，评估下开发可行性和难度，把实现不了的需求砍掉。
这么多年过去了，我发现这是最Low Level的需求分析。
原因在于当时的我完全不知道产品经理为什么要提出这个需求，我甚至压根没有关注过这个问题，当时的我只关注这个需求如何实现，难度如何。所以我很难理解产品经理，甚至经常站在技术的角度认为产品经理提出的这个需求好SB啊，他是智障吗？
但其实产品经理和工程师不应该是敌对关系，应该是“搭档”，现在我和我们的产品经理一直是搭档关系，我们的关系很融洽，因为我们的目标是一致的：让我们的产品，满足用户的需求。
但有时候产品经理提出的需求可能不是很正确，这个时候需要工程师进行辅助。这里面有很多原因：
- 产品经理可能对技术的边界不是很了解，所以无法充分利用技术解决用户需求
- 对用户原始需求的理解是很难传递的
- 产品经理对用户需求的理解有误
- 其他
产品经理可能对技术的边界不是很了解
优秀的产品经理是需要有技术广度的，他不一定要深入了解技术的原理，但一定要理解技术的边界。某个技术能做什么，不能做什么，最近是不是又有新技术了，和我的产品有关系吗？
但通常大多数产品经理都比较缺乏技术广度，所以这个时候需要工程师去补位。
但工程师去补位有一个前提，那就是工程师真的理解产品经理，理解他在想什么。这就要谈到第二点：对用户原始需求的理解很难传递。
对用户原始需求的理解很难传递
很多时候，产品只是发了个产品文档过来，然后就拉着技术做“需求评审”，但其实这份需求文档，是产品经理对用户需求理解的二次加工。工程师在这份需求文档里是很难看清用户的原始需求的。
比如：用户需要一个消息提醒。产品经理可能是不知道有Web Push Notifications这项技术，也可能是对用户需求理解有误，总之最终提出来的需求是在网页的最顶部添加一个消息通知功能。
所以工程师应该主动去了解用户的原始需求是什么，当工程师能理解用户的原始需求是什么时，也就能理解产品经理为什么提这个需求了，就可以在这个时候成为产品经理的搭档，提醒他，有一项技术叫做Web Push Notifications，它的能力边界是什么。
一个好的需求，应该是技术深度参与，而不是产品经理单方面输出一个产品需求文档，因为产品经理有时候也会犯错，这就是我们要谈论的第三点：产品经理对用户需求的理解有误。
产品经理对用户需求的理解有误
有时候用户反馈需求，或者产品经理在推测用户想要什么的时候，往往得到的答案是不正确的。因为有时候用户自己也不知道他需要什么。有一句名言非常有名：你如果问用户想要什么，他的回答是“一匹更快的马”，而不是汽车。
所以工程师要理解用户的原始需求，并且有自己的看法，这样不光可以给产品经理提出建设性意见，并且还可以对技术方案进行“预判”，如何设计项目的架构？最重要的就是要对产品未来的发展方向进行“预判”，一方面要对未来的改动 “做足准备”，另一方面也要避免 “过度设计”。