主题：【文摘】一个关于项目管理的通俗讲解 -- 【子衿】
一个关于项目管理的通俗讲解
想首先问大家一个问题：你觉得中国人聪明还是美国人聪明？
我见过最好的回答是美籍华人。
我们说美国人很愚蠢，为什么呢？
你们都考过T或G吧，他们经常会出这么一道题1/3+1/2=？
50%的人回答是2/5，这可是美国研究生入学考试的试题呀！
通常在这个问题之前还有一个1/2+1/2=？为什么？
他们怕太难了，先给个容易的热身一下。
我在美国的时候见过很多的PHD，对于美国人来说if...else...是逻辑，而if...if...else...就成了哲学，也是美国这么多哲学博士的原因：）
我们说美国人很愚蠢，那我们为什么还要学习他们呢？这个问题稍候我们会回答。
再问一个问题：如果你刚买了一个豪华的房子，可你三岁的儿子把整个墙壁上都写上“我爱长城永不到，我爱北京天安门”，你该怎么做？
有的女孩子说暴打，呵呵，这个答案从女生的嘴里说出来还是比较少见。
美国人怎么办？
他们会对孩子说：“你老人家真有绘画的天赋，简直就是毕加索的毕加索，你这一幅画至少能卖100万美金”你们知道美国人喜欢钱，用金钱来量化一定是效果明显。
但显而易见，您老人家把画画在墙壁上是不能永久保存的，所以我明天给你买一个画布，你就尽情的画吧。否则我们要损失多少个毕加索呀！
于是我们就可以看见我们的小宝贝在画布上快乐的滚来滚去。墙面也干净了。
中国人很聪明，从大家就可以看出来，但中国人聪明做工作就有了聪明的做法，他们往往是每个项目都是按照自己的见解来做。
而美国人如何来操作呢，他们就象洗澡，会在面前挂一张纸，上面写着先洗头，再洗耳朵，再细脸，，，这样做事情就有了一定的流程，渐渐的就形成了一套体系。
所以这也是我们今天来探讨项目管理的目的所在。
项目管理分九个知识领域，分别是成本管理、质量管理、时间管理、范围管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理。
其中时间，质量和成本管理构成了三角形
大家在纸上画一个三角形
在各个边上标上时间、质量、成本（等边三角形）
任何一方的移动必定带动其他的变形，如果时间缩短，怎么样？就是我们常说的“献礼工程”，同时必定会影响质量和成本。问大家一个问题，这个三角形中间是什么东东？
对，是范围管理，也就是我们说的项目范围。这也就是我们常说的项目“项目管理三角形”
下面介绍一下项目管理的“项目管理三角形“
项目三角形中的成本，主要来自于所需资源的成本，自然也包括人力资源的成本。这个相信很好理解。
为了缩短项目时间，就需要增加项目成本（资源）或减少项目范围；
为了节约项目成本（资源），可以减少项目范围或延长项目时间；
如果需求变化导致增加项目范围，就需要增加项目成本（资源）或延长项目时间
通过“项目管理三角形“我们了解了项目成本、时间，质量和范围的简单定义。
我们说一个项目经理有多少时间是用来做沟通的工作的？
应该不少于75%的时间是用来沟通的，所以项目管理将项目沟通管理单独列了出来。
所有这些领域都有一个主线就是项目的整体管理来统一的。
由于时间的限制我们不详细讨论其他的知识领域，因为今天是入门的，哈哈
另外项目管理除了九个知识领域，还应该了解5个过程组
5个过程组就是：启动，计划，执行，控制，收尾。
这5个过程组贯穿于每个知识领域的始终，你们了解吗？
举个例子字来说
某人（比喻）好不容易找了个女朋友，为了增进进一步的距离，他想来个欧亚8日游，于是他把自己多年的积蓄——3万元，一次性投入。
但在旅游过程中，他的MM看上了另外一个帅哥，于是人财两空，说明什么问题？
说明他的项目启动的时候就出现了问题，没有很好的做市场调研，结果过程就没有办法控制。
根据PMI的解释，接单之后项目自然转入启动阶段
于是他刻苦的工作，终于又攒了3万，这次他不和美女旅游了，考虑到自己的费用，他请这个姑娘看了场电影。
于是他带这个这个姑娘看了——《第一滴血》
看的那叫爽，姑娘看的也很爽，看看完后她觉得这个家伙有暴力倾向，于是又分手。说明什么问题？
对，没有进行有效的需求调查，也就是在计划的时候没有明确的需求定义。
于是他下次的时候知道了姑娘爱看歌舞剧，于是他就请一个靓女看了《天鹅湖》，可是以外有发生了——
进去后发现座位不在一起，等他们把位子换到一起的时候歌舞剧结束了，这说明什么？
对，说明没有很好的执行，起码在执行过程中没有进行有效的监督。
其他的过程不一一解释，我在这里强调的是收尾的重要性。
我们往往非常注重合同性收尾，却总是忽略管理性收尾。什么是管理性收尾呢？
某人同志吸取了所有的经验教训，终于领了结婚证，还应该干些什么呢？
对了，还应该把所有的经验教训总结一下，以书面的形式汇报给老妈，并张贴于门后。
然后在中堂挂一幅对联：欲谈恋爱者需先阅读门后之——《恋爱指南》
以后凡是自己的兄弟姐妹要谈恋爱的，必须先参阅门后的恋爱指南。
这样能起到什么效果呢，对，以后他们的恋爱项目操作至少能停留在这个水平。
这个过程怎样来保证呢，对，还需要我们的QA人员，也就是他的妈妈负责质量控制。
家规一条，不参阅者或不照此操作者不许谈恋爱！
大公司一般有质量管理部门（QA），QA的成员基本上都是由非常有经验的PM转型过来的老狐狸，是老总接班人的有力争夺者：）
这也是我们说一个失败的项目会培养一批优秀的项目经理的原因。
哪个门后的《恋爱指南》我们称之为文档，文档重要吗？我们说在电信科技处的同志们说重要，为什么因为他们管这个，但对于我们呢？
大家拿起你身边的一只笔，告诉我他多长？
有的说10厘米，有的说10。0987厘米。
我们说他的估算很精确，但不准确！！
这是我如果拿一只笔告诉你正好10厘米，然后和你的笔比对你是不是就比较容易得出测算？
这说明文档是非常重要的，有的人认为文档是最无聊的，项目结束后做个总结不就是了吗。
错，文档的整理应该贯穿于项目管理的始终。
文档的管理是对项目进行良好的跟踪和监控的一个手段，简单的讲就是根据你的项目计划进行你的文档管理。
一般档案分类主线是：立项、计划、执行、结束4大类；然后在每大类中，再根据任务或者团组分类管理，根据哪个需要根据你项目复杂程度和管理习惯，总之原则是方便你对整个项目进度的追踪。
以上我们讲了项目管理的九个知识领域，五大过程组，还有“项目管理三角形“，下面我们讲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只船：）
但当有一天你和你的朋友进了一个小黑屋子，然后带了两个盖章的本本的时候，你还可以脚踩N只船吗？
我们说此时就不允许了，因为你过了一个基准线（BASELINE）
如果你还想脚踩N只船就需要重新回小黑屋子再盖两个章就可以了。
那我们的项目要越轨怎么办，也就是项目变更？
我们说对这样的项目变更会影响各要素比如时间，成本，质量等
我们应该统一由项目管理办公室来进行控制，如果你要变更基准，必须要进行严格的限制。
在客户提出变更请求时，要建立变更申请登记表和变更申请 表，并让客户签字。
有时候一些不是非常关键的模块PM也不至于一点不讲情面，该卖面子的时候还是要卖，尤其是当着对方领导的面，千万要 卖面子，但是也别卖的太干脆，不要让他们得到的太容易。
PM在变更管理中需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。
如果一个项目进行过程中，比如现在的点心的3G项目，你发现如果再多花一点时间就可以编写出对以后非常有用处的程序，但这个程序不在本项目范围之内，你要不要做？
对，我们说不能做，你可以重新起一个项目来做，但不能在这个项目里做，这样会是我们的项目成本超出，风险增加，而且和其他的项目缺少比对性和参照的价值。
这也是我们说现在有大约80%以上的项目失败的原因，我们说项目失败并不是项目进行不下去了，彻底破产，在PMI有明确的定义，凡是项目的成本超出预算，质量没有得到保证，时间超过预计等等都在失败的范围之内。
这个在华为做的很好，华为有个有名的增量开发的名声。
只用20%的功能先满足你80%的需求，其他的功能我可以开发升级的版本，于是就在小数点后平明的增加数字，于是就是了V1，V1.1，V1.11....等版本
它从来不一下子满足你所有的需求，我们大家想想，谁没有事情拿出自己的手机把所有的PING码都试用一下，我们说没有，我们大部分的需求是在打电话，发消息，打打游戏，对不对？
这点在项目管理中非常重要，请大家结合资料好好研究。
项目干系人是什么东东，谁给我举一个例子？
对，包括项目人员的老婆孩子，正确
我们说有的项目需要的时间很紧张，如果你的项目成功了，但项目的程序员们都成了光棍，那项目还是非常失败，至少不是丧心病狂的PM这么想。
合理解决项目干系人的冲突是个很累的问题，其中还包括你的只能经理们，你的董事长，你的客户，等等，等等，有的说没用？
好，如果你的项目进展不下去，你该怎么办？
对，开会，把你的高层找一个坐到会议室，不用他说话，只让他暧昧的看着大家，大家一定会想，这个家伙一定和领导有关系，我们还是好好的做这个项目，下一个项目再给他使拌子吧：）
所以为了不累死好好分析一下你的项目干系人吧
我们上次讲了一些基础的知识，包括什么是项目管理，项目管理包括什么？
你说项目管理有几个知识领域？
你说项目管理有几个过程组？
让我们想起了泡MM的例子是不是？
还有老母亲做QA的比喻
几天我们着重强调的是
项目是什么?人们常用“时间”，“资源(或缺乏资源)”，“某种工作努力”，“交付物或者产品”，“综合工程”，“缺乏凌驾其他班组的职权”，以及“预算”来给它下定义。实际上，项目是一种独特的工作努力，即遵照某种规范及应用标准去导入或生产某种新产品或某项新服务。这种工作努力应在限定的时间、成本费用、人力资源及资财等项目参数内完成。
项目范围对应用户需求，但我理解用户需求实际上是个不断变化的东西，需求开发是一个狗追兔子的过程，如果时间延长，成本必定增加，范围必定扩大。不可能通过延长时间降低成本。
相应的既然产品质量主要取决于分析设计阶段，而目前这基本上是个依赖人主动发挥的工作。保持成本不变，压缩项目时间并不一定导致质量下降或项目范围缩小。
所有的开发人员都有荣誉感，如果项目经理告诉他们，可以牺牲质量来换取成本或进度，都将导致士气严重受挫。企业除了得到项目失败外，还将收获员工流失。
“项目管理三角形”“为了缩短项目时间，就需要增加项目成本（资源）或减少项目范围；
为了节约项目成本（资源），可以减少项目范围或延长项目时间；”
请问是如何用模型表现出来？这一点有点没想通？
这也是文中用的华为的意思. 20%的功能满足80%的要求.剩下的20%的要求可以变,但那就是另外一个了.
渐进明细是项目的一个特点。所以就不要做瀑布式一蹴而就的梦了。
我的疑问是在所谓项目管理三角形中延长项目时间将导致项目范围扩大，原因是需求开发本身是动态的，时间延长将导致用户需求增加，因此项目成本增加。不会带来成本下降。
您所说的迭代求精的意思应该是指通过迭代开发及时满足用户的核心需求，同时确定系统架构，从而限制用户需求增加反复？我基本上认同您的思路，但是由于用户对系统以及对业务的认识实际上也是渐进的。因此随着时间的延长，即使是核心需求也会发生变化，特别是迭代法的迭代周期控制不好的话。楼下同仁的建议如何将新需求划入下个项目？我认为这是很值得讨论的。
楼主正文中提到了变更管理，您的问题其实应该在这里面找答案。说到迭代是因为有个印象在某个帖子里您曾表示希望做一次真正的瀑布式的开发。
软件开发中有一个比较独特的东西在项目管理知识体系中难以找到对应，就是配置管理。配置管理与变更管理有相交，而变更控制其实是更大的项目范围管理的一部分。
在配置管理中，最基本的一点就是建立基线。举个例子，假设在9月1日的时候，截至当前的需求经整理得到一个版本v0.1，那么在当次迭代中，随后进行的设计、编码、测试等等工作都是基于这个0.1版的东东，就有了对应的设计v0.1，编码v0.1，测试v0.1......在所有这些工作进行的同时，需求也在发生变化并被捕捉到，而这些发生变化了的需求，就反映在v0.2中，如果不涉及对软件框架的重大影响，一般不在v0.1的迭代中涉及。只在到达v0.1的里程碑后，才考虑v0.2。
这个是比较现实的，如果动不动就放到下一个项目中去，签合同的双方都会很难受的。或者，试着将一次迭代理解成一个“子项目”您会比较容易接受？