公司刚刚接到一个软件项目，小明被任命为项目经理。在制定了项目章程后。他开始按照一哥给的项目计划编制流程图来收集客户的需求了。并根据客户的需求开发了第一版，提交给了客户，客户摇摇头说这不是我想要的；小明虚心听取了客户以及同事们的意见和建议后，再次和团队一起开发了第二版，提交给了客户，客户还是摇摇头说这也不是我想要了。如此往复到了第五版，客户仍然摇头。此时小明憋了很久的怒火终于压抑不住了，朝着客户发飙了，说“你究竟想要什么？”客户也怒吼着来了一句“我也不知道我想要什么，我只知道你做的都不是我想要的”。
不知道上述场景你是否遇到过？如果有，就说明你没有真正弄清楚客户的需求是什么。
那么什么是需求？先引入两个英文单词，need和want，两者是否有区别？当然有，need是必需的，want是想要的。比如一个人渴了，你给他一瓶水，就满足了他的need。一个人饿了，你给他一碗饭，也满足了他的need；但是你此时不仅给你他一碗饭还给了他一碗汤，那就满足了他的want。
结合到项目当中来，根据PMBOK的定义：需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他干系人的已量化且书面记录的需要和期望。
在项目中常见的需求类型如下：
业务需求。整个组织的战略要求我们必须去做什么样的项目才能抓住市场机遇，进而提高公司的盈利能力等。比如，我们要实行工业化4.0项目来满足客户多种类，小订单的需要，来提升公司市场占有率。
干系人需求。特别要注意干系人背后的或者私人的需求，你懂的。这种最好在非正式场合下去进行了解。
解决方案需求。为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。分为功能需求和非功能需求：
功能需求。例如，智能手机内存要有4G，跑分要达到多少分等。
非功能需求。例如，保密性、安全性等。
过渡需求。当前要做到最优可能不太现实，那么可以考虑做一个过渡的产品。等到条件成熟再进行更新换代。
项目需求。例如客户期望的交付里程碑日期、合同责任义务等。
质量需求。例如质量标准、测试方法、CCC认证、ISO取证等。
收集需求的时候要考虑各种各样的方法，包括但是不限于：
头脑风暴。集思广益，群策群力。
访谈。经常是一个访谈者和一个被访者之间的“一对一”谈话，对于一些私密的，私人的需求可以通过私底下的非正式沟通来获取。
问卷调查。设计书面的问题，来完成受众广，快速得出结果，受访者地理位置分散的需求分析。并可以使用统计方法来获得结果，比如使用饼图或者帕累托图得出比例最高的那部分。建议使用微信中的小程序。
标杆对照。同业对标，或者企业内部的经验交流会。
观察。很多行业会有相应的潜规则，当事人不愿意明确提出他们的需求。当然有时候也有那种只可意会不可言传的东西，就可以旁站观察得到相关需求。
当通过以上方法收集到了相应的需求后，就可以使用以下方法来确定，哪些是need，哪些是want。或者哪些应该要满足，哪些可以不用或者不用现在就满足。
投票表决。
一致同意。都同意。
大多数同意。超过 50%。
相对多数同意。比如三个或者三个以上选项时，A占40%，B占35%，C占25%，那就选择A。
独裁决策。一个人或者一小部分人做决定。
多标准决策。考虑多方面的因素，比如性价比等。
由于项目资源的稀缺性，你时刻都面临着事多、钱少、时间紧的状况。那项目经理在需求管理中该如何去做呢？首先要满足干系人的need，并且是关键干系人的need。
给大家推荐一个非常简单却行之有效的工具：其实就是两个同心圆，当你在收集需求的时候，就可以把所有的need写在内圆中，want写在两个圆圈之间，而外圆之外就是除外责任。
在了解到了干系人的相关需求，并进行了相关的后，就需要记录下来，形成需求文件。并作为后期定义范围的输入。
当然，咱们虽然在前面讲过，说项目资源有限，只能满足关键干系人的need。但是一哥想给大家说的是，在实战中不仅要满足need，还要尽可能的、有选择性的满足一小部分最关键的干系人的want（有可能是私利，不，应该是大多数情况下都是私利。你懂的），也就是超出他们的期望。只有这样你的项目才能够有更大的几率取得成功。也希望今天的文章对你有帮助哦。
