1、随着时代发展和技术进步,计算机在各行各业得到了广泛应用,成为了人们工作生活中不可缺少的重要工具。计算机之所以能够“大显神通”,背后离不开软件系统的支撑,所以软件又被称作是计算机的灵魂。营销学认为,需求是一切营销活动的起点,这个观点对软件项目来说同样适用基于某种用户需求而启动。然而,随着软件规模的扩大和复杂程度的不断提高,需求收集的难度也水涨船高,并成为影响项目成败的关键。著名的软件设计工程师 Grady Booch 认为,许多软件项目失败的根本原因在于开发人员没有正确理解客户的真正需求。有研究表明,软件项目中 40%耀60%的问题都是在需求分析阶段埋下的隐患。因此,“需求”一词成为决定软件项目
2、成败的全局变量,需求管理也成为软件工程和项目管理领域研究的重要内容之一。一、相关理论经过长时间研究和发展,需求管理已经有了相对成熟和完善的理论体系。20 世纪 80 年代中期,逐步形成软件工程的子领域需求工程。1993 年起,需求工程国际研讨会(ISRE)每隔 2 年举办一次;1994 年起,需求工程国际会议(ICRE)也每 2年举办一次,一些关于需求工程的工作小组相继成立。以下简要介绍主流开发模型中的需求管理以及需求管理方法论。(一)瀑布模型中的需求管理。1970 年,温斯顿 罗伊斯提出“瀑布模型”。瀑布模型是软件项目中广泛使用的经典模型,其特点是将软件开发分为可行性分析、需求分析、软件设计
3、、编码、测试、运维六个阶段,各阶段按顺序依次进行,上个阶段的输出作为下个阶段的输入,因此后一个阶段必须在前一个阶段完成后才能开始,强调项目过程的分阶段控制。虽然瀑布模型可以很好地确保每个阶段的工作质量,但其缺点也显而易见:过分强调文档评审和结果确认,当需求不明时,项目容易卡壳在需求分析阶段,出现开发周期长、产品迭代速度慢等问题。(二)敏捷开发模型中的需求管理。1986 年,哈弗商业评论 刊登了一篇名为“新型新产品开发策略”的文章,论述了需求管理在产品研发过程中的重要性,并提出通过可伸缩、基于团队的“接力赛”式、快速灵活实现产品目标的研发方法,形成了敏捷开发的雏形。2001 年 2 月,Mart
4、in Fowler、Jim Highsmith等 17 位著名的软件开发专家在对之前经验理论深入总结的基础上,正式提出了 Agile(敏捷开发)的概念。敏捷开发强调面对面沟通、不断迭代、频繁交付新的软件版本、快速响应需求,相比瀑布模型,敏捷开发模型能够很好地适应需求变化,能够及早反映需求误差,避免在项目后期出现大规模需求变更,从而降低变更成本,减小变更带来的负面影响。(三)PMBOK 中的需求管理。现代项目管理的知识体系起源于美国项目管理协会的 项目管理知识体系指南(PMBOKGuide),它为软件项目的需求管理提供了基本的架构结构。PMBOK Guide 第六版分为十大知识领域、五大管理过程
5、组。随着项目管理理论、项目实践的不断发展,PMBOK Guide 也在以四年为周期进行着修改、调整和完善,至 2021 年 7 月已更新至第七版。PMBOK Guide 中的范围管理对应的就是软件项目中的需求管理,范围管理的任务主要是明确项目边界、监控项目执行、防止范围蔓延,具体方法包括制定范围管理计划、开展需求收集、制定范围基准、分解开发任务、监控任务执行、控制需求变更等。(四)CMMI 中的需求管理。20 世纪 90 年代,许多软件开发的失败促进了软件开发过程管理,过程管理开始被约束条件加以限制,软件能力成熟度模型(CMM/CMMI)借以产生和发展。在 CMMI(能力成熟度模型)中,需求管
6、理是已管理级的一个关键过程域,其目标是为产品需求建立一个基线,供软件开发及其管理使用,使计划、产品和活动与需求保持一致。需求管理内容包括在产品开发过程中维持需求一致性和精确性的所有活动,例如需求基线控制、控制单个需求和其文档的版本,管理需求和其他交付物之间的依赖关系,跟踪基线中的需求状态等。二、需求管理的作用如前文所述,需求管理是决定项目成败的关键变量。如果在没有弄清楚用户真正想要什么之前就启动开发活动,往往会使开发出来的软件产品偏离用户需求甚至南辕北辙,导致后期进行大量的修改和返工。如果没有对需求变更施加控制、对用户变更有求必应,又会让项目如摊大饼一样变得越来越大,造软件项目需求管理常见问题
7、文/张晓博(河南省烟草公司新乡市公司河南 新乡)提要 需求管理是软件项目管理的重要内容。本文介绍需求管理相关理论,论述需求管理的重要性,点出需求管理常见的几类问题,结合相关理论和笔者实践经验,总结问题成因,从项目论证、开发方法、项目沟通、组织团队等方面提出解决对策。关键词:项目管理;软件工程;需求管理;沟通中图分类号:F27文献标识码:A收录日期:2023 年 1 月 3 日管理/制度No.10 x圆园23叶合作经济与科技曳133-成范围蔓延。而无论发生返工还是范围蔓延,最终都将导致工期延长、成本超支甚至项目失败等严重问题。下面的案例可以很好地证明这一点:美国从 1995 年开始对全国 8,0
8、00 个软件项目进行跟踪调查,数据显示,有 1/3 的项目没能完成,在 2/3完成的项目中,又有一半的项目没有成功实施,经过仔细研究发现,与需求过程有关的原因占了 45%,缺乏最终用户参与以及需求不完整是两大主因,分别占 13%和 12%。有研究指出:用户的积极参与、明确的需求表达、管理层的大力支持是软件项目成功的主要因素。由此可见,需求管理对软件项目而言至关重要。需求管理的作用在于收集并识别项目需求、定义项目范围,促成项目双方就项目范围做出承诺,并在实施当中严格控制项目变更,避免范围蔓延,使项目在软件功能、开发工期、资金支出等方面符合条件约束,促成项目目标的全面实现。三、软件项目需求管理存在
9、的问题尽管人们已经意识到需求管理的重要性,并且学术界对此也有众多的研究成果和方法论,但由于软件需求多是模糊的、多变的、主观的,因此在项目实践中,需求管理仍旧存在各种各样的问题。本节将对其表现和成因分别论述。(一)问题表现1、需求表达不够完备。软件系统开发是一项复杂的工程,开发过程需要经历分析、设计、编码、测试等诸多环节,前期需求分析开展越彻底、用户表达的需求越完备,则后期变更对项目的负面影响越小。Boehm 和 Papaccio 在 1988 年研究报告中表明,如果在需求定义过程中找出并修改一个基于需求的问题只需花费 1$,在设计阶段就要花费 5$进行修改,编码时是 10$,单元测试时是 20
10、$,而在系统递交后则是 200$,也就是说前期的需求错误会导致交付时软件开发成本的放大因子达到200 倍。然而实践中,用户很少能够一次性地、完整地给出软件需求,随着项目的进展,新的功能总是被不断地提出,新需求层出不穷,大型项目更是如此,以致开发过程充斥着修改、变更。2、需求描述不够细致。对开发人员来说,用户提供的需求越详细,则软件开发出来后就越接近于用户希望看到的样子,比如开发人员不光需要用户告诉他文本框出现在哪个位置,还希望用户告诉他文本框的颜色、校验规则、提示信息、按键响应等细节问题。但实际上,要求用户对需求表达到如此细致入微的程度,无论在理论上还是实践层面其实都是行不通的。项目中,用户给
11、出的需求往往极为含糊,许多功能细节需要开发团队帮助用户思考和完善。3、需求评审流于形式。如前文所述,软件项目的需求管理并不缺乏方法论和理论支撑,PMBOK Guide 对需求收集、需求定义、需求确认、变更控制等都有较为完备的理论指导,在需求评审前,项目组也会准备详细的需求说明书。然而,面对动辄数百页的文档,很少有用户会仔细阅读,也没有时间和精力逐条确认。此外,由于项目双方角色上的差异,用户方往往缺少对需求文档进行确认的行动自觉,开发团队出于避免冲突、维护关系的需要,也会对用户的这种做法采取默许态度,致使评审活动流于形式。4、容易产生理解误差。项目组中需求管理人员大多是技术出身,而用户通常只关注
12、业务而不了解技术,这种巨大的知识差异很容易导致双方在具体问题上产生分歧和误解。一种情况是用户通常只关注解决具体问题而缺乏系统性思考,如果项目团队只是机械性地执行而不去剖析用户内心的真实想法,往往会事倍功半甚至出力不讨好。另一种情况是用户不了解技术原理,认为技术无所不能,提出的要求过于“刁钻”,而开发团队却不懂得对用户的此类要求及时“劝退”,反而助长误差的加剧。5、需求变更缺乏管控。软件项目的目标本来就是逐渐明晰的,用户很少能够一次性地提出完备的开发需求,变更在所难免,所以无论开发方还是用户方都对变更做足了心理准备。需求变更并不可怕,可怕的是变更不受控制。从项目管理的角度看,一旦需求基线形成,任
13、何变更都要经过评估、审批等控制流程后才能实施,但实际上,许多变更都是由用户口头发出,开发团队口头答应,并没有经过评审、确认,也缺乏文档记录,这就为后期的需求溯源和项目验收埋下了隐患。(二)成因概述。以上问题并非孤立存在,问题之间相互交织,成因也错综复杂,总的来说有以下方面:1、论证不够充分。受数字化、信息化趋势导向影响,有些用户在建设软件系统时往往会有跟风现象,在论证不充分、没有回答好“是否需要、需要什么”的情况下就匆忙立项,前期论证不充分,导致实施过程中对软件需求的定义也摇摆不定。2、存在沟通障碍。沟通是获取软件需求的主要途径,沟通障碍会降低沟通效果,进而影响需求获取。沟通障碍可分为个人障碍
14、和组织障碍两类。个人障碍包括语言障碍、自我认识的偏误、双方地位差异、情绪影响、经验影响等;组织障碍包括准备不足、组织氛围、目标模糊、信息过载、信息反馈失灵等。3、需求的多样性。用户的预期需求是显性的,而基本需求和兴奋需求却是隐性的、不易察觉的,需要项目团队主动地理解、挖掘,而项目团队因为知识范围、业务理解的限制,往往很难窥探出用户的真实想法,导致在需求问题的理解上出现偏差。四、对策建议笔者从问题表现、问题成因等方面综合思考,总结出以下改进建议:(一)充分进行项目论证。项目论证是项目的开端,起到引领作用,对后续决策有重要影响。论证应当坚持问题导向,坚持实事求是,突出对必要性的论证,要把是否能够推
15、动业务发展、解决现实问题、提高企业效益、降低运营成本作为论证的出发点和落脚点,做到科学、客观、公正,尽量用数据说话,将问题现状、预期收益等进行量化,不能仅靠直观、经验、主观臆断进行判断,更不能先下结论,后作论证。从一开始就要树立正确的建设导向,坚决克服跟风式、冲动式、包装性的立项冲动,要根据论证结果控制投资规模和建设范围,避免重复建设、超项目范围实施等“搭便车”现象。(二)尽早展示软件原型。如前文所述,软件项目的需求是渐进明晰的,用户需求随着项目的进展而逐渐完善和精确。瀑布模型是广泛使用的开发模型,在促进软件工程化方面起着重要作用,但其缺点也显而易见:瀑布模型在解决软件需求不明确问题方面缺少灵
16、活性,用户往往在软件开发完毕才发现软件并不是真正想要的。因此,如果能在早期向用户展示软件雏形,便可以及早收到用户反馈,启发用户提出真实的、完整的需求,将用户需求由“后知后觉”变为“先知先觉”,从而避免将变更推到后期。快速原型模型和敏捷开发模型较好弥补了瀑布模型的缺点,它们的共同点是:不追求软件的一次成型,对用户需求动134-态响应并逐步纳入开发,都会形成软件的初始版本(原型),通过对初始版本的多轮迭代、修改、进化,形成最终交付版本。(三)进行充分而有效的沟通。成功的项目中人们往往感受不到沟通所起的作用,而在失败项目中却最能看出沟通不畅的危害。国外有学者指出,“沟通和协调中断是导致软件项目失败的
17、主要原因之一”;国内有学者通过因子分析发现,“设计阶段团队协调沟通因子、设计阶段客户沟通因子、客户需求识别沟通因子能够影响项目产品(系统软件)的质量”。沟通是双向的,所以无论是项目的建设方还是承建方,都应该积极参与、作充分准备,根据沟通目的、沟通内容、沟通对象设计沟通方案,选派沟通技巧出色的人员尤其是熟悉对方业务的人员负责沟通,努力克服语言障碍、认知偏见、地位差异等影响。最重要的,双方的沟通应当就软件需求达成确定的、一致的意见,让沟通真正起到效果,不能模棱两可。(四)组建矩阵式项目团队。这里的项目团队特指用户方的项目团队。用户方为加强与承建方的项目对接,通常也会成立项目组,指定项目组成员。然而
18、,这些项目组大多属于职能型组织,成员大多时间都在自己的部门处理各自业务,受部门领导支配,很少有精力投入项目建设。用户方的缺席,也是导致需求管理问题的主要原因之一。所以,对用户方来说,应当成立项目型或强矩阵型的团队,提高团队独立性,赋予团队一定的运作权限,使队员有充分的时间和精力保障与建设方沟通协调,发挥好项目组职能,从而进一步提升需求管理的质量。综上,需求管理是软件项目管理的重点,同时也是痛点、难点。由于软件需求与生俱来便有模糊性、不确定性、变化性、渐近性等特点,所以需求管理中的问题必将长期存在,同时对问题的研究也将推动管理理论的不断进步。主要参考文献:1 李学剑.小型移动 APP 开发项目需
19、求管理研究 D.济南:山东大学,2017.2赵海地.敏捷开发模式下 ZY 银行软件项目需求管理研究D.郑州:河南大学,2019.3 陈丽杰.浅析软件项目管理中的需求管理 J.科技资讯,2007(14).4 吴艳艳,周长伦,姜家轩,王春梅,许自国.软件项目管理中的需求管理 J.信息技术与信息化,2008(02).5 单宇姣.软件项目管理中沟通的研究与应用 D.大连:大连海事大学,2008.6 杨根兴,金荣得,宗宇伟.软件需求的不确定性与解决途径J.计算机应用与软件,2002(04).7 张保军.银行业务需求管理方法探究 J.中国金融电脑,2013.17(03).8 王达.需求工程的探讨 J.软件
20、,2011.32(05).一、公司简介高途是一家兼具教育基因和科技驱动力的科技教育公司,是 B2C 在线教育机构,2014 年 6 月由陈向东带领创建,其团队成员主要为新东方、百度、阿里、腾讯等知名企业的核心技术人员,是中国互联网在线教育领域的领军企业,旗下拥有跟谁学、高途课堂、成蹊商学院、金囿学堂、微师等产品。全力打造“直播+辅导”双师型教学模式,打造上千门课程。提供辅导老师全程服务、课堂互动、课程视频回放等功能,课程涵盖中小学、大学、成人英语、思维训练、瑜伽、家庭教育、国学、从业考证等几十个类型,致力于为学生和家长提供个性化、互动化、智能化的高途集团盈利模式分析提要 随着互联网科技的发展,在线教育发展进程十分迅速,这种不受时间、地点、年龄限制的新型学习模式满足现代社会经济发展的需要。伴随着大量在线教育企业的涌入,竞争十分激烈。2021 年“双减”政策发布后,在一定程度上限制高途这一类以学科教育为主导的在线教育,受到很大冲击。本文以高途集团为例,通过对其盈利模式进行分析,探究其存在的问题,并提出相应对策,以期对在线教育企业提供借鉴。关键词:高途集团;在线教育;盈利模式中图分类号:F275文献标识码:A收录日期:2023 年 5 月 23 日文/王新月陈涛(沈阳化工大学辽宁 沈阳)管理/制度No.10 x圆园23叶合作经济与科技曳135-