做了那么多个项目，我深深感到对项目的需求把握管理好了，是项目成功的关键。对需求的管理大概有那么几个活动，首先是需求获取，这是一个确定和理解客户的需要和期望的过程，为实现项目目标而定义、记录、分析干系人的需求；其次，是要求获得相关人员对需求的认可和承诺；最后，即使是需求确定下来之后，也不可避免得会有变更，如何控制和管理变更，是保障项目目标的实现的重要环节。
2010年，我担任了公司一个重要项目，老挝TAIS系统的项目经理，该项目是一个系统集成项目，在此之前，我并没有做过类似项目，为谨慎起见，严格按照需求管理的规范执行，收获了很多经验，也保证了项目的顺利交付。
1、 需求获取
需求获取分为两个阶段，需求调查、需求定义。需求调查和需求定义在逻辑上存在先后关系，但实际工作中二者通常是迭代进行的。需求分析的工作则贯穿于“需求调查”和“需求定义”两个阶段。
需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。
在进行现场需求调查之前，我首先需要了解的是，这个项目是什么样的项目，大概做什么事情？并仔细阅读了售前阶段产生的所有文档资料，和售前阶段参与人员交流沟通，进一步了解项目是谁提出来的，目的是解决什么问题。不单单听介绍，特别关注了与合同具有同等效力的那些文件，如技术协议，工作说明书（SOW）、实施方案等等。从而知道，该项目是一个老挝TAIS (THSCAN-ASYCUDA Integration Solution)项目是我司集装箱/车辆检查系统与海关数据系统整合解决方案的简称。目前在老挝境内，8个地点部署了6套车载式系统和2套组合式系统，老挝海关使用的海关自动化业务系统叫ASYCUDA，TAIS就是要实现NUCTECH扫描设备与海关数据系统的高度集成和信息共享。
了解都项目的业务领域之后，我又对客户干系人进行了分析，这样，就能保证正式调研需求时，能够选择一些典型的客户代表进行需求调研。刚开始没有经验，参与人员太多，提供的信息过于零散，减慢了收集需求的进度。后来我们制定了现场访谈计划，一次讨论不超过10人。效果就好多了。通过和客户的有效沟通，获取了大量的信息。我发现，跟客户交流时，提的问题最好是开放式的，比如 “是否确认进度检查确认方式”比“如何确认进度检查确认方式”可以获得更多的信息。“项目计划编制完成后，是否征求下级部门意见，如果下级部门不接受上级部门分配的计划，如何协调和处理？”这样一个问题就可以了解客户的计划批准和协商过程。现场调研的工作很顺利 ，共去了3次。除此之外，我们还参观了用户的工作流程，观察用户的操作。
初步的需求信息得到以后，要对需求进行分析。需求分析有很多方法，“问答分析法”、“结构化分析法”和“面向对象分析法”，总之，是要对得到的信息进行处理，提取这些信息间潜在的逻辑关系，分成不同的类别，这样才能充分理解它们。这就要求项目经理不仅要尽可能记录客户信息，同时还要做一定的整理，否则，所有的讨论只剩下一个模糊的印象，需求仍然是一件遥远的事情。只有进行深入收集和分析，才可以消除任何冲突或不一致性。
信息量越大，对准确理解客户的需求越有帮助，但同时，对需求的分析也就越难。对于软件项目，我认为这可能是最困难、最关键、最需要交流的工作。因为软件不是硬件，不是主板，显示卡之类看得到摸得着的东西，软件是思想，是理念，是规则，是对真实世界的抽象。软件项目的交付物是有形的，可又不同于其他行业，比如汽车的构造是固定的，其组成部分是不变的。而一个软件系统的模块划分则可以有多种方法，多种结构。这个特征导致对软件项目经理的抽象思维能力要求很高，要求要有较强的逻辑性。否则，就有可能表现为缺少全局概念，对项目整体的范围和业务系统把握不够，在项目过程中被客户牵着鼻子走，今天客户说要个什么功能，就添加个什么，明天要修改个什么，就跟着修改什么，被动至极。
将客户信息结构化，编写成需求文档。这是需求定义的工作。公司的《产品需求规格说明书》的主要内容包括：“ 产品介绍；描述用户群体的特征；定义产品的范围； 阐述产品应当遵循的标准或规范；定义产品中的角色；定义产品的功能性需求；定义产品的非功能性需求，如用户界面、软硬件环境、质量等需求；”仅有这份需求文档还不够，我上现场调研时带了个美工，将我们和客户沟通好的软件部分用图形界面UI画了出来。
需求定义是需求获取中最“痛苦”的一件事情，为了尽量避免日后的扯皮，我们力图使每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，追究“是什么”和“为什么”的目的是获得正确、清楚的需求。对需求定义的标准大致如下：
需求存在二义性吗？²
需求文档的上下文有矛盾吗？²
需求完备吗？²
需求是必要的吗？²
需求可实现吗？²
需求可验证吗？²
需求的优先级确定了吗？²
|