项目管理指导书

1、项目管理指导书文 件 编 号：KDC-版 本 号：V 0. 2实 施 日 期：保 密 等 级：秘密 机密 绝密流程主导部门： 李洪强 会 签： 修订记录日期版本号描述作者2005-8-20.1初稿完成李洪强2005-8-260.2根据结对互审的结果修改李洪强目录1目的和范围72项目运作指南72.1PDT的组织结构72.1.1PDT人员的职责72.1.2PDT与相关部门的运作关系72.1.3PDT的业务汇报关系：72.2PDT的组织运作82.2.1PDT的组建82.2.2PDT的解散82.3PDT的授权与决策83项目计划管理93.1概念阶段项目计划93.2端到端项目1/2级计划93.3计划阶段项

2、目计划103.4端到端项目3/4级计划104指导和管理项目114.1控制项目计划114.1.1计划评审115项目变更管理115.1项目计划变更115.1.1计划变更申请单模板126项目经验教训总结127项目问题管理127.1定义127.2问题解决上报路径127.3生命周期137.3.1行为图137.3.2相关描述147.3.3职责147.3.4问题记录矩阵157.3.5计算优先级方法：157.3.6问题记录单157.3.7管理单个问题157.4问题分类标准168风险管理168.1风险的分类168.2研发常见风险178.3评估风险188.3.1风险的定量评估198.3.2风险的定性评估198.4

3、风险防范措施208.4.1人力资源风险的应对措施208.4.2对于需求变动的缓解措施208.4.3对于技术因素的缓解措施：218.4.4环境、物料、设备风险的缓解措施：218.4.5进度风险的缓解措施218.4.6商业风险的缓解措施218.5风险的监控218.5.1对于人员风险的监控因素：218.5.2对于市场风险的监控因素：218.5.3对于技术风险的监控因素：218.5.4环境、物料、设备风险的监控因素：228.5.5进度风险的监控措施228.5.6商业风险的监控措施228.6风险的跟踪228.6.1风险跟踪单228.6.2风险分解238.7风险管理流程238.7.1适用对象238.7.2

4、流程图238.7.3风险跟踪管理说明239项目沟通管理操作指导239.1项目组成员日志操作指导239.1.1日志目的239.1.2提交对象239.1.3提交时间249.1.4日志归档249.2项目组成员周报操作指导249.2.1周报目的249.2.2提交对象249.2.3提交时间249.2.4周报归档249.3项目组周报操作指导249.3.1周报目的249.3.2提交对象249.3.3提交时间249.3.4周报归档249.4项目组周例会操作指导259.4.1目的259.4.2参加人员259.4.3时间259.5项目组月度工作总结报告操作指导259.5.1目的259.5.2提交对象259.5.3

5、提交时间259.5.4归档259.6项目组月度工作总结例会操作指导259.6.1目的259.6.2参加人员259.6.3时间259.7PDT双周报操作指导269.7.1周报目的269.7.2提交对象269.7.3提交时间269.7.4周报归档269.8PDT双周例会操作指导269.8.1目的269.8.2参加人员269.8.3时间269.9研发系统运营月简报操作指导269.9.1目的269.9.2提交对象269.9.3提交时间269.9.4归档269.10例会的程序2710配置管理271 目的和范围本指导书的目的是帮助项目管理人员在实践中管理项目的。本文中讲述了有关项目管理的相关知识。同时也讲

6、述了在IPD实施过程中制定的相关制度和实施细则。本文的阅读对象为项目管理人员，包括产品经理、项目经理、核心组成员等。2 项目运作指南2.1 PDT的组织结构PDT一般由PDT经理及相关核心人员组成。PDT的构成图如下：制造操作人员PQAPDT经理项目操作员采购代表市场代表销售代表开发代表财务代表客服代表制造代表网管工程师资料工程师结构工程师软件工程师测试工程师硬件工程师网管组长资料组长结构组长软件组长测试组长硬件组长采购人员市场策划专员销售专员高级制造工程师试制工程师技术支持工程师系统工程师图2-1 PDT组织结构图2.1.1 PDT人员的职责参考产品开发流程-角色和职责说明2.1.2 PDT

7、与相关部门的运作关系l PDT位于产品线与资源线的节点，PDT是产品开发的责任主体，PDT的设立主要根据产品开发实际情况进行，一般起于任务书下达，终止于GA点。l IPMT对PDT任务执行情况进行考核。2.1.3 PDT的业务汇报关系： l PDT经理接受IPMT的领导，并向其汇报工作；l PDT核心组成员和外围组成员在相关资源部门的指导下，完成PDT经理交给的各项工作，并定期向PDT经理和资源部门汇报工作；l 项目操作员向LPDT汇报工作并接受领导；2.2 PDT的组织运作2.2.1 PDT的组建在任务书发放后，开始组建PDT，并进行任命2.2.1.1 PDT经理确定l PDT中最重要的成员

8、为PDT经理，负责产品研发在相应领域内的任务分解，与相关资源部门打交道，因而应具备较深的技术背景和较强的沟通能力。l PDT经理的来源：a. IPMT的提名；b. 相关资源部门提名；c. IPMT最终批准。2.2.1.2 PDT小组扩充概念决策评审通过后，根据情况增扩PDT；根据项目任务书进行任务分解，制定各级计划。计划决策评审通过后，由PDT经理与相关资源部门协商确定相关项目小组的成员，组建全员小组，并进行全员任命。2.2.2 PDT的解散PDT的解散分为正常解散和异常解散两种情况。正常解散是产品研发任务顺利完成，PDT完成历史使命而宣告解散；异常解散是指产品撤项或转向情况下的PDT解散。l

9、 正常解散产品运行稳定，全套资料文档齐全，在GA点。PDT完成历史使命而宣告解散。l 异常解散异常解散有很多原因，通过IPMT的评审来决定PDT是否继续运作下去。PDT异常解散后对人员进行相应的安置。2.3 PDT的授权与决策IPMT在项目的各个阶段给PDT分配资源并授予PDT对产品研发所有具体事务执行上的决策权，以保证PDT获得充分授权。获得充分授权的PDT的决策变得更快更有效。这种决策是一种集体决策，因为这是让最明白的人最有权的方法，并且这些决策在需要理解的人之间得到充分沟通。3 项目计划管理图3-1 项目计划图总则：所有项目计划制定时，应加入管理类活动，如：管理例会、评审等。3.1 概念

10、阶段项目计划计划制定责任人：PDT经理参与制定计划者：概念阶段小组成员输出：概念阶段项目计划模板：参见概念阶段WBS3,4级计划模板计划制定步骤：l 获取概念阶段WBS3,4级计划模板；l PDT经理组织小组成员在PQA指导下进行裁减、确定概念阶段主要活动/里程碑和重要的依赖关系以及每项任务的启动/完成时间,最终形成一份完整的概念阶段项目计划以指导概念阶段工作。3.2 端到端项目1/2级计划计划制定责任人：PDT经理参与制定计划者：概念阶段小组成员输出：端到端项目1/2级计划模板：参见端到端WBS1,2级计划模板计划制定步骤：l 获取端到端WBS1,2级计划模板；l PDT经理组织小组成员进行

11、裁减、确定产品开发端到端主要活动/里程碑和重要的依赖关系以及每项任务的启动/完成时间,最终形成一份完整的端到端1,2级计划，每个职能领域的代表负责制定本领域的端到端1,2级计划，然后由POP统一汇总形成产品级别的端到端1,2级计划。3.3 计划阶段项目计划计划制定责任人：PDT经理参与制定计划者：PDT核心组成员输出：计划阶段项目计划模板：参见计划阶段WBS3,4级计划模板计划制定步骤：l 获取计划阶段WBS3,4级计划模板；l PDT经理组织小组成员进行裁减、确定概念阶段主要活动/里程碑和重要的依赖关系以及每项任务的启动/完成时间,最终形成一份完整的计划阶段项目计划以指导计划阶段工作。3.4

12、 端到端项目3/4级计划计划制定责任人：PDT经理参与制定计划者：PDT核心组成员、外围组成员输出：端到端项目3/4级计划模板：参见开发阶段WBS3,4级计划模板、验证阶段WBS3,4级计划模板、发布阶段WBS3,4级计划模板计划制定的步骤：l 获取端到端项目1,2级计划，开发阶段WBS3,4级计划模板、验证阶段WBS3,4级计划模板、发布阶段WBS3,4级计划模板；l PDT核心组成员分别组织其外围组成员对自己负责的业务进行详细的活动分解（WBS），在WBS的基础上对研发项目开发计划模板中任务进行增删；l 各核心组成员及其外围组对自己所负责的活动进行工作量估计和资源需求预估；l 各核心组成员

13、及其外围组提出各自与其他活动的配合关系和时间要求；l 每个PDT核心组成员检查各自的计划是否与项目阶段里程碑一致，如果不一致则修正自己的计划和资源需求，或者与PDT经理沟通调整阶段时间。l 每个PDT核心组成员检查需配合的其他PDT成员活动计划是否匹配，如果不能匹配则与之沟通并协商解决。如果不能达成一致则提交PDT经理解决；l PDT经理将各PDT核心组成员的计划收集起来并组织PDT核心组成员讨论修改和整合，确定最终的关键路径和里程碑，调整其他相关路径的起止时间。最后形成完整详细的研发项目开发计划。l 各核心组成员在各个领域提出风险并进行风险分析，提出可能的降低风险的措施，最后由PDT经理在业

14、务计划中汇总。l PDT核心组成员在研发项目开发计划的基础上提取其关键的监控点和与之配合的相关任务，形成各个PDT核心组成员的监控计划。4 指导和管理项目4.1 控制项目计划4.1.1 计划评审表4- 计划评审表说明计划类型批准人参与人概念阶段项目计划PDT经理PDT核心小组成员端到端项目1/2级计划IPMTPDT经理、PDT核心小组成员计划阶段项目计划PDT经理PDT核心小组成员端到端项目3/4级计划PDT经理PDT核心小组成员、相关外围小组成员5 项目变更管理5.1 项目计划变更表5-1 项目计划变更说明表变更类型变更申请人批准人备注1级计划变更PDT经理IPMT涉及决策评审点的变更2级计

15、划变更PDT核心组成员PDT经理各个职能领域关键阶段的变更涉及计划变更时，由变更申请人填写计划变更申请单，提交相关批准人批准。变更原则：l 当进度和原计划偏差大于（10）时，由变更申请人填写计划变更申请单，提交相关批准人批准。l 目标成本：当目标成本上升大于10时，需要提交成本变更申请报告。l 偏差计算公式：（实际时间（成本）计划时间（成本）/计划时间（成本）5.1.1 计划变更申请单模板表5计划变更申请单产品名称或型号变更申请人申请日期变更描述变更原因造成的影响审批IPMT（LPDT）： 日期：6 项目经验教训总结在一级里程碑结束时，由LPDT负责，使用各阶段项目经验教训总结模板编写项目的经

16、验教训总结。7 项目问题管理7.1 定义“问题”是一个通用的名词，指项目要关心的事。可能需要使用一个或多个问题解决流程来解决一个问题。它可能是下列中的一个或几个：行动项管理，变更管理，等等。一旦成功完成了相应的问题解决流程，并通过书面协议认定问题已经解决，则可以关闭该问题并通知相关的利益相关人。对问题的整体管理是PDT的主要角色。问题解决流程的启动者是PDT经理。该指定方将在合理的时间内，通过合理的工作努力解决问题，当无法获得可接受的解决办法时，他会向更高的级别汇报。上报路径中上报的对象可以是下列个人或可以代替他/她的人。7.2 问题解决上报路径表7-1 上报路径表级别l责任人第5级IPMT第

17、4级LPDT 第3级PDT 核心代表第2级项目经理第1级任何员工7.3 生命周期7.3.1 行为图7.3.2 相关描述问题解决管理流程中问题的状态有以下四种。7.3.2.1 提出问题（submit）任何员工对产品开发过程中发现的问题进行描述，进行提交。当一个问题被提交那么这个问题将立即被注释为提交状态（Submit）7.3.2.2 开启状态（Open）当一个问题被初次鉴别后，并决定解决时，问题由提交状态转变成开启状态（Open）,可以从上图看出有多个开启状态，当一级发现无法解决时可以向自己的上级继续提交，这样问题又重新转变成提出状态，当问题被上级接受并责令解决问题又转变成开启状态。因此在问题流

18、程中必须注明问题处于什么阶段。如上图所示任意员工问题，项目经理问题等。7.3.2.3 关闭状态问题无论处于任何阶段都可以被直接关闭，关闭的条件为问题被解决或放弃解决此问题。7.3.2.4 挂起状态问题也可在任何阶段被挂起，当然同样要注明问题在具体什么阶段被挂起。7.3.3 职责表7-2 问题职责划分活动职责提出问题任何项目成员项目问题挂起项目经理PDT问题挂起PDT小组LPDT问题挂起LPDTIPMT问题挂起IPMT项目问题关闭项目经理PDT问题关闭PDTLPDT问题关闭LPDTIPMT问题关闭IPMT解决问题问题责任人问题监控问题负责人注：问题解决人又各阶段负责角色根据讨论指定，其职责是对具

19、体问题的解决负责，包括问题的解决，资源的申请和问题的重新提出等7.3.4 问题记录矩阵表7-3 问题记录矩阵问题编号问题类别问题名称优先级问题责任人状态计划完成日期提出日期阶段注：我们正在开发的平台缺少问题严重性，问题优先级。计划将严重性，紧迫性，完成时间，提交人，验证人放入问题单内显示7.3.5 计算优先级方法：1. 通过分析来确定问题的迫切性，确定迫切度的高，中，低2. 通过分析来确定问题的严重程度， 确定严重度的高，中，低表7-4 优先级严重程度/紧迫程度高中低高高高高中高低中中高中中中低低低高低中低低比较规则：高高中高高中中中低高高低低低7.3.6 问题记录单表7-5 问题记录单编号行

20、动 状态行动责任人计划日期实际日期阶段123注：现在开发的电子模板没有这个内容，正在考虑加入此内容7.3.7 管理单个问题表7-6对于单个问题各个角色的职责范围责任行动 （参见下面的问题状态进展）任何员工1 该情况被认为是一个问题，并在IT系统的问题管理部分进行描述，并提供期望解决时间。2 项目经理，PDT，LPDT，IPMT任命问题责任人，问题验证人和问题责任人项目经理，PDT，LPDT IPMT1 接受该问题为有效问题，对问题进行分析，如确定问题，便组织讨论并对其进行优先级排序，并给定问题解决日期，如可直接给出解决方案或定位此问题非问题级别则关闭问题。2 将问题记录在问题管理系统中，给出问

21、题的编码3 大家认同问题已解决，关闭问题。4 更新产品定义，和项目开发计划，反映因解决问题而带来的变化。问题责任人1 计划的行动和进展被记录在问题行动记录单上。负责对问题管理记录进行准确及时的更新。 2 负责代替项目经理对问题的发展过程进行监督，在适当的时间点组织讨论会议3 对问题责任人提交的问题解决结果进行验证，通过后上报项目经理7.4 问题分类标准表7-7 问题分类标准类别问题分类标准备注第5级在自己的范围内能解决的问题，则自己协调解决；如果在本级解决不了的问题需要向上一级汇报，例如以下问题：1 资源得不到满足。2 接口问题。3 PDT与职能部门之间出现的问题。4 项目进度出现偏差。本类问

22、题必须上报给IPMT，由IPMT协调解决该问题第4级本类问题必须上报给LPDT，由LPDT协调解决该问题第3级本类问题必须上报给PDT 核心组，由PDT 核心组协调解决该问题第2级本类问题必须上报给项目经理，由项目经理协调解决该问题第1级本类问题可以由PDT的任一相关成员解决8 风险管理8.1 风险的分类在产品开发过程中，风险主要来源于如下一些方面：a. 市场风险：市场风险对我们来说主要是指市场需求发生变化，引起产品规格的改变，包括增加新的需求；原来开发的功能需求取消；是否开发某项功能，何时开发完成由确定变为不确定。b. 技术风险：在产品开发过程中出现方案选择失误、方案设计考虑不周等，导致任务

23、不能按时完成；在新产品开发中采用比较先进但还不成熟的技术。采用新的技术可能是出于市场竞争的压力，但是新技术在性能、稳定性方面都会存在一定的风险，导致产品的开发进度及质量受到影响。c. 环境、物料、设备风险：主要是指生产启动时间、计划物料的数量、外购件供货期等方面不能满足实际需求的风险。d. 进度风险：主要是指关键通道上的任务、外协任务、有多个前项的任务、浮动期极短的任务、乐观估计的任务等产生的风险。e. 人力资源风险：新员工技能不熟；从事某项开发任务的工程师突然抽调处理更紧急任务、辞工、生病等引起的风险。f. 商业风险：主要指客户对产品的规格需求、供货时间需求等突然发生变化，或预定的签单不能按

24、时签定或被取消等风险。g. 法律、政策风险：由于国家、地区法律法规的变化，导致产品不能进入市场或进入市场的门槛提高。h. 资金风险：由于公司扩张过快，资金回拢不及时等因素，造成公司流动资金紧张。资金不足导致产品开发、生产无法按计划进行。i. 管理风险：公司管理水平跟不上，导致公司的流程、制度不完善，或已有制度得不到有效的实施，影响产品开发、生产。管理水平及管理队伍上的不足也会对产品开发造成风险。j. 客服风险：由于客户环境的问题造成产品使用、维护、升级出现问题。这些问题将影响产品在市场上的表现。客服上的问题不能很好的解决也会对产品的最终成功造成影响。8.2 研发常见风险以研发领域为例，我们在这

25、里列举了一些常见的风险： 表8-1 研发常见风险说明表序号风险类别概率影响1有些开发人员只能部分精力投入该产品人力资源风险中低2交付日期将被紧缩商业风险中高3产品需求在交付以前经常变更商业风险中高4人员在技术上不配套人力资源风险中低5人员缺乏经验人力资源风险高高6人员流动频繁人力资源风险中高7物理资源的限制环境风险低低8需要采用新的算法或输入输出技术，引起计划延迟技术风险中高9公司高层支持将降低人力资源风险中高部分风险的简单描述：a. 交付日期将被紧缩：由于市场（客户）需求紧迫，我们面对的客户要求我们的交付日期经常比较苛刻，往往会要求我们提前供货，此风险出现的概率很大。一旦出现将减少测试和问题

26、解决的事件，严重影响产品质量。b. 产品需求在交付以前经常变更：由于客户对产品的需求经常变更，而且由于前期需求分析存在一定的局限性，所以产品需求经常容易被变更。一旦出现开发进度将受到严重影响，而且由于新功能的增加将影响到产品的稳定性。c. 人员缺乏经验： 由于新产品对开发测试人员多是陌生的，此部分对计划的完成有较大风险。研发领域的风险需要我们根据实际研发中的经验教训不断的总结完善，而且不同的产品研发项目面临的风险也各不相同，PDT经理需要在制定具体项目计划时，充分考虑不同的风险因素并制定应对措施。8.3 评估风险风险评估是指评估风险对项目造成影响的可能性及后果。一般来说，风险评估要从风险发生的

27、概率以及风险的影响程度（或损失的大小）这两个方面来对风险进行评估。风险发生的概率及影响程序可以采用定性的评估，也可以采用定量的评估方式。通常情况我们只需要采用定性评估就可以了。风险评估由项目组在风险识别后立即进行，将评估结果（风险发生概率、风险影响程度、风险等级、风险响应责任人等）填写入项目风险跟踪单/项目风险跟踪单中，纳入项目管理中进行跟踪管理。8.3.1 风险的定量评估风险发生概率分为五个等级：a. 0.1，几乎不可能b. 0.3，不大可能c. 0.5，可能d. 0.7，很可能e. 0.9，几乎可以肯定 风险影响程度也分为五个等级，分别为1，3，5，7，9。影响取值的标准见下表。表8-2

28、风险影响评估标准影响取值对项目的负面影响程度技术方面进度方面成本方面质量1影响项目的设计性能，但仍然满足用户需求项目进度延误2天以内项目成本超支10%以内发生1起以上一般故障3影响项目的设计性能和功能，但仍然满足用户需求项目进度延误2天或更多项目成本超支10%或以上发生3起以上一般故障5影响项目功能、性能，但用户仍然接受（影响轻微）项目进度延误1周或更多项目成本超支20%或以上发生1起以上重大故障7影响项目功能、性能，但用户仍能接受（造成用户不满）项目进度延误1.5周或更多项目成本超支25%或以上发生3起以上重大故障9影响项目的功能、性能，而用户无法接受项目进度延误2周或更多项目成本超支30%

29、或以上发生严重故障评估了风险发生的概率和影响程度的取值以后就可以计算出该风险的综合影响。计算风险综合影响的公式为：综合影响 = 发生概率 * 危害8.3.2 风险的定性评估风险发生概率分为三个等级：高、中、低风险发生后的影响程序同样分为三个等级：高、中、低。有了风险的概率和等级，我们就可以看出各类风险的影响程度。在产品开发过程中要重点跟踪双高风险。图8-1 各类风险的影响程度8.4 风险防范措施当风险还没有发生时，我们要采取一定的预防措施来降低风险发生的可能性。这样在风险发生时才能降低给产品开发所带来的影响。我们只针对前面提到的风险列举一些示例：8.4.1 人力资源风险的应对措施a. 和有关资

30、源部门充分沟通，达成共识，建立人员的稳定和释放机制，在开发周期内保持人员的相对稳定，资源线调动资源需要和产品部协调，并将此作为产品线考核资源线的一个指标。b. 针对人员缺乏经验，需要进行系列的培训组织，保证项目开发人员及时了解产品知识。c. 工作交接规范化，保证产品开发不会因为人员变动受到大的冲击。d. 对项目组进行良好组织，使得每一个开发活动的信息能被广泛传播和交流。e. 对所有工作进行详细复审，避免只有一个人熟悉该项工作情况出现。f. 对于每一个关键技术岗位都指定一个后备人员。8.4.2 对于需求变动的缓解措施a. 在进行需求分析时和市场人员甚至用户进行充分沟通b. 定出基线进行详细评审c

31、. 周知版本计划，并用市场销售指导书指导市场人员签单时注意公司产品的规格，引导用户d. 严格控制需求的变更，建立需求变更控制机制，e. 及时调整计划；并周知所有项目有关人员8.4.3 对于技术因素的缓解措施：a. 使用模块化、层次化开发模式，尽量降低系统复杂性b. 加强评审8.4.4 环境、物料、设备风险的缓解措施：a. 加强和采购，物料部门的沟通b. 加强新品管理的控制，加强部品标准化c. 尽量选用目前设备可以生产的零部件8.4.5 进度风险的缓解措施a. 强化周报，月报，例会等措施b. 定期（如月）更新日程表c. 重点关注关键路径8.4.6 商业风险的缓解措施a. 和客户定期，充分沟通8.

32、5 风险的监控8.5.1 对于人员风险的监控因素：a. 以上风险缓解措施是否到位b. 项目组成员对于项目压力的一般态度c. 项目组的凝聚力d. 与报酬和利益有关的潜在问题8.5.2 对于市场风险的监控因素：a. 需求变更机制是否运转正常b. 用户需求是否和产品线建立快速通信渠道c. 客户是否具有该产品领域的技术素养8.5.3 对于技术风险的监控因素：a. 定期的质量报告中的缺陷情况b. 相关产品的版本发布机制是否和本产品有较好的配合c. 技术培训的效果是否到位d. 各级审核机制是否有效运转8.5.4 环境、物料、设备风险的监控因素：a. 以上风险缓解措施是否到位b. 将部品标准化列入考核8.5

33、.5 进度风险的监控措施a. 定期了解进展情况b. 不定期了解人员负荷状况8.5.6 商业风险的监控措施l 加强合同评审8.6 风险的跟踪8.6.1 风险跟踪单对于已实别的风险，在项目开发过程中对其进行跟踪，了解各类风险在目前情况下的状态。风险跟踪单的内容包括：a. 风险编号：b. 风险分类：参见前面的风险分类标准。c. 风险描述：d. 造成的后果：描述风险发生后对产品开发会造成什么样的影响。e. 发生概率：定量分析（五个等级，0.1，0.3，0.5，0.7，0.9）或定性分析（高、中、低）f. 危害：定量分析（五个等级，1，3，5，7，9）或定性分析（高、中、低）g. 综合影响：定量分析（发

34、生概率 * 危害）或定性分析（参照图1）h. 预防措施：在风险发生前可以采取哪些措施缓解该风险，降低该风险对产品开发的影响。i. 应急措施：当风险发生时，要采取什么样的应急措施来减少该风险对产品开发的影响。j. 触发条件：在什么样的条件下会触发该风险发生。k. 负责人：l. 综合影响排序：m. 状态：只有两个取值（Open和Close）。已经的风险的状态为Close，未发生的风险为Open。n. 发生的日期：o. 采取的措施：风险发生后实际采取的措施。8.6.2 风险分解为了方便跟踪，风险跟踪单里的每一个风险都是单纯、明确的风险。在一个项目开发过程中，一个风险发生后就关闭掉了，不存在多次发生的

35、可能。如果存在多次发生的情况，则需要把该风险进行细分，直到分解到可以独立追踪的程度。8.7 风险管理流程8.7.1 适用对象风险管理流程指在产品开发过程，如何识别和跟踪风险。适用的对象主要是项目经理及其他项目管理人员。8.7.2 流程图参见风险跟踪管理流程。8.7.3 风险跟踪管理说明项目经理在产品开发前期要识别出本项目内有可能存在的风险。首先项目经理从公司级的风险库中挑选出本项目中会遇到的一些风险。然后再根据本项目的具体情况，识别出本项目特有的风险。将所有这些风险收集整理在一起，提交为风险跟踪单。在项目开发过程中，不断地进行对风险跟踪单进行跟踪。当发现风险发生时，要启动风险应对措施。当风险发

36、生或消除时，要更新风险跟踪单。更新时要记录下新的风险，关闭已发生的风险，并根据实际情况修正各项风险应对措施及内容。当风险跟踪单中所有风险都已关闭或项目结束时，就可以关闭整个风险跟踪单了。在此之前要持续地对所有未关闭的风险进行跟踪。9 项目沟通管理操作指导9.1 项目组成员日志操作指导9.1.1 日志目的记录项目组成员每天工作及第二天工作安排；向项目经理汇报项目的进展情况及出现的问题。9.1.2 提交对象主送人员：项目经理抄送人员：无9.1.3 提交时间每个工作日下班前，项目组成员进行日志提交。9.1.4 日志归档由项目组成员直接提交到ClearCase指定目录。如果需要的话，可将日志发送项目经理，由项目经理提交。9.2 项目组成员周报操作指导9.2.1 周报目的记录项目组成员每周工作及下周工作安排；向项目组汇报项目的进展情况及出现的问题。9.2.2 提交对象主送人员：项目经理抄送人员：无9.2.3 提交时间每周五下班前，项目组成员把项目组成员周报提交。9.2.4 周报归档由项目组成员直接提交到ClearCase指定目录。如果需要的话，可将周报发送项目经理，由项目经理提交。9.3 项目组周报操作指导9.3.1 周报目的记录项目组每周工作及下周工作安排；各项目组间进展沟通；向PDT汇报项目的进展情况