需求评审这件事，在软件项目管理的流程上，一直是沦为一个多余的存在，不少企业面对这个事情，从来都是得过且过。也许是由于技术人员不足，从产品到设计到开发到测试，一人包办，自然觉得需求评审没有必要；也许是需求主管部门过于强势，搞一言堂，需求草稿即定稿。再有就是，正在各种混乱流程交错中挣扎的成长型公司，正在历经规范化的痛，对于这个事情正在摇摆。
之所以需求评审会沦为众矢之的，就是因为他不仅会带来工作量的增加，琐事的增多，更重要的是，他需要一个背锅的人。软件需求的准确性和合理性直接关系到开发人员的工作效率和项目工期，而需求评审本身就是对需求的再审核，直接决定需求的质量，如此重要的责任做的好自然是功劳，做不好导致项目返工、开发人员怨声戴道，那就是罪人一个。因此，没有多少人愿意主动背起这个锅。
翻开软件工程和项目管理的教科书，我们会发现，理论很精妙。但是一旦付诸于实践，很快就会发现，情况并不是想象中的那么理想。但理论是方法指导，只是一个体系框架，实际的应用还需要结合每个公司不同的工作流程，各自发挥。这里就需求评审这个环节，笔者谈谈自身的经验。
其实，要让需求评审不沦为形式主义、众矢之的，可以参考以下的流程方法进行，多裁少补。
在开始需求评审会之前，需要事先定好需求评审的内容，界定好本次讨论的需求边界，防止开会时由于思维过于发散，偏离主题导致讨论内容无限制扩大，影响评审目标的完成。我们的目标很明确，本次讨论解决什么问题就是什么问题，在过程中发散出来的，适当做个记录，应该立即回到主题上。
参会人员分两类，一类是必须参加的人，一类是选择性参加的人。必须参加的人包括：需求评审会主讲人和项目直接相关的人员。一般情况下，参加需求评审会的项目直接相关人必须是多角色的，因为无论多牛逼的人，也无法做到全才、想法360度全方位无死角，这就需要包括：需求人员、交互设计师、UI设计师、架构师、后端开发人员、前端开发人员、测试人员。这些项目直接相关人，也是工作任务上跟需求紧密相关的人，他们的评审意见至关重要。小公司可能“架构师、后端开发人员、前端开发人员”是同一组人甚至是同一个人也有可能。安排不同角色参与评审，就是需要这个人或者这些人从不同角度评估需求的合理性和开发的代价，从不同角度考虑需求可能存在的问题和需要改进的地方，尽最大程度在前期发现需求本身的问题，防止需求发生过大的偏差。
确定会议时间、会议时长，提前明确预计会议预计多长时间，并提前通知大家，让大家心里有个数，方便各自安排手上的工作，如果预计的时间内，没有将内容讨论完，那么也应该适时终止会议，另外选择时间继续讨论，切忌长时间作战。长时间作战到最后只会让很多内容都草草了之。
提前一小时（半小时太短了）分发讨论内容稿给参会人员，让参会人员提前阅读并组织内容意见，到会议上直接抛出各自的意见，提高会议效率。
一定要让其参与会议，当讨论过程不同意见僵持不下的时候，需要需求决策人来排版。这点很重要！
需求文档更新负责人，让其认真参与，记录好讨论过程。会后需要公布会议纪要，其实也就是需求评审记录，并纳入文档库。
会议讨论结束后，需要明确时间下次复审是什么时间，有效率地推进工作进展。
其实，需求评审的流程真正用心落实，不会多花太多时间，反而对于软件项目的质量、效率的提升有着非常重要的作用，上面说到的并不是教科书上的内容，而是笔者实际工作中的心得体会。要想成为一棵大树，必须要知道大树的成长历程，一枝一叶的生长，并不是需求评审的流程多余，而主要是大家习惯的现有的流程，不愿意进行改变。
很多软件开发公司需求可能都是老板或者项目经理甚至是开发人员一个人说了算，那么需求评审做的如何这取决于公司相关负责人的经验和专业能力。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
