CSDN需求管理沙龙聊天记录（三）如何管理需求

【登录】【免费注册】首 页新 闻社 区文 档Blog杂 志管 理Job培 训Java移 动游 戏产 品搜 索第二书店博文视点DonewsTelelogicVERITAS微软SUNIBMBizTalk书友会人邮365keyeMag 您的位置：CSDN 首页 -> 新闻频道 -> 正文 CSDN需求管理沙龙聊天记录（三）如何管理需求 2005.08.05 来自：CSDN管理频道 主持人：现在进入第三个话题，进入到需求的管理阶段，如何是管理需求的？刚才提到客户需求会很多，也会很随意，很乱，变化也会很快，请大家讲一下对这个问题是怎样管理变化需求？各位公司在开发的时候，对于需求变更的流程是怎样的？是怎样一个步骤？是否都有一个比较完整一套的变更机制？ 张皖秋：以前我们一直用手工的方式来做，今年为了提高我们在这方面的有效性，因为以前手工的方式的时效性，也就是你对变更的控制，比如用EXCL表，对变更状态的掌握的时效性不是很好。现在用Telelogic的DOORS工具以后，以后每一次变更可以随时通过各种方式看到变更的状态，这样能够比较好的把这些需求管起来。我认为首先要有机制，你怎么管它，不管通过什么方式，通过专家认可的方式还是什么方式，你要让它进入到产品来要有一个认可的过程，如果没有认可的过程，随意加进来的话，必定对你的项目造成灾难性。如果有一个好的机制，让它更有效，可以引用一些方式在你的工具当中。 张皖秋：如果要管得好，就像刚才前面所说到的用户有很多需求，用户有很多需求是因为不能掌控，不能控制它，所以会很多很乱。如果你建立到一套怎样管好机制的话，就不会觉得乱，因为一切都在你的掌控之中，所有东西都要加以控制。我们公司一般是自己建立了一套机制，2001年我们通过了CMM二级，在需求管理上有一套要求，比如在变更方面，不论从哪个方面来的，都会提供变更请求，项目开发这边会有一个评估，我增加一个需求或者变更一个需求会有工作量，包括对现有项目的一个评估，然后才决定我做还是不做，一般是这样一个控制机制。 于波：CMM在需求管理里面有三个活动，第一是实现需求的人，说得比较笼统，比如设计需求变为软件需求，他们要对总体需求有一个共同的理解。再一个，需求管理要基于需求进行项目管理工程活动的管理，工程活动也是刚才一样，需求细化、设计、编码、测试等等这些，都要和它结合在一起，以需求为源头。另外，需求不可能不变更，这是永远是一个事实，不管怎么做，前期再大的工程量，需求也是变更的，你怎样控制需求呢？刚才张皖秋说得比较多。 于波：CMMI模型收集以后变为五个方面来做，跟踪有工具，CMM也有工具，但比较笼统一些，手工的工具，比如EXCEL表，还有专门用于需求管理的各种需求。另外，前面需求和后面出来双向跟踪当中，CMMI进一步强调了，尤其是需求变更了，双向机制非常有帮助。刚才张皖秋已经谈到决定需求变与不变，靠什么？靠影响分析，会影响哪些功能，有哪些风险，新进来的功能能不能实现可测试等等方面，由谁来实现？成本是多少，进度上还要做承诺，能不能按照承诺要求，哪些方面由谁来做，这都要考虑，同样也跟模型周期有关系。另外，CMM更强调实现需求以及计划当中的不一致，如果需求通过开发环节，贯彻到产品项目当中，前面的需求、开发、引导做得再好，也没有实际的意义。这里强调跟踪性更清楚，而且更清楚强调要达成对需求的理解，而且要进行监控。 吴浩刚：对于CMM方面，对于需求分析之后，建立需求跟踪的机制。一般对于后期编码的设置要一一对应。另外，如果中间有一过程要修改需求，或者增加、删除，就要启动一套机制通过，是现在做还是以后做，通过以后我们根据要求进入需求变更的程序。还有就是在评审需求的时候还要评审需求识别，在这当中会影响什么产品的需求，否则也会删除一些产品的需求。 张皖秋：对于随意性的变更，只是教育客户，并不体现在随意性变更。 主持人：刚才各位提到自己有一套比较完整的管理需求变更的流程，但是客户在提出需求的时候，往往是非常随意的，这种随意的需求，有时候需要你很快作出决定，把这些需求才能够实施，你可能还没有来得及走这套流程，就要求你做实施了。这种情况下，你们是如何管理客户这种随意的变更呢？另外，在工具方面，能不能支持客户这种严格化的变更以及半规化的变更以及随意性的变更呢？ Kristian Persson：我们简单一下Telelogic是怎样处理这些问题，作为Telelogic的产品经理，是负责来写现在目前用户的版本，根据用户说明书，产品开发经理要做系统的需求说明书，写完系统说明书后会建立链接用户说明书里面去，然后进行判断，我估计一下需要多少时间，什么东西能实现，什么东西不能实现，要多少人力物力开发。经过这样工作讨论以后，大家在一个达成协议的基础上，在大家同意目前的版本上定一个期限，定完一个期限以后，产品经理和产品开发经理要在这个期限上签字，Telelogic提供电子签名的功能，在DOORS里面进行电子签名，表达双方认可。如果将来有任何变化，以后做用户需求变更，可以根据系统的需求，双方再讨论做互相的让步，再形成其他的版本。 潘加宇：如果改的话，还是没有通过流程变更。 张皖秋：如果是现场开发的话，如果改了，可能要和领导说一下改了会怎么样的，对整个进度没有什么影响，或者多加一个小时的班可以搞定就OK了。 潘加宇：现实开发存在很多这种情况，尤其是客户和开发商很熟的时候，客户说你改这么一点点，实际上没有变更的需求，很随意就改掉了。因为是举手之劳，我想这怎么应对呢？ 张皖秋：每周都有一个报告，你最开始没有问到那个地方，是一步一步深入，到那个点上肯定会有各方面的报告，可以看出那个状况。尤其在现场开发的时候，经常打电话，一周之内不知道要打多少次电话，有可能要跑到现场了解情况，就像你刚才所说的，包括你去问用户的情况，也会要问领导层，而且你不能随意添加什么东西，你添加了以后，至少最低限度的就是要做记录，或者你在报告里要体现出来增加了什么东西。 白慧冬：我后来和电信集团混得很熟了，他们给我们提出需求，我说你这个东西加多少钱会影响什么东西，时间上能不能承受？如果时间能承受就改，如果时间不能承受将来再改。另外我进入了很大一部分文档，我说如果改得不满意，我就拿文档让他看，一看，30多页。 张皖秋：尤其国内用户对待国内的开发商，更是这样子，国外开发商说要增加一个需求，增加十万、二十万，他就乖乖的掏，而对国内开发商就说NO，你不做，有别人做，你要慢慢的培养你的用户，让他接受是很难，如果你不做，是永远做不到这一点。 于波：我们和客户之间是什么关系？是双盈吗？需求管理当中不是需求开发必要的，但是为了更好的把承诺的需求实现了，这是一个保证。白先生说会记录下来，管理当中要有一个变更请求，看实施还是不实施。但是从另外一个角度考虑为什么提出这个变更，为什么早期的时候没有分析这个需求后期会有变化。另外一个，需求给你变了，你不给我加钱，可能晚交货，或者另外一个功能切换了一下，这个功能上，另外一个功能就要晚一些。我们要让客户理解我们工作的特点，如果不这样管理就不会有好的产品管理和质量，只有把这些记录记录下来，才能把所有修改的需求体现到产品里面去。 主持人：我还是同意张皖秋老师的观点，可能教育这个词是打一个引号的。因为我原来印象中跟潘加宇办过一次活动，是邀请国外一位在需求方面非常有名的专家，当时也有提问，如果客户不断提出随意需求的话，你怎么去做？当时这位专家建议就是要告诉他，如果我给你改的话，你要为此付出代价，如果你这样做的话，会怎么怎么样，把后果告诉他，你还会不会选择这样去做，你帮助客户分析这个需求，是否真的值得这样做，而不是客户来了就去做，要分析真正的需求。 张皖秋：必须有记载，上次你提了10个，我改了7个，你没有记录，就没有办法跟别用户交流，我认为这是起码的东西。 Kristian Persson：在Telelogic当中有工具来满足这种现状，可以建立链接的功能，可以把相关需求链接在一起，对于变更可以进行多级分析来实现，而且在变更过程，有一个变更的管理系统可以管理变更的过程。当某一项有变化的时候，Telelogic工具有警告的系统。 主持人：我想问一下，Telelogic的工具方面有没有这种功能可以迎合随意的需求和变更呢？ Kristian Persson：利用工具可以非常好展现出来为什么这种改变会很难实现，因为通过工具管理的链接，可以做一个多级的分析，可以看到你这种改变会涉及到哪些操作，会告诉他带来的后果，他会认真考虑为什么会带来更多的后果。 主持人：我们遇到需求泛滥的情况下，来自不同渠道、不同声音，很多需求一块儿汇总到你这边来，这种情况下你是如何来做的呢？有没有漏掉的需求，客户反馈来找你，怎样提高管理需求的效率呢？ 于波：这要看企业方向的能力。如果你需求不明确，这种变更很麻烦的。我们国内是客户是上帝，尤其是在现场开发的时候，这是很危险的。如果一时提出很多需求的话，综合需求也是很重要的，对于管理来讲，也不是完全拒绝封闭的。 主持人：有网友问到，如何可以有效的将需求变更控制在一个合理的范围内呢？ 殷志梅：我认为毕竟是一个工具，如果是一个工具并不能阻挡，我认为最主要是机制，如果你想增加工具的话，根本就阻挡不了这种需求。 主持人：是否这跟你们产品需求做得很到位的原因呢？ 吴浩刚：做产品开发的时候，提出的需求比较少，但也有需求提出来，我们首先是要审批这个需求值不值得我们现在做，有可能我们会选择当场做，但也要根据流程做，也会选择一段形成的需求以后再整体的做。 于波：需求管理的时候，谁来做兼职的决策，比如由产品角色管理，有需求变更没有问题，产品的需求，最终用户会反映需求，还有内部和外部的，在实现上也会提出来有问题，对于这些需求谁来分析处理，这是一方面。另外，在开发的时候，分析前期、早期以及调研当中，在开发的时候，有些决策你没有符合到他的需求，这个原因要从哪方面来看？在配置方面，如果要改，可能也会出现其他的情况。 殷志梅：需求有时候看感觉会很多，我们公司做产品，实际上有很多需求是因为用户不会很用这个产品，很多需求实际上可以使用电话询问完成，其实有很多产品的功能，用户用得不熟，我们可以帮助用户来分析需求，看用户需求到底是怎样的。就我的经验来讲，我们公司很多用户的需求，就是因为根本不会用这个产品，也许是我们的培训不到位。我们当时用DOORS工具的时候，他说没有这个功能呀，当时也没有教我们用，其实这个功能已经具备了。 吴浩刚：我们也有一些工具来帮助管理，现在用EXCEL来管理需求。 欧阳璟：比如没有购买商业软件的话，怎样去测算需求变更？ 吴浩刚：有一定关系，我觉得跟产品开发也有关系。 张皖秋：如果用敏捷的话，定项目的话，那种情况比较合适。而他们相对比较稳定，用敏捷的话，对公司整个产品线上都没有什么好处的。 欧阳璟：有没有考虑过用一些像敏捷这样的软件把它定死呢？ 任群力：Telelogic在全球一直都是领先的，从历史来看，对需求管理的工具来讲，是连续七年都是世界上排名第一位的，无论是在功能上面、理念上面还是市场占有率，连续七年排名世界第一。在很多方面创造了第一，比如第一个PC的版本，这是很多年以前的，第一个带电子签名的，第一个带变更系统的，连续很多年都是在领先第一位，这也是产品领先、技术领先，所以市场份额领先，我们客户广泛用了以后，我们提供非常好的支持。 主持人：在国内碰到过天融信这样的情况，有很多公司没有采用Telelogic的工具，我想问一下Telelogic工具与其他工具相比有什么特点？适合在哪些企业用。 任群力：在提供技术方面，我们有很好的培训，首先我们不仅有工具本身的培训，还有需求管理，如何进行有效需求管理，这是我们非常好的一个培训。用户在脱离工具的同时，在开始阶段就会想到培训理念的掌握非常重要。另外还有一种方法论就是怎样写一个很好的需求，告诉你怎样一个需求是一个好的需求，这样一系列的培训能够帮助我们快速的上手。除了这个以外，我们还有几天甚至五天以上的培训，我们叫PAW，包括和用户访谈的这段过程，通过几天的时间，帮助用户消化他的问题，把模型建立在多少平台之上，然后教会用户在这个需求上怎样做，可以让用户很快的上手，这也是我们成功的一大原因。 主持人：从Telelogic角度来讲会有一点点自喜。我想听听用户方面对Telelogic工具提出有什么改进的意见？ 任群力：另外，今天各位手里拿到一本书叫《需求工程》，这是我们公司一位同事写的，他是一名工程师，他在需求管理方面的理论也有很多贡献。前一段时间他来过北京做演讲，非常的受欢迎，这也就是为什么Telelogic能够在市场上做得这么大，而且一直处于领先位置。 跟其他工具比较的话，实际上也就是我刚才说的那些长项，也就是我们之所以做得这么好的原因。刚才讲到有没有特殊功能？从一个功能来说的话，太多了，不适合一点点的交流。 任群力：还有刚才提到领导者委员会，我们经常做一些交流，我们还有用户大会，用户可以分享心得，他们给我们提出很好的建议，认为工具当中有哪些地方有缺陷来进行改正和改进，针对目前市场的趋势来讲，应该怎么做。下一步阶段就是电子版本，针对顶头的客户，这种技术会带动第一层的客户，我们一直在当中保持领先性。 殷志梅：一个好处就是时效性方面，我这边的需求都看得见，过去用EXCL的话，我如果要告诉大家的话，要发E－mail，现在我哪个需求增加了，会告诉他们需求是第几条，非常的清楚，而且所有的变化，每个人都看得见，非常的清楚。另外还有一个链接，这个功能非常的好，因为需求是一个项目源头，包括设计，还有测试方案，都是同期来的。写测试方案的人不会像过去那样随意，针对需求一条一条的写测试方案。还包括设计也是一样的，有设计流程图，每个类图都会非常的清楚。 主持人：你利用Telelogic工具的主要原因是什么呢？ 林治宇：我知道Telelogic这个工具，但是细节不是很了解。 主持人：林治宇，你们公司也使用了Telelogic这个工具，你们具体了解吗？ 张皖秋：还有一点就是我们做培训的时候，上手比较快，尤其从管理角度来说，我希望能看到整个变化，比如一月份需求是多少条，或者怎样的一个变化，还有我到了第二周又可以看到有没有变或者怎么样。另外，因为和设计方案或者用例有一个链接，可以看到用例需求测试的覆盖率。以前你可能有一般的EXCL表也可以看到，但没有这样方便。另外时效性也很好。 Kristian Persson：还有一点就是刚才大家提到的有效性，用Telelogic的需求跟踪，更增加投资回报率，这是一方面的考虑。还有就是我们很多客户是不得不用，因为必须要展现出来开发一种产品符合政策的规定、规则或者标准，或者符合用户的标准，这是在DOORS工具根据管理方式得到有效性，所以客户不得不用。 Kristian Persson：实际上Telelogic提供的需求跟踪并不是我们独家的产品，实际上管理工具都提供跟踪性。但是我们看到在跟踪性方面，Telelogic提供得更有优势。从两方面来看，一方面就是非常易会，因为很多工程师在建立这种链接的时候，有的工具比较麻烦，而我们这种工具非常的简单，几乎没有额外的工作。另外在DOORS方面提供最强的，也就是在跟踪方面能够更好的和客户进行建立链接分析，有很多分析方法，但是我们认为这种链接方法是最好的。 主持人：我所了解的DOORS有一个很强的工具是需求跟踪这方面，是这样的吗？ 林治宇：因为可以提高更大的效率。刚才也说了我们的需求变更不多，用EXCEL做跟踪效果不是很好，我们主要是注重效率。 主持人：其实真正是要靠整个机制来提高效率。还有一个问题，想问一下你们在咨询当中接触这么多客户当中，你认为他们的需求管理过程中存在最大的问题是什么？你们又是给他们提供一些解决的方法呢？ 潘加宇：我一年到头跑来跑去，到现在已经有80家软件组织，像西门子、东方通我都去过了，而且去西门子已经不止一次去了，有些是深入的指导，有些是浅入的。对于面向对象的时候，我们做的话都是做项目公司，很多都是短期行为的，面向对象的时候，大概都是有点长期的行为，做产品的时候可能会考虑下一个版本的拓展。但是做项目的时候不用考虑这些，我现在给你做到了，里面结构乱了也不要紧，如果下面还改的话，下面再谈。从我的经历来看，改变需求，往往是团队非常乐意做的，而且也是非常容易见效果的。 于波：因为我们是做企业管理咨询的，首先要帮助企业为什么需要来做管理咨询，比如你现在的状态是什么，在管理上会不会有问题，会不会造成人为的一些质量、进度方面的情况，是不规范造成的。我们会按照国际上的一些最典型的方法，通过最佳的实践来培训，对他们自身存在的问题，比如我们会进行前期分析，我们分析现在存在的问题是什么，以及怎样帮助他建立机制或者流程，从而避免这样的问题。建立机制的过程当中，又包括帮助他选择一些规范，选择一些工具，工具包括比较简单的EXCL表以及专门销售商的工具，在这当中我们会根据企业自身的特点根据企业的经验和问题进行评介，以及在实践结果进一步改变流程，怎样更有效的利用合理工具，解决他们的问题，使工具加流程更加有效。 潘加宇：但要让团队知道需求是一种技能，里面包含很多种技能，像刚才说的合成技能，业务流程要寻找改进点，这是非常复杂的，业务流程只有一个，业务流程就这样，你说需求会怎么提，有很多种提法，你要研究简要的目标得出恰当的需求，用例也可以提出很多需求方案，但只有一个是最适合的，这是要研究透的，所以这里面有很多技能，包括管理的技能，把需求从哪里来到哪里去，以及变更呀，我们选需求也是有学问的，知道这一点就好办了。就像围棋一样的，最开始业余的时候就是死活，看能赢多少，一开始看后面死活就不行，就讲究别的东西，大概跟这是一样的。 主持人：其实刚才大家给了我们很多建议，按照我们的惯例，请在座的各位对做需求的工程师说一句话作为寄语。 白慧冬：我做工程比较多，实际上做项目和技术方面来讲，需求最难做的就是如何对需求做区分，说得再白一点就是哪些需求是现在要做的，哪些需求是将来要做的，哪些需求是不可以做的，这都要区分出来。 李峻：我觉得需求工程师这个职位应该是很有前途的，比如我们这么大的开发公司，这个名称在我们公司是刚刚加进入的，原来根本没有这个职位，现在在招聘网上叫需求工程师这个名称，如果大家对这个感兴趣，认识到它的重要性的话，应该是很有前途的。 林治宇：需求对项目成败有直接的影响，我们有直接的经验和教训。另外，对于跟踪需求如果价格很合理的话，我愿意考虑。 吴浩刚：需求公司会比软件公司的发展潜力会更好。需求公司如果做专业的话，一定要加强自己的技能，包括沟通方面，还要加强自己需求开发的方法，从而把需求做得更好。因为需求直接关系到一个产品的成败，影响非常的大。 潘加宇：需求就是一种技能，大家认识到这一点就行了 于波：需求工程分为需求开发和需求管理，开发出来的需求是整个项目开发活动和管理活动的需求，好的需求活动贯穿全产品项目周期，进一步支持产品开发和管理。 白慧冬：需求是软件工程资源，好的开始是成功的一半。 于波：需求工程分为需求开发和需求管理，开发出来的需求是整个项目开发活动和管理活动的需求，好的需求活动贯穿全产品项目周期，进一步支持产品开发和管理。 Kristian Persson：我想用需求管理大师在一本书上写到的一句话，也就是中国《孙子兵法》里面的一句话，原文我也记不太清楚了，大概是要知胜而后战，而不是战而求胜，而是要知道你能胜才战，意思是说你要知道你做的事是什么，然后再去做。 任群力：Telelogic公司，大家都知道，在需求管理方面提供了很好解决方案，我们到这来，并不是来卖东西，你可以考虑形式上是卖东西，实际上是帮助在座的或者帮助用户来掌握或者开发过程当中最关键的一部分需求。 主持人：今天的活动就到此结束。 从技术到管理，从优秀到卓越！CSDN管理频道，实现你的卓越梦想！ 声明：CSDN 登载此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述 相关文章 CSDN需求管理沙龙聊天记录（二）如何表达需求 　　(2005.08.05) CSDN需求管理沙龙聊天记录（一）如何捕获需求　　(2005.08.05) 需求获取过程中的逆向沟通　　(2005.07.20) 软件需求调研中的5W+1H定律　　(2005.06.28) -------------------------------------------------------------------------------- 新浪诚聘搜索引擎、测试、Java、PHP开发工程师 软件所培训软件测试、Oracle 泛微协同OA免费下载！ 搜索 热点文章 java的事件处理 Adventures in Encapsulation Part IV @ JDJ Workshop控件和扩展：第一部分——编写扩展 Real-Time Applications with Java and CORBA @ JDJ 存取程序状态的几种方法--Java I/O应用杂谈 From Writing Programs to Creating Compilers Multithreaded Tests with JUnit Generics: Reflecting on Cast-less Reflection Exclusive JavaOne Interview...with James Gosling @ JDJ 技术原型法：软件技术难点不等于软件目标--从技术交流看软件实现思路 最新更新 编写一个Web service客户端 不断扩大的Eclipse生态系统 利用HSQLDB 进行Hibernate单元测试 Diablo照亮了共享服务的未来 在现有系统上实现 SOA 克服类加载器混乱 无风险部署的最佳实践 利用Jakarta Commons Lang简化Java 企业平台中的业务规则引擎 新一代Java技术即将出现 关键字 技术关键字 XML(2067) J2EE(1598) JSP(1423) test(1409) 数据库(1285) 产品关键字 WebLogic(745) IDEA(700) Tomcat(508) WebSphere(460) Struts(457) 最新招聘信息 AV软件工程师 (20) Customer Service Prime/Loadbuild Contributor (5) Kernel and driver development Engineer（FM02） (6) Test Engineer（职位编号：FI02） (5) C++ Development Engineer（职位编号：FI07） (10) 平台架构师 (1) Development Engineer in Eclipse plug-in unit（F01 (5) Tech Support Engineer（职位编号：FB01） (6) CSDL Test Engineer（职位编号：FI03） (6) Java software tool development Engineer（FM05） (6) 更多职位... -------------------------------------------------------------------------------- 网站简介－广告服务－网站地图－帮助信息－联系方式－English 北京百联美达美数码科技有限公司 版权所有 京 ICP 证 020026 号 © 2000-04, CSDN.NET, All Rights Reserved --------------------------------------------------------------------------------