项目研发工作计划

项目研发工作计划（推荐9篇）

项目研发工作计划篇1

（提纲）

项目计划书为Word格式（可插入图片或公式），由标准封面和具体内容组成。报告各页面距要求设置为2.5厘米，行间距、字间距、字体大小可参考本提纲。具体内容要求翔实清晰、层次分明、重点突出，并按以下提纲撰写。

一、项目实施的背景和意义

阐述项目所面向的我市经济、社会和科技发展等有效需求，项目的先进性、重要性、必要性、可行性以及在行业发展中的地位和作用；预期实现的经济和社会效益。

二、与国内外同类技术的综合比较

阐述项目相关技术的发展趋势、国内外研究开发、产业化状况、我市相关行业与国内外先进水平的差距、以及知识产权、市场需求情况等。

三、项目主要研究内容

阐述项目涉及的技术领域、工艺范畴，拟解决的关键技术问题，拟采用的技术原理、技术方法、技术路线以及工艺流程，项目的主要技术创新点，涉及的相关知识产权等。

四、项目预期目标

阐述在技术进步、工艺创新方面可实现的预期成果，形成的产业前景，培养的技术人才，以及对解决产业发展问题的预期贡献，须有五年期内的可考核技术指标和社会经济效益指标。

五、项目实施方案

阐述实现预期目标所需的组织管理方式、技术实施步骤、科技资源综合利用、成果产业化策略、研发资金的筹集与投入、知识产权和技术标准的对策措施以及特殊行业的许可报批等。

六、项目计划进度

在项目执行期内，每一阶段应达到的具体目标，包括时间进度指标、技术指标、资金使用计划、产业化情况等。每一阶段目标应是比较详细的、可进行考核的定性定量描述。(每半年为一个阶段)

七、依托单位的工作基础和条件

1．依托单位在相关技术领域的已有研发基础、主要研究成果。

2．项目实施具备的支撑条件，包括研发资金、实验平台、大型仪器设备以及重点实验室、工程中心等研究基地在项目中所起的作用等。

3．申请单位近三年承担的国家、省、市相关科技计划项目的完成情况。

4．与其它企业、科研院所、大专院校的合作情况(若有)。

八、研发团队

1．研发团队的规模和结构，包括年龄、专业、职称等情况，团队规模要适度。

项目研发工作计划篇2

2016年2月19日, 科技部发布国家重点研发计划“国家质量基础的共性技术研究与应用”重点专项2016年度项目申报指南, 启动项目申报工作, 其中包括国家标准、国际标准研制以及中国标准“走出去”适用性技术研究等重要领域标准项目19个。

国家质量基础 (NQI) 最早由联合国工业发展组织和国际标准化组织在总结质量领域100多年实践经验基础上提出, 由计量、标准、合格评定 (检验检测和认证认可) 共同构成, 现已被国际公认为是提升质量竞争能力的基石。其中, 标准作为国家质量基础的重要组成部分, 已成为国际通行的“技术语言”, 是促进互联互通的桥梁和纽带, 更是“十三五”时期支撑国家治理体系和治理能力现代化的重要手段。

据悉, “国家质量基础的共性技术研究与应用”重点专项是在中央财政科技计划 (专项、基金等) 管理改革的大背景下, 由科技部、国家质量监督检验检疫总局、国家标准化管理委员会会同其他12个相关部门共同研究提出的, 执行期为5年。按照全链条设计、一体化实施的思路, 专项围绕计量、标准、合格评定 (检验检测和认证认可) 和典型示范应用5个方向设置了11个重点任务、35个子任务。其中, 标准方面涉及基础通用与公益标准、产业共性技术标准、中国标准国际化3个重点任务、10个子任务。这些任务预期支持研制我国优势特色领域国际标准200项以上, 推动超过100项中国标准“走出去”, 研制基础通用、社会公益和产业共性国家标准1 000余项。预计到2020年, 在专项的支持和带动下, 我国主导制定的国际标准占同期国际标准总数的比例将由“十二五”时期的0.7%提升到1.5%, 我国技术标准整体技术水平和国际化水平都将有明显提升。

研发项目的机制保障篇3

为主的企业

其项目管理之失败

在于缺乏一套

有效的运作机制

而不是部门主管

缺乏执行力

上世纪70年代中期，美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善引起的，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。可见在研发项目中管理的重要性。

而笔者在本土软件公司协助建立项目管理制度时发现，以项目工作形态为主的企业，其项目管理之失败在于缺乏一套有效的运作机制，而不是部门主管缺乏执行力。

以研发项目为例，由于项目管理方法及软件已经相当普遍，大部分的项目经理都知道如何展开工作计划及分配工作项目，比较常遇到的，反而是下列问题：

研发人员未主动向项目经理汇报工作情形与遭遇到的困难，导致项目经理无法及时掌握进度，并将问题排除。

项目经理未在适当的时间请其它部门提供必要的支持，或是这些支持事项到后来石沉大海，没有下文，影响到项目的进度。

大部分的研发人员不愿意制作项目管理所需之文件，例如：填写会议记录、工作计划、产出成果文件等，导致后来执行类似项目的人员，没有资料可以参考。

决议事项未被遵守，没有人执行后续工作，导致事情延宕。

项目相关文件资料未适当整理及保管，甚至遗失。

当项目规模不大，或只是一两个项目时，这些可能只是小问题，项目经理只要提高意志力或执行力即可解决。一旦项目规模扩增，变成有数十个单位共同参与，而且同时有数十个项目一起进行时，这些小问题的影响就会累积成大问题。所以对于拥有较大规模研发团队的制造业，必须建立一套项目管理机制，让项目管理成为每个人的责任，便利各项产品开发工作的推动。

资源管理机制

X企业是一家ERP系统开发公司，接到订单后，必须依据客户要求列出待开发的功能项目，交由研发部门执行程序开发，并整合成为系统功能的一部分，再由客服部门提供导入的服务，工程师协助客户安装系统，以及提供使用者教育训练。

这天，负责A客户系统导入的项目负责人李勇拿着手上的单子，怒气冲冲地朝着研发部门走去，原来他已向客户承诺明天前往安装新系统功能，但是刚刚手下的工程师通知他研发部门还没将功能开发完成，情急之下就想找研发主管理论。

李勇见到研发主管齐威时，强压下心中怒火，以还算委婉的语气询问两周前即已提出的功能开发需求，为何到今天尚未完成。由于李勇面色不善，一向不喜与人争执的齐经理耐着性子向李勇解释：“由于这两周的开发项目比较多，其中有大型客户预定的开发项目，必须到下周一才能将A客户的功能需求完成。”齐经理解释后，李勇怒气未消，质疑着说依过去的经验，A客户所需的功能只要60个工作小时即可完成，研发部门有那么多人，为何已花了两个礼拜的时间还无法完成。齐经理说：A客户所需功能的开发时数不只60小时，此外由于研发人员擅长的项目不尽相同，而且还有新人要训练，所以研发部门会将预计开发的项目与人员的专长作调配，再来排时程，不太可能直接将工作时数换算成天数来交件。另一方面李勇当时只是传来一张联络单要求开发的功能项目及日期，并未与研发部门进一步确认这些功能开发的难易度及时程。齐威进一步质疑A客户的需求早在上个月中即已收集完毕，李勇为何不早点提出，造成研发部门上个月有2名人员闲置，而这个月所有人员都得加班的不平衡现象，增加其管理上的困扰……

企业在资源管理方面常遇到下列问题：

规划项目应完成的工作时，无法合理估计需要多少资源，包含：人力、设备、共同资源及其它辅助单位的支持；项目执行时，原本预定的资源遭挪用，由于人力断层导致项目进度中断或延后；或是提供支持的部门迟迟无法将工作完成，影响到研发部门后续工作的进行；部门人力资源分配不均，有些人员业务繁重，有些人员则游手好闲；对部门资源的需求未作适当安排，造成某些月份工作量大，某些月份人员闲置；缺乏客观的数据来评估部门或人员执行工作的效率，也没有预计与实际工作时数的比较数据。

为了解决这些问题，在资源管理方面则应建立以下制度：

标准工时制度。将参与研发流程的相关部门区分为主体部门、共享资源部门、支持部门。再由各个部门依据详细工作清单，估计每个项目的标准工时，或工时范围。

部门资源分配制度。评估人员的素质，初步计算部门对于每个工作项目所能提供的最大产能；设计资源分配表，显示资源分配及耗用情形；应重视人员的能力、成长性，使实际执行情形与标准工时相符；运用作业研究等资源分配工具；律定资源挪用的权限、判断标准与机制。

部门／人员工作时程规划。规定时程变更的机制；设计各部门及人员的工作程序和方式；将此信息以及时的方式提供给其它部门。

资源耗用统计。设计工时报告并要求人员填写；累计资源耗用时数。

进度管理机制

企业在进度管理方面经常遇到以下问题：

第一，对于整个项目包含了哪些工作、如何完成、执行的顺序等，缺乏通盘的规划。

第二，未针对每个项目指定专责的管理人员，导致发生问题或需要协调时，没有人愿意主动出面处理。

第三，高阶及相关部门主管无从得知项目进行到哪个阶段，以及执行的情形。

第四，由于突发事件的冲击，项目计划未能妥善应变，导致项目工作中断或胎死腹中。

为了解决这些问题，在进度管理方面应建立以下制度：

选定项目经理。建立项目经理的遴选制度；明确定义项目经理的权力与责任（与矩阵式组织结构的设计互相搭配）；建立项目成立及项目启动会议的机制。

提出项目计划。展开工作计划及时程，并律定标准化作业流程；建立指派项目成员的机制；建立项目团队的管理模式；设立项目管理中心，可与研发资料中心搭配。

进度报告。规定项目各项进度的检查时点，并予以标准化；规定进度报告的内容及格式；规定定期会议的机制。

建立项目计划变更的程序。明确定义在何情形下可以变更项目计划；指派项目计划变更的评估人及决策人；制定变更的程序；建立变更后项目执行情形监督的机制。

通讯管理机制

企业在项目执行过程中，常发生以下协调问题：

不晓得哪个项目有哪些人员参与，遇到问题时找不到该工作项目的负责人。

有重要信息必须通知项目成员时，由于不知道要通知哪些人，所以只好所有可能有关的人员都通知，造成高阶主管每天都有收不完的E-mail，不但浪费时间，而且易因疏忽而遗漏了重大事项。

总是有人不知道项目会议重要决议事项的相关信息，未依决议事项立即调整工作方向及内容，导致项目成员间工作步调不一致，以及工作上的混乱。

遇到问题时各吵各的，不知如何解决争议。

针对各项问题召开会议讨论解决方案后决定的事项，没有执行，导致问题一直延迟未解决，进而衍生出更严重的问题。

设计审查的文件丢出去后石沉大海，不知道文件传到哪里，也不知何时审查作业才会完成。

为了解决这些问题，在通讯管理方面应建立以下制度：

第一，制作项目人员的联络数据，包含：项目组织图、项目成员名单、项目及相关人员通讯簿、项目及相关单位联络窗口等。

第二，规定信息公布与通知的主要管道。

第三，规定会议作业程序，包含：临时性协调会召开的程序，以及决议事项的处理及跟踪。

第四，规定工作传递机制，包含审核作业的数据传递。

文件管理机制

“拜托你们赶快找一找好不好，总经理已经在发脾气了！就是D客户的服务计划书与合约书啊！三个月前签约的那一家，找到了赶快拿过来。”电话的另一边周秘书匆忙挂掉电话，项琳手上拿着话筒愣了一下，刚刚的声音彷佛还在脑海里盘旋，嘴里反复念着“服务计划书？与合约书？”按了一下电话又切掉，“这该找谁要啊！D客户……，先问业务吧！”

拨通电话到业务部，找到负责D客户的冯刚业务员，得到的答复是：“服务计划书怎么会问我呢！又不是我写的，你找客服部吧，看当初是谁写的，或是找一下他们的档案夹，可能会有。”项琳碰了个钉子正有点恼火，电话又响了：“对了，除了刚刚那些，总经理还要客户的需求数据，赶快拿过来，不然待会挨骂的可是您喔！”再次传来周秘书急切的声音，项琳满肚子不高兴，反驳着说：“为什么都找我？我又没参与客户项目，何况我们从来没有整理过什么客户需求资料啊！”周秘书看情况不对，稍稍把语气放缓：“反正你们就什么都管嘛！不然怎么会叫做管理部呢？如果没有客户需求数据就找类似的，总经理要看一下客户所提的是否有超出当初答应的范围，拜托拜托啦。”项琳也没辙，只好去找客户部助理小容。

小容说：“我帮你问一下李勇，他是项目负责人，应该知道哪里有，你等一下。”转身走到座位上打电话。项琳趁这个空档瞄了一下资料柜，不小心看到一个机械业的档案夹，随手拿出来翻了一下，内心嘀咕着：“流程图、计划书、窗体清册、系统分析，这不是上次唐副经理想要参考的数据吗？原来这里有。”转过头顺口问了小容一句：“是不是每一个案子都会有流程图、窗体清册、系统分析这些资料。”小容答道：“不一定啊！要看项目负责人，他们放了哪些资料，档案夹内就有哪些。啊！你要的计划书有着落了，李勇那边有，你去跟他拿。”“那客户需求数据呢？帮我想一下，有没有类似的数据？”项琳像是抓到救生圈一样，紧黏着小容不放：“客户需求哦！客户服务记录表里应该是有啦，不过都零零星星的，你整份拿去好了。”

20分钟之后，项琳找齐了所有数据，满心欢喜地交给周秘书。回到座位才坐下喘了两口气，看着窗外有一只黑色的鸟飞过，电话铃声又响了：“你合约书拿错了……”

以上的问题在你企业的项目执行过程中，是否也经常发生呢？相关人员不知道公司内部有哪些文件数据可供参考。而人员在找数据时，不知道应向哪个单位查询。

为了解决这些问题，在文件管理方面应建立以下制度：

第一，以档案流程、信息流程为基础，逐步检讨企业应产生的档案及文件等数据。第二，建立文档类别及清单。第三，制度标准的档案格式。第四，建立和统一文件编辑的方式。第五，档案数据产生和归档的方式。第六，建立文件管理中心。

数据管理机制

企业在项目执行过程中，由于数据管理不善而产生的问题也常常困扰着管理者。比如：人员未依规定产生电子数据、电子数据未集中保管。由于文件数据没有适当的编号，造成管理与查询的困扰。机密的电子数据外泄，或是重要的电子档案遭到修改等等。

为了解决这些问题，在数据管理方面应建立以下制度：

研发项目经理工作的岗位职责篇4

1. 负责项目执行过程中的协调及监督管理工作，确保项目顺利实施;

2. 负责协调推进各关联团队工作，把控项目进度，质量，风险，沟通及人力配置;

3. 负责将项目管理相关专业知识，经验和技能标准化，体系化;

4. 管理和协调内部资源，监督各部门分支计划的执行，保证项目按计划顺利执行;

5. 跟踪计划实施情况，必要时提出及调整项目计划，对影响项目按时完成的因素要及时发现并找到原因、及时解决;

6. 对项目的进展情况、阶段性成果，关键里程碑任务的完成情况做定期和及时汇报。

【岗位要求】

1、28-32岁，统招本科及以上学历，项目管理、计算机、电子、自动化等相关专业，英语四级以上;

2、熟悉项目管理流程及方法，通过PMP认证;

项目研发工作计划篇5

国家安全监管总局规划科技司作为安监总局科技主管部门负责安全生产领域国家重点研发计划项目推荐工作。2016年10月,国家安全监管总局规划科技司印发了《关于2017年度国家重点研发计划安全生产项目申报工作的函》,明确了2017年度国家重点研发计划安全生产项目申报工作的相关安排。

一、项目申报

具有独立法人资格的研发单位,均可通过国家科技管理信息系统向科技部提交项目申报书进行申报,指南以外的研究项目和未经国务院有关部门科技主管司局或省级科技主管部门推荐的项目不予受理。

二、评审推荐

有意愿申报2017年度国家重点研发计划安全生产项目的单位可向国家安全监管总局,行业主管部门或所在省(直辖市、自治区)科技主管部门申请推荐,需要通过总局推荐的单位,请自行到科技部网站下载申报指南,并于11月7日前将纸质预申报书报送国家安全监管总局规划科技司。国家安全监管总局规划科技司将会同有关司局组织专家评审遴选后向科技部推荐。

三、批准立项及项目管理

科技部收到推荐项目后,将委托专业机构进行形式审查和专家咨询审议,提出立项项目报科技部批准。项目的日常管理由科技部认定的专业机构负责。

谷歌公布送货无人机研发项目篇6

谷歌提供的一段视频反映了在澳大利亚一个牧场进行的一次无人机送货试验。画面显示，一架无人机在接到送货指令后，很快抵达目的地，在收货人上空盘旋。与此同时，从无人机腹部缓缓向下伸出一根缚有一小盒狗粮的绳索。在将狗粮稳稳放到地面后，无人机收绳离去。

据介绍，“翼计划”第一阶段已进行了多次这样的试验。谷歌送货无人机的原型机宽约1.5米，高约0.8米，有4个推进器，使无人机能朝各个方向移动。这种无人机能从距地约46米的高度向地面递送包裹。

谷歌表示，送货无人机与其研发的无人驾驶汽车有许多相似之处。谷歌研发人员在解决送货无人机的精确定位和导航技术问题等方面，参照了研发无人驾驶汽车的相关手段。

谷歌送货无人机项目已有竞争对手。电商巨头亚马逊去年年底宣布它正研究用小型无人机快递小件包裹的计划，引起业界关注。另外，美国达美乐比萨公司去年也尝试过用无人机运送比萨饼。

不过，包括送货在内的无人机商业运营在美国尚不合法。亚马逊不久前向美国联邦航空局递交了在美国空域测试无人机的申请，该局正在考虑是否修改相关法规。分析人士认为，谷歌加入无人机快递服务研发，可促使相关政策制定方更加重视这一业界呼声。

项目研发工作计划篇7

一、申报单位情况

1、基本情况：单位名称、地址、注册时间、注册资金、登记注册类型等。

2、研发能力：项目负责人及主要承担人员简介；研究开发人员、设备、资金等投入情况；研发及知识产权管理体制；承担市级及以上各类基金、科技计划、人才计划支持情况，及其取得的成果等。

3、经济财务状况：重点说明单位财务、经济和管理情况及对本项目实施的支撑能力，企业历史融资情况，企业上年末总资产、总负债、销售收入、利税等财务数据。

二、项目基本情况

1、项目概述。应包括项目的主要研究内容、技术水平及应用范围，我市现有技术基础、项目申报单位优势等。

2、目的意义：项目社会经济意义、相关领域国内外发展现状与趋势、项目实施的必要性等。

3、预期目标。项目完成时预期达到的总体目标，累计实现的工业增加值、销售收入、缴税总额、净利润、创汇额等经济目标，预期达到的主要技术指标，执行期内可以实现的知识产权指标，创新团队与创新人才预期成果。

4、推广及应用前景。

三、项目可行性分析

1、项目创新性：说明本项目的基本原理及相关技术内容，技术创新、产品结构创新、产品工艺创新等创新点。

2、前期工作基础。本单位已有的相关研究成果、支撑条件和主要仪器设备等，项目合作单位在本领域或同行业的研发水平、能力、实力、国内位次等。

3、拟采取的研究方法。实施本项目的主要研究方法、技术路线及实施方案的可行性分析。

4、项目成熟性和可靠性。详细说明项目目前进展情况、技术成熟度。对成果转化和产业化项目应用提供产品性能检测报告、产品鉴定证书；对于引进技术项目，需提供消化、吸收、创新和有关知识产权的文件。

5、市场竞争能力预测。未来市场预测，本项目产品国内主要研制单位及主要生产厂家研制、开发情况；在建项目和已批准拟开工建设项目的生产能力，预计投产时间。分析本项目产品的国内外市场竞争能力，替代进口或出口的可能性，预测本项目市场占有份额，以及近期内市场占有率的增长情况，并说明预测的根据。

四、项目实施进度方案

项目各阶段的目标、进度安排以及实现目标的主要措施等。

五、投资估算与资金筹措

1、投资估算：项目总投资、已完成投资、需新增投资及主要用途。

2、资金筹措：按资金来源渠道，说明各项资金来源、预计到位时间、使用条件。

3、使用计划：根据实施进度和筹资方式，编制全部投资的资金使用计划。

六、经济、社会效益分析

1、市场前景：项目产品产业化后的市场销售情况预测。

2、盈利预测：编制该项目五年的盈利预测，包括收入预测、成本预测、利润预测。

3、社会效益：对促进经济社会持续协调发展、对本地区产业带动作用、对增进人民身体健康和增加就业等方面效益的分析。

浅谈项目管理训练系统研发的意义篇8

关键词：项目管理；训练系统；模拟

项目管理是通过对有限资源的有效计划、组织、控制，实现项目管理目的，保证项目目标的实现。可以确保项目质量的实现，确保項目的如期完成，确保项目投资处于受控状态。有效的项目管理可以节省项目费用10—20%。所以项目管理能力对管理人员来说是非常重要的。能力就是效益，能力就是质量的保障。因此训练提高项目管理能力既是项目管理的需要，也是市场的需要。因此，项目管理能力提高的训练也有很大的市场潜力。

随着社会信息化进程的推进，作为项目管理过程中，对社会信息利用、对项目管理思路的调整、对项目管理经验的积累等，都需要有个平台来模拟项目管理活动，训练项目管理思路，提高管理能力。不论项目管理的教育培训部门还是项目管理部门都需要使用方便而有效的方式来管理、训练自己的管理人员。在计算机日益普及的今天，模拟项目管理活动，模拟社会活动，模拟信息存储方式等都可以实现的，为此通过现代信息管理技术实现项目管理仿真训练是必然的，只是时间问题。

一、项目管理能力训练情况介绍

目前，项目管理能力的培养、训练提高主要有以下几点：

（一）习题练习。习题训练以单项选择、多项选择、判断对错了训练。这种训练只能是训练学生对知识点的记忆，项目程序的死记硬背。例如，论证建设工程项目总进度目标时，需要进行：①编制各层进度计划：②项目的工作编码；③进度计划系统的结构分析等项工作。对上述三项工作而言，正确的工作步骤是（单选题）。

A①一②一③ B.②一①一③ C.②一③一① D.③一②一①

习题训练存在的问题：这种训练只是识别记忆的训练，提示性也很明显，现实工作中是没有提醒的，项目管理是比较独立的工作，训练中有提示，会误导训练工作。习题训练是单一、理想的问题，且是提问的方式，因此缺少综合性、实战性的训练。

（二）案例讨论式训练。一般是以典型案例为模型编制训练用案例。通过语言描述，给出案例的基本要素。公司背景材料、市场背景材料、项目目标、项目要素、项目成本等，然后要学生进行项目训练。

案例训练存在问题：第一，案例训练要把项目的背景、市场情况、项目的要素要说的很清楚，否则项目策划、项目管理无法进行，说的太清楚实战性训练的意义就会大大减少。第二，一个案例只代表一个特定的情况，表现出来的问题也是限定那几种情况，具有单一性和偶然性。第三，案例给出的要素、背景都是固定的，只是学生进行合理想象，没有交流的过程，没有互动性。第四，语言表达总是有限的，不生动，不形象，没有真实的体验和感受。

（三）是沙盘模拟训练。沙盘模拟训练是项目管理能力训练的主流，多数院校都采用这种方式训练学生的项目管理能力。以辽宁建筑职业学院的沙盘模拟实验室为例简单介绍沙盘模拟训练的情况[5]。

沙盘模拟训练是一种具有极强实战色彩的项目管理训练，是西方知名商学院借鉴军事兵棋推演的演习形式而开发出的优秀高端培训模式。军事演习一般是通过模拟一个比较接近实战的环境，让红、蓝两军从战略、战术角度进行不断地对抗与演练，从而达到检验和锻炼指挥团队作战能力的目的。而项目管理沙盘模拟培训则是由参加学习的人员组成几个相互竞争的团队，围绕与培训主题相关的经营活动，完成演练与学习，同样也可以达到提升学生知识和技能，改变学生认识和工作态度的目的。

沙盘模拟训练过程中，是对抗的过程，每个组都要根据模拟给出的激烈市场环境，规划、设计、实施项目管理的每个目标。同时，在各组对抗中能够脱颖而出。在沙盘模拟对抗中，各组成员都要全面、细致地考虑使用资金，并实现资金运用的成本最低。这就需要考虑如何优化资源，如何平衡进度，合理利用资源，在实现成本比较低的情况下，实现或保障进度。

在材料、库存以及价格管理中，如何使库存比较合理以，材料价格的浮动又在可以控制的、可以接受的范围之内。

沙盘模拟是在仿真的激烈市场竞争中进行的，所以也要进行风险管理的模拟训练，所以各组受训的人员，会遇到各种各样的风险，例如生产安全、灾害事故、小组危机、同业竞争者之间的强烈冲突等。

参加沙盘模拟的学员一般要经历3个以上的项目模拟，例如，人力资源管理、风险管理、成本管理、沟通管理、时间管理等等，同时也要经历亏损、意外打击以及成功的过程。通过这样的沙盘模拟训练，对项目管理的各个能力都会有所提高，对各个领域知识都会得到强化。项目小组成员之间的理解沟通也将得到增强。

沙盘模拟项目管理训练简单说也是案例训练的一种，有两点不同：一是沙盘模拟训练增加了形象的物体、物品、货币的样品等。二是沙盘模拟增加了教师与学生，学生与学生的互动（但情景也是按照案例事先确定的）。

沙盘模拟存在问题：第一，训练案例的项目背景、市场情况、相关要素仍然需要用语言进行说明，与案例训练一样。第二，虽然有教师、学生的互动，但是项目表现出来的问题也是限定那几个，具有单一性和偶然性。第三，沙盘模拟训练的项目管理的内容有限，多见于“项目规划”、“采购管理”、“成本管理”等3—5个模块。第四，缺少综合整体训练，缺少全过程的训练。

（四）项目管理仿真训练系统优势。该系统就可以解决上述问题的80%以上。该训练系统是把项目管理的各种要素数字化，建立相应的管理数据库，然后按照项目管路的需要随机给出。第一，是在项目管理的全过程中随机给出，训练的是全过程。第二，可以按照项目管理模块给出，分别训练相应模块的管理能力。第三，数据库收集了大量的项目管理各阶段，各个管理模块的问题，因此给出的问题是背对背，更具有实战性。第四，是人与计算机（系统）对抗，不是人与人对抗，系统是项目管理专家的集合体，所以训练更全面，更科学，更贴近实战。第五，可以把各种案例、经验积累起来，供后来人学习借鉴、训练提高。

二、项目管理训练系统的意义

项目管理仿真训练系统是一种对抗性强、形象仿真、贴近实战的训练模式，继传统教学、案例训练、沙盘模拟之后的一种教学与训练的创新模式。利用现代信息技术，通过仿真项目管理的全过程，提供给受训人员模拟操作（训练），从而提高学员的项目管理能力，强化学员的项目管理知识，达到全面提高学员综合素质的目的。该系统的模拟训练是项目管理理论的体现，更是项目管理实践、积累经验的好模式；也是充分体现了项目管理中的色扮演和岗位风格体验。受训学员在形象中体验，在仿真中训练，从而更有效地把知识转化为技能。

该系统是全方位展现项目管理的全过程，通过仿真模拟形象的、生动的体验，可以使学员获得如下的收获：

夯实项目管理的战略规划知识。有效的项目管理必然会有准确的战略规划，这里有项目管理战略、人力资源战略、市场战略、风险战略、资金运作战略、时间时机战略等。项目管理战略主要包括战略规划、战略目标、战略实施。该系统模拟项目管理的各种情况，学员通过仿真训练，大概会经历迷茫、挫折、探索、成功喜悦等四个阶段。这样就夯实了项目管理的战略知识，积累了战略的经验，并会用眼光看待项目管理的规划与实施。从而保证项目管理与项目管理战略的一致性。在工作岗位上获得战略成功的机会就很多，也坚定了项目管理的信心、自信。

夯实项目进程管理的综合知识。项目进程管理就是项目实施中，用成本、质量、时间的综合价值不断来满足项目目标的需求过程。项目实施，就是管理小组使用应有的资源（人、财、物）、工具、手段方法等，来满足项目目标的需要。系统仿真项目中的进程对抗是让学员学会分析市场、明晰对手、掌握项目目标的需求、制订项目管理战略与规划、确立项目管理目标，还要建立有效的实施计划，这样才能实现最终的目标。这个训练过程就把项目管理的综合知识得以巩固、夯实。在该系统仿真训练中，涉及到的项目管理中的成本管理、风险管理、时间管理、质量管理、采购管理、范围管理等等统统纳入到项目管理进程（综合）管理进入训练程序。系统会给出采购管理、项目实施管理等一系列问题，然后由受训人员进行解决问题，作出决策等，这就自然地训练学员的全面的、综合的项目管理能力，也强化、巩固了学员项目管理方面的综合知识。

（三）巩固成本管理知识，强化效益意识。在该系统仿真训练过程中，受训小组成员必须认识到成本意识、效益意识，因此要明确资产负债情况、利润与效益的结构关系，运用资本流转，控制好损益。控制好项目实施过程的各个阶段。预先预估长短期资金需求额度，用最合适方式筹集资金。在筹集资金过程一定要控制成本。在使用资金过程要提高资金使用效率。通过仿真训练让学员理解项目管理中的成本与效益的关系。

（四）巩固人力资源管理知识、积累管理经验。该系统仿真训练过程中，主要是经过项目组的组建、不同岗位的分工、确立各个岗位的职责、部门与部门之间的沟通与写作、人员与人员的沟通与协作、项目实施流程、各个部门、人员的绩效考核等阶段。总体是是一系列的人力资源管理的过程。仿真训练过程中，每个小组都要经过组建、争论、纠结、磨合、逐步会默契，也就进入比较合理的训练状态。在仿真训练过程中，逐步体会到人力资源管理的真谛，积累管理经验，巩固管理知识，同时理解人力资源管理在项目管理中的重要性，人是最关键的！也可以使学员深刻地理解合作的重要性，一个人的能力是有限的，你好不等于小组好，一个人强不等于小组强。人力资源管理是管理人，因此，人的主观能动性是第一位的，因此训练中加入了意愿、愿景的问题，让小组的每位成员都必须明确，小组的全体成员有着共同的愿景，共同遵守相本项目工作规范，项目才能达到预期目标。通过训练可以使得学员队人力资源管理的能力大大提高，知识得以强化和巩固。

（五）转变现代管理的思维。现代信息时代，项目管理的思维方式也要转变。该仿真统训练系统，在信息化、信息技术的使用、信息化思考问题的角度等都有所涉及，通过该系统的训练，学员会感觉、体会到构建项目管理信息系统的重要性、效益性和紧迫性。第一，时代变迁，信息技术的不断完善，项目管理信息化是项目成败的关键，也是记录跟踪项目实施的记录仪，更是项目管理的生命线。因此，信息技术、信息化改变管理方式方法，更改变管理人员的思维方式。第二，项目管理就是对项目实施过程进行控制、监督，这样只有信息化、信息技术才能记录结果，并引导及时修正和总结提高。该系统设计了信息化的训练节点，通过训练，让学员体验项目信息化的实施过程及关键点，这样就会对项目信息化有心的认识，心的提高，在观念和能力上都有所训练有所积累。

（六）全面提高学员综合素质。该系统是项目管理仿真训练系统，所以该系统主要是训练学员的综合素质，全面提高项目管理能力，分别训练分项管理能力等。学员会在理念、意识、技能等方面获得收获：

1、共赢理念得到强化。系统设计的理念就是双赢，在设计问题中体现共赢的思想，项目管理是在市场经济中进行，竞争是不可避免的。竞争不是你死我活，竞争是寻找利益共同点，因此训练中就体现你如何寻找利益的切合点，共同利益点。因此在系统建设中，设计了双赢的原则，项目管理中寻求与合作伙伴之间的双赢、共赢才是项目管理的真谛，是项目管理可持续发展的路子。训练时，就要求伙伴与对手、人与机器（系统）之间，做到知彼知己，在市场中分析對手，在竞争中寻求利益共同点，这样的项目管理才会有的无限的生机，训练才能得到高分，获得成功的喜悦。

2、强化合作理念和全局观念。该系统模拟训练重点过程是小组作业。模拟训练是小组与计算机（专家）对抗的过程。在训练过程中，学员体验到小组协作的重要性，协作精神的可贵性。项目管理，项目实施就像一艘大船，项目经理是舵手、人力资源管理与成本管理是保驾护航、时间管理、进程管理、风险管理是冲锋陷阵。在仿真训练过程中，受训人员都要以项目总体目标的优化为出发点，以大局观念为思考起点，各个部门各负其责，各负其职，团结协作，这样才能赢得对抗的胜利，实现项目管理的最优目标。

3、个性与职业定位。该训练系统是以团队合作的训练，团队的角色各有不同，每个个体因为拥有不同的个性而存在，这种个性在模拟对抗训练中会得到充分表现。训练是小组分别训练，但是训练吗结果可以进行比较，这样就体现不同小组训练的结果不同，也这就就要看团队中的各个角色的发挥与表现，既是每个人的个性特点展现，也是角色胜任与否的体现。同时也有二者关联度情况，从中看出每个人的个性与职业定位的情况。

4、实现从感性到理性的飞跃。该训练系统集中了专家的理论和实践的经验，因此，通过模拟训练，让学生从理论到实践，再从实践到理论的过程，也是螺旋上升的的飞跃过程。学生把训练体验到的宝贵实践经验转化为理论的融通。学生是通过该训练系统来推演他们团队的项目经营管理的思路，每一次基于现场的分析，基于数据分析的项目诊断，都会使学生受益匪浅，既能提升项目决策的灵感，也能提升决策能力以及战略规划的能力。

5、系统具有贴近实战、积累经验的功能。项目管理仿真训练系统就不同，全面仿真项目管理的所有要素，全面模拟项目可能出现的问题和遇到的麻烦，所以对项目管理能力的培养、训练提高是系统的、科学的、全面的。从项目管理角度，强化项目负责制的理念，培养团队精神，灵活过程管理的实践，体现了贴近实战的特点；培养学生综合运用相关专业课程所学知识解决实际問题的能力。系统功能具有如下特点：

缩短训练周期。在网上训练，项目管理的各种情况处理，问题解决，很快积累经验，提高能力。

全面系统提高项目管理能力。项目管理的全程仿真，问题给出也是按项目管理7大模块给出，所以训练是全面的，系统的。

积累经验、传播经验。系统具有经验积累功能，系统可以收集各种成功案例，分解数字化，存到系统数据库中，系统就会把这些经验加载到训练案例中，供受训人训练提高能力，积累经验。

参考文献：

[1]基于沙盘模拟的工程项目管理课程改革胡新萍计算机与光盘软件与应用，2013年15期

[2]项目管理/（美）宾图（Pinto，J.K）著.北京：机械工业出版社，2007.1

[3]现代项目管理，白思俊主编，北京：机械工业出版社2002

[4]组织结构中的项目管理/美J.D弗雷姆.北京：世界图书出版社，2002

[5]IT项目管理施瓦尔贝.凯西北京：机械工业出版社，2002

项目研发工作计划篇9

一、预算管理

对于银行研发中心而言，项目预算主要包括项目规模评估、项目工作量评估、项目工期评估、项目质量评估等。本节内容在此前连载中已有所论述。

二、质量管理

关于项目质量管理，有许多内容，包括项目质量的度量、影响项目质量的因素、项目质量的过程管理和过程改进等。相关内容可参考此前论述。下面来补充说明银行研发中心需要关注的一些问题。

（一）投入与质量的关系

为了保证生产安全，首先要保证产品的质量。但在任何产品生产过程中，都不可能追求毫无瑕癖，因为这会带来极大的投入，本身就是一种浪费。一般投入与质量的关系如图1所示。

投入与质量不是线性关系。越接近终极目标，需要付出的投入就越成倍增加。

对于研发中心而言，投入主要是指人力资源和时间资源，质量的指标主要是缺陷率。我们可以通过加大测试的人力资源投入、加长测试周期、模拟各种系统的应用情况，使缺陷率降到最低。它们两者的关系如图2所示。

对于一个既定的研发中心，要完成一定规模的任务，资源投入和缺陷率是负相关的。投入越大，一般缺陷率会越低。但很明显，两者的变化有一个边际效应：当缺陷率低到某个程度，加大投入带来的边际效果会越来越低。所以，从研发资源最大化利用的角度出发，应该把投入控制在整体质量可以接受的范围内，而不是追求完美无缺。

（二）不同产品的效率与质量，及其平衡关系

针对一定规模的任务投入一定的资源，如果忽略其他因素不计，整个版本质量基本能控制在一定范围内。但如何合理安排资源并平衡一个版本内各个项目的质量，从而得到整个版本最理想的质量分布，是一个非常值得研究的问题。

理论上，如果把研发资源(时间资源和人力资源)按项目规模大小平均配置在各个项目上，忽略主观因素不计，每个项目的质量应该差不多，这样整个版本的质量也应该能控制在一个既定的水平上。

但在现实情况下，项目的质量表现与预期大相径庭。一些原来非常希望其质量有好表现的项目，往往问题不断;另外一些认为相对不重要的项目，质量表现却不错。而整个版本的质量表现像木桶原理一样，一些重要项目质量表现不好，就像木桶的短板，整个版本的质量表现也不会好。问题出在哪里呢?恰恰是在平均配置研发资源上。

软件质量与质量表现不是一个概念。如果两个规模差不多的软件各自随机散列地隐含了相同多数量的缺陷，我们可以认为这两个软件的质量是差不多的。研发资源的平均配置，可以使软件隐含的缺陷趋于一致。但是，软件不同的应用环境，其质量表现会非常不一样。以下各方面因素会影响投产后应用的质量表现。

1. 应用被使用的频率

假设有A, B两个应用，其规模和内部构造大致一样。根据各自不同的应用场景，均有1 000种内部逻辑路径的组合，并且其中2种应用场景对应的内部逻辑有缺陷。这2个应用投产后，假设各种应用场景平均分布，出现问题的概率为0.2%。也就是说，平均每运行1 000次这2个应用均会出现2次问题。

但是，A应用一天会被使用100万次，B应用每天只被使用100次。这样，A应用平均每天会出现2 000个生产问题，而B应用平均5天才会出现一个生产问题。这样一来，两者在质量表现上的缺陷率就有天壤之别。

当然，上述的分析只是一种机械性的分析。实际上，缺陷不会平均分布，应用场景也不会平均分布。

2. 生产类应用还是管理类应用

通常，生产类应用的缺陷会直接影响银行对外的经营服务，而管理类应用不会或者只间接影响银行对外的经营服务。所以，同样的缺陷率，生产类应用比管理类应用的影响更严重。

3. 应用是否涉及计算机信息的变更

计算机信息的处理动作，大概可以归纳为增、删、改、查四类。其中，前三类动作会引起计算机信息的变化，而最后一类动作不会改变其内容。

对于不同的应用，如果其处理涉及计算机信息的变更，特别是涉及计算机重要信息的变更，例如客户资料重要信息的变更，客户的资产、负债资料的变更，甚至是大额的资产负债信息的变更等，其缺陷引起的生产问题会非常严重。有些信息的破坏甚至是不可逆的。而如果应用对应的计算机处理仅仅是信息查询，不会破坏计算机的固有信息，其缺陷引起的生产问题严重性会相对轻一点。

4. 应用涉及的当事人

此前说过，银行计算机应用系统的当事人不但包括银行内部人员、银行客户，还有第三方机构和监管机构。

如果应用是内部应用，仅涉及银行内部相关人员，其缺陷产生的生产问题影响范围一般只在银行内部。如果应用是外部应用，涉及的当事人还包括银行客户，其缺陷的影响会涉及银行和银行客户双方。如果应用还涉及第三方机构或监管机构，其影响除了银行客户，还会涉及第三方。较大的生产问题还会产生不良社会问题，会给银行信誉带来很大损害。

可见，对于银行来说，由于其应用环境和处理的内容不一样，不同的应用应该有不同的质量要求。如果该应用(项目)交易量比较大，会引起计算机重要的资料变化，甚至是大额的资产负债资料的变化，而且是外部客户使用的，甚至还涉及第三方，那么，对其质量要求应该最高。反过来，如果该应用(项目)涉及的交易量很少，是内部员工使用的，不涉及客户、更不涉及第三方的资料变化，那么，对其质量要求相应最低。

这样才能有最好的投入产出。研发中心不单要关注产品的质量，更应该关注产品的质量表现。只有重要产品有较好的质量表现，应用系统才能取得最好的整体质量。这就是平常所说的，好钢要用在刀刃上。

（三）改进办法

在现实上，研发中心研发的应用种类繁多。一般来说，由于不同的应用采取的软硬件技术平台、工具、语言不同，生产效率也会有不同。加上运行环境不一样，去掉主观因素，也会有不同的质量表现。根据上述对不同应用场景的分析，可以把不同质量要求的应用分类。例如分成不同的4类，1类质量要求最高，4类质量要求最低。

通过对银行实际生产问题进一步分析，发现问题出现最多最严重的是1类应用，问题出现最少最轻的是4类应用。这就验证了前面所说的：质量期望值越高的应用，往往表现为质量不高;而质量没有被寄于厚望的应用，质量反而比较高。

其原因是明显的，恰恰与我们对不同类应用的定义相关。

例如4类应用，首先，它的交易量少，问题出现的几率本来就很低;其次，它是内部管理类应用，而内部员工对应用缺陷的承受力一般比银行外部客户大;最后，由于它不涉及客户相关资料的变更，也不可能犯这方面的错误，并且更不会犯下涉及第三方的错误。而1类应用由于交易量大，犯错误的机会多，且错误会涉及资金的差错和损失、客户和相关合作方，因此对社会影响较大。

根据历史数据的分析，忽略其他原因，如果对不同的应用投入(效率)一样，即每百功能点的研发规模投入相同的人力资源和时间，在平均缺陷率表现统计上，1类应用会比4类应用起码高出2-3倍。并且这只是考虑了缺陷的数量，还没有考虑缺陷的严重程度。

上述结果有2个值得注意的地方：一方面，前提是我们对不同类的应用投入一样;另一方面，结果并非我们期望的结果。

如何解决这个问题?我们可以通过人为地调节研发资源来解决。

从研发中心的资源配置来说，对于高质量要求的项目，应该配以比平均资源更多的资源，以保证其有更高的质量。当然，该项目的效率要求就低一点。反过来，对于低质量要求的项目，研发中心要求其有比平均效率更高的效率。也就是说，分配较少的资源给它。当然它的质量相对会低一点。

让我们重新回顾一下质量与投入的关系图。为了方便起见，我们把该图再展现一下，如图3所示。

从图3可见，在时间资源和人力资源均压缩50%的情况下，缺陷率大概增加一倍多。也就是说，假设在资源平均分配时，1类应用的缺陷率比4类应用的高一倍。如果以1类应用作为标杆，要让1类应用与4类应用缺陷相当，在项目资源分配上，4类应用应该比1类应用压缩资源50%;如果以4类应用作为标杆，要让1类应用与4类应用缺陷相当，在项目资源分配上，1类应用应该比4类应用分配多一倍以上的资源。通过这种资源调节方法，在实际运行中，可以达到两类应用在质量上表现一样。

但这还没有达到理想的目标。考虑到缺陷的不同严重程度，我们还希望1类应用在实际运行中的表现要好于4类应用。例如，缺陷率低于20%。

再看一下图3，如果资源分配相差20%，缺陷率大概也会相差20%。我们可以在原来的基础上进行最终的资源分配，让1类应用比原来平均资源多获得20%，让4类应用在原来平均资源分配基础上压缩50%。这样，两类应用资源分配的权重比为1.2:0.5，也就是2.4:1。这个结论出人意料。并且前提是当资源平均分配时，原来4类应用与1类应用相比，其缺陷率表现为1:2。如果原来差别更大，那么结论就会更惊人。

这种方法的可操作性究竟如何，实际效果会如何?让我们来算一下。为了简单起见，假设应用只有1类和4类，并且，出于安全考虑，希望要求整个应用系统质量高一点。所以在定义上，1类应用在数量上一般比4类应用多，假设比例为7:3。相对应的，其研发工作量比例也为7:3。

先看资源分配的情况(见表1所列)，资源分配前后方案的总资源基本一样。也就是说，把4类应用压缩出来的资源基本上都分配给了1类应用。

再看质量表现(见表2所列)，通过资源分配的优化，在整体版本质量基本不变的前提下，1类应用和4类应用的实际表现已经基本满足需求。

当然，实际情况要复杂得多，上面表述的仅是一种方法论。

三、风险管理

软件工程管理的一个重要理念，是强调过程风险管理。只有每一个过程达到目标，才能保证软件工程达到最终目标。为了保证项目的进度和质量，过程风险管理是非常重要。

风险管理的展开可以细分为：依赖管理、风险管理和问题管理。

（一）依赖管理

顺利完成一个项目需要具备各种条件，如需求、人力资源、时间、研发环境、测试环境等。当研发中心正式接受项目研发任务时，上述条件有些已经具备，有些已经确认可以具备，但总有些条件具有不确定性。这些未能确定的条件会影响项目的顺利完成，我们把这些未能确定的条件称之为依赖。

依赖管理其实是风险的早期识别管理。除了应该能够把所有未能确定的前提条件识别出来，更关键的是制定落实这些条件的措施，并监控这些措施的执行。

如果我们能够把所有未确定的条件都识别出来，能够制定并且落实所有的应对措施，且这些措施都有效，那么，项目必须的前提条件都可以具备。理论上，项目的后续过程应该再没有什么风险可言，项目如果还不能顺利完成，只能说明研发中心的主观努力不够。

根据统计，每千功能点的项目依赖条件一般有5-10个。少于这个数量，风险前期识别可能不足;多于这个数量，项目完成的条件就可能不足。

（二）风险管理

当我们事先没能识别所有的依赖或者制定和落实的依赖应对措施无效，项目需要具备的条件在接近临界点时还未能具备，这时就会形成风险。

所谓风险，就是存在将会影响项目进度或质量的问题。如果这些问题在预定的时间内不能化解，就会影响项目的进度或质量。

项目风险分为可预见风险和不可预见风险。可预见风险是前面所说的依赖，项目组要对所有可预见风险事先有对策和措施，项目管理的要点是对策和措施的落实。对于不可预见风险，项目组一方面要吸收教训和积累经验，在今后的项目管理中尽量避免出现不可预见风险;另一方面要马上采取措施化解风险。

项目风险还分为内部风险和外部风险。内部风险是由研发中心内部的客观或主观原因造成的。客观原因包括研发中心内部研发环境或测试环境不完备、研发中心内部人力资源不足、结构性不平衡等，主观原因有研发中心的管理水平和研发人员的素质等。这些风险，要通过加强内部管理、内部协调沟通解决，相对可控。外部风险主要是涉及一些外部原因，如需求问题、必须的软硬件采购问题以及外部研发环境、测试环境等，这些风险相对不可控。如果要解决的这些问题超出研发中心的能力，要把问题汇总，与相关部门沟通解决。

按统计，每千功能点的项目风险数不应该超过两个。另外，我们希望所有的风险均在前期依赖管理中识别出来，不要出现无依赖识别的风险。通常，无依赖风险应该控制在总风险的5%以内。如果上述两个指标超标，均说明项目管理前期的依赖管理可能有问题。

（三）问题管理

当风险未能在约定的时间内化解，风险就转化为问题。此时，项目已经受到实质性的损害。

对于问题的管理和对策，也有多种策略：

维持项目需求基本功能目标不变，继续努力化解风险，争取项目按期发布。但由于问题的存在，项目的进度受损，因此最好的结果就是风险在项目发布前最终解决，使项目能如期发布。但这样项目质量不可避免会受到影响。

根据风险解决的时间，顺延项目发布周期以保证项目质量。如果风险难以在短期内解决，应立即评估问题造成的损害程度和影响点，修改或减少项目需求目标，以规避风险。

暂停项目，视日后情况进展而定。对于这种情况，应该是在项目立项的可行性分析阶段对项目可行性分析不足，或者项目依赖条件有了很大变化所致。

按统计，每千功能点的项目问题数应控制在0.1个以下。超过这个数，整个项目的可行性分析和风险管理就会有问题。

四、变更管理

在研发中心软件研发项目管理中，有许多因素会影响项目的质量。但在某一段特定的时间内，一些因素相对固定，且不容易简单改变(如研发中心的管理水平、研发人员的素质、研发的软硬件基础设施环境等)。排除上述因素，还有三大因素会对项目质量造成影响：一是项目人力资源投入是否足够;二是研发周期是否合理;三是需求变更是否在可控范围内。

需求变更有多种原因。从软件生产的特点分析，需求变更是不可避免的。问题在变更的数量、变更涉及的规模与变更的阶段。通常是，变更越多，规模越大，时间越往后，变更带来的额外工作量越多，给项目造成的损害越大。其中特别是需求变更提出的时间越靠后，代价越大。

不同阶段变更的不同影响如图4所示。

从图4可以看出，相同的功能需求，在需求分析阶段前提出的权重为1。如果到了应用设计阶段提出，要完成该变更功能的工作量将比该需求在一开始就提出来多一倍，如果在集成测试阶段提出，工作量将是原来的6倍。如果到验收测试阶段才提出，工作量将是原来的10倍。通常，把项目周期内各阶段接收到的所有同意纳入当期项目实现的变更，其所需的工作量加权合计，称之为综合变更工作量，其对项目的影响称之为综合影响。

特别令人沮丧的是，变更恰恰一般都在比较靠后的阶段才提出来。因为越是到后期，越能看到项目的成果，就越能发现原来需求的不足。出于完美主义，是谁都有变更的冲动。

在整个研发周期里，变更数量如图5所示。

举例说明，如果一个项目经评估，其功能点为1 000;在应用设计阶段提出一个变更，其功能点为10;在集成测试阶段提出一个变更，其功能点为20。则

加权合计功能点=10×2+20×6=140

综合影响=140/1000=0.14=14%

结论是，3%的需求变更造成14%的影响。

变更管理的主要措施包括以下几个方面。

（一）事前充分考虑变更

由于变更是不可避免的，所以在编造项目计划时一定要把可能的变更开销考虑在内，特别是对于需求质量不高的项目。通常可以把变更的综合影响预计为10%以内。如果最终综合影响超过预计的数量，肯定会对项目的进度或质量造成影响，可以认为项目前期的需求和需求分析有问题。

（二）科技研发团队加大项目前期的投入

为了尽量减少变更及其带来的影响，科技研发人员一定要尽量加大项目前期需求分析的投入，应该与业务部门深入讨论需求的可行性、前瞻性，尽量落实需求的每一个环节。

（三）业务需求部门积极参与整个研发过程