《新产品开发项目中的需求管理问题》由会员分享，可在线阅读，更多相关《新产品开发项目中的需求管理问题（4页珍藏版）》请在金锄头文库上搜索。
1、 新产品开发项目中的需求管理问题软件需求在软件项目中扮演着及其重要的角色.不管哪种类型的项目,无论是新产品开发,还是外包项目,开发队伍都面临着普遍存在的需求问题,比如如何获取有效的需求,如何处理需求的变更等等.这些问题有其共性的一面,也有和项目类型相关的一面.本文着重讨论了在新产品开发项目中的一些需求问题,以及避免和解决这些问题的建议. 一.概述 在开始进一步讨论之前,我们先明确几个概念. 首先,本文是从开发团队,或者说项目组的角度来看需求问题.所谓开发团队,通常包括了程序员,测试员和其他一些项目成员,如配置管理员和软件架构师,以及基层的管理人员,比如项目经理.类比于传统企业,开发团队相当于企
2、业的生产车间.但是,在大多数的软件组织中,开发团队除了担当生产任务以外,往往也是需求获取的主体;在某些较为正规的组织中,也许会有市场部门给出一些需求,但这些市场数据和有限的调研结果通常是远远不够形成需求规格书的. 其次,何谓新产品开发项目.简单而言,在本文中,新产品开发指开发团队需要从无到有将一个想法(idea)转化为产品(product).新产品开发不同于产品升级,开发团队没有一个已存在的基础;新产品开发不同于开发一个实验型的作品或者演示,原型之类的东西,开发团队最终的产出必须是产品,在功能,性能,可用性等方面都有比较高的要求和期望;新产品开发不同于承接一个软件开发项目,也不同于为明确指定的
3、用户或者客户定制产品,开发团队最终面对的是广泛的市场,是一个由众多独立的最终用户(同时也是客户)组成的群体.新产品开发项目更加不同于维护型的,或者其他类型的项目. 第三,本文所讨论的需求基于需求的传统定义,即软件需求指用户对软件产品明确的和期望的要求.这些要求直接影响了用户对此产品的满意程度,或者更直接的说,影响了用户的购买决定以及对产品和开发商喜好的判断.对于开发团队而言,在实际工作中,需求问题往往和设计问题,特别是高层(Highlevel)的设计纠缠在一起,很难有明确的界限划分.但在本文中,需求问题不涉及与具体实现相关的问题,比如技术选型,人机界面. 概括而言,在一个新产品开发项目中,开发
4、团队面临的需求问题涉及到需求的获取,分析和管理.本文的余下部分将重点讨论新产品开发项目中典型的四大问题,分别是:有限的需求来源,模糊的需求界定,CPD陷阱和NV陷阱. 二.有限的需求来源 新产品的想法可能来自老板的拍脑袋,也可能来自市场部的报告,或者也可能来自研究部门的某个创意;但不管怎样,可以肯定的是,没有人具备足够的信息来准确的描绘出未来的产品(而且通常这个未来也不会很远)是什么样子.如果项目组成员恰好属于这新产品开发项目中的需求问题个产品的用户,比如这个产品是一个字处理软件,或者仅仅是搭上一点关系,比如这个产品是一个个人理财软件,那获取需求的任务就更加理所当然的落在了开发团队身上.表面上
5、看,由开发团队自己定义需求会使得需求相对稳定,对开发团队是有利的.但事实上,开发团队会面临不少棘手的问题,最直接最明显的,就是需求的来源受限.开发团队最需要的就是明确的(最好也是稳定的)需求,而现在,要开发团队自己去获得,而且获取需求的来源又很有限. 由于是新产品,在组织内部,开发团队通常找不到足够的帮助.而要从外界获得,又受到时间,经费和职责等因素的限制.在这种情况下,学习竞争对手的产品是一个很有效的方法.开发团队可以从研究和剖析类似产品着手,例如,如果要开发一个电子邮件客户端软件,那么,Outlook和Foxmail就是很好的学习对象.亲身的去使用和体验这些软件,仔细阅读它们的用户手册,在
6、线帮助,甚至联系它们的客户服务.而且,这项工作应该让整个团队一起参与,增强每个团队成员对产品的理解和感性认识,当然,参与的程度和时机可以有所不同. 面对有限的需求来源,引入资深用户是另一个解决方法.所谓资深用户,他们可能很熟悉同类产品的使用,或者了解用户通常需要些什么.比如开发个人理财软件,那么一个理财顾问,或者一个理财高手就是很合适的资深用户.对于面向群体用户的产品,特别是那些大众消费类软件,这些资深用户事实上并不如想象中那么难获得.个人关系是主要的获取途径.为了减少个人偏好的影响,应该尽可能多引入几个资深用户.对于某些产品,比如前面提到的电子邮件客户端软件,似乎团队成员中就可以找到资深用户
7、.但在团队内部发展资深用户并不值得鼓励.其中的原因在CPD陷阱一节中会解释. 三.模糊的需求界定 在一个新产品开发项目中,某项需求是否需要,它的优先级如何,某项功能或者要求究竟如何表述,这些界定问题由于没有一个确定的用户或者客户说要还是不要,好还是不好,急还是不急而会变得模糊不清.这种模糊的需求界定也发生在开发团队内部.每一个成员都可以声称用户要这个功能,或者用户根本不可能那样操作.需求的界定常常成为公说公有理,婆说婆有理的争论.在现实世界里,开发团队往往处于一个尴尬的境地.他们通常被认为有义务制定出需求规格,并对此负责,却没有被赋予对需求规格最后拍板的权力.在这种情况下,开发团队以及开发团队
8、的领导要明确自身的立场,并将相关的责权利落实到纸面上.在技术层面上,解决模糊的需求界定问题的一个方法就是采用原型.利用原型来讨论,利用原型来证明观点,这比空对空的争论要有效得多.拓展出去讲,在界定需求的时候,尽量用事实和数据来支持观点,避免可能怎样怎样的猜想,如果不能肯定,就落实到概率上,这样可以通过风险分析的技术手段来帮助决策. 四.CPD陷阱 CPD是PMT的一个词汇,意即无谓的创造-追求完美-自我否定.团队成员过多涉足需求的开发(比如在前文提到的让团队成员充当资深用户)很容易导致团队陷入CPD陷阱.新产品开发项目中的需求问题即使可能存在进度上的压力,项目的初始阶段也几乎总是一段美好的时光
9、.进入一个新鲜而陌生的领域,团队的每个人都容易发现一片崭新的世界,每个人都能够为新产品添加一系列激动人心的特性.但这些特性是否合适,是否有必要却往往被激动淹没了.追求完美是计算机技术人员一个很普遍的特征,这一特征会促使这些无谓的创造继续下去,直到大家觉得这个产品做得再好也不过如此,于是,自我否定就会接踵而来. 为了防止陷入CPD陷阱,开发团队只需要个别人参与新产品的需求开发,而其他人则可以以已开发的需求作为进一步讨论的基础.这或许限制了团队的创造性,但却是更高效率的.产品开发不同于研究.产品开发更多的是需要一种收敛,从想法到产品的收敛.如果你发现这种做法埋没了团队中太多富有创造精神的成员,但你
10、要检讨团队的成员结构,或者你现在的团队适合研究而非产品开发. 五.NV陷阱 NV是PMT的另一个词汇,意即下一版本.在功能性需求上,CPD陷阱是常见的.而对于非功能性需求,比如产品性能上,NV陷阱是很容易陷入的.陷入NV陷阱后,往往到时候产品的质量会大打折扣,甚至拿不出手.另外,不完整的需求也容易导致错误的设计,这种架构上的缺陷实际上很难在下一版本轻易的改变.除了主观上对非功能性需求的不重视,陷入NV陷阱的原因常常还有迫于时间压力,或者毫无来由的乐观.开发人员常常认为他们在以后的同样长的时间里可以完成多得多的事情,而且这些事情通常是现在不大愿意做的事情.这个版本的确不够稳定,下个版本再说吧,这
11、是经常可以听到的说法.为了防止陷入NV陷阱,非功能性需求从一开始就要被提出来,并受到应有的重视.如果这些非功能性需求是确实需要的,就应该被写入需求规格书,并在产品开发过程中接受实现状况的检查. 有限的需求来源,模糊的需求界定,CPD陷阱和NV陷阱是新产品开发项目中常见的四大问题.除此以外,新产品开发项目中也存在其他的一些特殊问题,比如在需求的跟踪管理上,新产品开发项目就与其他类型的项目有不同的地方.PMT将继续这方面的研究和实践,并期待和广大读者的交流. 出师表两汉：诸葛亮先帝创业未半而中道崩殂，今天下三分，益州疲弊，此诚危急存亡之秋也。然侍卫之臣不懈于内，忠志之士忘身于外者，盖追先帝之殊遇，
12、欲报之于陛下也。诚宜开张圣听，以光先帝遗德，恢弘志士之气，不宜妄自菲薄，引喻失义，以塞忠谏之路也。宫中府中，俱为一体；陟罚臧否，不宜异同。若有作奸犯科及为忠善者，宜付有司论其刑赏，以昭陛下平明之理；不宜偏私，使内外异法也。侍中、侍郎郭攸之、费祎、董允等，此皆良实，志虑忠纯，是以先帝简拔以遗陛下：愚以为宫中之事，事无大小，悉以咨之，然后施行，必能裨补阙漏，有所广益。将军向宠，性行淑均，晓畅军事，试用于昔日，先帝称之曰“能”，是以众议举宠为督：愚以为营中之事，悉以咨之，必能使行阵和睦，优劣得所。 亲贤臣，远小人，此先汉所以兴隆也；亲小人，远贤臣，此后汉所以倾颓也。先帝在时，每与臣论此事，未尝不叹息
13、痛恨于桓、灵也。侍中、尚书、长史、参军，此悉贞良死节之臣，愿陛下亲之、信之，则汉室之隆，可计日而待也。臣本布衣，躬耕于南阳，苟全性命于乱世，不求闻达于诸侯。先帝不以臣卑鄙，猥自枉屈，三顾臣于草庐之中，咨臣以当世之事，由是感激，遂许先帝以驱驰。后值倾覆，受任于败军之际，奉命于危难之间，尔来二十有一年矣。先帝知臣谨慎，故临崩寄臣以大事也。受命以来，夙夜忧叹，恐托付不效，以伤先帝之明；故五月渡泸，深入不毛。今南方已定，兵甲已足，当奖率三军，北定中原，庶竭驽钝，攘除奸凶，兴复汉室，还于旧都。此臣所以报先帝而忠陛下之职分也。至于斟酌损益，进尽忠言，则攸之、祎、允之任也。愿陛下托臣以讨贼兴复之效，不效，则治臣之罪，以告先帝之灵。若无兴德之言，则责攸之、祎、允等之慢，以彰其咎；陛下亦宜自谋，以咨诹善道，察纳雅言，深追先帝遗诏。臣不胜受恩感激。今当远离，临表涕零，不知所言。
