一、弄懂需求目的。
对开发而言，弄懂需求，就是要知道需求的目的，以及用何种方式去实现。实现后，再看结果跟预期是否相符。如果相符那就做对了。如果不相符，那肯定哪里做错了或想错了。
产品经理的需求文档是通过X推导出来的Y。我刚刚工作那会，需求评审会上讲的都是Y，从没人告诉我X是什么。但Y只是实现方式之一，也许还有更合适的方式Z，在不知道X的情况下，团队其他人没办法想到Z方案。
有了需求目的，每个参与者都可以想”有没有更好的实现方式？“开发人员也可以提出实现方式，而不只是用编码去实现需求。虽然我们戏称自己是“码农”，但我们不能是”码农“。
回过头看我自己经历的项目，做了很多伪需求。也就是加班加点，做完后对产品没有任何改进的功能。最关键的问题就是产品负责人很少说需求的目的。这也是后来我要求做需求必须先讲需求目的的原因。
二、弄懂需求细节。
代码的世界里没有"随便”，要么0，要么1。把需求理清不是一件容易的事情，这是一种需要锻炼的思维方式。你得非常熟悉理解业务和系统，否则你就只能先听、先学。
我们来看一个案例，产品根据用户反馈，做了一个需求。当用户购买的订单，满49元就免邮费。
初看很简单的一个需求，但你做的时候，要考虑很多细节。比如：
是一个商家的订单，还是所有商家的订单？
跟虚拟商品一起支付是否也支持？
如果店家有设置不包邮地区，两者冲突了，怎么办？
现在是29包邮，以后会不会改成19或者39？
订单满29除了包邮，还会不会有其他优惠，比如特价购其他商品？金额减免？
如果商家支持选择快递，需求里的包邮，用户是否可选？
这些细节，你不一定在评审会能完全想到，但在做的过程中，一定要和产品经理保持沟通，把模糊的需求确定。有些新人不好意思问，其实没啥，大家都是这样过来的。这种确认问题的能力，是需要经验积累的。也是程序员非常重要的一个能力。
