某公司项目管理内训培训教材(PPT 67页).ppt

1、,项目管理内训（PM）,员工平台中心,宛宗伟,培训主题系列 项目管理基础 复杂项目管理 人人都是项目经理 人人都是产品经理 PMO与PM 探讨敏捷 项目集管理,培训内容包括，但不仅限于： 一、项目管理基础 二、项目管理核心流程解析 三、项目管理微创新 四、IT行业基准介绍 五、数据分析在项目管理中的应用 六、项目绩效评分新规则解析 注：本次培训针对主要面向员工平台研发中心所有员工，不仅限于产品经理,项目和产品的区别,什么是项目经理,2020/8/9,软件开发工程师,实施顾问,产品顾问,技术总监,产品总监,售前顾问,软件开发项目经理,项目总监,产品经理,架构师,项目经理,销售,BOSS,测试 工

2、程师,测试经理,7,专职的项目经理 兼职的项目经理，来源于某一个技术部门，如开发部或事业部，同时可以兼任其他岗位。 对于第二种方式，往往项目经理只会对他熟悉的作业内容、熟悉的人员进行管理，名义上是项目经理，实际是个局部经理。 争议 项目经理要懂技术。 配备专职的项目经理。,2020/8/9,8,项目经理的三种内在类型,以自我为中心,以公司为中心,以客户为中心,以自我为中心者寡； 以公司为中心者生； 以客户为中心者王；,三者达兼则天下无不可去也,9,开发式项目经理,产品式项目经理,外包式项目经理,按照不同公司主营业务不同区分,无成熟软件产品，新开发项目； 主要工作在产品规划与研发； 项目管理偏重

3、于进度，质量；,软件产品成熟，定价销售； 主要工作是实施，BPR； 项目管理偏重于干系人，成本，范围；,新开发和产品化实施都存在； 项目管理偏重于成本，进度；,项目经理的三种外在类型,你心目中的项目经理应该是个怎样的人？,项目管理问心,项目经理具备的基础能力,PMP的九大知识领域是什么？ CMMI、ISO对项目流程控制的各项要求了解吗？,理论基础20%,协调能力40%,文档能力20%,沟通能力10%,对项目成员协调 对领导协调 对客户协调,什么情况出什么文档 什么人看什么文档 文档积累 为什么出文档,察言观色 反应迅速 清晰表达 知识面广,项目管理问心,项目经理具备的能力,抗压能力10%,喜怒

4、不行于色 能忍所不能忍 清楚压力临界点 有解压方法,12,产品经理必备技能 1、一个成功的产品经理的能力中应该有35%的项目管理能力。2、个人的能力占15%。3、产品经理的业务能力占全部的20%。4、产品经理的技术能力占全部的15%。5、产品经理的沟通和处理冲突的能力占全部的15%。 产品经理应该领导项目组，指导产品从概念设计到市场接受，保证实现设计、收益、市场份额和利润目标，解决项目组的冲突； 同时产品经理还应该管理项目，制定项目的计划和预算，确定和管理参与项目的人员和资源，同职能部门之间相协调，跟踪相对于项目基线的进展； 产品经理还要负责和管理层进行沟通，提供项目进展状况的报告，准备并且确

5、定状态评审点，作为产品的领导同管理层沟通，提供对项目组 成员的工作绩效评审的输入材料。 一个成功的产品经理通常在一个或多个职能部门从事过管理和操作方面的工作经验，并有管理项目开发的经历。产品经理可以来自财务、R&D、市场等任何部门。 产品经理富有项目管理经验很重要，产品经理最好具备项目经理的任职资格证书。,项目管理问心,13,我的总结： 1. 业务知识，产品，项目管理，开发测试不求都精通，但都要学习； 2.会哭会闹会上吊 3. 对内定海神针，对外李鸿章 4.既得利益前，不计较个人得失，会做人 5.坚持原则 以身作则 谦虚且勇于担当 让人信服 6.熟悉心理学，厚黑学的谋略家 7.永远不会说”我不

6、知道，不可能，不关我的事” 8.永远首先站在客户立场思考，解决问题 9.深谙职场之道 职业素养优秀 10. 三教九流能喝酒，四海之内皆朋友,项目管理问心,14,项目管理的分类： 项目管理 中国式项目管理,中国式项目管理的特点：多 快 好 省,15,项目管理矩阵,影响力的来源梳理 1.职位影响力 短期可执行性：效果： 2.专业影响力 短期可执行性：效果： 3.资历影响力 短期可执行性：效果： 4.情感影响力 短期可执行性：效果： 5.品格影响力 短期可执行性：效果：,评估项目成功的指标是什么?,项目成功评价指标,时间,成本,企业的荣誉,项目目标,项目影响者的满意度,高层领导的满意,社会责任,项目

7、实施者成就感,项目管理3要素（3重制约）,质量Quality,时间Time,成本Cost,范围Scope,人 People,项目管理魔鬼三角,时间,成本,范围,项目管理魔鬼三角,成本,时间,范围,质量,Time 时间限制,Quality&Quantity 质量&数量限制,Resource 资源限制,核心利益 干系人,事实是这样吗,到底什么才是成功的项目,2020/8/9,利益均沾 团队成型 王者诞生,保证能生存下去 （进度，成本）,解决痛点 满足需求 获得认可 （范围，进度，质量）,直接受益 品牌建立,到底什么才是成功的项目,项目管理的5大过程,项目管理过程可被分成5个过程组，每个过程组有一个

8、或多个管理过程： 初始过程：识别一个项目或阶段应当开始并提交去完成； 计划过程：设计和维护一个可以工作的规划方案去实现项目所要达到的商务需要； 执行过程：协调人员和其他资源完成计划； 控制过程：通过监督和测量进展，并在必要时采取正确的动作保障项目目标的实现； 收尾过程：定型为认可形式，并清晰地结束该阶段。,项目管理过程组间的交互,项目管理的5大过程,项目管理PMP 47过程组与10大知识领域,项目管理软件生命周期模型,喷泉模型,喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目。 优点：该模型各个阶段没有明显的界限，开发人员可以同步进行开发。 缺点：由于可重

9、叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，审核的难度加大,项目管理CMMI,ISO9001与CMMI有哪些区别和联系？,CMMI与PMBOK有没有直接的关系？,项目管理PDCA,ISO9000就是采用PDCA精神循环实行的,天津汉邦企业管理咨询有限公司,循环主要包括四个阶段：计划、实施、检查和处理，及八个步骤,问 题,有时候你是不是觉得凭借自己的直觉和积累的管理知识，就可以把事情办好？ 有时候你是不是觉得自己解决问题的办法已经很科学、很有效率了？,你的解决方案有多好？,1、你是皇帝的俘虏。他要给自己的城堡增加三个新地牢，让你做一个规划。干得好

10、就释放，干不好就终生监禁。 2、小地牢很难设计，要12周，但容易建成，1周即可；中地牢设计要5周，施工要6周；大地牢设计只要1周，但建造要用9周。 3、你有一个设计师和一个建筑师，设计师不会建造而建筑师不会设计。 4、要建好这三个地牢，你规划的工期是几周？,Q、R、T分析,Q：三个地牢 （最不灵活因素）,T：时间最短 （依你的设计而定，灵活因素）,R：一个设计师、 一个建筑师 （人员固定，但在开展具体工作的顺序上有变动余地，较不灵活因素）,质量或数量,资源,时间,规划时不同的思路,思路一,思路二,理性的选择,思路一的缺点： 从一开始就关注单个产品这样的细节。容易造成只见树木，不见森林. 思路二

11、的关键： 建造可以根据设计的整体安排进行调整。要取得最佳效果必须安排好工作的起点与排序.,思路二指导下的工作安排,1、先设计小地牢 2、先设计中地牢 3、先设计大地牢,最后工期太长,真的很遗憾,设计建造地牢的任务中，按照你的规划，虽然工期是最短的，但有两周建筑师没有活干，成天睡觉或出去游玩。不巧的是国王就在这两周里的某一天来视察了，发现建筑师在睡大觉，认为你的方案工期虽短，但让他多浪费了粮食和工钱，不是最佳方案。所以他下令：,判你终生监禁！,意外的结果,项目管理谁的责任,项目管理-案例1,1）阶段：立项 非订单软件 订单软件,领导紧急安排,原始需求（市场需要，业务需要，功能优化，BUG修复）,

12、自提自解决（创新，整合，性能提升，弥补从前的错误）,员工平台中心项目来源,立项申请书,项目背景，项目目标，项目等级，变革点， 团队介绍，资源计划，里程碑计划， 技术路线，验收标准，风险分析,项目可行性分析,产品定义说明书,项目可能性,客户群&潜在客户群,投入产出分析（ROI）,业务需求分析,产品设计，蓝图,运营分析,立项,现阶段主要问题： 1。目标不明确，可量化程度低； 2。变革点中对现有流程，系统的影响范围缺乏描述； 3。项目团队及资源计划在立项评审时仍不能完全确定； 4。里程碑计划形同虚设； 5。验收标准含混不清； 6。沟通不畅； 7。项目等级确定有疑问； 8。整体概念感差，缺乏营运视角；

13、 9。基于需求本身，而很少考虑用户感受； 10。项目例会制度没有建立； 11。对于评审未通过的原因没有记录和总结； 12。通过不通过，无法量化，目前领导说的算；,立项,反面教材：,正面教材：,立项,立项评审指标,产品项目从需求到上线流程,Diagram,针对现在的企业现状和行业趋势， 战略需求文档， 可以是商业可行性分析,重点放在为一个被提议的新产品或者 现有产品的改进定义市场需求 侧重于从产品本身角度看待需求,区别-BRD关键说明产品的方向， MRD关键说明产品的定位,开始衔接开发 定义产品功能需求的全部细节,现在我们生产车最有赚头,现在我们生产小汽车才真有赚头,产品定义说明书 业务需求说明

14、书 系统需求说明书 系统概要设计 系统详细设计,文档困惑,What Why Who When How,系统评审,需求评审,立项评审,立项准备,需求调研,开发,测试,上线 验收,产品定义说明书 业务需求说明书 系统需求说明书 系统概要设计 系统详细设计,文档困惑,What Why Who When How,系统评审,需求评审,立项评审,立项准备,需求调研,开发,测试,上线 验收,产品定义说明书 业务需求说明书 系统需求说明书 系统概要设计 系统详细设计,文档困惑,What Why Who When How,系统评审,需求评审,立项评审,立项准备,需求调研,开发,测试,上线 验收,产品定义说明书

15、业务需求说明书 系统需求说明书 系统概要设计 系统详细设计,文档困惑,What Why Who When How,系统评审,需求评审,立项评审,立项准备,需求调研,开发,测试,上线 验收,产品定义说明书 业务需求说明书 系统需求说明书 系统概要设计 系统详细设计,文档困惑,What Why Who When How,系统评审,需求评审,立项评审,立项准备,需求调研,开发,测试,上线 验收,阶段2：需求评审,项目管理-案例2,3.2.1业务简单描述,字段解释 3.2.4 业务规则；,3.2.6 设计细节； 3.2.7备注；,3.2.2 业务流程图及说明,阶段3：系统评审,项目管理-案例3,简要说

16、明 前置条件 后置条件,业务规则 补充说明,表单数据说明,主流程,PRD,该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。,产品需求文档：,阶段4：项目计划,项目管理-案例4,项目计划：凡事预则立，不预则废。 项目计划一定要包括这几方面的内容：各阶段里程碑时间点，各个里程碑的输出结果，风险预测，意外应对。计划一定要提前于交货时间计划，风险意外是否留下时间和应对处理方案？,介绍重点：项目计划(plan)，进度监控(progress control)，质量监控

17、(quality control)，风险预测(exposure rating),不要说项目的失败是因为新需求引起的,一个没有新增需求和风险的项目是不存在的。,项目的误区：,三边行动 边计划 边实施 边修改,坏了坏了，期限到了，忙不完了！,不行啊，情况变化，我们的项目进程恐怕也要变动了！,下一步该干什么?还没想好，正在作新计划呢。,造成“三边行动”的根本原因是在目标未清、职责未明的情况下就仓促开始往下做细节，结果常会因为在一些小事上扯皮导致项目被不断地延期。即时最后勉强完成了，也与最初的目标相去甚远。,计划之痛,已结项项目数据,已上线项目数据,计划之钥,WBS的重要性：,一般情况：4-6级 工作

18、包1天，不超过2周 须分解到个人 独立可交付,进度监控,进度监控：对每个阶段把握好，每个阶段要完成的任务一定要完成，如果完不成，是什么原因导致的？我们的应对策略是什么？我们要信任别人，但是不要忘记锁门。,进度监控数据分析,垂直偏差：实际与计划之差；横向偏差：实际自然天与计划自然天数之差；横向偏差率： （实际消耗自然天数-计划实际消耗自然天数）/计划实际消耗自然天数 整体横向偏差率：横向偏差天数/（计划总自然天-横向偏差天数）,2020/8/9,55,进度监控案例：,2020/8/9,质量监控,国际标准组织ISO9000对质量的定义就是:质量是产品或服务用于满足人们潜在或明示的需求的所有特征和性

19、能的总和,2020/8/9,57,质量监控,质量监控：也应该是分阶段进行的，每一个阶段的质量监控内容有所不同。 需求分析阶段：完整而又正确的理解用户需求，需求是否清楚可懂，写用例的测试人员是否明白需求？ 分析设计阶段：设计是否完全满足需求？这个设计方案是否满足以后新功能的扩展？以及是否有考虑到新功能的意外和设备环境，运行平台的变化？ 编码阶段：变量命名是否规范？代码是否可读？是否有详细的注释？是否有重复代码？要知道重复代码是必然会造成系统不稳定，bug成群的。做code review代码公开评审。 项目经理设立检查点的基本原则是:,2020/8/9,58,质量监控数据分析,不正确的系统需求、过

20、度的进度压力、团队缺乏沟通、产品功能复杂度高、产品设计不好、关键岗位人员离职、人员经验不足、系统需求识别不充分、需求频繁变动、测试覆盖度不足10个因素对项目的质量影响最严重。 系统需求频繁变动、对系统需求识别不完整、关键岗位人员离职、缺乏有效的开发方法、团队成员缺乏沟通、不正确的系统需求、过程监控的不足、过度的进度压力、人员缺乏责任心、人员缺乏类似项目经验、不清晰的系统需求、采用不成熟的技术、团队人员短缺、人员结构缺陷等因素与项目的质量问题存在着正相关性。,2020/8/9,59,质量监控,增加加班时间只会降低生产力？ 短期的压力乃至于加班可能是有用的策略，因为他们能使员工集中精力，并且让他们

21、感到工作的重要性，但是长期的压力肯定是错误的； 经理之所以会施加那么多的压力，也许是因为他们不知道该做什么，或者因为其他办法的困难而感到气馁； 最坏的猜测：使用压力和加班的真正原因是为了在项目失败的时候让所有人看上去能好过一点。 在早期，人员超编会迫使项目跨过关键的设计阶段（这是为了让所有的人都有事可做）； 如果在设计完成之前，工作先被分给了许多人，那么人与人之间，工作组之间的接口就会很复杂； 这会使团队内部耦合度提高，会议期间，重复劳动和无效工作都会增加； 理想的人员安排是这样：在项目的大部分时间是由小型核心团队来做设计工作，在开发的最后阶段（时间安排的最后1/6）加入大量的人手；,2020/8/9,问题不应该依赖由测试人员来发现，而应该由开发人员来发现。 软件的质量应该由程序员来保证的，而不是测试人员。 问题不应该由测试人员来发现，而应该由开发人员来发现。也就是说，我们尽量不要让测试人员来发现问题。如果第一次测试有至少25%以上的用例通不过，那说明质量监控出了问题。这