第二类就是需求是可实现的，但是难度有点大，比如说这个东西可以实现，但是需要10个人去做三个月，会花费很多时间精力，这时候产品经理需要思考一下，这个需求是否一定要实现？有没有什么可以替代的实现方式？如果非必要，可考虑搁置；

　　第三点就是，如果能做，时间允许，精力允许，团队允许，就看跟你的主目标有没有一个很高的匹配关系，也就是看下这个东西，现在做和你一个月之后做，会不会有什么区别。如果现在做和一个月之后做没有什么区别，那就一个月之后做；如果现在做和一个月以后做差别很大，那就现在做。

　　第二点：PM团队内审

　　一个很重要保障需求质量的方法就是PM团队内部评审，不然这个东西出来，就会变成你想要的，或者是总监想要的，亦或者是老板想要的。

　　这里面需要注意的点是：

　　提前1-2天把需求相关文档发给大家。

　　那团队内审的要求是大家提前1-2天把需求相关文档发给大家，确保大家有时间看，大家会看过记录下问题，才会有时间跟你讨论，不然内审的时候，大家就会提出各种各样的小问题，让会议效率变得很低，经常半小时可以结束的会议，结果团队审完后2个小时过去了，然后改的东西和之前的一模一样，团队内审是为了保证输出质量很高。

　　第三点：需求评审，保证相关工作责任的明确与落实

　　现在很多团队需求评审变成一种走过场的形式，并不是为了保证需求质量、大家工作内容职责需求等的明确，就会变成评审会上达成一致的内容，在开发的过程中，又觉得你这个地方有问题那个地方有问题。所以你需要提前和大家沟通好，大家需要输出什么东西，然后你需要大家给你什么反馈。

　　第四点：落实过程中的时间点和产物

　　之前了解到别的团队会遇到过一个问题，就是把需求交过去，就完全不管了，就到了上线的前一刻才去查收，结果是时间到了，才发现很多东西都没有做完。那怎么解决这个问题，就是定好时间节点的产物，在什么时间，我需要有什么东西，最好是以天为单位，每天需要拆出来一个可验或可跟进的结果，到时候每天盯着那个时间节点要出的东西，如果东西出不来，就提前知道项目存在延期风险，也会想办法去解决这个问题，是要大家一起加班呢？还是说是需要更多的人投入。

　　第五点：项目立会

　　每天早晨10分钟立会，会议主要包含，昨日重点任务、进展、今日任务、遇到的问题，作用就是在于可以快速发现问题，每天早晨去收集头天的问题，找到重点的问题，尽快解决。

　　最后一点就是结果验收了，这点大家都知道如何去做了。

　　关于需求的变更：

　　个人觉得在做产品的过程中，需求变更是个很重要也无法避免的事情，但是在变更之前，我会思考以下的点，希望对大家有些帮助：

　　关于需求的思考：

　　（1）要清楚变更需求是什么（需求的内容）？会带来多少工作量？是否必须要变？

　　其实好多人不会判断，就觉得，不用管，只要变了我就去做。但是你要搞清楚，在程序员中，改一个动画和改一个字，是有区别的，改一个字可能分分钟的事情，改一个动画要改半天。

　　（2）对于需求的变更你做了哪些反馈，是否进行过相关复杂度、工作量等的反馈给领导或需求方？是否具备需求变更的必要条件？

　　（3）需要变更的时间点是什么时候？在项目执行中会有什么影响？主要需要思考成本和风险问题。

　　你做了什么：

　　（1）对于这个需求你做了什么内容，是否提出过关于这个需求最优的方案以及修改办法？

　　（2）目前这个需求做了多久？如果变更你有需要付出多少时间？团队付出多少时间？

　　（3）是否明确得知需求的时间点（搁置或者修改后上线的时间）？

　　（4）需要修改的内容是什么？有哪些？被修改或搁置的原因是什么？

　　找领导请教：

　　（1）请教问一下你的领导，该如何更好处理这种需求的变更（搁置或者修改），如何让大家减少做无用功，或者避免白做的现象？

　　（2）需要明确领导是否有更好的方法，下次遇到类似的需求，有更好的处理方法（比如事先避免需求的变更或提高变更成本）。

　　说完了产品的日常，我们在聊一下做产品应该有哪些点需要注意？

　　对于产品的要求：

　　我觉得对产品有要求，是一件很重要的事情。

　　（1）要做有价值的事儿