极简设计

关于项目管理的通俗讲解

九个知识领域 五大过程组

中国人聪明做工作就有了聪明的做法,往往是每个项目都是按照自己的见解来做 而美国人如何来操作呢,他们就象洗澡,会在面前挂一张纸,上面写着先洗头,再洗耳朵,再细脸,,,这样做事情就有了一定的流程,渐渐的就形成了一套体系,此为探讨项目管理的目的所在

九个知识领域

  • 成本管理
  • 质量管理
  • 时间管理
  • 范围管理
  • 人力资源管理
  • 沟通管理
  • 风险管理
  • 采购管理
  • 整体管理

时间,质量和成本管理构成了三角形 在纸上画一个三角形 各个边上标上时间、质量、成本(等边三角形) 任何一方的移动必定带动其他的变形,如果时间缩短,就是常说的“献礼工程”,同时必定影响质量和成本

三角形中间是范围管理,也就是项目范围。就是常说的项目“项目管理三角形”

项目管理三角形

项目三角形中的成本,主要来自于所需资源的成本,自然也包括人力资源的成本,很好理解 为了缩短项目时间,就需要增加项目成本(资源)或减少项目范围 为了节约项目成本(资源),可以减少项目范围或延长项目时间 如果需求变化导致增加项目范围,就需要增加项目成本(资源)或延长项目时间 通过“项目管理三角形“了解项目成本、时间,质量和范围的简单定义

一个项目经理有多少时间是用来做沟通的工作的? 应该不少于75%,所以项目管理将项目沟通管理单独列了出来 所有这些领域都有一个主线就是项目的整体管理来统一的 由于时间的限制我们不详细讨论其他的知识领域,今天是入门

过程组

项目管理除了九个知识领域,还应该了解5个过程组 - 启动 - 计划 - 执行 - 控制 - 收尾 这5个过程组贯穿于每个知识领域的始终

举例 某人好不容易找了个女朋友,为了增进进一步的距离,他想来个欧亚8日游,于是他把自己多年的积蓄——3万元,一次性投入 但在旅游过程中,他的MM看上了另外一个帅哥,于是人财两空,说明什么问题?

项目启动时候就出现了问题,没有很好的做市场调研,结果过程就没有办法控制


根据PMI的解释,接单之后项目自然转入启动阶段 于是他刻苦的工作,终于又攒了3万,这次他不和美女旅游了,考虑到自己的费用,请姑娘看电影 于是他带这个这个姑娘看了——《第一滴血》 他看的那叫爽,姑娘看的也很爽,看看完后姑娘觉得这个家伙有暴力倾向,于是又分手。说明什么问题?

没有进行有效的需求调查,也就是在计划的时候没有明确的需求定义


于是他下次的时候知道了姑娘爱看歌舞剧,于是他就请一个靓女看了《天鹅湖》,可是以外有发生了—— 进去后发现座位不在一起,等他们把位子换到一起的时候歌舞剧结束了,这说明什么?

没有很好的执行,起码在执行过程中没有进行有效的监督 其他的过程不一一解释,在这里强调的是收尾的重要性


我们往往非常注重合同性收尾,却总是忽略管理性收尾

管理性收尾

吸取了所有的经验教训,终于领了结婚证,还应该干些什么呢?

还应该把所有的经验教训总结一下,以书面的形式汇报给老妈,并张贴于门后 然后在中堂挂一幅对联:欲谈恋爱者需先阅读门后之——《恋爱指南》 以后凡是自己的兄弟姐妹要谈恋爱的,必须先参阅门后的恋爱指南 这样能起到什么效果呢? 以后他们的恋爱项目操作至少能停留在这个水平

这个过程由QA人员来保证,也就是他的妈妈负责质量控制 家规一条,不参阅者或不照此操作者不许谈恋爱!

大公司一般有质量管理部门(QA),QA的成员基本上都是由非常有经验的PM转型过来的老狐狸,是老总接班人的有力争夺者:) 这也是一个失败的项目会培养一批优秀的项目经理的原因


门后的《恋爱指南》称之为文档,文档重要吗? 文档是非常重要的,有的人认为文档是最无聊的,项目结束后做个总结不就是了吗 错,文档的整理应该贯穿于项目管理的始终 文档的管理是对项目进行良好的跟踪和监控的一个手段,简单的讲就是根据项目计划进行你的文档管理

一般档案分类主线 - 立项 - 计划 - 执行 - 结束

然后在每大类中,再根据任务或者团组分类管理,根据哪个需要根据项目复杂程度和管理习惯 总之原则是方便对整个项目进度的追踪

以上讲了项目管理的九个知识领域,五大过程组,还有“项目管理三角形“

PMBOK

PMBOK是项目管理圣经,也就是Project management body of knowledge,项目管理知识体系指南 它是美国项目管理协会(PMI)的核心指导出版物 但它象一本字典,往往看到第三页会睡着

简单介绍美国项目管理协会(PMI)和国际项目管理协会(IPMA) 美国项目管理协会只有PMP一个证书,而IPMA有四级

下面讲几个名词,如果你掌握了,一和人讲项目管理你就抛出来,一定没有人敢小看你 WBS、甘特图、基准(BASELINE)、项目干系人和关键路径

WBS

WORK BREAKDOWN STRUCTRE ,工作分解结构 WBS的定义还是很麻烦的,PM要召开团队进行讨论,向成员提供与项目相关的所有详细资料,并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式(BRAINING STORM)思考,制订工作产出和相应人员的职责,记录每一个工作包的完成标准 比如我们要结婚了,怎么来分解呢 无非是办酒席,拍结婚照,,等等

为什么WBS重要,大部分项目管理的咨询都是针对WBS的咨询 WBS做好了,以后工作就有了参考物,就知道在不同的阶段你应该干什么,完成到什么进度 其实WBS的划分是没有规则的,主要的考虑角度是方便你做各类的统计工作,为管理服务 同样的一个项目其管理的侧重点不同,WBS结构的划分也可能是完全不同的 衡量划分好坏的标准应该是看其是否满足你管理的需要

甘特图

也叫横道图等,很多名称,我们说它是甘特在第一次世界大战时开始使用,它就是在WBS的基础上将WBS形象化控制进度 对于基准,举个例子 在没有结婚之前,你脚踩几只船? 但当有一天你和你的朋友进了一个小黑屋子,然后带了两个盖章的本本的时候,你还可以脚踩N只船吗? 此时就不允许了,因为你过了一个基准线(BASELINE)

如果你还想脚踩N只船就需要重新回小黑屋子再盖两个章就可以了 那项目要越轨怎么办,也就是项目变更? 这样的项目变更会影响各要素比如时间,成本,质量等 应该统一由项目管理办公室来进行控制,如果要变更基准,必须要进行严格的限制 在客户提出变更请求时,要建立变更申请登记表和变更申请表,并让客户签字

有时候一些不是非常关键的模块PM也不至于一点不讲情面,该卖面子的时候还是要卖,尤其是当着对方领导的面,千万要卖面子,但是也别卖的太干脆,不要让他们得到的太容易


PM在变更管理中需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件 如果一个项目进行过程中,比如现在的点心的3G项目,发现如果再多花一点时间就可以编写出对以后非常有用处的程序,但这个程序不在本项目范围之内,要不要做? 不能做,可以重新起一个项目来做,但不能在这个项目里做,这样会使项目成本超出,风险增加,而且和其他的项目缺少比对性和参照的价值 这就是许多项目失败的原因,说项目失败并不是项目进行不下去了,彻底破产,在PMI有明确的定义,凡是项目的成本超出预算,质量没有得到保证,时间超过预计等等都在失败的范围之内

增量开发

这个在华为做的很好,华为有个有名的增量开发的名声 20%的功能先满足80%的需求,其他的功能我可以开发升级的版本,于是就在小数点后拼命的增加数字,于是就是了V1,V1.1,V1.11....等版本 它从来不一下子满足你所有的需求 手机来说,大部分的需求是在打电话,发消息,打打游戏,没有用完所有功能

这点在项目管理中非常重要,要结合资料好好研究

项目干系人

包括项目人员的老婆孩子 有的项目需要的时间很紧张,如果项目成功了,但项目的程序员们都成了光棍,那项目还是非常失败,至少不是丧心病狂的PM这么想

合理解决项目干系人的冲突是个很累的问题,其中还包括职能经理们,董事长,客户,等等,等等,有的说没用? 好,如果项目进展不下去,该怎么办? 开会,把高层找一个坐到会议室,不用他说话,只让他暧昧的看着大家,大家一定会想,这个家伙一定和领导有关系,我们还是好好的做这个项目,下一个项目再给他使拌子吧:)

所以为了不累死好好分析一下你的项目干系人吧 我们上次讲了一些基础的知识,包括什么是项目管理,项目管理包括什么? 你说项目管理有几个知识领域? 你说项目管理有几个过程组? 让我们想起了泡MM的例子是不是? 还有老母亲做QA的比喻 几天我们着重强调的是

项目是什么

人们常用“时间”,“资源(或缺乏资源)”,“某种工作努力”,“交付物或者产品”,“综合工程”,“缺乏凌驾其他班组的职权”,以及“预算” 来给它下定义

实际上,项目是一种独特的工作努力,即遵照某种规范及应用标准去导入或生产某种新产品或某项新服务 这种工作努力应在限定的时间、成本费用、人力资源及资财等项目参数内完成

项目的定义

根据PMPBOK的定义,项目是在一段时间内为完成某一独特的产品或提供独特的服务所进行努力的过程 这个过程受到时间、人力、资源、成本、质量上的限制

项目几个特征

  • 临时性
  • 独特性
  • 一次性

哪个是项目: A 惠普与康柏机构重组惠普与康柏机构重组 B 建造一座新工厂 C 改建道路 D 工程材料采购 E 开发软件包 F 结婚典礼 G 寻找拉登

有人说是寻找拉登,大家说寻找拉登有明确的结束时间吗? 当然可以假设寻找拉登50年如果找不到,项目就结束是不是?

所以问题要放到具体的环境下,否则没有意义


WBS

WBS是工作分解结构,就象一张道路交通图,它能够指引你如何从当前位置到达想去的地方。没有它,你可能就要迷路了 怎样来做一个好的WBS呢? 有时候在接受新项目时前无例子可借鉴感觉分解时真困难 因为每个人的解决问题思路不同,同一个项目不同的人有很多种分类, 因为可以按照工作的流程分解,也可以按照系统论的方法进行结构上的分解 有一条很重要的原则应该注意,那就是麦肯锡的精髓,他们在分解工作时非常强调的就是MECE, muturally exclusive, collectively exhaustive-相互独立,完全穷尽的原则, 也就是现在较流行的说法"横向到底,纵向到边" 如果分解时坚持了这个原则, 我想一定会有Perfect 的WBS, 其实WBS并非是PMI的"真传", 只是被PMI起名为WBS, 有时候工作中也会用类似的方法解决问题无非是没有提升到理论高度, 但WBS确实是做事的核心步骤

做一个WBS需要注意的问题

  • 第一级通常与项目生命周期相同(如需求分析,设计,采购,施工……)
  • 第一级应在项目进一步分解前完成
  • WBS的每一级都是其上一级的片断(Segment)
  • 一个工作单元只与一个上层单元相关
  • 上层单元的工作内容应该等于其所有直接下层工作单元的总和
  • 一个工作单元由一个人负责
  • 在整个WBS中使用同一种定义,在整个组织中亦然
  • 通过将人员包括进WBS来激励他去完成计划

甘特图

  • 以图形或表格的形式显示活动
  • 现在是一种通用的显示进度的方法
  • 构造时应包括实际日历天和持续时间。不要将周末和节假日算在进度之内

风险

在一个项目中,初始阶段和结束阶段哪个时候项目的风险大? 开始的时候,因为在开始的时候我无数的不可控制的因素 什么阶段的损失大 结束的时候,所以说两者是相反的

在项目的启动阶段成功的可能性最小,风险发生的概率也就最高,但是这时候一旦预计的风险发生了,损失是最小的