#背景
这个项目将在五天后正式启动。根据之前的规定，Heroes向客户发送了试运行版本的安装程序。
谁知道，客户今天下午给Hero发了一条信息：“请你和你的产品经理过来开会。”
看到这句话，男主角心里咯噔一下。有问题吗？还是要讨论下一个版本的需求？
会议当天，客户表情严肃委婉地说：“如果以后有不确定的需求，请及时确认”。
听到这句话，主人公的心又冷又冷。结束了。这绝对是个问题。这个版本的迭代肯定不会上线。
那之后会发生什么？今后如何避免这种情况？
#为什么？
面对这种情况，首先我们来分析一下根本原因。
我们从客户的话中知道，这次迭代无法上线的根本原因是需求与客户的目标需求不匹配，导致系统与客户理想状态不一致。
那为什么不一致呢？以下是几个重要问题的原因：
1.没有和客户确认需求，没有形成需求说明书，没有留下需求确认单。(有些情况下，客户的需求发生了变化，但没有被接受)
2.项目经理的能力不足，没有有效的监控，没有控制需求的内容。
3.产品经理没有足够的能力理解客户的真正需求。
#我该怎么办？
因为这个迭代不能正常上线。那你只能经历改变的过程了~ ~ ~
项目经理需要提交变更申请，分析变更带来的影响(比如计划什么时候延期上线，具体要求为什么调整，为什么)，然后提交给建行(变更控制委员会，如果有些项目没有成立，可以发给客户和公司领导)审批。如果获得批准，将按照批准的方案实施。如果不通过，会很难。需要进一步分析失败的原因，反复调整要更改的内容，再重新提交审批。
申请变更时，项目经理还需要安排好团队成员的工作(如果是强矩阵管理)，同时安抚团队成员的情绪。
产品经理需要更新需求文件，修改需求原型，然后与客户确认。
之后，团队有必要召开一次续会。
#如何避免？
有了产品经理的项目团队，项目经理仍然需要密切跟踪需求，您不需要设计特定的功能模块和绘制原型。但是，还是要非常清楚需求是什么样的，客户的期望是什么样的，而不是只是做一个“主持人”，指挥大家做这个做那个。
需求错了，我们会改变，那以后怎么避免呢？首先，我们需要知道需求的水平。通过层层确认需求，可以从整体到局部，从概念到细节，详细梳理客户的真实需求。
在接收项目时，用户通常会说我想要一个xxx系统，比如“环境监测系统项目”的流程决定了需求的第一层次——业务需求。
之后和客户深入沟通，了解到客户每次需要环境数据，都需要第三方计算，然后用Excel整理，比较麻烦。因此，我们希望能够通过一个平台实时看到环保检测数据，进行多级管理，查看设备实时状态，实时监控视频等。这个过程就是需求的第二个层次——用户需求。
在了解客户的用户需求后，产品经理和项目经理需要对接内容。应该如何通过系统呈现，还是应该通过表格反映？还是用图表呈现？这个过程是需求的第三个层次——系统需求。
综上所述，这三个层次的定义如下：
业务需求：是指企业或客户对高层系统的目标要求，通常来自项目投资人、购买产品的客户、客户单位经理、营销部门或产品规划部门等。
用户需求：描述了用户的具体目标，或者用户要求系统完成的任务。换句话说，用户需求描述了用户可以用系统做什么。
系统需求：
它是从系统的角度解释软件的需求，包括功能需求、非功能需求和设计约束。功能需求也变成了行为需求，行为需求指定了开发人员必须在系统中实现的软件功能，用户可以使用这些功能完成任务，满足业务需求。
设计需求的时候，往往是最关键的时候。
这个要求是客户想要的吗？是否符合客户的想法？
这时，有必要与客户反复确认。一次确认不了，就两次；如果你不能确认两次，那将是三次，直到用户签署需求确认表或回复电子邮件。
但这期间的时间会影响整个项目的进度，所以确认的次数不宜过多，这也需要产品经理准确定位客户的需求，项目经理控制需求内容。
了解更多信息
