评审过程本身也是一个知识传递过程，评审人员与产品经理一起讨论用户需求，这有助于评审人员获得用户需求的前期认识。
评审过程中可能发现不明确的或者遗漏的需求，这需要产品经理进行二次需求分析和定义。
评审过程中可能发现某些特殊需求，这时产品经理和评审人员可以群策群力共同思考解决问题的方式。
当局者迷、旁观者清。再有经验的产品经理也可能犯错，评审人员可以提出更合理或者更有建设性的想法供产品经理参考。
需求跟踪是产品经理日常必须完成的工作
产品经理每天都需要跟进当前迭代中需求的实现进度，确保需求执行的过程没有出差错，一般而言，需求的跟踪分为两种：
正向跟踪：检查已安排的每个需求是否都能在后续的实现过程中有相对应的部分，确保没有漏做的需求，并保证需求的实现程度和需求定义要求的一样。这就需要每天都与后续的各个负责实现的人员进行确认。
逆向跟踪：根据已有的交互设计稿、系统设计文档、测试用例文档等成果文档，反向检查是否包含了所有已安排的需求。
需求变更考验产品经理需求把控能力
需求变更的原因有很多种，这里不去具体展开。产品经理要做的更多是需求变更的管控，我们都知道需求变更对产品来说坏处多于好处，也有变了之后反而好的，不过是少数。
控制变更的规则比较简单：
如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。需求变更控制过程中难办的事情是莫过于“拒绝用户提出的需求变更请求”。产品经理要灵活的控制变更的尺度，以产品业务价值实现为导向，更多的从产品角度出发。
需求管理是一项十分重要的工作，据调查显示在众多失败的项目中，由于需求原因导致的占了很大的一部分。
sales@spasvo.com
