-
一、需求评审是什么
-
假如没有需求评审，要么就是口头确认，会临时约人、临时被更改内容、临时发现缺人缺时间缺拍板；要么会被遗忘，被否定。当然也会存在好好的做下去，并且很顺利，但这个几率很低。
-
假如没有需求评审，那么也可以通过邮件或通讯工具答复的方式或流程审批的方式确认相关内容，但涉及到人多，流程复杂，涉及到多个平行部门，涉及到一人有疑问多人进入讨论就会很麻烦。
-
假如没有需求评审，能够拍板的人一句话，大家干就完了。其实也免于更多的麻烦，可做不到啊。
-
人：发起人&主讲人、参会人、执行人
-
物：图、文、音视频等宣讲文件
-
事：主题、事件、流程、各关联关系、参与范围、任职、结果
-
时：参会时间、会议时间、决定后的项目时间周期段
-
总结下来就是：由发起人发起参会时间和会议时间，并准备好会议的相关资料，告诉参会人和执行人会议主题+内容。需要参会人在会议上听取主讲人对主题、事件、对应的流程和各自时间的关联关系进行说明。在会议上进行展示的宣讲文件，让参会人和执行人了解相关流程和想要结果，需要相关人员对会议内容确认和约定好的时间段结果确认。如果不确认结果就是修改内容重新在约会或否定结果。最后是告知相关人员和领导：本次会议的结果，这条是非常关键的。
-
一件事情，需要大家集体做，在规定的时间内，按照固定的要求，有序的执行，并产出符合要求的优良结果。
-
1、需求评审的目的
-
2、需求评审应对的说明
-
3、如果没有需求评审
-
二、日常需求
-
一定要在会议的过程和结束时，得到结果。这个结果不一定是预期结果，也可能是延期，甚至是否定，但要对应的人都确认这个结果，这个一定是明确要得到的产出。
-
如果通过，并不是说皆大欢喜，因为每个立项都是要给别人增加工作量，还有可能是一个紧急&重要的限人限时间任务。那么就需要会议发起人协同项目经理或各负责人尽快、尽早、准确、有质量的推进各方的工作，确保事宜完成。
-
如果否定说功能不够细致，还需要在完善，那这个也不能说是坏事。每个人都有不同的想法，别人会提出更好的意见来协助你完成，虽然是反驳，但最终获益的是你。只是你要确认：这是不是你当期的需求，是不是要纳入需求池中。
-
还有一个否定结果，完全被批的一文不值，做这个事情没意义，不值得做，我们现在有比这个更重要的事情要做，我想这个大家都经历过，那么既然有人调皮捣蛋，那么就当场怼回去“你有意见，我可以听从，也会考虑你的意见，但这个会议现在是我在主持，要么我说你闭嘴，要么你来主持会议，你来当XX负责人，你来领导这个公司”该强硬的时候一定要强硬，不然事情总做不好，一定要有自己的态度。我可以不打断你说话，但在我讲话的时候，也不能任由别人打断。
-
如果不确定，会议现场无法确认结果，要排期，说要回去商议下工作内容，询问具体的人能否完成等，那么就明确告知，时间节点已经明确，其他人员都已确认，现在就差你这边，你是现在打电话来确认，还是我发邮件的时候说明其他人都等你开工？反逼很好用，但也要谨慎用。
-
针对结果后续要做什么
-
1、确认：既然是结果确认，那就要盯人盯时间盯项目，跟进项目整体的进度，保质保量的完成。
-
2、未能确认：盯人，在会议要明确给你答复的时间，并且去催促这个事情确认。一般两遍没有结果，就可以艾特对方的上级，如果还不行，就得发邮件告知相关人员，因XX未能确认，目前项目存在延期风险。一定要把风险点曝出来，并且积极的推进，还要落地，往前赶进度。最重要的是：领导不问过程，只看结果，只要结果达到预期，那么当中发生的事情，都可以是有计划性变更的。
-
3、否定：被否定了，这个事情其实比较严重，事情无法推进，但你的领导是不会这样放过你的。一旦被否定，就要在会议上明确否定点，记录下来，单独沟通，确认可以解决这些问题。并且约定好下次会议的时间，再次说明第二次会议的内容，以及上次会议的问题点，解决方案。这个时候有些部门就可以不用参加了，主要参与人就可以了。否定的会议内容，不能多次，一般建议两次，你也要找你的上级说明，协助推进。
-
会议主题：主题要明确。需求评审会是要得到大家的确认与支持；项目启动会是通知各方人员要干活了（已明确结果）；技术讨论会才是针对问题，需要大家进行商讨。不同的会议要定义不同的主题和内容。
-
预期：
-
会议需要内容：一般可以从问题开始，讲在实际的情况中出现了什么情况，造成什么影响，针对这些情况我们如何让去解决或提前规避。在这当中计划如何，需要什么人来做什么事情，时间周期预计是多久 ，明确每个节点。其实这块是最重点的东西，这块不光牵扯到你内容的输出，如何展示，还有你的宣讲能力。哪怕是一句话，你能够描述清楚，大家能够理解，那么也好。
-
会议上不需要的内容：商讨比较细的细节，一但牵扯到比较细的内容，就会延长会议时间，还会打乱你的节奏。这里也可以针对一些点，用草图和要求结果来叙述，具体的内容由具体的部门去做执行。在会议上也不要沟通过于明确的背景方案，记住每个会议的主题。预留时间点，这个是项目经理的经验，在规定的期限前完成，是最好的结果，为了防止有突发的事件，所以适当的预留一点时间。但这个时间是不能告诉大家的，不然这个时间点就留不住了。
-
这里要拆分为两个时间，会议时间是预期本次会议要商讨几个阶段的内容，每个阶段预计要多久，总体要多久。项目时间是确认内容后，对整体计划进行排期的时间。在会议期间切记不要把会议时间延长太多，会耽误大家很多的事情，而且会议上商讨的时间越多，就越容易出现更多莫名的问题。
-
1、会议时间：小会议半个小时到1个小时；一般的中型会议需要负责多个层面，会1个小时起步，根据情况长到3个小时左右，可能还会更长。大型会议会分阶段，分别针对不同的模块做介绍说明，这里也会有不同的人员进出（会议的大小并不一定是以会议时间定义，也会根据人数和会议重要程度定义）。
-
2、项目时间：如果是针对一个模块，那么会议上要把预排期的时间点说明。例本次针对会员体系重新开发，需要在1月1号前由运营部出体系规划、会员等级说明、晋升分值；需要产品根据运营提供资料，在1月3号前出大概的规划，在1月5号和运营确认明细内容（当中要结合设计、研发的排期），在1月6号确认结果后，1月7号转交给技术进行开发。在开发阶段产品原型和需求文档是1月7号同步递交，UED需要在1月9号完成设计稿给前端，前端需要在1月11号完成页面给研发，研发需要在1月15号完成功能设计并进行内部测试后反馈给测试，测试需要在1月15号前写好测试用例和产品进行评审，并在1月17号完成一轮功能测试和UED的界面+交互测试，并反馈测试报告，在1月19号进行修改后的第二轮测试，在1月20号前确保测试通过，在1月21号进行试运行。运营根据在1月15号前出活动方案，在1月21号同步进行试运营，最终在1月23号正式上线。上线前每个部门都应该在相应的时间节点收到来自前一个部门递交的资源和确认信息，若不能确保，至少提前一天要报预警，并通知对应的负责人。
-
人员：相关人员务必要到期，若负责人不能到，需要负责人指定一名人员来参会；参会人员若不能做决定，那么需要让其记录下相关问题，确认结果后，反馈给大家。为了防止这种情况的发生，提前沟通好响应的结果和要做的事情，也不至于会议出现尴尬的情况。
-
时间：
-
结果：结果最理想的就是全员通过，如果不是全员通过，那么就要有一个主心骨的人来定下来这个事情是不是一定要做，要做就按照上面的时间点完结。结果如果不理想，有小部分人反对说排期不够，内容不够细还可以在沟通，其他人员也可以先按照计划执行，会后在沟通；如果超过一半的人都反馈有问题或大半人都反对，那么凉了啊~这个会议很失败，在不行就得重新确认，下次在拉会了。
-
三约：约时间、约会议室、约人。这里要确认信息落实情况，很多的时候我们只是去通知了，仅此通知，对方只是看了、知道了、同意了。不要相信邮件已发，对方已读，已经来确认好来，这都是前期点工作，重要的会议，还应该在会议开始前再次和对方确认一次，便于对整个会议召开的把控。
-
会议资料：不管是什么项目内容，在需求评审阶段，都需要针对相关人员介绍项目背景、构想项目的过程、预期研发结果、计划产出内容、需各人员配合情况、时间周期安排以及备用方案。
-
备用方案：会议在开始前，要做好备用方案，如果有相关人员不能来，那是否可以提前确认（其实一般在重要会议前，最好和相关人员确认下结果更好）；如果相关资源不到位，那么整体进度是可以在哪里进行调整；还有一个是针对一些问题如何应答，切记不要无准备应答，更不要说细节的问题可以不在会议上讨论，这里会和不讨论细节有冲突，该说的时候还是要说明一下。比如你提报了一个安全防护措施，别人会问你怎么做安全防护，可以说使用账号来限定登录，还要说下发内容的时候做加密通道，内容以数据的形式下达到数据库等，这里如果在谈论细致的过程，就可以单独商讨了。
-
1、准备工作
-
2、开会：
-
3、产出：
-
三、如何确保需求评审确认&通过
-
1、确认结果：以上的过程，我们都一直在说过程多重要啊，当中需要做什么什么啊，但最终的目的是什么？无论前面做了多少铺垫，都是为了拿到确认这个结果，为了这个结果而去做很多的事情，多做一些工作还是可以的。如果未能确认/否定，那不是凉了啊~一定是以这个前提去做事，去协调所有的一切。
-
2、沟通及应对措施：提前沟通，单个沟通/一起沟通，确认好各方需要协调和需要修改的地方，并且确认结果，然后在开会通知各方。会议的过程是为了说事，给结果，不要变成茶话会，各抒己见，脑洞大开。在会议的过程中，对需求明细，可以有沟通，可以有各方的提问，但要注意控场。准备好一切顺利，然后撒花撒花，也要准备一些明细的解答，防止有人来砸场子。
-
3、最关键的是你：其实，上面说的那么多都是废话，真的。如果是能够拍板的人，那么你的需求评审，就是告知过程，然后安排下面的人做事就好。如果你是需求明细撰写人，那么你的需求评审，就是已确认好内容和大家进行宣讲，告知目的和需要的过程，大家照做就可以，没有什么反驳的意见。如果你是业务提出方，那么你的需求评审，就是需要大家各自领取对应的任务，然后相互配合解决问题；这里就需要提前沟通，确保能够顺利进行。
-
四、思考
-
2.1具体要什么格式？
-
答：一般提出这样的问题，就是追问细节的过程了。如果提前知道，那么在文档中就应该标出出来。如果不知道，那么需要询问各负责人，可以让他们提供，你来决定。具体要什么格式，具体要展示什么样式，具体要做哪一块等等这些都是常见的问题，能够提前就提前确认，尽量不要在会议上被抓住询问。
-
2.2这个要等UED出了页面，前端才好评时间。
-
答：工作当中没有需要前面做完，后才能出计划这么一说，说类似这句话基本就是推辞，评审的过程，就是需要用专业、丰富的经验来评定。如果用这句话挡住了，那么就一定要跟进到底，要追问出结果。当然这里你的原型和文档，要描述清楚，要详细，不能一句话需求丢出来，让别人给结果。大家都工作了那么长时间，设计一个页面要多久，开发一个搜索逻辑需要多久，测试一个模块要花多长时间其实大概都有数。
-
2.3研发的技术我们还需要在商讨下。
-
答：如果把推辞说的委婉点，那么就用这句话最合适，但这个优雅的规避要怎么解答呢？直接追问：问题已提前沟通过，你们当时给过答案，是XX，现在需要在商讨是要修改之前的回答吗？如果是，那么按照前面沟通的，各自的排期是XX，其中你们的排期是XX天到XX天之间，你们可以在设计出图的这段时间在商讨，但前端一旦进入开发，你们就必须确认技术方案。合理的堵住对方的话，给时间周期，但也要给对方约定最后截止时间。
-
2.4你这里有漏洞。
-
答：我们前面一直在说备用方案，说多准备一些解答，就是用来回应这类问题的。没有人能够完美，所以没有人能够一次把方案做完美无缺，那么这里第一不要被吓到，第二要做好回答的准备，第三要针对性的解答，但一定不要被带偏节奏。首先，既然对方说了有漏洞，那么询问对方的解决方案是什么？如果对方回答，那么确认下，合理就认可；觉得不妥当，就记录下来，这条会后在沟通，确认结果后反馈给大家。其次如果对方没有答案，只是说了不合理，那么就单独约沟通的时间，详细来聊这块。还有如果这个漏洞引发出来的更多的争论，那么这里就要自我反思，为什么会留下这么大一个漏洞，需要马上来决定，这个漏洞是在本次需求研发的过程中解决掉，还是漏洞影响了本次的需求，整体需要延后。无论如何，先记录，然后切断讨论，继续会议。
-
2.5这个业务价值需要我们花这么大的精力做吗？
-
答：谁能来决定业务价值？业务最有发言权，研发都是负资产的研发，所以这里要思考的是如何做有价值的业务，而不是要做什么？研发可以提出自主意见，但在研发前面有产品、有运营，有专门的销售团队，这些人才是主要决定业务价值的人。这里还有一个点：你的研发团队很牛逼，真的是在做很高的东西，那么所有的精力真的需要围绕他们来做事。比如你的研发团队是在做区块链，是在做AI算法，是在做技术驱动的领域，那么其他人请闭嘴，研发请讲话。
-
2.6和现有的业务逻辑有冲突，是要推翻重新做？
-
答：如果发生这种事情，那真的是发起人自己打脸了，这种情况没啥好说的，自己悔改吧。在会议发起前一定是要确认之前的业务逻辑和新开发的需求之间的关系。如果是要推翻之前重新做，那么会议的一开始就要说明，并且还要对之前的业务给出修补方案。是否推翻重新做，这里无论是否决定继续，都需要承担前方的责任，规划要做好，是错可以，但机会不多。
-
2.7我现在给不了，需要明细评估才能答复。
-
答：同第二条类似，跟进，追进，明确结果，原则性的问题一定是得到明确的答复才可以。一些不太重要的小细节，做下记录，能够跟上进度，也可以延后。
-
1、没有什么是解决不了的问题，有问题就是一顿烧烤的事情，不行就两顿外加两箱酒。如果有人就是要整你一下，那也没办法，强硬点，该怼回去的时候就要怼回去。
-
2、日常会被爆的点：
-
3、收尾：需求评审，是需求是评论还是审核？针对不同的问题要做不同答复召开不同的会议内容，但一定是要明确会议主题，要梳理好会议内容，最后一定是要跟进过程，并拿到结果。
