资深项目经理对需求管理的认识，需求收集与部署

（一）对项目需求管理的认识和体会

　　做了那么多个项目，我深深感到对项目的需求把握管理好了，是项目成功的关键。对需求的管理大概有那么几个活动，首先是需求获取，这是一个确定和理解客户的需要和期望的过程，为实现项目目标而定义、记录、分析干系人的需求; 其次，是要求获得相关人员对需求的认可和承诺;最后，即使是需求确定下来之后，也不可避免得会有变更，如何控制和管理变更，是保障项目目标的实现的重要环节。
　　2010年，我担任了公司一个重要项目，老挝TAIS系统的项目经理，该项目是一个系统集成项目，在此之前，我并没有做过类似项目，为谨慎起见，严格按照需求管理的规范执行，收获了很多经验，也保证了项目的顺利交付。

　　1、需求获取 需求获取分为两个阶段，需求调查、需求定义。需求调查和需求定义在逻辑上存在先后关系，但实际工作中二者通常是迭代进行的。需求分析的工作则贯穿于“需求调查”和“需求定义”两个阶段。 需求调查的目的是通过各种途径获取用户的需求信息(原始材料)，产生《用户需求说明书》。

　　需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。

　　在进行现场需求调查之前，我首先需要了解的是，这个项目是什么样的项目，大概做什么事情?并仔细阅读了售前阶段产生的所有文档资料，和售前阶段参与人员交流沟通，进一步了解项目是谁提出来的，目的是解决什么问题。

　　不单单听介绍，特别关注了与合同具有同等效力的那些文件，如技术协议，工作说明书(SOW)、实施方案等等。从而知道，该项目是一个老挝TAIS (THSCAN-ASYCUDA Integration Solution)项目是我司集装箱/车辆检查系统与海关数据系统整合解决方案的简称。目前在老挝境内，8个地点部署了6套车载式系统和2套组合式系统，老挝海关使用的海关自动化业务系统叫ASYCUDA，TAIS就是要实现NUCTECH扫描设备与海关数据系统的高度集成和信息共享。

　　了解都项目的业务领域之后，我又对客户干系人进行了分析，这样，就能保证正式调研需求时，能够选择一些典型的客户代表进行需求调研。刚开始没有经验，参与人员太多，提供的信息过于零散，减慢了收集需求的进度。后来我们制定了现场访谈计划，一次讨论不超过10人。效果就好多了。通过和客户的有效沟通，获取了大量的信息。

　　我发现，跟客户交流时，提的问题最好是开放式的，比如 “是否确认进度检查确认方式”比“如何确认进度检查确认方式”可以获得更多的信息。“项目计划编制完成后，是否征求下级部门意见，如果下级部门不接受上级部门分配的计划，如何协调和处理?”这样一个问题就可以了解客户的计划批准和协商过程。现场调研的工作很顺利，共去了3次。

　　除此之外，我们还参观了用户的工作流程，观察用户的操作。 初步的需求信息得到以后，要对需求进行分析。需求分析有很多方法，“问答分析法”、“结构化分析法”和“面向对象分析法”，总之，是要对得到的信息进行处理，提取这些信息间潜在的逻辑关系，分成不同的类别，这样才能充分理解它们。

　　这就要求项目经理不仅要尽可能记录客户信息，同时还要做一定的整理，否则，所有的讨论只剩下一个模糊的印象，需求仍然是一件遥远的事情。只有进行深入收集和分析，才可以消除任何冲突或不一致性。 信息量越大，对准确理解客户的需求越有帮助，但同时，对需求的分析也就越难。


　　对于软件项目，我认为这可能是最困难、最关键、最需要交流的工作。因为软件不是硬件，不是主板，显示卡之类看得到摸得着的东西，软件是思想，是理念，是规则，是对真实世界的抽象。软件项目的交付物是有形的，可又不同于其他行业，比如汽车的构造是固定的，其组成部分是不变的。而一个软件系统的模块划分则可以有多种方法，多种结构。这个特征导致对软件项目经理的抽象思维能力要求很高，要求要有较强的逻辑性。否则，就有可能表现为缺少全局概念，对项目整体的范围和业务系统把握不够，在项目过程中被客户牵着鼻子走，今天客户说要个什么功能，就添加个什么，明天要修改个什么，就跟着修改什么，被动至极。 将客户信息结构化，编写成需求文档。这是需求定义的工作。公司的《产品需求规格说明书》的主要内容包括：“ 产品介绍;描述用户群体的特征;定义产品的范围; 阐述产品应当遵循的标准或规范;定义产品中的角色;定义产品的功能性需求;定义产品的非功能性需求，如用户界面、软硬件环境、质量等需求;”仅有这份需求文档还不够，我上现场调研时带了个美工，将我们和客户沟通好的软件部分用图形界面UI画了出来。 需求定义是需求获取中最“痛苦”的一件事情，为了尽量避免日后的扯皮，我们力图使每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，追究“是什么”和“为什么”的目的是获得正确、清楚的需求。对需求定义的标准大致如下： 需求存在二义性吗?2 需求文档的上下文有矛盾吗?2 需求完备吗?2 需求是必要的吗?2 需求可实现吗?2 需求可验证吗?2 需求的优先级确定了吗?2

　　2、 需求确认 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 在需求调研的过程中，我发现对项目范围的定义和当初了解的存在误差，这也是很正常的，因为未签订合同前，谁也不能做很深入的调研，只能了解个大概要求。但我们的原则是不轻易更改工作范围，只是在原来的框架内做一些小的调整。 而且每次和客户讨论之后，我们都写一份会议纪要，请客户签字确认。但即便如此，对需求的确认也是一件很让人头痛的事情。如何划定边界?做到什么程度就可以了?因为只有提供需求的人才能确定是否真正获取需求，我们都尽量请客户参与讨论并更正。 需求评审会议非常重要，但是以前几个项目的评审会都开得不很理想，大家事先不认真阅读文档，会上乱哄哄的，你说一句，我问一句，往往花费了很多时间，却啥结论也没有。这一次，我吸取了教训，组织了一个非常正规的需求评审会议，将部门领导、公司的业务专家、技术骨干都请来当评审人员。并自行设计了《评审准备表》和《评审记录表》。会前两天提前发了老挝项目的需求文档《老挝TAIS项目方案建议书》、《老挝TAIS项目调研报告》，发放了《评审准备表》，让大家提前将问题记录在评审准备表中，并反馈给我，我一直等到反馈意见收集的差不多了，才召开评审会。评审会开的很成功，效率很高。我让人整理了评审发现的问题，放在了评审记录表中，方便下去追踪。

　　3、 需求变更控制 需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。

　　需求变更难以避免，重要的是不能没有章法得变，要遵循一个标准的变更控制程序，使得变化有序起来。 如果不进行变更控制，那么，项目就不能得到及时的警告，常常会因为进度超期、预算超支而陷入泥潭，成为“烂尾”工程。但是变更实在太频繁，如果每次变更都走变更流程，也会大大影响项目进展。按照变更控制流程，需要对变更做影响分析等等。

　　既然变更在所难免，不可能只要有变更就执行严格的变更控制程序，这个过程也是有成本的，所以，和项目组成员讨论的结果，只有重大变更时，才执行变更控制程序。比如影响了项目里程碑的达到，工作量超出了原先估计的30%等等。

　　这样一来，既保证了变更的有序性，又保证了项目进展。 除此之外，我还对需求的稳定度做了一个度量，度量了原始需求的个数，增加、删除、更改的需求个数;并分散在项目各个阶段，如需求分析、概要设计、详细设计、编码阶段、测试阶段等等的需求数，并将每次需求变更的提出人、变更原因，是否走了正式的变更流程都记录了下来。一来是为以后的项目做参考，二来跟客户沟通时也有话说。不至于拿不出令人说服的事实和根据来。


　　比如这个项目，初始的软件需求共有142个，中间增加了21个，删除了6个，更改了34个。总体需求稳定度在30%左右，对于一个软件项目来说，就很不错了。 老挝项目于2011年12月底结束，项目获得了老挝海关的好评,目前系统运行正常，系统已经融入老挝海关工作流程，成为海关工作不可分割的一部分。公司也收回了该项目所有尾款，实现了公司的价值。

　　在此项目中，我们做到了一下几点：尽早开始需求调研，清晰进行需求定义，随时和客户进行沟通，及时记录需求变更，统计需求变更的影响和工作量。因此，项目进行得很成功，期间克服了很多困难，比如人手紧张，客户方接口人变动等等。但因为工作范围没有什么改变，需求一直在掌控之中，项目一直按计划执行和完成。


（二）如何能正确理解项目需求

【事件】我所在项目组开发的产品是运行在移动设备上的CAD应用。由于CAD是辅助设计软件，与图形处理密切相关，所以我们招底层开发人员必须有相关开发经验才行。但就目前的市场形式，我们又不得不招一些上层（移动端）开发人员，辅助我们去完成产品的开发工作。

这些上层人员的介入，使得我们沟通有了不少阻碍。因为他们不了解CAD，对其中的实体、命令、图层、布局一窍不通。这样的话，我们只能让底层开发人员，尽量将底层库封装好。上层人员只需调少了的接口，就能实现功能就好。但是问题还是会出现的。

当新的需求（包含CAD专业性的）产生后，底层开发人员很快就能理解需求，马上做出响应（做完设计开始编码）。可上层人员还在想需求到底是什么？此时他可能会做出两种反应：1）找产品经理，让他解释每个专业名词的意义。一时理解了就开始着手设计。2）猜想出是某种功能，然后开始设计。

第一种行为可能造成的后果是，耽误了很长时间，做出的功能一半正确一半错误。保留那正确的部分，可能与解决错误后的模块兼容不上。不保留的话，又感觉之前的设计白做了，浪费时间很可惜。

第二种行为造成的后果是，兴致勃勃作完的功能交给产品经理验收。一盆冷水浇了过来，他可能会告诉你，需求本来就不是这个意思。你的设计偏差很大，全部丢弃，重新设计。

【解决方案】

我们说理解需求最好的方法就是去沟通。所以上面事件中，第一种行为肯定比第二种更好些。但对于一个非专业的人士来讲，沟通也需要技巧。盲目的询问只能是鸭子听雷，完全没有理解。

我们经过讨论后，决定“如何能正确理解需求，需要产品经理和开发人员相互讲解此需求”。

就是说，当一个项目需求制定出来后。产品经理先根据自己的需求给大家讲解一遍。这时，大家可以根据自己处于的角色对此需求做评定。测试人员也可以参加，他们可以代表用户，指出哪里设计不符合常理等等。开发人员可以根据需求里面的专业知识点，深入咨询。产品经理在解答问题时，其他专业人员可以对答案做审核，给予补充等等。这样使得提问者能够更清楚地理解需求。 

经过产品经理讲解后，大家回去可以细细研究一遍，对不懂的地方可总结到一起，必要时可做第二次讲解会议。如果已经没有异议，那么开始做概要设计。设计好后，开发人员召集大家，讲解一下自己的设计。让产品经理看看开发人员设计的是否合理，需求是否已经理解透彻。针对细节处，大家可以深度讨论。

通过这样的互相讲解需求的方式，就能保证需求设计的质量，以及开发人员理解需求的正确性。


（三）做好项目中的需求收集和管理


需求收集真正的体现了需求的市场和用户驱动。访谈，调查表，头脑风暴，竞争对手和产品分析都是需求收集的方法。需求收集我们需要搞清楚用户真正的需求，问题背后的深层次问题，这样才可能为挖掘需求提供数据。需求收集的过程应该流程化，收集的需求应该分类入库的归档化。必须将需求收集活动看做为一个结构化的流程或过程，以真正的促进收集的过程和采集的数据的有效性。

收集的需求在论证分析中应该确定优先级，而优先级的确认应该引入价值工程，即我们应该认识到一个需求的重要性应该体现到它对产品价值的短期和长期的增值上面。要理解这个，就必须要考虑收集的需求是普遍需求还是特殊需求，是核心业务对应需求还是辅助业务对应需求，是使用频率高的需求还是偶尔使用的功能点需求。我们必须有清晰的头脑来分析用户急的是否就一定是优先级高的需求。

用户往往习惯了给我们提希望系统实现什么功能，这些需求往往是用户已经转换后的需求而不是原始需求。当用户遇到业务上的问题的时候他们往往假设了一种实现方式，如果在需求收集过程中错误的把问题的解当做需求，则我们就忽略掉了真正的原始需求。需求收集的重点应该在用户真正面临的问题域和问题场景的收集。

需求收集人员的业务背景和经验往往对需求收集有效性有很大的影响。需求收集的访谈过程不是简单的听用户如何讲，而是需求我们去引导用户讲出他们真正面临的问题。通过我们积极的沟通让用户把他们真实的想法真正的表达出来。

需求收集是整个软件产品开发的源头，是确定产品方向和定位的重要活动。需求收集活动出现大的误差将是方向性的重大错误。如果我们开发出来的产品不能真正满足用户的需要和得到用户的认可，那产品本身就不可能创造价值，及时这个产品有很好的质量，易用性和功能等，这个产品仍然是失败的。

需求分析和开发

需求分析工作需要意识到是包含了业务分析和系统分析两部分内容。对于业务分析包括了业务流程分析，组织结构和岗位角色分析，以外的对象分析，数据流分析，重点是描述现在。系统分析的内容重点是将需求转换为系统可实现的软件需求，因此必须要考虑到需求的可实现性，如果对于面向对象分析则重点在用例分析，业务对象建模，业务规则分析。系统分析最好是有软件开发经验的人和业务背景的人进行，这里的一个重点就是要把软件开发中已经成熟的分析模式和模型和实际的业务进行匹配。

软件产品要能够适应需求的变化，不仅仅是软件架构上的可扩展性考虑，更重要的是在需求分析阶段就需要考虑软件需求如何适应用户需求的变化。对应用户经常可能变动的需求点进行抽象，引入一些标准的可配置的模型，如权限模型，工作流模型等。软件需求对业务需求和用户需求的一个处理要点就是会考虑到哪些经常变化的需求需要转换为灵活的可配置的需求。

用户都不清楚自己要什么或者说用户的需求经常变动更应该促进我们去改进需求分析和开发的过程。在这个时候系统分析员的开发经验和业务背景将起到很重要的作用。需求的一种变更对于软件开发往往是一种必然的情况，只是如何把它变更的范围控制住，如何实现需求的变更不是要修改设计和编码，而是通过灵活的配置来实现的。

收集来的用户需求如何转换为需求规格说明书，中间的一个重要过程就是需求分析和开发。这样正好体系一些需求分析工作的重点内容，通过识别需求的优先级以更好的安排项目资源和进度，有的放矢。通过对原始需求的分类，合并，抽象以提取通用的需求模型。通过识别非功能性需求以增加整个系统的健壮性，性能和易用性。通过对需求模块单元的划分，流程和规则的描述，功能点分析为项目进度计划安排和进度跟踪创造条件。因此我们将需求分析是一种业务和系统的模式匹配，如果才能够匹配好就是需求分析的责任。

需求管理

应该首先看到需求管理的目的首先为项目管理服务，结构化的需求管理使项目管理真正做到可视化，另外需求管理为用户服务，通过有效的需求管理能够更好的满足用户的需求，提升用户满意度。最后需求管理为后续项目提供支持数据和依据，因为需求管理的内容是结构化和文档化的，这些是内容是项目重要的过程资产。

要管理需求，则我们的需求必须是结构化和文档化的，否则就谈不上需求管理。因此需求管理必然会涉及到配置管理相关工作。同时为了量化的说明需求管理的有效性，我们的需求本身又必须是可度量的，需求功能点的粒度应该在一定范围内。需求规格说明书是需求管理的重要对象，必须文档化，而且会在整个软件开发生命周期中被多次使用到。

需求全生命周期的管理的一个重点就是需求的状态管理，用户提出来的需求就是是否实现了，现在处在哪个环节都需要依靠需求的状态管理和跟踪来实现。因此需求分析阶段需求功能点的条目化就是需求状态管理的一个重点，而需求状态跟踪的过程正好就是我们对项目进度和状态的跟踪过程。如果项目管理的状态监控的好，则需求状态管理也可以做好，同时拆分后的需求状态管理为我们增量和迭代开发提供了基础，有了这个才可能真正做好项目挣值管理，才可以更好的应用挣值中的0-100原则。

需求的变更控制重要性体现在真正的使甲乙双方对范围的承诺有共同的重视。当有了共同基准依据的时候才能够真正的体现用户满意度上面，同时需求变更真正的体现出项目计划的严肃性，保证项目计划的受控和严格执行。需求老发生变动，项目老延期都是需求变更没有做好的一种表现形式。对于已经开发完成的软件产品，我们更需要有结构化的需求变更流程，将变更的影响分析影响植入到流程中，这样才可以保证整个软件产品的稳定性。