产品开发项目管理制度

制度是共同遵守的办事规程或行动准则。制度对实现工作程序的规范化、管理方法的科学化,起着重大作用。以下是小编为您整理的《产品开发项目管理制度》，欢迎阅读，希望大家能够喜欢。

第一篇：产品开发项目管理制度

IT项目-知识管理系统开发项目

仲 恺 农 业 工 程 学 院

课 程 设 计 报 告

**公司知识管理系统开发项目

目录

一，知识管理系统开发项目需求分析 ........................................................................................... 2 二，知识管理系统开发项目范围分析WBS .................................................................................... 4 三，知识管理系统开发项目进度安排 ........................................................................................... 4 四，知识管理系统开发项目费用安排 ........................................................................................... 5 五，知识管理系统开发项目可能存在的风险 ............................................................................... 5

一，知识管理系统开发项目需求分析

1，知识管理的困境与问题：知识管理混乱：我公司大部分项目资料分散在各部门个人电脑中、企业内的公共存储设备中或人企业各应用系统数据库中，没有相关的知识管理制度，没有企业内统一数据查询入口、没有统一的知识共享发布应用平台，不能统一规划、统一管理，导致企业知识资产状况无法了解，项目知识成果无法有效传承与共享，无法深入挖掘知识管理规律，无法及时获取服务设备和运营成果第一手相关资料、无法及时总结项目管理成果，增加各部门知识应用成本。

2，知识资产流失严重:我司人员规模较大，日常工作60%的工作成果都以知识的形式保存下来，但这些花费了大量人力物力创造的知识资产，因为缺乏有效的管理系统，会因为人员的流动、机器的变动而流失，对我司的无形资产造成了一定的隐患。

3，知识共享困难，形成信息孤岛：在日常工作过程中，部门与部门之间，岗位与岗位之间，存在着大量知识共享的需求，一般通过邮件、硬盘共享的方式传递，既不方便也不安全，在员工出差的情况下，就更难以调用公司的知识信息。在企业中各个部门之间由于种种原因造成部门与部门之间相对的孤立，各种信息(如产品信息、各种计划信息等)无法或者无法顺畅地在部门与部门之间流动，形成了信息孤岛，不能使企业知识资源配置最优化。

4，知识安全难以保障：在企业中形成的知识财富属于企业的资产，是企业花费大量人力、物力，经过工作实践而形成的重要资产，也是我们企业在市场中生存，面对激烈竞争的重要能力来源，因此必须加强知识的安全保护措施，避免知识的外泄，形成知识密级和权限体系。

5，知识再利用不足：公司的业务经验、资料、方案等知识利用率较低，员工需要找准确的资料和知识时，往往没有统

一、准确、及时更新的数据源，仅凭借自己的经验做出决策，或者是从头再来，从零做起，导致重复劳动，不仅效率低下，而且没有充分借鉴前人经验。

6，知识资产量化不足：对公司知识资产的统计不足，没有真正树立起知识资产也是公司无形资产的重要部分的理念，不能明确的了解各部门的知识存量状况，知识贡献状况等。

7，知识培训与考核：我公司尚未建立起以知识库为核心的培训考核体系。基于知识库的培训考核体系，能够依赖于庞大的企业知识资源，对员工进行及时的、广泛的、有效的培训考核。实现知识、培训、考核一体化。对新员工、晋升员工的知识培训还停留在一帮

一、传帮带的传统模式上，没有充分利用知识平台让员工自主的学习。

8，岗位知识传承和优化：组织中的岗位一般都是相对固定的，但人员是不断流动的，员工离职后其岗位知识、经验等也就随之流失掉，导致了岗位知识得不到有效的固化、传承，后继者没有可借鉴的信息资源。个人知识无法转化为企业知识，员工是公司的财富，他们头脑中有很多很好的经验和知识，应该充分鼓励，进行挖掘。

二，知识管理系统开发项目范围分析WBS

知识管理系统开发项目WBS

三，知识管理系统开发项目进度安排

知识管理系统开发项目进度表甘特图

四，知识管理系统开发项目费用安排

知识管理系统开发项目费用表

五，知识管理系统开发项目可能存在的风险

1，知识管理各阶段的风险

战略支撑风险：知识管理战略规划，必须从企业整体战略出发。知识管理战略规划成果应当支撑企业战略。企业面临的风险在于，如何形成支撑企业整体战略的知识管理战略。上文也提及，战略重点决定了知识管理应用的重点。这也是体现KM项目的价值所在。起步阶段的规划失误将直接导致知识管理走向失败。

组织设计风险：对于大型企业而言，知识管理工作需要一个专门的组织完成。知识规划阶段需要考虑该组织的架构及其团队构成。不同的团队构成会直接影响该组织对于知识管理的推动力。

变革推进风险：企业顺利开展知识管理，必须将员工绩效考核策略直接挂钩。这对于很多企业来说，绩效考评的调整会受到既得利益者的反对，如何推动这场变革，企业面临很大的风险。

共识达成风险：企业内部不同部门和团队，对于知识管理的理解、看法都不同。有些部门对此感到恐惧，担心部门利益受损。这与大家对知识管理的认识程度差异密切相关。企业必须考虑如何让知识管理在企业内部达成共识，让所有人理解知识管理对于他们的意义和价值。

文化惯性风险：企业原有的文化，有可能与知识管理不相匹配。企业需要逐步调整和塑造企业文化，以支撑知识管理工作的顺利开展。固有的企业文化存在一定时间的惯性，如何尽快调整文化的惯性，是企业面临的一个挑战。

知识遴选风险：在知识梳理阶段，如何选择能够支撑核心业务和管理活动开展的知识，企业面临知识遴选的风险。若梳理的知识为非核心知识，则KM无助于企业业务和管理活动的顺利开展，将导致企业员工对知识管理的不信任感增强。

知识协同风险：不同部门、团队的知识，存在协同的风险。在未实施知识管理前，不同部门之间的知识没有缺乏正式的沟通渠道，很多企业存在“部门墙”。打破这堵墙，实现知识协调，会面临各利益团体的挑战。

流程调整风险：知识梳理前，企业通常需要开展流程梳理和调整的工作。明确核心业务和管理流程后，才能明确关键控制点上的知识。流程调整后，员工的工作方式和流程会发生改变。如何让员工适应这种调整，企业需要做很多工作。

知识共享风险：这是知识管理面临的最大挑战之一。在企业内部塑造知识共享的文化，让所有员工积极主动的共享他们的显性知识和隐形知识，对于许多传统企业来说是很难做到的。 项目控制风险：企业在实施知识管理项目的过程中如何有效把握项目的进程，如项目推进组织不力、项目时间和进度失控、实施成本超出预算、实施质量难以保证等等。这是知识管理项目的控制风险。

制度保障风险：若企业只指望从技术上给知识管理提供支撑，而不能通过制度来保证企业知识管理活动的进行，进而塑造新的企业文化，那企业知识管理活动就存在失败的风险。知识管理项目的最终用户是全体员工，让如此众多的最终用户改变日常的工作习惯是一件工作很大而且困难的事情。如何让员工能够在工作中自觉地使用知识管理系统来贡献和共享知识呢?除了系统使用方便、简单、有效，并且能够满足公司业务在知识管理方面的要求等技术因素之外，更为重要的是建立一套严格的管理制度进行保证。

系统支撑风险：挑选合适的知识管理系统软件支持知识管理，存在系统支撑风险，主要包括知识管理系统软件本身存在的功能风险以及企业选择软件时的选型风险。软件功能不符合企业需求、集成开放性不足、成熟稳定性差强人意、缺乏软件供应和服务商的评估手段、选型时无所适从、盲目决策等都会最终造成知识管理项目的失败。

系统使用风险：主要是指企业在知识管理软件系统上线运行之后，企业员工却不能经常性地使用系统，也不能对知识管理系统进行维护，从而难以保证知识管理系统中知识的数量和质量，在“恶性循环”中使知识管理系统逐渐成为一个华而不实的摆设。

战略模糊风险：知识管理项目结束后，其他的战略会随着时间的推移逐步调整，知识管理战略也需要紧密跟随企业整体战略做调整，否则很容易出现战略模糊风险，导致KM在支撑企业战略方面力度不足。

组织涣散风险：全职或兼职的知识管理团队，在项目期间会投入很大的精力参与工作。进入项目结束后的持续改进期，团队容易出现精力不集中，企业知识管理工作也面临组织涣散的风险。

人员流失风险：知识管理项目结束后，一批专业的KM从业人员已经成长起来，企业必须采用一套好的绩效管理体系维持这批专业人员的稳定性，否则企业将面临KM专业人士的流失风险。

持续发展风险：主要是指企业对知识管理的长期变革特性认识不足，以为只要软件系统上线，项目就大功告成了，从而给企业的知识管理带来了一个发展中的风险问题。知识管理技术在发展，企业对知识管理的需求也在不断变化，如果以静态的观点来看待知识管理项目，则难以从知识管理中充分“榨取”效益，也不能使知识管理在企业中得到持续推广。随着业务的发展、流程的调整，企业的知识管理工作需要进一步提升。

文化弱化风险：企业的文化需要不断塑造和加强，否则会逐步弱化，企业员工的知识共享文化和精神也容易逐步淡化。企业需要采取各种措施，做大量企业文化强化的工作，保证良好的企业文化指导和影响企业所有员工的行为方式。

第二篇：新产品开发项目管理制度

TO：总经理、各部门

FROM：财务部

DATE：2010-06.07

研究开发项目费用管理制度

一、 研发项目立项及成果报告：

1、研发中心负责新产品的调研分析、立项、产品的设计、试制、鉴定、移交投产等方面的管理。供应部、生产部、质管部在整个开发过程中给予支持和配合。

2、研究开发项目是指“不重复的，具有独立时间、财务安排和人员配置的研究开发活动”。立项要符合国家和河南省的技术政策和产业政策，符合《国家重点支持的高新技术领域》、国家发展改革委员会等部门公布的《当前优先发展的高技术产业化重点领域指南(2007)》规定。是为获得科学与技术新知识，创造性运用科学技术新知识，或实质性改进技术、工艺、产品而持续进行的具有明确目标的研究开发活动。不包括对产品的常规升级或对公开科研成果直接应用。下列各项不属于研究开发活动：

(一)企业利用已经掌握的成熟技术，包括已经完成产业化开发的产品、工艺、材料及其系统;

(二)通过简单改变尺寸、参数、排列，或者通过类似技术手段的变换实现的产品改型、工艺变更以及材料配方调整活动，企业通过上述活动对产品、工艺无实质性改变;

(三)一般设备维修、改装、常规的设计变更及其已有技术直接应用于产品生产的活动;

(四)一般检验、测试、鉴定、仿制和应用活动;

(五)软件复制和无源代码的程序编制活动;

(六)其他非研究开发活动。

3、新产品的可行性分析是新产品开发不可缺少的前期工作,必须在

进行充分的技术和市场调查后,对产品的社会需要、市场占有率、

技术现状、发展趋势以及资源效益等方面进行科学预测及经济性的

分析论证。 立项计划书编写要求：(字数要求在5000字以内)

3.1、立项依据

(一)国内外现状、水平和发展趋势

(二)项目研究开发对本企业、行业的推动(带动)作用

(三)项目达到的技术水平及市场前景

3.2、研究开发内容和目标

(一)项目主要内容及关键技术

(二)技术创新点

(三)主要技术指标或经济指标

3.3、研究开发方法及技术路线

3.4、现有研究开发基础

3.5、研究开发项目组人员名单及具体负责内容

3.6、计划工作进度

3.7、费用预算情况，包括

(1)人员人工：研发人员全年工资薪金，包括基本工资、奖

金、津贴、补贴、年终加薪、加班工资以及与其任职或者受雇有关

的其他支出。

(2)直接投入：为实施研究开发项目而购买的原材料等相关

支出。包括：原材料、水电;用于中间试验和产品试制达不到固定

资产标准的模具、样品、样机及一般测试手段购置费、试制产品的

检验费等;用于研究开发活动的仪器设备的简单维护费;以经营租

赁方式租入的固定资产发生的租赁费等。

(3)折旧费用与长期待摊费用：为执行研究开发活动而购置

的仪器和设备以及研究开发项目在用建筑物的折旧费用，包括研发

设施改建、改装、装修和修理过程中发生的长期待摊费用。

(4)设计费用：为新产品和新工艺的构思、开发和制造，进

行工序、技术规范、操作特性方面的设计等发生的费用。新产品设

计费、新工艺规程制定费以及与研发活动直接相关的技术图书资料

费、资料翻译费。

(5)装备调试费：主要包括工装准备过程中研究开发活动所

发生的费用(如研制生产机器、模具和工具，改变生产和质量控制

程序，或制定新方法及标准等)。

为大规模批量化和商业化生产所进行的常规性工装准备和工

业工程发生的费用不能计入。

(6)无形资产摊销：因研究开发活动需要购入的专有技术(包

括专利、非专利发明、许可证、专有技术、设计和计算方法等)所

发生的费用摊销。

(7)委托外部研究开发费用：是指委托境内其他企业、大学、

研究机构、转制院所、技术专业服务机构和境外机构进行研究开发

活动所发生的费用(项目成果为企业拥有，且与企业的主要经营业

务紧密相关)。委托外部研究开发费用的发生金额应按照独立交易原

则确定。

(8)其他费用

为研究开发活动所发生的其他费用，如办公费、通讯费、专利

申请维护费、高新科技研发保险费研发成果的论证、评审、验收费

用等。此项费用一般不得超过研究开发总费用的10%。

3.8 各项目现有专用设备、固定资产及需新增设备、固定资产也应在

计划书中列明。

4、审批立项计划书，形成立项决议：

4.1公司经理办公会根据立项计划书，经研究同意实施研发项目(自

主、委托、合作研究)，签批立项决议。

4.2立项决议及立项计划书经批准后，分别送达至总经理、研发部、

财务部。

4.3一般立项计划书应在每年的12月提交公司决策层，立项决议12

月31日前签批。年中有新项目需要立项的，所需资料及程序同上。

4.4如果项目当年未完成，需要第二年继续开发的，应在立项决议中

单独列明并附新的计划书及当年已开发情况的总结报告。

4.5所有研发项目的启动、暂停、终止都须经总工、总经理、财务部

审批。项目组人员、设备变动须报总工、财务部备案。

5、项目鉴定及研究成果报告

5.1 按高新区科技局规定时间和要求，分项目填写项目情况表，项目

鉴定表及其他资料，由科技局对所立项目进行鉴定签章。

5.2开发项目完成后应及时提供研究开发项目效用情况说明、研究成

果报告等资料。

5.3开发项目过程中或完成后可分别进行查新、专利申请、技术成果

鉴定、客户使用情况证明等。

5.4委托、合作开发项目的，分项目提供委托、合作研究开发项目的

合同、协议。

二、研究开发费用归集

1、研究开发经费是用于进行科学技术研究、开发、新技术推广应

用的专项费用，必须按计划专项管理，统筹安排，节约使用。

2、研究开发经费的来源： 政府的专项科技基金拨款;公司自筹研

究开发项目资金;

3、研究开发经费的管理

3.1公司应根据研究开发项目的立项报告建立研究开发费用专项明

细账，准确、及时地归集各个项目的费用发生情况。多个研发项目使

用共同资源的，应采用科学合理的方法将研发费用在各个受益项目之

间分摊。

3.2公司研发中心是研究开发经费的归口管理部门，具体负责研究开

发费用的签批、核定;公司财务部是研究开发经费的归集、核算、记

帐、监督部门，研究开发经费实行专款专用，严格管理。

3.3研究开发经费的拨付在研究开发项目立项决议审批后才能启

用，并由项目负责人按规定的使用范围严格控制、合理使用。

3.4研究开发有关内容需要与外单位合作或委托其进行的，必须签

订科研项目外委技术合作研究合同，该合同须由公司研发中心审查后

才能生效。

3.5研究开发经费报销时，须由项目负责人、技术副总审核签批，

并在核销票据上注明所属项目后方可到财务核销;所有新产品领料，

不论是研发中心还是生产、技术部门，只要是用于新产品的材料必须

由研发中心调度签批，注明所属项目后方可领取。

3.6研究开发经费一律不进入本单位产品成本，在管理费用中列支，

月末仓库原材料耗用表中根据新产品领用材料金额在表中单独列明，

领料单单独附后。

3.7各项目因研究开发工作需要，购置2000元以上设备、仪器者，

须列入该项目专用固定资产，项目完成后办理有关转资手续。

3.8财务部应每季度对研究开发费进行汇总分析，包括金额及占收

入的比例，如未按计划执行或比例未达到高新技术企业规定标准，应

及时通知相关部门进行调整。公司的财务会计报告须披露研究开

发费用的相关财务信息，包括研究开发费用支出额度及其占销售收入

的比例情况等。

3.9对于研究开发经费的使用情况，公司将组织适时审查，如发现经

费使用不当的，要追究项目负责人的责任，并视具体情况，收回项目

计划安排的投资款项。

2010-06-07

第三篇：软件项目开发管理流程

研发中心项目开发管理流程

1，新项目开发管理流程

按照项目管理规范，项目管理分为：项目启动—》项目计划—》项目执行—》项目控制—》项目结尾。5个阶段。根据该管理流程和我公司实际情况，将新项目开发的管理流程制定如下图：

1.1 项目立项

项目立项阶段，首先由的项目经理编写《项目立项报告》。

研发项目立项报告模板.doc

1.2 立项评审

《项目立项报告》编写完成后，交由项目管理委员会进行立项评审，评审通过后由副总经理签字确认立项。确定需求分析和项目设计阶段的时间和人员安排。

1.3 需求分析

需求分析阶段，需要与用户交流，双方对软件需求取得共同理解基础上达成的协议。编写并完成软件需求说明书：也称软件规格说明书。

软件需求说明书模板 .doc

1.4 系统设计阶段

常规的系统设计需要依次完成《概要设计说明书》，《详细设计说明书》。以下是文档的简要说明：

概要设计说明书：该说 明书是概要设计阶段的工作 成果，它应说明功能分配、模 块划分、程序的总体结构、输 入输出以及接口设计、运行设 计、数据结构设计和出错处理 设计等，为详细设计奠定基础。

概要设计说明书.doc

详细设计说明书：着重 描述每一模块是怎样实现的， 包括实现算法、逻辑流程等。详细设计说明书.doc

详细设计说明书编写完成后，项目经理应该依次编写安排项目开发工作计划。工作计划安排可以根据项目经理的习惯进行工作计划编写。建议采用project。附件为综合考务平台的工作计划安排，可以供参考：

考试考务综合管理平台工作计划.mpp。并且确定里程碑，以便在后期项目执行过程中，对其进行确认。 对于大项目，建议按照项目设计流程，先进行概要设计，再到详细设计。但是对于特殊项目(项目周期较短，小项目)，可以讲概要设计和详细设计阶段合二为一，编写功能，接口方案。但是值得注意的是，该方案中，仍然需要涵盖项目模块功能，用户权限和各模块实现逻辑，接口等。

项目设计开发方案.docx。

1.5 项目设计评审

设计阶段完成后，项目经理填写《项目设计评审表》，将相关文档交由项目管理委员会进行项目设计评审。通过评审后，方可进行编码工作。

项目设计评审表.docx

1.6 编码和测试用例编写阶段

项目编码阶段，项目经理需要对项目执行情况进行控制和监督，其中包括(项目输入，项目输出，里程碑)。如果由于特殊情况，如：需求变化，人员临时调配，或者其他原因导致的项目范围和时间，计划等变更，项目经理应该及时填写变更申请。并提交给项目管理委员会。作为之后项目输出验证的重要依据项目变更申请书.doc。

在此阶段，测试人员应该根据《需求说明书》，《概要设计》和《详细设计说明书》的内容，编写相应的《测试用例》。 1.7 测试阶段

编码完成后，应该移交测试组进行相关测试工作。按照测试流程，需要提交《测试申请表》。测试人员在接收到《测试申请》后，应该与研发人员讨论《测试用例》的相关内容，确定测试时间，开始程序测试。并在测试工作完成后，编写对应的《测试报告》。

1.8 结项评审与验证

项目负责人和测试负责人分别填写《项目结项评审表》，交由项目管理委员会进行评审。评审通过后，由研发中心副总经理进行发布确认。

项目结项评审验证表.doc

1.9 新产品发布

编写《用户手册》。方可进行新产品发布。

2，旧项目升级开发管理流程

旧项目的升级，依照如下流程：

2.1项目升级需求分析

项目需求分析，需要收集用户在产品使用过程中，已经技术人员在调试过程中的反馈作为需求分析的输入。并填写对应的项目升级需求报告表。项目升级需求报告表.doc

2.2 升级评审

将《升级需求报告》交由项目管理委员会，评审通过后，进行升级设计。 2.2项目升级设计

项目负责人，根据需求报告和升级具体情况，编写升级开发方案。项目升级开发方案.docx。并安排整改工作计划。

2.3 项目升级设计评审

升级开发方案完成后，填写《项目设计评审表》，交由项目管理委员会评审。

2.4 编码

按照项目升级开发方案进行编码设计，如果编码工作中，发生特殊情况需要变更计划，或者项目范围等，同样需要提交《变更申请》，作为项目验证的基础。 同样，此阶段，测试人员应该编写或者修改相关测试用例。

2.5 测试

编码完成后，应该移交测试组进行相关测试工作。按照测试流程，需要提交《测试申请表》。测试人员在接收到测试申请后，应该与研发人员讨论《测试用例》的相关内容，确定测试时间，开始程序测试。并在测试工作完成后，编写对应的《测试报告》。

2.6 升级输出评审

项目负责人和测试负责人分别填写《项目结项评审表》，交由项目管理委员会进行评审。评审通过后，由副总经理进行发布确认后。

第四篇：软件开发项目管理（范文）

管理目标

1、 所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求;项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。

2、 项目管理三要素平衡(时间/成本/质量)，即开发项目按需按时按质的完成。

3、 目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。

执行概述

1、 建立有效的工作流程保证项目的顺利进行，初期使用传统RUP过程，引入部分敏捷方法，团队磨合完成后逐步实现敏捷开发全流程管理。

2、 明确项目目标，制定具有可行性的项目计划，有效明确的分解项目需求。

3、 跟踪设计/开发/测试/回归/发布全流程，推动项目按预定计划执行。

4、 解决项目过程中出现的问题和冲突，一般集中在需求不明/工作量或时长/开发难度/跨部门协调等几个方面。

5、 调动开发团队的积极性，创造力，推动团队成员在项目过程中的学习成长。

6、 风险识别、风险控制以及风险的预案。

项目管理

1、需求阶段

对项目进行技术可行性分析、技术评估、成本评估以及风险评估。 与需求提出方的代表进行需求讨论，明确项目的目标、价值。 确定项目范围、功能及优先级。

组建项目团队，特别要搞清楚项目的关键人。 项目启动会议，相关的关系人都必须参加。

2、设计阶段

根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS);资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源);数据库设计;系统设计;文档(包括系统用例、Demo、测试用例等);评审会议。

设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。

该阶段交付成果需要进行评审。

3、执行阶段(开发和测试) 准备开发环境、测试环境。 跟踪，推动项目按计划进行。

项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB审核等。 对需求变更进行控制管理。

测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。

4、发布阶段

包括制定项目发布计划，用户培训，发布上线。

5、试运行阶段

数据监控(日志、服务器状态)，根据监控出现的问题，及时进行处理，改进性能问题，特定情况执行补丁升级。

6、收尾阶段

产品交付，项目总结会。

常见问题

1、开发时间的估算

制定项目计划时，需要估算每个任务所需的时间，其中主要是开发任务中模块的分配和时间估算，在公司现有的技术框架下，开发人员主要的工作是投入在具体的业务逻辑实现上。通常单个模块开发时间取决于以下因素：

1、负责模块的业务逻辑的复杂程度。

2、开发人员的技术水平和对项目所在应用的熟悉程度(包括对框架和应用的熟悉程度)。

3、模块技术实现上是否存在难点，所谓的技术难点定义是：在现有系统中还未实现的、开发人员自身未没接触过的技术。对于这样的难点，开发者没有相关的代码可以参考，自己也没有经验，所以需要投入学习时间用于研究解决。

模块分配和开发时间估算的步骤：

1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。

2、召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，分配给开发人员，如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。分配模块的时为确保开发的速度和质量，基本原则如下：

A、类似的模块由同一人负责开发，比如用户信息的增删改应由同一开发者负责。这样开发者对相关逻辑会比较熟悉，代码/接口的定义也会相对明确，沟通的成本低，相应可以降低功能实现的缺陷概率。

B、技术难度较大的模块由技术水平比较高的人负责。 C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。

3、模块分配完成后，开发人员评估自己负责开发的模块所需要的时间。在此过程中应

4、对开发人员估算的时间进行确认。在确认过程中作为，项目管理者将预估时间和开与开发者讨论每个模块的技术实现细节，使时间的估算更加准确。 发人员估算时间进行比较。那些差异较大的，与人员探讨其中的缘由。对于时间周期比较长的任务，将任务拆分为更小的子任务，每个任务的完成时间为8-24工时，消除时间周期较长的任务，避免不确定性影响项目的进度。

2、CodeReview CodeReview是保证项目中代码质量非常重要的一个环节，在这一环控制不严往往是测试后出现大量bug的主因，有时甚至导致返工;关于CodeReview执行，首先应有编码规范和代码审查规范。通过这两个文档来规范开发人员的代码实现，代码编写者必须要严格按照规范来进行;代码审核者根据这些标准来CodeReview代码，同时在CodeReview过程中需要不断完善该文档。

CodeReview一般可按以下步骤实施：

1、 检查开发者的代码实现是否遵循了编码规范。

2、 从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。

3、 代码编写者和代码审核者坐在一起，由代码编写者按照UseCase依次讲解自己负责的代码和相关逻辑，代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug，对这些bug记录在案。

4、 代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。代码需要检查Bug。同时全面兼顾，确保代码整体上结构优良;审核完毕后，代码审核者编写“代码审核报告”记录发现的问题及修改建议，提交给相关人员。

5、 代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出。

6、 代码编写者bugfixed完毕之后给出反馈。

7、 代码审核者把CodeReview中发现的有价值的问题更新到"代码审核规范"的文档中，对于特别值得提醒的问题可群发email给所有技术人员。

3、需求变更管理

需求变更管理也是项目管理中最重要的一个环节，对需求变更管理的有效性将直接影响对待需求变更的正确态度：

1、需求变更是不可避免的。

2、需求变更要必须被管理。

3、积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。 需求变更管理的目标：

1、相关的干系人必须清楚地了解发生的变更。

2、变更处于有效的管理中。

3、尽量降低变更带来的风险。

通过制定需求变更的流程，确保项目中的需求变更有效地进行，实现上述的目标。需求变更流程：

1、确定需求的基准线。将以UserCase作为需求基准线，在UserCase确认之后的任项目的成功与否。 何需求改变，都需要走需求变更流程。

2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。

3、项目管理者评估该需求变更。针对接收到的需求变更的要求，召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。项目管理者对项目的成功与否负有主要的责任。需求变更的决策应由项目管理者做出。

4、需求变更确认后，由专人将生成需求变更单记录下来，通知给项目中所有关系人。

5、确定变更的负责人。承担需求变更的具体工作，比如基线控制，对需求变更的记录，并通知相关人员。

6、相关人员接收到确认的需求变更后，需求分析人员修改需求说明书和UserCase的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部分。

7、按照变更后的计划实施项目，并进行检查，跟踪，对变更后的实施反馈和可能出现的问题及时沟通和处理。

8、需求冻结。项目越到后期，需求变更对项目的影响就越大，所以在一定时候要进入需求冻结阶段，不再接收新需求或需求的变更。

4、风险管理

影响项目成败的因素涉及方方面面，并且风险伴随着项目的始终，是客观存在的，风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面，常见风险如下：

1、目标以及需求不明确

为了市场竞争或内部管理决策的需要，业务部门提出的需求往往要求的时间比较紧迫，需求的提出大多停留在几张纸或口头的传达上，没有正式的业务需求文档，在没有明确的需求范围的情况下，有时为了迎合业务部门的口味匆匆开工，过程中用户不断地提出新的想法，技术人员开始疲于奔命和应付，很难保证项目的进度和质量，也难以取得业务部门的认可。

在项目的前期一定要采取相应的手段或措施，与业务部门共同明确项目目标、需求范围，充分考虑现有的时间和资源约束，将需求排定优先级，对于关键的需求优先实现，其他辅助性的根据过程中的具体情况进行滚动式计划，并取得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统原型等手段让用户在前期充分暴露自己的想法和需求。

2、项目目标扩大以及需求变更

在有了明确的目标和需求范围的情况下，需求的变更还是不可避免的，业务部门在看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控制，新的需求的加入通常会影响已实现的需求，并且对项目进度和成本产生很大的影响。项目管理者针对这种情况一定要采取严格的变更控制流程，不能碍于面子，否则最终的结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相关团队成员进行分析及评估，作为是否实施的依据，变更控制负责人根据分析结果判断是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求。

前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户)，所有的需求要经过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确认、UserCase确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变更时，严格按照需求变更流程执行。在分析设计阶段的中的确认和评审也是降低此类风险的重要手段。

3、代码质量风险

质量风险主要指开发代码的质量。在制定项目计划时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响很大。开发人员为了赶进度在比较紧张的时间需要完成指定的任务，可能就存在很大的开发质量问题。在编码前，开发人员要对框架熟练掌握;一份好的系统设计文档对指导开发非常重要。

往往有这样一种情况，每个团队成员按照项目计划报告进度都是100%完成，但一到最后系统交互测试或集成的时候就会发现一大堆问题。这需要在项目实施过程中采取有效的措施来规避风险，通常的做法有同行评审，比如概要设计完成之后，邀请其他项目组的技术专家进行技术评审以发现架构设计问题;管理评审，通过组织级的质量审计看产品以及实施过程是否满足质量要求;代码走查，在编码过程中加入至少一次的代码走查，排查不符合规范或性能要求的代码，走查通常能够发现50%-70%的错误;每日构建，这是一种非常有效的方法，可以避免把各部分的集成问题拖到最后，并且能够及时发现相应的错误，日构建一般在项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。

4、人员技能和资源的不足

项目实施过程中由于人员技能欠缺造成的进度延后和软件质量问题并不少见，一个熟练的技术人员完成同样一个任务需要3天，但一个新手可能就需要7-10天。项目管理者应该在前期就分析清楚项目所要采用的技术以及相应的人员技能要求，针对不同的角色，及时采取相应的技能培训，以保证项目的顺利实施。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找可替代方案。这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风险在后期或中期出现。

5、缺乏良好的团队协作

软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清楚工作界面及接口关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融为一体。这是一个团队的软实力，团队之间的协作好坏也将是个潜在的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。

6、项目会议

组织会议是项目执行过程中一项非常重要的工作任务，项目过程中很多重要的决定都是在会议中做出的，不成功的会议会对项目本身造成了不好的影响。

不成功的会议通常表现为如下形式：

1、会议氛围不好，参与者发言不踊跃;

2、会议讨论常常偏离主题;

3、会议没有取得预期的结果;

4、会议时间常常一拖再拖。

这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的目的，很多人都对这样的会议都有抵触情绪，对此也是深恶痛绝。以下是组织会议时应该注意的问题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必须要清楚：

1、会议是否会取得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有可能取得成功，这是会议成功的充分条件。

2、会议的组织者和参与者的想法通常是不一致的，有时候甚至会大相径庭。所以不要希望会议的参与者和你一样，对会议有着如此的期待，对大多数参与者而言，在会议中他只是一个发表想法的人，他不用对会议的成功承担责任。

3、以下十一条最佳实践是形式上的约定，具体的实施可以根据实际情况来做。 组织会议的十一条最佳实践：

1、只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。

2、提前发出会议议程，以便会议参与者知道他们来做什么。

3、请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确保必要人物都在的情况下一次会议参与者越少效果越好。

4、提前预约参与者的时间，以确保他们能按时到场。

5、会议的开场很重要。会议组织者要在开始前做好几件事情。通常我建议有几点要在开场时说： A、再一次强调会议的目标，我们来做什么。

B、强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求讨论会，主要是讨论做还是不做以及告知大家我们要做什么，而不要把太多的精力放在讨论如何做上面。

C、说明一下会议的规则。如要发言，请举手;不要有小圈子讨论;不要打断别人的讲话，等别人说完你再说等等。

6、会议过程中时刻注意引导和控制会议，以确保会议按照目标进行。一次会议的氛围是否良好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。

7、会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成果之一。

8、会议要有结论。我们常在会议上听到有人说："大家讨论了这么半天，结论呢?"。没有结论的会议是没有意义的。

9、会议后别忘发会议纪要，以及一些Action，什么人什么时候做什么。

10、会议后的action执行情况的反馈很重要。反馈是对会议参与者的尊重，同时也告知了会议的效果。否则会让大家感觉到这是一个可无可无的会议，大家以后参与的积极性也会降低。很多会议往往都不注意这一点。

11、按时结束的会议会受到所有人的欢迎。

第五篇：新产品研发项目管理

(2天)

一、课程背景：

课程在对新产品项目和项目管理的基本概念做出明确阐述的基础上，着重培训学员的实施能力，针对于项目管理人员围绕项目组建、计划管理、项目计划控制、质量控制等主要环节的操作及容易出现的误区和问题做重点讲解，另外介绍研发管理的一些主要工作方法。

二、课程收益

了解新产品开发管理体系框架;领会开发项目组织环境及其工作关系;掌握项目项目管理方法在新产品开发中的应用;熟悉新产品开发计划编制与执行;掌握新产品开发过程管理与控制;把握新产品开发风险管理;了解如何正确地制定新产品研发战略;学习选择正确的新产品项目的技术和方法;学习如何建立新产品研发项目管理体系;学习新产品研发的风险控制和管理的要旨;学会评价和改善新产品开发项目绩效的途径;新产品研发的项目模板与工具介绍;了解新产品开发收尾与评价体系。

在这个课程中，我们将至少为您解决如下问题：

如何对产品研发进行项目化运作?如何处理多项目并存的产品研发管理?如何应对产品研发的技术变更?如何保证研发项目的质量和产品质量?怎样才能改善新产品研发项目的绩效?如何建立高效的研发项目团队?

三、课程内容

第一部分、项目管理基础篇

1、 案例研讨：开发项目经理的烦恼

 项目与项目管理

 项目管理与日常运作

 项目管理国际化组织

 项目经理职业化发展

 项目管理九大知识体系

 项目管理五大过程组

 项目生命周期管理与新产品开发的全生命周期管理

 技术研发与产品开发管理特质与差异

 新产品开发定位与价值链分析

 企业新产品开发历程演进

 新产品开发项目成功与失败因素分析

2、 新产品开发管理体系构建

 新产品开发战略匹配

 产品战略与产品规划

 新产品开发组织结构

 新产品开发流程设计与优化

 新产品开发项目管理方法论

 新产品开发人员的薪酬激励与考核

 新产品开发人员的生涯规划与专业发展

3.新产品开发组织环境

 新产品开发项目管理组织结构及其如何对项目产生影响

 新产品开发项目组织环境及其工作关系

 各职能部门如何参与和支持新产品开发项目?

 新产品开发项目与领导的关系

 新产品开发项目与支持体系，及其工作模板

 如何建立多项目的工作环境和工作系统，以高效发挥资源效率?

 如何建立多功能开发小组

 模拟：新产品开发中的角色模拟

 新产品开发中项目组织容易出现的几个问题

 成功的新产品开发项目组具备的典型特征

 新产品开发职能型组织的特点

 新产品开发项目管理四种基本团队及职责

 企业在不同发展阶段和不同产品形态下新产品开发项目组织有何不同

 案例研讨：新产品开发项目干系人识别与管理

 新产品开发项目经理的定位

 新产品开发项目经理的素质要求和责权利

第二部分、新产品研发项目管理应用篇

4、 新产品开发项目启动

 NPD中项目管理概览

 如何从业务计划到新产品开发项目的启动

 新产品开发项目启动的必备要素

 如何选择符合市场需求的产品

 新产品开发项目章程与任务书模板介绍

 接受产品开发项目任务书

 新产品开发项目启动会

 新产品开发项目环境准备

5、 新产品开发项目计划

 从市场业务计划到开发计划

 演示讲解：新产品业务计划书

 新产品开发项目计划制定的原则、要素

 新产品开发项目计划制定的步骤和注意事项

 新产品开发项目管理计划模型与模板

 如何让项目成员参与项目计划编制

 新产品开发项目三级计划制定的时间点

 拟订新产品开发项目合同

 新产品开发项目进度计划制订技术与技巧

 新产品开发项目依赖关系

 新产品开发项目工期估算

 网络图方法应用

 关键路径法增值

 随堂练习：根据新产品项目任务书，制定出新产品开发项目进度计划

 进度比计划快怎么办?

 如何使计划适应变化?

 可指导性、可操作性和可变性计划是如何做出来的?

 新产品开发项目进度如何确保满足客户要求，过程中又如何实施进度监督与控制，

资源或

 需求发生变化后的进度基准如何确定，对项目进度应如何评价?

 新产品开发项目资源计划

 新产品开发项目职责矩阵

 新产品开发项目沟通计划

6、新产品开发项目执行与监控

 新产品开发项目执行模型

 新产品开发项目质量目标与质量保证

 新产品开发项目团队建设

 新产品开发项目变更控制组织

 新产品开发项目变更控制流程

 新产品开发项目变更控制权限设定

 新产品开发项目变更多级控制工作系统

 新产品开发项目控制基本过程

 开发部门经理在产品开发过程中应介入的程度  新产品开发项目的三条管理主线

 新产品开发项目的四种有效控制手段

 新产品开发项目监控的五种方法

 多个产品集中开发时如何协调资源冲突

 如何设定产品优先级

 开发项目经理与开发主管、开发工程师的关系处理  开发项目经理与开发部门经理的错位预防

 开发经理在研发财经与成本管理中关注的重点

7、新产品开发项目风险管理和问题管理

 新产品开发项目风险防范

 新产品开发项目风险意识如何树立

 新产品开发风险识别方法与风险知识库

 典型的新产品开发风险类型

 新产品开发风险责任与评估分析

 新产品开发风险评审与风险审计

 新产品开发风险的应对灵活性如何把握?

 面对积极风险和消极风险的预防策略与应急措施  随堂演练：新产品开发风险应对讨论

 为什么对风险和问题要进行集中监控

 新产品开发问题管理管理流程

8、新产品开发项目收尾

 新产品开发项目总结

 新产品开发项目数据库更新与关闭

 发布项目终止信

 关于新产品开发项目人事问题

 关于新产品开发项目专利与安全问题

 关于新产品开发项目的评估与考核

 关于项目的考核

 开发项目经理的考核

 开发工程师的考核

 新产品开发项目的跨部门考核

9、新产品开发评价体系

 新产品开发计划和成果评价方法

 新产品开发项目优先级、开发进度、开发成本评价方法  新产品开发商业转换率收益指数评价方法

 新产品开发立项考核指标

课程总结