客户，是一个系统或软件赖以生存的基础，客户的需求更是整个系统或软件开发过程的核心。“对于不知道自己要去何处的人是没有顺风的”。如何不断地挖掘客户的需求，围绕其进行开发，并最终交付给客户符合其期望的产品，这就是需求管理的整个过程——捕获、表达、组织、追踪、评审、审批、变更和验证。
8月5日，CSDN管理频道与需求管理工具全球市场占有量最大的Telelogic共同举办了“探索需求——需求管理专家在线沙龙”活动。聊天活动一共邀请了来自Telelogic、赛柏科技、西门子、东方通、天融信等企业的10位嘉宾，共同探讨了如何对需求工作流进行管理。讨论中还结合了网上的需求管理调查，对调查结果进行了多方面的深入分析。以下是聊天记录的精华部分。
对需求工作流的认识
主持人：哪一句比较符合您的情况？（A）我认为需求不重要；（B）我知道需求重要，但不知道为什么重要；（C）我知道需求为什么重要，但不知道怎么去做；（D）我知道需求为什么重要，也知道怎么去做。CSDN的调查结果显示：一半以上的人“知道需求为什么重要，但不知道怎么去做”。
潘加宇：这个结果很正常。我们现在很多团队知道需求重要，也想改进，但实际上很多时候改进不了，就是因为不知道怎么去改进，不知道怎么去做。比如我们经常说一定要做好需求，各个团队都有这样的想法，很可能在整个工作量当中也安排了时间，实际上真正去做的时候，不知道怎么去做，去客户那里找谁、问什么问题、怎样做调查，这些技能都没有掌握，去了以后不知道怎么去做，结果就不了了之了。
很多开发人员，拿来需求都急于马上进入设计和实施阶段，因为这个阶段是他熟悉的，也是他会做的，做的时候很舒服。实际上，需求没有完全掌握、没有进行分析。虽然知道需求重要，但是不知道怎么去分析这些需求，最终做需求调研的时间很容易虚度掉，然后急急忙忙做开发和设计，最后不断的再返工。这是大多数开发团队的现状。
主持人：需求工作流占你的整个项目工作量的比例有多大？
林治宇：在天融信，需求工作一般占到项目工作的8％－10％。
Kristian Persson：8％－10％，应该说这是一个非常合理的数字，也是国际上大多数公司的数字。
李峻：如果采用了一些好的需求管理工具，需求的工作量还有压缩的可能性吗？如果有好的一些工具的话，能否再缩短工作量吗？
Kristian Persson：如果再压缩的话，可能会比较困难。我指的8％－10％并不是项目一开始需求阶段的工作，而是与整个项目相关的需求工作都包括在内。需求工作是贯穿项目始终的。管理不善的情况下，需求工作量可达到整个项目工作的40％－50％。
主持人：在CMM和CMMI当中，对需求部分的描述是怎样的？与CMM和CMMI相比，国内软件企业在需求流程方面的差距有多大？
于波：对于需求捕获，或者需求分析和需求开发，这种定义是在CMM 三级产品工程中的一个活动，包括分析、开发和验证客户的需求。而在CMMI里，把需求捕获称为需求开发，分为用户的需求、产品的需求、产品构件的需求以及产品接口之间的需求，需求之间还有相互关系的确认，跟设计和实现之间也需要一个反复循环的阶段来完成。
吴浩刚：现在国内公司做需求的方法和构成，与CMM的要求还是有差距的。很多公司没有把用户需求、产品需求区分开。一些公司做任务需求的时候，仅仅局限于外部需求，恰恰忘了更重要的内部需求。一个产品要达到高效益，还要考虑成本，而一些公司为了应付测试，在捕获需求的时候往往制造一些需求。维护方面的需求经常被忽略掉。等等，这些都是目前需求工作中存在的问题。
从混沌到素材，需求的启发
主持人：你们公司谁负责捕获需求？有专门的需求工程师？面向客户的市场部人员？还是负责设计和实现的人员同时也做需求？CSDN的调查显示：在约60％的企业里，负责产品设计和需求实现的人员同时也做需求。
青润：需要指出的是，负责设计和实现的人员同时做需求，并不是所有做编码的人都去捕获需求，而是有一部分人在一段时间做。负责编码的人同时做需求的确比较常见。
潘加宇：在做项目的公司里，单独设立需求工程师职位比较少。更多的情况是，部门经理带着骨干做需求调研，其他人做开发。做需求的人和做开发的人，两种是不同思维的人。做需求工作的人要有集成思维，能够把问题集成起来去思考；而做开发的人则要有分解思维，问题已经给出来了，要分解成对象，分解为模块，就可以搞定它。所以不让做产品设计的人去做需求或者需求调研，我认为这是非常有必要的，尤其是在对产品有更高的要求的情况下。
林治宇：是否设立需求工程师这个职位，与公司实力强没有直接关系，而是公司是否认识到需求对产品的重要性，才会设这个职位。
李峻：在西门子，真正负责捕获客户需求的工作主要由市场部人员去做，但并不是直接将这些需求转给开发部。我们有一个需求管理小组，隶属于研发中心，主要职责则相当于市场部和开发部的一个接口。需求工程师对从市场部那里获取的零散和庞大的需求文档进行整理和分类，然后提交给开发部。开发人员不需要和市场部争论哪些事情做得到还是做不到，而是由需求工程师来做，由需求工程师把需求一层一层进行分解，由需求工程师把客户没有任何技术背景的需求更详细分析出来，这样我们的开发人员就可以在纯技术领域下思考这个需求。需求管理小组的设立还是收到了很多成效。
于波：我想大家会达成共识：首先由市场人员捕获最原始的需求，这是用客户的语言、客户的业务和流程来做的。再有需求分析人员，把客户需求进行整理，细化为产品或者软件的需求，还要细化一些产品的构件以及具体构件的接口等一些潜在的需求。需求很难完全由做设计和编码的人来做，他们是很难站在项目整体的高度来考虑客户所有相关人员的需要、需求、期望以及对未来还会需要什么，这样也会对未来的需求变更带来一些潜在的影响。很多规范企业的需求捕获和分析，是由系统分析人员来完成的。
Kristian Persson：真正做需求的人，往往是会是那些与市场接触很多的人。因为他们与客户接触紧密，最了解客户心里想什么。由他们反馈给开发人员的需求，更加准确和直接。
Telelogic公司是一个中等规模的公司，我们产品线上的每一个产品，都设有一个产品经理，由他们来负责捕获和分析需求。产品经理虽然属于研发部门，但是他们会到市场去做调研，看需要什么产品，竞争情况怎样，然后与开发人员一起来分析这些捕获的信息，哪些需求有实现的必要性，哪些需求的实现优先级更高。
吴浩刚：需求有不同种类，不同的需求由不同的角色来捕获。用户需求有内部用户需求和外部用户需求，有明示的需求也有潜在的需求。市场人员一般捕获的是外部用户明示的需求，而对于那些潜在需求，必须要由有技术背景的人来捕获，这样才可以从产品架构的角度来细化需求，否则需求的实现工作就会变得很艰难。
殷志梅：我现在在东方通的职责就是产品经理，负责管理公司内部用户的需求。根据市场上一些相关软件和产品的功能，在公司内部收集一些需求意见。我个人技术方面的背景相对较强，与开发人员能够比较好的沟通，能够比较容易的把用户的需求意见转换为真正的产品需求。
主持人：你的“探索需求”的过程中，会经常使用哪些方法或技能？你认为哪种方式最有效？CSDN的调查结果显示：最常用的方法是“访谈”，其次还有“开会协商”、“文档研究”、“问卷调查”和“原型”。
潘加宇：访谈最常用，应该是很自然的。要做需求，就要提问，提问就要有访谈。当然访谈也有技能，比如找的人对不对，问问题的技巧对不对。问卷调查是访谈的一个补充，因为访谈往往是不全面的。访谈之前还要做文档研究，对于一些业务知识要有所了解。这几点是联系在一起的。
访谈做完以后，可能就会发现，不同涉众有不同的需求，也可能有利益冲突，比如营业部门希望越快越好，维修部希望越慢越好，发生冲突就要开会协商研究。这些方法都是紧密联系在一起的。比如原型，也是访谈当中要用到的。
此外还有研究竞争对手，尤其是对于做产品来说，研究竞争对手是首要的。市场上有一百种产品，都是可能满足客户要求的，但为什么要买你的呢？要从竞争对手的视角思考，才能找到自己的位置。比如Telelogic，他们有很多产品，除了需求管理工具DOORS之外，还有建模产品等，但为什么强调需求管理工具呢？因为这是Telelogic的强项，与竞争对手相比自己的优势所在。往往竞争中要突出一点长处，有特点，大家才能记住。
很多人经营公司非常盲目，不自觉地认为自己没有竞争对手。比如我一个朋友的公司做信息化服务的，我问他竞争对手是谁？他说没有竞争对手。我说为什么？他说这里已经垄断了，政府让我们做，别的地方不让做。我反问他如果没有竞争对手，那么你们的产品应该像身份证上的IC卡一样，人手一张。后来我帮他分析，他就逐渐认识到他们还是有竞争对手的。所以说，研究竞争对手非常重要。
青润：我从做工程软件的开发来谈，在需求捕获中，首先是访谈，借此收集用户的一些初始想法，绘制出用户的业务流程图，绘制完成后，要让用户做初次的确认。其次是研究用户的内部资料和文档，访谈的过程中要收集相关资料和文档，然后就研究用户的真实想法和需求，通过这些收集整理，就可以做出原型，无论是实用性原型、抛弃性原型还是演示性原型。原型之后，让用户可以更深入的明确他们的实际需要。下一步还是访谈，对前面的业务流程进行再次确认。原型之后需要开发出一个版本，就是客户基本可用的，但不是完全可用的版本，在用户使用的时候再继续访谈。问卷调查，做工程的很少用，发给谁呢？没有人接。不像做手机，西门子可以发给运营商或者任何使用手机的人，比如大街上遇到的任何人。而我们不一样，比如做电信的系统，几个运营商，发问卷调查，就几个，我给他们发完了，实际上得到的样本也就那么几个，没有什么实际意义。观察用的比较少，因为工程软件往往是在用户企业内部获取需求，然后进行收集、整理、分析研究后得到的。因为工程软件很少有同类的或者可以模仿的软件产品，这也就是国内软件厂商无法进行大规模批量生产而不得不各个定制开发的原因。从素材到文档，需求的定义
主持人：目前最常用哪种方式来表达从客户那里获取的需求？哪种需求的表达方式最有效？CSDN的调查显示，需求列表、业务流程图、用例，几种表达方式最常用。
青润：我通常的做法是：通过和用户的初步交流获取对该系统整体业务的了解，然后分活动通过业务流程图（状态/活动图）和客户做交流，获取大的需求列表，然后抽取其中的需要软件实现的环节整理成用例图，接着就进入后续的分析设计过程了。在项目之前我会得到一个小的需求列表，也是和用户沟通得到的，这小的需求列表是开发人员看的，让开发人员知道根据这个怎么做实现，应该说业务流程图、用例图和需求列表这三个是我经常用的。我书里面也是这样描述的，我这个人是做什么写什么，不做的就不敢写。
举一个例子吧，02年我在中国电信做过调研，我是先找集团的整体业务负责人，从相关部门获取，然后找相关人获取信息，在访谈过程中，我的方式是他说我画，我画的是目前业务操作过程，然后给他看，让他提意见，然后再作修改，直到他满意，访谈结束以后，我整理文档，因为当时中国电信要求出一份全国的工程建设规范文档，再过三四天之后，这期间的时间是访谈其他人，我会再找他一次，要知道往往一个人的想法和语言在一次访谈中可能会因为冲动或者某种偶然性而存在一些偏差，甚至对于同一个人访谈同一个流程会得到不同的结果，所以我一般会做两到三次的访谈。
潘加宇：业务流程图表达的并不是直接的需求，而是表达现实的情况，并没有说我这个软件要做什么，只是现在是怎么回事。所以说，单纯的业务流程图只能算是捕获需求的一种工具，并不能表达需求。但如果把所有功能和用例串起来变为业务流程图，从这个角度来看，业务流程图也可以表达需求。需求列表是最通用的表达需求的方式。使用用例组织需求也越来越多了，不管是正式还是非正式的。 从文档到实现，需求的管理
主持人：面对变化无常的需求，你的公司是否有一套完整的变更管理机制？
张皖秋：东方通在2001年通过了CMM二级，在需求管理上有一套管理机制。比如在变更方面，不论从哪个方面来的需求变更，都要提供变更请求，然后开发部门会对变更有一个评估，包括工作量的评估，最后才决定做还是不做。
以前东方通一直用手工的方式来做，比如用EXCEL表。今年使用Telelogic的DOORS工具以后，用户的每一次变更以及变更的状态都可以随时看到，这样能够比较好地把这些需求管理起来。对需求的管理首先要有一套机制，不管通过专家认可还是其他方式，需求在进入实施阶段前必须要有一个认可的过程，否则随意加进来的话，就会对你的项目造成灾难性的后果。要想让需求管理机制更加有效的发挥出它的作用，可以引入管理工具。
Kristian Persson：在Telelogic的情况是这样的：根据用户需求，产品开发经理要做系统的需求说明书，写完系统说明书后会建立链接到用户说明书里面去，然后进行判断，估计一下需要多少时间、多少资源来实现，以及开发工作量。经过讨论，大家达成协议的基础上，在大家同意的版本上定一个期限，然后产品经理和产品开发经理在这个期限上签字。Telelogic提供电子签名的功能，在DOORS里面进行电子签名，表达双方认可。如果将来有任何变化，以后做用户需求变更，可以根据系统的需求，双方再讨论，做互相的让步，再形成其他的版本。 主持人：需求的提出往往是很随意的，经常变化的。在应对这些变化的过程中，往往会因为客户的需求，需要我们对需求变更的实现采取严格、或半规范化、或较随意的不同的应对措施。有时客户的需求要求我们不能做到先决策再布置更改，不能很严格的按照变更机制来运作，变更来不及走流程，就要很快实现，这时，你是如何应付的？
张皖秋：我们的做法是每周都有一个报告，向客户汇报一周的实施情况。现实开发中存在很多这种情况，尤其是客户和开发商很熟的时候，客户说改就改了，实际上没有变更需求，开发就很随意的改掉了。尤其在现场开发的时候，经常客户打电话，一周之内不知道要打多少次电话，有可能要跑到现场了解情况，这些需求的交流和变更都很难记录和提交上去，然后走流程。在这种情况下实施的需求变更，一定要做好记录并在报告里得以体现。否则出现意见不一致的地方就会很麻烦。
青润：客户每一次提出要改，你要帮他分析清楚改了有什么后果。比如改了会增加成本、推延交付时间，这些能不能承受？如果能承受就改。帮助客户分析这个需求是否真的值得这样做，而不是客户说做就做，要分析他们真正的需求。 主持人：Telelogic的工具是否可以支持不同级别的变更、迎合客户随意的变更呢？
任群力：Telelogic工具DOORS可以帮助解决这个问题。DOORS建立链接的功能，把相关需求链接在一起，对需求进行多级分析来实现。对于需求变更，有一个内置的变更管理系统来控制。当某一项有变化的时候，DOORS会自动提出警告。
利用工具可以非常好展现出来为什么这种改变会很难实现，因为通过工具管理的链接，可以做一个多级的分析，可以看到你这种改变会涉及到哪些操作，会告诉他带来的后果，他会认真考虑所有这些引起的后果。 主持人：需求管理中很重要的一点就是需求的可跟踪性。请问DOORS在这方面的性能如何？
任群力：用DOORS做需求跟踪，有很好的投资回报率。这是一方面，另外，还有我们的很多客户是必须要用，因为必须要展现出来开发的产品符合政策的规定、规则或者标准，或者符合用户的标准。
实际上并不只有DOORS提供需求之间的跟踪，需求管理工具都提供可跟踪性。但是，DOORS这方面做得更好。从两方面来看，一方面就是易学易会，因为很多工程师在建立这种链接的时候，有的工具比较麻烦，而我们这种工具非常的简单，几乎没有额外的工作。另外DOORS提供了最强大的链接分析能力。 主持人：Telelogic需求管理工具在国外的很多行业都有广泛的应用，为什么他们会选择Telelogic的工具？比较其他需求管理工具，有何特点？适合在哪些企业用？
任群力：Telelogic在全球一直都是领先的，从历史来看，对需求管理的工具来讲，连续七年都是世界上排名第一位的，无论是在功能上面、理念上面还是市场占有率，连续七年排名世界第一。在很多方面创造了第一，比如第一个PC的版本，这是很多年以前的，第一个带电子签名的，第一个带变更系统的，连续很多年都是领先第一位，这是产品领先、技术领先，所以市场份额领先。我们客户广泛使用了以后，我们提供非常好的支持。
在技术支持方面，我们有很好的培训，首先我们不仅有工具本身的培训，还有需求管理理念，如何进行有效地需求管理，这是我们非常好的培训。用户在脱离工具的同时，在开始阶段就会想到需求管理理念的掌握非常重要。另外还有方法论培训，怎样写一个很好的需求，告诉你怎样一个需求才是一个好的需求，这样一系列的培训能够帮助客户快速地上手。除了这个以外，我们还有几天甚至五天以上的培训，我们叫PAW，包括和用户访谈的这段过程，通过几天的时间，帮助用户消化他的问题，把需求管理模型建立在客户现有的开发平台之上，然后教会用户在这个平台上，怎样做需求管理，可以让用户很快地上手，这也是我们成功的一大原因。 主持人：东方通作为DOORS工具的使用者，对这个工具的评价怎样？
殷志梅：DOORS一个好处就是时效性方面，我这边的需求都看得见，过去用EXCEL的话，我如果要告诉大家的话，要发Email，现在我哪个需求增加了，会告诉他们需求是第几条，非常的清楚，而且所有的变化，每个人都看得见，非常地清楚。另外还有链接，这个功能非常的好，因为需求是一个项目源头，包括设计，还有测试方案，都是同期来的。写测试方案的人不会像过去那样随意，会针对需求一条一条的写测试方案。还包括设计也是一样的，有设计流程图，每个类图都会非常的清楚。
张皖秋：还有一点就是我们做培训的时候，上手比较快，尤其从管理角度来说，我希望能看到整个变化，比如一月份需求是多少条，或者怎样的一个变化，还有我到了第二周又可以看到有没有变或者变得怎么样。另外，因为和设计方案或者用例有一个链接，可以看到用例需求测试的覆盖率。以前你可能用一般的EXCEL表也可以看到，但没有这样方便。另外时效性也很好。 寄语
青润：需求是软件工程之源，好的开始是成功的一半。
李峻：需求工程师这个职位是很有前途的。
林治宇：需求关系着项目和产品的成败，影响非常大。
吴浩刚：需求工程要专业化，就要加强需求技能，包括沟通技能、需求开发技能。
潘加宇：需求就是一种技能，大家认识到这一点就好。
于波：需求工程分为需求开发和需求管理，开发出来的需求是整个项目开发活动和管理活动的需求，好的需求活动贯穿全产品项目周期，进一步支持产品开发和管理。
Kristian Persson：用中国《孙子兵法》里面的一句话，要先胜而后求战，而不是先战而后求胜。
任群力：Telelogic公司在需求管理方面提供了很好的解决方案，希望能够帮助用户来掌握开发过程当中最关键的需求环节。
|
