众所周知项目范围是项目根本，项目没有范围，就不可能有项目，项目范围就是项目需求，希望通过今天的文档能让大家明白需求的重要性。
先说下项目过程中可能出现的需求问题

1
不知道做什么
这种情况还是比较常见，特别是在一些靠商务推动的项目上，客户领导或者说是你们领导给客户领导提出了一个新的理念，合同草草就签了，关于最重要的需求部分要么模糊不清，要么一句话概括了，或者都是一些冠冕堂皇的官话。
接下来下边人就开始推进项目，团队成员对业务不明白，客户自己对业务也不明白，项目一直在做一直在改，改来改去bug一堆，还上不了线。

2
双方理解不一致
你以为做的是一个结果管理系统，客户以为做的是一个过程管理系统。
需求文档上写着“要对组织架构进行排序”，开发人员开发出来的是按照姓名首字母排序的，结果客户认为是按照入职时间排序的。
或者说大家都认为最基础的功能没有描述清楚，比如说项目要具有高可用性，稳定性等，你认为的稳定性就是满足客户现在的使用人数，结果下半年客户收购了另外一家公司，使用人数暴增，系统直接宕机。
尽管有需求文档，双方理解的也不一致，还有很多细节需求文档上根本没有体现出来。

3
一直提需求
一直提需求也有几种原因，有可能是前边1和2的原因，有可能是客户业务调整，有可能是客户换了领导。
一直提需求项目就一直拖，拖过了上线时间，拖过了验收时间，拖过了运维期。

这些都可能是导致需求不可控的原因，归根到底都是沟通问题和工作方式问题，对项目经理更是严峻的考验，试着尝试以下方法看能不能解决。

1
认真调研需求
项目到底要做成什么样子，有什么样的目标，一定要在前期了解清楚，让项目干系人都参与到需求调研中，通过项目经理的专业能力、行业经验，要了解不同层次，不同用户群体的需求。
对用户提出的需求要结合实际业务场景，需求不会平白无故出来，客户要一杯水你就给了农夫山泉，结果客户是用水来拖地，要多问问为什么，多思考一下。

2
需求文档要细致
需求调研文档、原型文档、设计文档、UI文档、测试等所有的文档都要细致，任何一个不能确认的问题都可能带来开发过程中的反复。

3
所有文档都要确认
在需求调研和确认的过程中，要让用户参与进来，每个文档都要和客户认真核对，每个文档都要让用户签字或邮件确认。

4
制定变更流程
尽管需求做的很完美，但是因为各种客观原因，该变还是要变的，针对需求的变动应该采取什么样的措施，是完全接受，还是置之不理，都要有严格的控制流程，有双方领导认可的变更流程，这些在处理需求变更才能得心应手。

希望大家都能够对需求保持着严谨的态度，毕竟需求清楚了，项目就成功了一半。

学习了！谢谢吧主~需求分析和管理确实是现场项目经理的重要职责之一。