聊天活动到场10位嘉宾，他们分别是（从左往右）：潘加宇（UMLChina）、殷志梅（东方通科技）、张皖秋（东方通科技）、Kristian Persson（Telelogic）、任群力（Telelogic）、于波（赛柏科技）、青润（丰元信）、李峻（西门子）、林治宇（天融信）、吴浩刚（天融信）。现场讨论气氛热烈。
嘉宾介绍
主持人：首先欢迎各位参加CSDN和Telelogic共同举办的需求管理在线沙龙活动，我们这次活动的主题是“探索需求”，活动分为三个环节，分别就需求的启发、需求的定义和需求的管理进行讨论，活动采用圆桌论坛和在线直播的方式，网友可以进入聊天室与现场互动，活动还邀请到了来自Telelogic、天融信、北京东方通科技有限公司、西门子等十位需求管理专家以及来自各行各业需求管理的工程师，下面有请各位嘉宾做一下自我介绍。
任群力：很荣幸今天来到CSDN来参加需求管理沙龙活动，也很高兴和业内的朋友见面。作为需求管理的领先方案的提供商，很愿意提供给客户解决方案。我是Telelogic的北方区负责人，负责Telelogic 中国公司在北方地区运作的所有事宜，包括人员规划、市场开发、销售和客户技术支持工作。希望有机会与大家交流，谢谢。
Kristian Persson：我叫Kristian Persson，中文名叫佩尔森，我在北京工作，是Telelogic需求管理DOORS的产品经理，主要是负责亚太地区，主要是东亚部分，比如韩国、日本、中国。我还负责Telelogic需求管理解决方案的教育、培训工作。在过去的6年中，我一直致力于软件行业从需求捕获、分析、设计、实现直到测试的软件生命周期所有阶段的工作，对系统和软件分析、设计和测试的多种过程、方法及工具有着一定的经验。
于波：大家好，我是于波，是北京赛柏科技公司高级咨询师，北京理工大学软件学院客座教授，今年年底或明年年初会成为赛柏科技CMMI准主任评估师。我们公司主要为中国软件和IT企业做软件工程CMMI参考项目的过程改进，负责CMM、CMMI等模型与标准、软件工程、质量管理和项目管理等方面的培训、咨询和评估工作，为中国软件在世界上的崛起贡献出我们的微薄之力。
白慧冬：我手上拿的这本书叫《需求工程》，和我写的那本书《软件工程之全程建模》的第一章名字也一样，也叫“需求工程”。需求是整个软件开发过程的源头，所以我把需求看得很重要。我目前是丰元信科技咨询公司首席顾问，主要面向国内软件企业提供工程开发方面的咨询服务。我还是CSDN软工版大版主，一个在不断摸索实践的国内软件工程方法和技术的亲历者。
李峻：大家好，我是李峻，我是代替我的同事——西门子智能手机研发中心需求管理经理黄谦来参加这次活动的。我是西门子手机研发中心硬件驱动部门、需求管理DOORS数据库的管理员，我也是我们研发中心软件流程管理项目组需求管理的其中一名Topic owner，负责相关的流程定义、文档模板等等。我们公司用了Telelogic公司的DOORS工具来做目前的需求管理。我们产品开发的管理，也在使用Telelogic公司的DOORS工具。很想和大家分享一下项目和管理中遇到的问题。
林治宇：大家好，我叫林治宇，来自北京天融信。天融信是一家做网络安全产品的公司。我是天融信公司CMMI过程改进和QA主管，主要负责CMMI的组织推广和策划工作，并曾组织多家企业实施并通过CMM2级、3级，CMMI2级评估。很高兴与大家交流，谢谢大家。
吴浩刚：大家好，我是天融信公司质量部经理，曾主持过多家企业的ISO9000/CMM/CMMI实施和评估。需求在产品开发阶段非常重要，今天有机会参加这样的活动感到非常的高兴，谢谢！
张皖秋：大家好，我叫张皖秋，来自于北京东方通科技有限公司，目前担任SEPG组长、SQA经理，主要负责软件质量的改进的工作。今天非常高兴参加这样的座谈会议，希望在这里跟大家交流和探讨，需求非常重要，以需求为驱动，使项目改进能够得到一个更好的提升。
殷志梅：大家好，我是北京东方通科技有限公司产品经理殷志梅，主要是负责使用Telelogic DOORS进行需求收集与整理、需求分析，参与产品的设计，跟踪需求的实现以及需求方案与测试之间的映射。我们公司采用Telelogic的DOORS工具来做需求管理。有些困惑，希望和大家进行交流。
潘加宇：我是UMLChina的潘加宇。一直从事一些软件技术难题的研究，也为不少软件企业提供过上门的咨询和培训服务，在座的西门子移动和北京东方通科技有限公司都是我们服务过的客户，希望今天在这里得到需求方面的宝贵经验。
你对需求工作是否重视？
主持人：谈到需求，我想了解一下大家对需求的态度是怎样的，所以现场做一个小的调查。我这里有一个调查问题：下面哪一句话比较符合您的情况，我按照A、B、C、D说一下，然后大家举一下手。A项，我认为需求不重要；B项，我知道需求重要，但不知道为什么重要；C项，我知道需求为什么重要，但不知道怎么去做；D项，我知道需求为什么重要，也知道怎么去做。我想知道大家选哪项。
看来大家选D项的比较多。
我们这个问题同样在网上做了调查，我们可以看一下网上调查的结果。选择“我知道需求为什么重要，但不知道怎么去做”，也就是选C项最多。大家可以就这个结果做一个大致的分析。
潘加宇：我觉得这很正常，知道需求为什么重要，他不知道也得知道，因为事实非常的简单，他要搞不定这个需求，将来客户那里马上就得返工，所以知道需求重要。
我们现在很多团队知道需要重要，也想改进，但实际上很多时候改进不了，就是因为不知道怎么去改进，不知道怎么去做。比如我们经常说一定要做好需求，各个团队都有这样的想法，很可能在整个工作量当中也为安排了时间，实际上真正去做的时候，不知道怎么去做，去客户那里找谁，问什么问题，怎样做调查，这些技能都没有掌握，去了以后不知道怎么去做，结果就不了了之了，干脆这个时间就去编代码。
为什么很多开发急于马上进入设计和熟悉的阶段，因为是他熟悉的，也是会做的。因为做熟的东西，做的时候很舒服。有些需求没有掌握，知道重要，不知道怎么做，最终做需求的时间很容易虚度掉，或者急急忙忙做开发和设计。所以，现状是非常的符合我们现在开发的情况。
需求工作流占你的整个项目工作量的比例有多大？
主持人：选择D项的也很多，就是“我知道需求，为什么重要，也知道怎么去做”。就像李峻所提到的一样，有很多人知道怎么去做，但做的情况下未必按照正确的方法做，所以选这一项也很多。但尽管选择这一项，在实际的需求工作当中，也会经常面临很多问题。我们下面进入第一个话题，需求是怎么来启发的，怎样来从你的客户那里获得需求？
主持人： 首先请问大家一个问题，各位在做需求工作的时候，你的需求工作流在你整个项目中所占的比例大概有多少？
林治宇：我举一下我们一个产品的例子，我们是根据市场行业和用户对手的信息总结的一些产品。我们最后统计了一个数字，需求工作占到我们项目的8％－10％。
Kristian Persson：刚才听到8％－10％的需求，应该说这是非常合理的数字，这是国际上大多数公司大概也是这样的数字，无论是做软件还是做什么的，都是这样的。
李峻：我想问一下Kristian Persson，还有压缩的可能性？如果有好的一些工具的话，能否再缩短工作量吗？
Kristian Persson：10％一般是比较正常的数字，如果再压缩的话，可能比较困难。我指的10％并不是一开始需求的阶段，而是与整个活动相关的需求都包括。有的项目需求花的时间更多，就是因为在有问题的时候，有时候不能确定需求，工作量达到了40％－50％。
李峻：我认为其实和客户的交流也很重要，在第一步需求搜集这一块。如果你的客户很清楚他自己的需求，可以缩短很多时间和工作量，达到大家一致需求的起点。
谁负责捕获需求？
主持人：我们再做一个调查：在各位的公司里，都是由谁来做捕获需求？A.有专门的需求工程师负责捕获需求。B.由面向客户的市场部人员；C.负责设计和实现的人员同时也做需求；D.没有人。
主持人：我们同时再看一下网上调查的情况，选择C项的占大多数，将近有60％。请大家分析一下产生这个现状的原因是什么？
白慧冬：对这个结果需要指出的是，负责设计和实现的人员同时做需求，并不是所有做编码的人都去捕获需求，而是有一部分人在一段时间做，而并不是全部的编码团队都去做捕获需求。所以会出现这个结果，负责编码的人同时做需求比较常见。
潘加宇：现在做项目的公司，单独设立需求工程师职位的，比较少。更多的情况是，部门经理带着骨干做调研需求，其他人做开发。对两种人的思维要求是不一样的。做需求的要有集成思维，把问题集成起来去思考；而程序员要有分解的思维，问题已经给出来了，要分解成对象，分解为模块，就可以搞定它。所以一个公司做设计的人专门做需求或者做调研，我认为这是非常有必要的。如果对产品有更高的要求，对自己软件有更高要求的话，这应该是一个比较好的方向。
于波：刚才白慧冬和潘加宇提到这个问题，跟目前国内软件业管理流程上还不算很规范是相关的，这个调查结果是很正常的。因为项目管理也不是做纯管理，需要有技术的背景，核心工程师和客户沟通需求，然后他们项目里面逐步把这些需求做实现。由于管理规范了，肯定会有一些专职人员，专门设了这样的职位以做需求为主。潘加宇说得也有道理，需求工程师需要在整体上把握客户的需求，无论产品也好还是功能开发也好，完全由做设计和编码的人来做，他们是很难站在项目整体的高度来考虑客户所有相关人员的需要、需求、期望以及对未来还要需要什么，这样也会对未来的需求变更带来一些潜在的影响。
林治宇：对刚才的60％这样的结果，我有一个看法：并不是公司实力特别强才有资源设立专门的需求工程师的人员，而是公司要认识到这个资源对产品的重要性，才会设这个职位。
主持人：做需求的人，都是离市场比较近一些，尤其是在产品型公司里，真正去捕获需求的人是做市场的人，是面向客户的市场人员来负责捕获需求。想借此问一下Telelogic，你们接触的客户，这种情况多吗？
Kristian Persson：这又是一个沟通的问题，各自干各自所擅长的事情，让编程的人集中精力做开发，真正做需求的人，往往是会做市场的人。因为他们与客户接触紧密，更加了解客户的需求。由他们反馈给开发人员的需求，更加准确和直接。
李峻：我们公司真正负责捕获客户需求的工作也是主要由市场部人员去做，但并不是直接将这些需求转给开发部。我们成立了一个需求管理小组，人员并不是很多，有一个需求管理负责人手下带了几个需求工程师，他们主要的职责，其实相当于市场部人员和开发人员的一个接口。市场部人员收集来的这些需求，基本上作为原材料提供给需求工程师。需求会从最终的用户、运营商当中得到，会有一个非常庞大的文档过来，但不会从技术方面做任何考虑，所以需要需求工程师对这些零散和庞大的需求进行整理和分类。
主持人：你们对需求管理小组的要求又是怎样的呢？小组成员都做哪些工作？
李峻：我们的工程师具有一定的技术背景，因为他们属于我们的研发中心，并不属于市场部门，是我们研发中心下面的一个组，和我们的市场管理人员接触更多一些。我们开发人员不需要和市场部争论哪些事情做得到还是做不到，而是由需求工程师来做，把需求一层一层进行分解，由需求工程师把客户没有任何技术背景的需求更详细分析出来，这样我们的开发人员就可以在纯技术领域下思考这个需求。我认为需求管理组在研发中心还是起到作用的，最初设立这个需求管理组，也是考虑到需求环节是研发中的一个弱项，之后才建立了需求管理组，现在收到了很多成效。
于波：我想大家会达成共识，首先由市场人员捕获最原始的需求，这是用客户的语言、客户的业务和流程来做的，内部还有需求分析人员，把客户需求进行整理，细化为产品或者软件的需求，还要细化一些产品的构件以及具体构件的接口等一些潜在的需求。原始需求由市场和客户人员做到，刚才Kristian Persson先生也提到了，因为和客户打交道最多，最了解客户心里想什么。
另外，对于需求工作，有两方面的说法，一是做需求开发，即前面说的是需求引导，还有需求管理，他们可能是一个角色来做，也可能不是一个角色来做。另外，除了前面市场人员外，很多规范企业会有专门系统分析人员，这些分析人员不一定是销售和市场人员。例如，电力行业人员，请电力行业非常了解的人来沟通最原始的需求，然后和公司里面负责产品需求的人来计划产品需求，一定要考虑企业的特点，刚才也提到企业投了什么样的资源来从事这个工作，是资深人员还是没有经验的人员，这要根据自己的情况来做，把几个方面的信息和相关人员结合在一起，大家进行沟通，然后再往下来做可能会好一些。
欧阳璟：刚才听各位发言，有一个共识，需求管理应该是单独抽出来做的。但有时会出现一个问题，现在大多数企业没有资源专门成立部门做这种单独的需求，这样就导致了市场人员、或编码人员、或设计人员来兼做需求。现在有一个问题，哪些角色更加适合来做这样的工作？
Kristian Persson：Telelogic公司是一个中等规模的公司，如果单独拿一个产品线来说，和一些中小型公司是类似的，我们每个产品都有一个产品经理，这个产品经理虽然属于研发部门，但是他们会到市场去做调研，看需要什么产品，看竞争情况是怎样的，然后把这些信息沟通完了以后，跟这些开发人员一起来商量，哪些需求有实现的必要性，哪些需求的实现更加重要。所以，产品经理这样的角色是比较适合的。
吴浩刚：一个需求做好的话，必须有一个角色完成，不同阶段要有不同的需求。比如从用户需求这个角度，有内部用户需求和外部用户需求，市场人员一般捕获的是用户明示的要求，如果是潜在要求的话，必须要用技术背景来捕获，否则需求的实现工作就会很难。
主持人：刚才提到我们在捕获需求的时候，一个很重要的角色就是产品经理，我想问一下殷志梅，你在东方通担任产品经理的角色，你的角色定位是不是也是捕获需求，把需求的一些相关的内容转达给开发人员呢？
殷志梅：我现在在东方通的职责就是管理需求，也就是公司内部的需求，根据市场上一些相关软件和产品的功能，在公司内部收集一些需求。这些需求，如果他们认为可以做就可以做，我们会进行讨论和评审，决定到底做不做。
李峻：市场部成员的技术背景都不强，所以必须有一个需求管理的团队来支持他们，更多偏向于市场部，由他们转过来的市场部信息，经过需求工程师的把关，再转给开发部门，否则，开发部门的人员就要抗议了。
殷志梅：我以前是做开发测试的，我个人技术方面的背景比较强，包括和开发人员沟通比较强一些，我很容易把他们的意思转换为我们的产品需求。尤其中国的市场，有时候忙于签单，用户说不需要这样需求，就立刻答应了，就逼着工程人员把这个需求实现了。
网友提问：“做需求的时候，在工作期间有没有淡季的说法呢？”
殷志梅：没有什么淡季，属于持续的过程。因为产品是一个版本一个版本在升级。
于波：技术在不断的升级，市场需求也在变化。本身软件市场的竞争强度很大，不可能停下来。
欧阳璟：针对产品做需求这块，这个版本做完了以后，相对一段时间会比较淡一点，或者这个版本做完以后做下个版本需求，那时候在做编码的时候，可能这边相对轻松一些。
Kristian Persson：如果在一个良好的需求管理流程过程当中，往往对需求管理都是很忙碌的，开发人员在目前管理的同时，也在看下一个版本，甚至到以后的几个版本。
殷志梅：一般是那个产品在编码，下个需求我们就在做，需求也会增加，没有什么淡季的说法，是一直持续的。
你的“探索需求”的过程中，会经常使用哪些方法或技能？
主持人：下面我要问一下大家，在捕获需求的时候，经常使用哪些方法和技术？我有几个选项：A.文档研究 B.问卷调查 C.访谈 D.观察 E.研究竞争对手 F.原型 G.开会与协商。
吴浩刚：在天融信，我们主要用到的方法是访谈，还有就是做原型，因为原型可以直接让客户看到产品大概是什么样的，访谈也很重要，因为尤其是对于做需求的公司来说，除了某些业务背景之外，客户交流这块也是有相当经验的。
李峻：我相信这些方法在西门子都用过，比如文档研究，会针对运营商的需求，沟通会比较多一些。每个运营商都会主动提供他们的需求文裆给我们，当然是格式不太一样，问卷调查也会有，比如提供统一的格式给他们做一些选项。研究竞争对手更是我们必须做的事情。原型也是这样，在开发的时候，不同阶段都会提供原型给经销商和开发商，咨询有没有改进的建议，我想这些方法在整个开发流程里，在不同阶段有它的重要性以及更大好处。
Kristian Persson：Telelogic有几种调研的方法，其中很重要的就是领导者委员会，比如我们做产品，用一百个用户形成一个团队，像这个大的用户每年都有一个活动叫在一起，然后共同谈论问题，需要什么新的功能在产品里面实现，他们也相互交流。第二，对于竞争对手分析也是要做的。第三，在技术支持过程当中，如果发现了问题，我们是需要解决然后再研究下一个版本。
另外，对于技术演变来说，比如有一个新的平台或者新的版本的话，我们这个版本也必须支持新的平台。在做产品的时候，在生命周期的时候，我和其他产品相互结合的部分要进行改进，要在新的产品实现。总的来说，刚才提到调研的几点，基本上每一点都涉及到不同的特色。我们也做产品原型，可能是对于一些特殊客户的定制，如果比较成功的话，自然而然也会对我们的产品更加的感兴趣。
殷志梅：可能和吴浩刚所说的调研方法比较相似，调研也有，原型也有，对于有些特殊需求的客户一般都用原型，我们会进行上门服务。技术支持也有一些，再有就是技术的演变会促进产品升级。
主持人：我们可以看一下网上调查的结果，了解一下现在大家做需求的时候都采用哪些技术，我们可以看到，选择访谈的人占的比例是最大的，其次是开会协商和文裆研究，原型也是不可忽视的环节。我想请问一下潘加宇，你对这个结果怎么分析呢？
潘加宇：访谈最多，应该是很自然的。要做需求，就要问你，你想要什么。当然访谈也有技能，比如找的人对不对，问问题的技巧对不对。如果往往找人找错了，比如做工厂系统内的，你就要访谈工人，不要访谈工厂主任。如果要做初中生的软件，你就找初中生进行访谈了。还有问卷调查也是这样，如果你不做问卷调查的话，得出的东西是不对的，访谈也是不全面的。另外，访谈之前要研究文裆，对于一些业务知识和业务要懂，这是联系在一起的。
访谈完了以后，可能不同涉众有不同的需求，也可能有利益冲突，比如营业部门希望越快越好，维修部希望越慢越好，发生冲突就要开会研究起来，但这都是紧密联系在一起的。像原型的话，也是访谈当中要用到的。还有就是竞争对手，尤其是现在做产品来说，研究竞争对手是首要的，已经不是访谈为中心了。从研究竞争对手出发的话，如果你研究的话，产品可能卖不出去了。市场上有一百种产品，都是满足客户的要求，但为什么要买你的呢？要从竞争对手想，才能找到自己的位置，所以这非常的重要。
像刚才Kristian Persson先生所说的，我觉得很有意思，这几次做活动的话往往是需求方面，其实有很多产品，有建模的产品等，但都是来做需求，为什么呢？因为这是强项，研究竞争对手的话，就要有一个结果，比如我就做DOORS，要鲜明突出出来，很多需求都是这样出来的。对于客户的要求，比如说TAU建模工具不好，是否就要研究在这方面呢？往往竞争是突出一个长处，有特点，给大家造成影响，所以这一点是研究竞争对手是非常重要的。
我们做产品的时候成功与失败，这方面是非常重要的。有时候很容易找错对手，有时候经营公司非常的盲目，不自觉的认为自己没有竞争对手，像今年二月份我去上海的时候，我有一个朋友做服务的公司，我问他竞争对手是谁？他说没有竞争对手。我说为什么？他说这里已经垄断了，政府让我们做，别的地方不让做。后来我跟他讲输入输出的问题，他就了解到原来还有竞争对手。如果现在做一个产品，东方通科技的竞争对手是谁呢？这应该要观察，本来有些人要买东方通科技产品，但没有买，我们就要知道竞争对手是谁呢？如果有这个需求，而没有买，去干什么呢？他去买防火墙和加密软件。有时候不买DOORS，而买其他的产品代替，我认为这都是竞争对手，这都是需要考虑的。
主持人：青润，你在你的那本书当中也谈到需求，是否可以谈一下你对需求捕获方法的认识？
白慧冬：需求就是要有捕获，没有捕获怎么会有后援的过程。在我那本书谈到需求，往往做需求的时候，尤其是做工程，我本人做工程比较多，产品反而做得比较少。我先说一下做工程软件，第一要做讨论，然后收集一些初始想法，第二要研究内部文档，你访谈的过程中要收集相关资料，然后就搞研究，搞研究的时候要出一些辅助的东西，那就是原型，原型之后，下一步还是访谈，原型之后出一个版本，就是客户基本可用的，但不是完全可用，在用户用的时候再技术访谈。问卷调查，做工程的很少用，发给谁呢？没有人接手，不像做手机，西门子运营公司可以发给别人，而我们不行。比如做电信，几个运营商，我发问卷调查，就几个，我给他们发完了，实际上得到的结果也就那样，没有什么意义。
观察方面比较少，因为工程软件往往是内部获得需求。当时我做的需求当时是电信内部提出的，本来要做ERP，后来由于宣布暂时停止，可以说生命周期得到的延长。
主持人：在CMM和CMMI当中，对需求部分的描述是怎样的？与CMM和CMMI相比，你所咨询的这些国内软件企业在需求流程方面的差距有多大？
于波：之前提到捕获需求的方法，提了自己的看法，工程也好，产品也好，首先方法上都讨论过了，CMM本身模型提得比较早，1993年提出来的，从1987年开始研究，当时软件工程发展到当时那个阶段，对于需求捕获，国内叫需求分析和需求开发，这种定义是在CMM三级产品工程里面一个活动，有分析、开发和客户验证的需求，就是一个活动。而CMMI就不一样了，因为行业在发展，技术在发展，方法在发展，模型也在发展，把需求捕获叫需求开发，这里面分得比较细，分为用户的需求、产品的需求、产品构件的需求以及产品接口之间的需求，以及需求之间还有相互关系上要确认，跟设计和实现之间也是一个反复循环的阶段来做的。
在国内来讲，如果要做了CMM和CMMI的话，严格来讲，和软件工程上流行的一些方法和做的规程，达到的要求基本能达到，我们在咨询的过程中，根据产品的形状以及项目的特点、应用领域以及客户的特点，来帮他选择定义并细化一些需求捕获过程中的规程和步骤，还有必要的重要的模板，每一层定义成什么样的，还有捕捉方法里面，比如产品以及工程，都会做过一些调查。如果没有做过的话，知道需求，但不是很清楚。另外就是时间的压力很大，成熟不成熟呢？规范不规范化呢？他敢不敢做下来认真看这个需求，以及怎样着手的话，他没有时间来做，就做编码，编码的话就陷入一个混乱的状态。
吴浩刚：现在国内公司做需求的方法和构成，CMM的要求还是有差距的。过去是用户需求、产品需求，很多公司都没有把它区分开。第二，一些公司做任务需求的时候，仅仅局限于外部需求，恰恰忘了内部的需求，一个产品要达到效益，还要考虑成本，在过去捕获需求的时候，为了测试，要制造一些需求。为了让成本降低，可能要做维护方面的需求。另外，在维护方面也要考虑需求方面。一个产品如果一开始考虑需求的时候，没有考虑批量生产的话，到了后期可能就会影响到项目当中。
李峻：这些我们都有用，但是根据整个流程的不同阶段来用，比如从市场过来的第一手的需求，是很简单的需求列表。如果到了需求工程师分布下来以后，分到产品的话，可能就用到用例来表示产品的需求，再到下一层，比如产品里的模块，模块会有更详细的图，甚至用Telelogic公司的DOORS工具来做一些分析。我们是根据不同的阶段来用的。
文章来源于领测软件测试网 https://www.ltesting.net/
