聊天活动到场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％这样的结果，我有一个看法：并不是公司实力特别强才有资源设立专门的需求工程师的人员，而是公司要认识到这个资源对产品的重要性，才会设这个职位。
文章来源于领测软件测试网 https://www.ltesting.net/
