漫画项目管理实战
2020-06-02 11:33:10 0 举报AI智能生成
在国内外同行的努力下，借助于社会需求的推动，“项目管理”这个词成了高频词。“一切皆项目”“一切都可以项目化”等不绝于耳。这些变化给我带来的不仅是喜悦，更多的是担忧！担心的是，社会的浮躁与泛项目化导致“项目管理”成为时髦概念，其结果必将降低项目管理的真正价值和生命力。在多年的讲学和咨询工作中，我接触过很多项目管理者，他们希望得到项目实践中实际问题的解决指导，但又时常反映文字书籍读起来较为枯燥，专业书籍更甚。本书希望借助漫画这种形式为大家提供帮助。需要说明的是，本书并不涉及太多的项目管理理论，更多的是从项目管理者的角度讨论国内项目管理中一些具体和现实的问题。
作者其他创作
大纲/内容
项目管理
前言
社会的浮躁与泛项目化导致“项目管理”成为时髦概念，其结果必将降低项目管理的真正价值和生命力。
项目经理并不是老板，而是属于弱势管理者，实际权力比较小，但要对项目的成败负责，所以更需要软性技能，通过沟通解决项目中的各种实际问题。
第一篇、项目管理越来越成为组织发展的手段
1.1、什么是项目管理
项目本质上属于非重复性工作，往往使用有限的资源、在有限的时间内为特定的干系人完成特定目标而开展工作，而且这些工作基本都是一次性的。
非重复性的项目工作有两个主要特点：临时性和独特性。
我们把“通过开展持续的活动来生产同样的产品或提供重复的服务的工作”称为运营。
项目与运营的主要区别在于，运营是持续性的、重复的；项目是临时性的、独特的。
项目需要项目管理，运营则需要业务流程管理或运营管理。
项目实现组织的持续发展，运营保证组织的持续稳定。
项目管理就是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。可以根据其逻辑关系，把这项目过程归类成五大过程组：启动、规划、执行、监控和收尾。
1.2、做不完的项目
项目是企业的成长发动机，更是每个人、特别是管理人员业绩的主要来源。
1.3、项目管理本质上是一种框架管理
项目与运营的管理方式是不同的。
独特性工作与重复性工作的管理方式
运营管理的本质是流程管理
每个项目都有其独特性，其创造的产品、服务或成果可能存在不确定性，项目团队所面临的项目任务是新的（甚至是全新的）。要么时间要求很紧急、要么成本控制很苛刻、要么需要质量第一，每个干系人对其有不同期望，而且时常受到事业环境因素的制约。
试图给项目建立所谓的流程是危险的，时常导致“一管就死，一放就乱”的困境，这也是国内普遍存在的问题。理解针对项目独特性而建立的“框架管理”本质，对项目管理的成功具有重要的实践意义
1.4、项目管理的价值在于沿着正确方向获得正确结果
要取得成功，首先要选择正确的方向，然后再使用正确的方法。
选择正确方向属于战略管理，使用正确方法属于项目管理；战略管理在前，项目管理在后。从这种意义上讲，战略管理比项目管理的层次更高。
战争中，有了正确的路线方针后，干部是决定性因素。
第二篇、成功项目源自组织和高层的支持
2.1 什么样的项目算是成功的
验收通过是项目成功与否的基本条件
项目成功标准是随时代变迁而逐渐演化的
1、帝王早期，只要把规定的工作干好就意味着项目成功，并没有明确的时间和成本限制，秦始皇陵和金字塔就是例证。
2、时代变迁，项目的成功标准逐步演变为在规定时间内把工作做完。钱用完了可以再申请，但是必须按时完工，隋朝的京杭大运河是一个典型代表。
3、在现代，普遍接受的项目成功标准是三重约束：范围、成本、时间（另一种说法是质量、成本、时间。）。
4、现在，项目不仅要在规定的范围、时间和费用内把事情做完，还要符合质量要求并使干系人满意。当然，时间、费用、质量也是项目干系人的需求，因而可以简单地认为：项目成功就是让项目的干系人满意。
关于项目成功的判断标准几乎都是主观的
项目干系人的看法、环境及各种期望都会对失败的判断产生影响。在客户公司中，与项目团队一起工作的人可能认为项目是成功的，但客户的老板却未必这么认为。
在项目早期，制定出各干系人一致认可的成功标准是多么重要。
2.2 真正成功的项目是可以复制的
在国人的文化里，某种程度都有试图绕开程序的想法（总有人试图拥有特权），以至于不喜欢按照程序做事。
程序的价值在于可复制性（或说可控性）
靠人完成工作往往有较大风险，因为人是容易出问题的。对组织而言，经验再丰富的人其价值也是有限的。而能把经验总结转化为程序，使得后来人可以重复实现，这就非常有价值。
成功的项目应该是可以为组织或后续项目提供可复制的方法、技术或经验。
2.3 中国特色项目之“项目过程”
项目是一种临时性、独特性的任务，对任何一个项目的管理在某种程度上都是风险管理，不做有效的可行性论证，没有明确目标和有效计划使得项目过程完全不受控，甚至走到哪儿算哪儿。有人将这种项目过程冠以中国特色的项目管理！
中国的问题只要找到了“国情”“特色”，大家就都没有责任了！
方法论背后应该是一部血泪史—其中不少弥足珍贵的经验或原则是人们在诸多项目失败的痛苦中总结出来的。有人说，方法论来自失败和恐惧，是诸多项目实施的先驱们痛定思痛的结果，是实施专家经过理论研究并在总结了无数案例和成功经验的基础上提炼而成的。
从“摸着石头过河”到方法论是历史演进的必然，也是项目实施从高风险、不确定态演进到低风险、稳定态的保障。领先一步叫先进，领先三步叫先烈。大约先烈们在做事情的时候是没有方法论的，他们只能靠“试错”，所以大都失败、成为先烈。
后人只有汲取先烈的经验教训，才能降低失败的风险，提高实施的成功率，有机会成为先进。
到今天实施项目还蛮干的人，不仅对自己不负责任，而且着实对不起以前的先烈！
2.4 中国特色项目之“六拍”
第一拍——拍脑袋：领导立项
经常有些领导有了做一个项目的想法后，不是组织相关人员严格论证是否可行，而是自己觉得可行就上马。
第二拍——拍肩膀：任命项目经理
启动会议上，为了鼓舞士气、调动项目经理的积极性，领导拍着项目经理的肩膀进行激励：“好好干，前途无量。”
第三拍——拍胸脯：项目经理向领导承诺
受到领导激励的项目组成员为了让领导放心，也会有所表示—拍胸脯，而且“牛人”们往往还会表决心：“选择我，没错的！”“放心吧，包在我身上！”
第四拍——拍桌子：项目遇到问题时相互攻击
项目进行一段时间后，运转情况远达不到预期，而且不知不觉中陷入了“墨菲定律”的陷阱，领导忽然发现项目进展情况与预期相去甚远。在领导们的压力之下，团队成员间的冲突开始出现，推卸责任、抓凶手、互相攻击——拍桌子！瞪眼睛！这成了项目中一些脾气暴躁的团队成员束手无策时或着急上火时常做的事。
第五拍——拍屁股：项目经理干不下去走人
团队的震荡冲突，项目的种种问题，使项目经理越来越难以驾驭。拍屁股——“不给支持、只要结果，现在项目做不下去了，就知道训我？我还不干了呢！走人！”
第六拍——拍大腿：领导后悔
项目结果令人大失所望，领导开始后悔项目开始时的决策和冲动：为什么上这个项目？为什么选择项目经理不慎重？为什么项目过程不认真策划？……大家都拍大腿——痛心不已，却又无可奈何：“唉，早知如此，当初就应该……”
2.5 中国特色项目之“三边”
1．边设计
项目开始时，项目经理和他的团队不清楚项目目标，也不知道项目具体该如何做。范围不清、目标不明，盲目、朦胧地凭感觉来做，边走、边设计，“摸着石头过河”成了一种习惯。
2．边实施
实施过程就像傻子和面，面多了加水，水多了加面，最后把人都糊到面团里了。我经常讲哥伦布式的管理，项目实施也有哥伦布式的项目。整个过程是一种布朗运动，完全是一个无序的混沌态。
3．边修改（边返工）
所谓计划不如变化快，项目环境实在多变，发生很多“始料未及”的事情。情况变了，随需应变，改呗。改来改去改成什么样子谁也不知道，反正最终的结果是什么样大家都不清楚，就顺其自然吧。
“三边”项目的结果是未知的，全凭运气，运气好就成功了。
2.6 中国特色项目之“四没”
1．没问题：项目开始时
项目开始时，乐观主义情绪充斥在组织上下，每个人都对项目的未来充满想象，风险意识全无。即便项目有可行性研究，也常是“为可行而进行研究”——研究到最后都是可行的！此时，即便有人提出疑问，也常被当做异类，没有人听进去。
2．没关系：项目实施中
项目实施过程中，时不时会遇到一些客户需求变更，而客户往往又表达不够清晰，技术牛人们常在内心里有“他不懂”的想法，认为按照自己的想法就够了，对所谓的“小问题”不以为然——没关系，为项目失败埋下了祸根，他们往往不记得“项目成功取决于干系人的感知”。
3．没办法：项目失败了
不出所料的项目结果终于如期而至，进度超期、成本超支、挫折感弥漫！……“客户根本就不懂，这种客户不是我们服务的对象”“中国特色呗”……
4．没资源：项目总结时
职能经理：“市场部不知道客户的关键干系人是谁，根本就不知道客户的真正需求是什么？”市场经理：“我已经拿到了订单，做好项目是项目经理和你们职能部门的责任。客户对我们的技术水平和服务态度很不满意，你们把我好不容易拿下的客户得罪了！”项目经理：“公司实施这种项目需要大家共同努力，市场部门没能搞定客户，各职能部门资源不能保证，根本就是先天不足——没资源。”
2.7 项目是基于业务的面向干系人的过程
很多信息化项目的失败是先天注定的！
信息化项目绝非简单项目，公司高层、各部门部长、公司所有员工都是项目的重要干系人，都对项目有自己的期望，不认真考虑所有干系人的需求必然会带来负面影响。
信息化项目涉及公司的流程改进和管理变革，异常复杂；换言之，信息化项目是一个面对人的过程，而不是一个简单的技术工作。这也是很少见到成功的信息化项目的真正原因。
ERP项目涉及公司各部门的流程改造和管理调整，需要各部门配合。
实践表明，清楚识别项目干系人并让他们承担起对项目的责任绝非易事。有时一个项目进行了很长时间，但项目组未必知道项目的真正客户是谁，常犯的错误是仅将项目成果的直接使用者作为客户。
技术背景的项目经理经常犯的错误就是喜欢面对感觉容易沟通的人，但是问题是这些“容易沟通的人”未必是最重要的干系人。一个研发类项目，项目经理和客户的研发部技术负责人沟通需求，就是一个严重的问题。多数情况下，需求并不来自技术部门，而是来自业务部门。
作为项目经理，一定要能够把自己提升到业务的高度，有能力和业务层面的人员直接进行沟通。
2.8 大象是不会和老鼠沟通的
项目发起人通常是处于组织的高层管理人员。除了正常的工作外，当项目需要时，必须能够提供必要的帮助。
项目发起人实际上像项目经理的“大哥”或建议者。项目发起人应该帮助项目经理解决那些项目经理自己不能解决的问题。
请记住：应该让合适的人担任发起人和项目经理，大象是不会和老鼠沟通的。
2.9 面对发起人与上级的不一致
项目发起人被认为是影响项目决策的关键干系人。但是，发起人通常拥有既定利益，如果项目经理认为发起人做出了一个错误的决定，他该怎么办？项目经理是否要走上上诉道路？
当发起人与高级管理层间的矛盾（尤其是政治因素）影响到项目时，项目经理又当如何？通常，对于高级管理层之间的冲突项目经理没有能力解决这个问题，也轮不到他来解决。更严重的是，发起人与高层管理者之间的利益，比项目经理与上述二者之间的利益关系更密切。
领导层内部经常出现不同的声音，而且，不同的声音并不能通过正常的程序取得一致。
在管理学上，“政治”至少是中性而不是负面的。如果你希望别人支持你，你必须先对对方有充分的理解，这个就是“政治敏感”，也是最为典型的“中国特色”的技能。
面对高层管理者之间的不一致类问题，我建议的原则主要有两个：
关注利益而非立场；不参与政治，但是必要时可以利用政治。
如果项目经理仍然在现有组织中生存和发展，可以采用如下办法：
1．没有永远的立场，只有永远的利益
尝试去探讨“真实动机”，而不是表面的“立场”，真实动机往往是和利益直接相关的。有时候尝试给一些试探性的建议，有助于理解对方的真实想法。
2．提升“政治敏感”性
遇到问题时，尽力考虑周全，在处理工作之前，尽可能通过面对面的非正式沟通（如午餐、运动）方式了解领导之间的意见。
3．从厚黑学角度（我不喜欢厚黑学）理解
如果一定要站队，我建议站在直属领导一边，否则会让自己陷于“时刻郁闷中”，因为顶头上司与自己待在一起的时间更长。除非你可以明确地判断出顶头上司“待不久了”。
4．多请示，多汇报，尽人事，听天命
无奈的体现，这是弱者经常使用的“阿Q方法”。
2.10 跑偏的“项目经理负责制”
1．项目经理应承担的责任有限的
项目经理之所以被称为“项目经理”，是因为有了项目才有这个职位，没有项目这个职位自然就消失了。“先有项目，再有项目经理”是基本的时间顺序。多数情况下，决定项目该不该干的人是企业高管，项目经理只是完成项目，他们不是项目的决策者。
“以无比高的效率完成了一件不该干的事情”是最糟糕的问题之一。“做正确的项目”往往比“将项目做正确”对企业来说更基本、更重要。对一个项目正确与否的判断，责任不应该由项目经理来承担，他们也担不起这个责任。
2．项目经理的权限和可用资源是有限的
临时性的项目经理和稳定的职能经理之间常常存在资源使用上的冲突。项目经理当然希望资源越多越好，而部门经理则希望项目资源消耗得越少越好。因此，不仅在项目决策上项目经理说了不算，即使在做项目计划时，项目经理也时常说了不算。他们需要去和职能经理商量，常见现象是项目经理需要的是“贤人”，但职能部门提供的是“闲人”。职能经理和项目经理常常为了抢夺项目资源而起纠纷。
3．项目成功与否更依赖于项目治理
尽管项目管理的重要性已被越来越多的人认识，但多数人仍认为项目管理是项目经理的事，而没有意识到高级管理层和项目发起人的项目管理责任。要想项目取得成功，不仅需要胜任的项目经理去完成项目管理，还需要胜任的组织高管去对项目进行有效治理。
项目治理的成果是项目成功与否的战略方向，而项目经理们只是按照这一方向具体实施项目的人。
2.11 可行性研究的是“为可行进行的研究”？
可行性分析失效的原因很多，我将其归为四点：
1．摆“花架子”、玩“两张皮”，为领导而论证
可行性论证前，领导已经有了想法和主意，工作只是履行一个程序而已。我将这种论证称为“为领导论证”。
2．倾向性意见导致判断上的自负
众所周知，人们在大多数概率判断时都会自负。也就是说，他们认为自己知道的比实际知道的要多。研究证据表明，人们在困难问题上会过于自信，而在简单问题上则会缺乏自信。
3．论证对象的选择天生缺陷，论证内容不足
项目的可行性研究一般注重技术经济分析，而忽视了项目风险的主要来源—管理，忽略了管理可行性研究。管理风险是项目最大的风险来源，特别是对来自企业外部的其他干系人的管理更是如此。
4．对论证结论不负责任，专家“家奴化”
管理和决策的系统设计缺陷，对评估结论不负责任或责任很小，从事可行性评估的“专家”要么迎合领导意图，要么是“伪专家”。这些都促使专家们不负责任地说昏话、狂话甚至神话。现在很多政治、经济问题的出现，与一些经济学家、法学家、社会学家说话不担责任不无干系。
第三篇、需求管理是项目管理的真正难点
3.1 好的需求和目标应该符合SMART法则
需求和目标管理是项目经理变被动工作为主动工作的好手段，好的需求管控和目标确认不但有利于团队高效工作，也为项目绩效考核制定标准；没有可验证目标的项目注定失败。制定目标看似一件简单的事情，实则不然。
SMART法则
Specific：目标是用具体语言清楚地表达的；
Measurable：目标是可以验证和测量的；
Attai门able：目标是通过努力可以实现的；
Relevant：目标是与工作有相关性的；
Time-based：目标是有时间限制的。
常见的不明确的目标如下:
客户满意（什么是满意）；
快速响应（多长时间算快速）；
稳定运行（稳定指哪些指标）；
有效控制（如何算有效）
3.2 一个“泛项目”的诞生
“范项目”是不能预先将目标、范围等清晰定义而只能大致明确的项目。
新产品研发（如抗埃博拉病毒药物的研制）常是“泛项目”，人们无法预知该项目将遇到何种技术难题、它们究竟需要多长时间才能攻克。
作为项目经理，尤其是新技术行业的项目经理，都会遇到“客户逼”“上司压”“牛人顶”的局面。这是任何技术手段都无法解决的矛盾。
3.3 需求的关键在于挖掘背后的业务
项目经理要有非常好的沟通能力，但沟通能力并不仅表现为滔滔不绝地说，很多时候，静下心来听是更重要的技巧。
项目经理需要的是耐心、技巧和深层次的沟通，搞清楚客户和干系人的真实想法
再次提醒项目经理，你是业务层面的管理者，项目是基于业务导向的。
3.4 展示你的样板房
在软件行业，在界面设计没有正式展现给客户之前，所有的工作都处于需求调研阶段。
客户买房子之前是先要看看样板房和模型的，什么都看不到这房子你敢买吗？除非你不是自己住！
在概要设计阶段所衍生出来的需求工作量是之前的5～10倍，甚至更多，因为这要看设计人员的业务沟通能力和建模水平。
在中国实施软件项目，必须以咨询方式展开：要推出自己的方案，而不能完全按照客户提的需求做项目。
要做好项目，实施者必须有很好的业务建模能力，快速地给客户展示合理的软件Demo。多年的经验告诉我，对于软件项目，一定要给用户看到“样板房”——软件Demo，才算需求调研结束！
3.5 忘记项目目标是技术型项目经理面前的一堵墙
时刻铭记项目目标是项目管理很重要的一个思维，项目所有的活动都围绕这个展开。
随着项目的逐步开展，尤其是复杂项目：人多、事多、周期长，很多项目经理会逐渐因为个人喜好而忘记了项目的大目标，比较典型的表现有以下几点。
技术出身的项目经理会沉迷于技术细节，花大量时间在学习新技术或者一头闷在解决技术难题上；
脾气火爆的项目经理会因为很多小事情大发脾气，把团队搞得乌烟瘴气；
小心眼、爱面子的团队成员会因为某个技术观点不同而怀恨在心，搞拉帮结派，不团结。
无论原因是自身不成熟，还是管理经验、管理能力不足，结果都一样，那就是项目出问题，甚至失败。
项目经理最重要的一项任务就是跟踪与控制，时刻把握项目方向，保证项目计划得以顺利执行，让偏差控制在可控风险范围内。项目经理一定要时刻保持头脑清醒，对项目无益的事情不做，对项目产生风险的事情更不能做。
项目经理一定要能明确以业务为导向的目标，清晰识别哪些是成功的机会，哪些是失败的风险，少走弯路。
3.6 “如来十掌”与项目管理思路框架
1.确定项目的工作内容（范围、需求）；
2.确定这些工作要在什么时间完成（时间、进度）；
3.确定这些工作要花多大代价完成（成本、财务）；
4.确定这些工作做到什么程度才可以接受（质量）；
5.弄清需要谁来完成项目，以及组织内部有没有这些人力资源（含知识、技能）；
6.如果没有足够人力资源，需外包一些工作给其他人（采购、合同）；
7.项目所涉及的内外部干系人之间需要协调一致（沟通）；
8.识别哪些不确定性会促进或妨碍项目成功，并加以管理（风险）；
9.如何实现干系人期望的控制并获得干系人的满意（干系人）；
10.在上述九个相互竞争的目标下，实现最优（整合）。
3.7 烦人的客户需求
需求才是项目管理的第一难题。需求，总有填不完的“坑”。
关于需求最为经典一句：“我确实说不清我想要的东西是什么样子，但是我能说清的是你给我的东西不是我想要的！”
3.8 从期望到需求
用户压根不知道自己需要什么，直到你把它摆在他面前
现在很多项目人员嘴里嚷嚷着的更像是“期望”，而不是“需求”
用户基于他们的阅历与认知习惯将自己的需求套到现实中的物质中。
福特汽车公司创始人亨利·福特询问客户有何需求，得到回答：“要一匹跑得更快的马。”他们回答“一匹跑得更快的马”，但并不意味着这就是他们的需求。需求是客户表达出来的期望，就是那匹更快的马。翻译过来，他们真正的期望是“速度更快的代步工具”。
用户真正期望的东西找到了，福特并没有给他们一匹更快的马，而是一辆福特汽车。这辆汽车就是我们所说的“产品需求”。
产品需求实际上是产品所具有的功能和特性，它基于用户需求，需要结合产品成形。产品需求是用户需求的进一步提炼。
项目需求——为实现产品而开展的工作。
当用户提出很多意见时，往往包含他们对这个问题的定性与解决方案。所以，我们往往听到的是“你在这里加个× ×按钮”“这不行，得那样才行”。其实，就像用户使用产品只是想完成他们的任务，而不是来体验的一样。他们给你提各种期望也仅仅是为了更好地完成任务。所以，我们需要对这些期望过滤，得到用户的需求，然后再结合自身得到产品的需求，最终迭代到产品。
3.9 谨防投射效应
横看成岭侧成峰，远近高低各不同
投射效应是指以己度人，并强加于他人的一种认知障碍。主要表现是，认为他人具有与自己相同的特性，把自己的感情、意志、特性投射到他人身上。
每个干系人对项目的目标都不尽相同，项目经理要谨防投射效应的负面影响，不要以自己的认知和喜好定义项目的需求和目标，更不能完全从技术角度看待项目的目标。
我们觉得好没有用，关键是干系人（客户）觉得好才有意义
3.10 区分想要的和需要的
项目实施过程中出现需求困惑的重要原因是干系人想要的与真正需要的之间存在差距。差距产生的原因可能是客户对技术激动不已，迷恋于在某处看到的东西，他们说自己一定要拥有它，却不考虑这是否是自己真正需要的。
麻省理工学院的经济学教授丹·艾瑞看到了这个方案以后感觉很纳闷，于是找了两组实验对象进行了对比测试，结果令人吃惊。◎当第2种方案不存在时，84%的人选择第一种方案。只有那些完全不缺钱或更重视阅读体验甚至收藏杂志的人——占16%左右——选择第3种方案。◎当第2种方案存在时，32%的人选择第1种方案，68%的人选择第3种方案。换句话说，第2个方案唯一的用途就是使第3个方案显得特别超值，在这种超值的感觉诱惑之下，很多人忍不住多掏了更多的钱。
请时刻记住以下几点：
项目中给干系人需要的而不是他想要的；
想要的很多，需要的不多；
想要的是理想的，需要的是能解决业务问题的。
3.11 切忌“鸵鸟心态”
“鸵鸟心态”，是一种不敢面对问题的懦弱行为。其结果只会使问题更趋复杂、更难处理。就像鸵鸟被逼得走投无路时，就把头钻进沙子里。
多数人不想过早地和客户纠缠一些问题，只是因为怕麻烦。问题不谈的话，眼前还可以走下去，一谈就可能会变得复杂……说实话，有时谈清楚是“技术”，不谈清楚是“艺术”。的确存在一些“只可意会不可言传”的东西，这是干系人管理的问题。
从现实角度而言，如确实有问题存在而且早晚躲不掉，假如争吵不可避免，早吵也会比晚吵好。一方面，问题在早期解决代价会比较小，后期就会付出很大的代价；另一方面，尽早暴露问题，吵完了大家也就可以安心地做事了。
3.12 需求是要确认的
记住：拿不到签字，下一阶段就不能开始。
其实，我们真正想要的并非他们的签字，而是逼他们认真考虑项目问题。
在需求和范围确认这件事上，项目经理需要“强势”一些，用各种可能的办法“逼迫”客户把需求考虑清楚。
不管用什么方法，在项目开始前，主要的项目干系人必须对项目目标、需求达成一致。
请注意一个原则：对事要硬、对人要软！
第四篇、项目必须被计划管着
4.1 没有计划的目标是浮云
目标未必是可行的，通过计划的制订与工作分解会逐步暴露项目目标的可行性。
干系人期望不是孤立存在的，期望与计划是相辅相成的，目标指导计划，计划的有效性影响着目标的达成。
管理项目是个复杂的过程，计划充当着这个过程的地图。
认真做好计划工作与项目的成功密切相关。而且据我们所知，没有任何一项研究支持相反的观点。
4.2 计划是应对帕金森定律的办法
工作会自动占满一个人所有可用的时间，工作总会拖到最后一刻才能完成。
如果一个人给自己安排了充裕的时间去完成一项工作，他就会放慢节奏或者增加其他项目以便用掉所有的时间。
工作膨胀出来的复杂性会使工作显得很重要。在这种时间弹性很大的环境中，人并不会感到轻松，相反会因为工作的拖沓、膨胀而苦闷、劳累，从而精疲力竭。
人做一件事情，耗费的时间越长，就会感觉越累。
如果你给了自己充足的时间去完成某项工作，你一定会不自觉地放慢节奏至最后的时间期限，才集中精力去完成这项工作，所以，你会因为时间的拖沓和最后的紧迫感而感到劳累，筋疲力尽。
为了避免无事忙，必须制订工作计划，更要明确工作完成的最后期限，这个期限越近，工作效率越明显。
4.3 计划是测量和控制的基础
计划是保证项目目标和方向的手段。
如果偏差较小，尽可能回到原计划，即偏差小，改变行动、回复计划。
如果偏差较大，保证方向改变计划，即偏差大，确保方向、改变计划。
计划为有效控制提供了测量标准和基础，没有计划，控制无从谈起。
计划是用来改的。正因为计划没有变化快，才更需要做计划——变更管理计划。
4.4 “摸着石头过河”还是“顶层设计”
“摸着石头过河”作为在没有经验借鉴情况下采取的一种战术策略，对推进改革发展进程发挥了非常重要的作用。
“磨刀不误砍柴工”对项目计划同样适用。
项目经理必须抵挡住立即开始项目工作的压力，花时间制订详细的项目计划。
事实证明：没有项目计划或者差的项目计划最终会付出进度延迟、质量低劣、不能满足期望的代价。
不做计划或糟糕的计划将会使你在项目开始之后备受痛苦折磨、以至于难度越来越大，直到摸不到石头，无法前进。事实上，这种痛苦将会持续地增加，除非在忍无可忍时不玩了。
制订项目计划的确是痛苦且困难的（需要明确项目需求、进度、预算、质量、资源、风险等），但会减少你在项目后期的痛苦和困难。
4.5 文档务必要简洁并可视化
实践告诉我们，长篇大论、复杂的文档让人很累，也没有人看。
汇报工作要简单、明了，否则不仅难以理解而且推动起来也比较困难。
作为项目经理，务必要把文档写得简明扼要，如果实在没有办法减少计划页数，至少也要把第一页纸写得高度概括，当客户（或老板）看的时候，他们可以选择只看第一页。
我们强调计划要细致，但一定不要把计划做成复杂、晦涩的文档。要善于使用图表、插图，以最短时间、最小篇幅，把复杂内容简化，让不懂技术的人了解真实情况，让高层管理者了解项目的关键要点，让干系人理解项目安排。
4.6 明确验收标准是项目早期的工作重点
明确的验收标准和约定条款是项目成功的关键条件。
4.7 魔鬼藏在细节中，WBS是揭开细节的神器
WBS的定义
工作分解结构（Work Breakdown Structure）， 创建WBS是把项目工作按阶段可交付成果分解成较小的，更易于管理的组成部分的过程。
WBS是项目管理重要的专业术语之一。WBS的基本定义 ：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。无论在项目管理实践中，还是在PMP，IPMP考试中，工作分解结构（WBS）都是最重要的内容之一。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。
要提高项目的执行效率，必须提高项目的构件化（标准化）程度，创建WBS的过程就是对项目进行结构化、标准化和构件化的过程，唯有此才能提高项目过程的复用性。这是组织提高项目管理能力的必由之路。
4.8 里程碑节点比验收节点更重要
当目标被分成几个重要里程碑，总目标的实现就变得现实了。当目标被清晰地分解，目标的激励作用就显现了；当实现了一个目标时，我们就及时地得到了一个正面激励，这对于提升挑战目标的信心的作用是非常巨大的。
“以结果为导向”是对的，但是“有条件要上，没有条件制造条件也要上”的提法本身就有很大的问题。并不是说结果不重要，但结果是靠过程来保证的，没有好的过程就很难有好的结果。对于项目控制来讲，里程碑就是最有效的过程控制手段。
作为项目经理，你应该做到以下几点：
在计划过程中，合理规划里程碑节点，使其有可行性，有验收价值；
在执行过程中，围绕每一个里程碑安排工作，找到项目的节奏；
在管理过程中，将里程碑的压力传递给项目中的每一个人。
眼睛盯住细节的，是工程师；
眼睛盯住结果的，是老板
眼睛盯住过程的，是项目经理。
4.9 一个“精确”项目时间的诞生
不管你制订出什么样的日程，高层管理者和客户总是希望项目能更早完成。你只会发现：高层管理者和客户对你提出来的每一个截止日期都不会认同——你的日期总是离他们的期望值很遥远。
4.10 糟糕的项目评审会
职能经理不重视项目会议（也可能是工作的确繁忙），让下属参加项目会议，导致参会人员无权做项目决定（也往往没有能力做决定）；
与会人员在会前不做会议准备，没有认真阅读会议资料，甚至不了解项目会议背景，会议主持人不得已将会议文件复读一遍，严重拉长会议时间，降低了会议效率。
在帮助团队朝着合理的交付截止日期前进时，保护团队不受外界干扰和影响，是项目经理的职责所在。
拒绝不解决问题的会议
很多组织每周都会有成千上万“状态报告”之类的会议。如果不能解决问题，这样的会议就不必召开，也不要参加。
拒绝多人顺序式进度报告会议
顺序式进度报告会议根本不是会议，更像是一个注重形式的仪式。
还应避免的会议
没有存在理由的会议；
没有会后行动的会议；
上层主管的顺序式进度报告会议。
为提高会议效率，必须根据会议需要做好会前、会中与会后管理。
第五篇、让项目运行在正轨上
5.1 技术状态必须确认，工作应该可以互换
“告诉你怎么干，还不如我自己干更容易。”是技术牛人们常说的一句话，尤其是他们看到别人的工作令人不满，而这项工作又恰恰是自己的老本行时更是如此。
当牛人们把工作分配给其他人时，由于对结果不满意，就亲自动手来代替之。第一次“我来”，第二次“我来”……做着做着就成为了甩不掉的工作了！
当然“教会了徒弟饿死了师傅”的心态也常在牛人心中作祟；为了体现自己的重要性，他们时常把工作做成了“不可替代”，以至于玩出了很多“秘笈”！
程序的价值在于可复制性（或说可控性）。靠人完成工作往往有较大风险，因为人是容易出问题的。对组织而言，经验再丰富的人其价值也是有限的。而能把经验总结转化为程序，使得后来人可以重复实现，这就非常有价值。
5.2 警惕变更处于“非管理状态”
基本原则：计划一旦形成，就严格按照计划去执行，而不受某个人、某件事的影响。
但是，另一个极端是很多项目经理排斥甚至拒绝改变计划。“计划一旦制定出来，就永远不要改变。”这是某些人的信条。有这种想法是可以的，但却是不现实的。
变化并不可怕，重要的是让变更处于受控状态，也就是必须遵循标准的变更控制程序，以一种有序的方式来进行变更。在此，我推荐你使用变更管理“九阴真经”（郭致星.做项目，就得这么干[M].北京：人民邮电出版社，2015.）。
归结起来就是一句话：要勇于拥抱变化。在遇到任务超时或超支时，首先完成最重要的任务，将最不重要的留到最后。项目管理本质就是管理变化，计划的第一规则就是“随时准备重新做计划”。
5.3 遵守生命周期中的变更管理原则
在通用的生命周期结构中：
干系人的影响力、项目的风险与不确定性在项目开始时最大，并在项目的整个生命周期中随时间推移而递减；
在不显著影响成本的前提下，改变项目产品最终特性的能力在项目开始时最大，并随项目进展而减弱。
变更和纠正错误的代价在项目接近完成时通常会显著增高。
站在项目实施方（乙方）来说，在项目生命周期中变更处理的原则如下：
项目早期的变更，原则上倾向于接受（我称之为“让怎么干就怎么干”），当然必须遵守变更控制程序；
项目中期，首先要分析变更的影响，原则上尽可能与干系人沟通取消变更（我称之为“要变更先谈谈”）；
项目后期，变更代价太大，原则上尽可能不变更：遇到大的变更时可以考虑启动一个新的项目，遇到小的变更也要到售后服务时再做。当务之急，必须获得验收，收尾项目。（我称之为“生米已成熟饭”——吃，是这盘菜；不吃，还 是这盘菜。）
站在实施方（乙方）的角度：项目过程就是“绑架客户上咱们贼船的过程”。
站在委托方（甲方）的角度：项目过程就是“逐步移交主动权的过程”。
5.4 项目滞后的资源问题——“牛人”争夺战
项目经理都希望项目组成员是一些“牛人”，这些“牛人”确实能对项目的效率产生重要的作用。但在一个企业中，牛人的个数是有限的，他们很难完全归某个项目所有。他们经常被迫在多个项目中充当救火队员或清洁工的角色。
这种由某个高管确定项目优先级的方式，就是常见的中国特色“一把手工程”。“一把手工程”强调了高管的重要性和他们的责任，也会因为缺乏管理程序而造成“无事不需一把手”的情况。
管理总是在“可行”与“合理”之间做选择。
5.5 项目经理的人际关系与政治敏感性
良好的组织因素和建设性的政治是项目成功的有力保证。谈起项目管理，人们会想到“项目经理负责制”，但实际上项目经理拥有的权限和资源很少，项目取得成功，不仅需要胜任的项目经理去完成项目管理，还需要胜任的企业高管对项目进行有效治理。
如果你希望别人支持你，你必须先对对方有充分的理解，这个就是“政治敏感”，也是最为典型的“中国式的项目管理”技能。在中国的企业文化背景下，“政治敏感”还包括对各方利益的深刻理解。
5.6 风险管理在国内的困境
一个事实是：风险管理是一个被忽视的领域，国内更甚。
面对真正的风险时，有勇无谋与采用科学的方法，是完全不同的。所以，不重视风险是最大的风险。
不发生点“事儿”我们无法证明风险管理的价值，可是发生了点“事儿”就证明我们风险管理失败了！这是一个死循环，“不信邪”的思维模式让国人不重视管理。
5.7 风险管控是务实的
很多项目都有风险应对计划，但不够务实，往往沦为应付领导们看的“花架子”。这不仅没有意义，还给员工造成“给员工增加无谓工作”的印象。
计划文档中的工作，必须是一些实实在在可以落实的工作。每一个风险描述和风险应对手段，必须是项目计划中具体的、可以落实的工作项。
糟糕的风险管理与正确的风险管理
第六篇、人的问题不可忽视
6.1 干系人识别的挑战
中国人做事大多是建立在“人脉”基础上的，影响到项目成败的干系人可能与项目有明显的相关性，这很容易识别。
项目干系人的识别颇具困难性、挑战性。识别干系人，并分析他们对项目的影响力，这是至关重要的。如果这项工作没有做好，将可能导致项目工期延长或成本显著提高。
6.2 不要指望别人和你的角度一样
不要指望别人和你的角度一样。这就是基于职能和职权的、组织中常见的所谓“屁股决定脑袋”，也算是国内项目诸多“特色”问题中的一个吧！
6.3 向左走？向右走？
项目的团队成员在关键时刻，会选择“出卖”项目，而绝对不可以“出卖”组织！—铁打的组织流水的项目！
6.4 秋千的诞生
在沟通中信息有55%的意义来自视觉所捕获的非语言信息（仪态、姿势、表情），38%的意义来自谈话时传递出的副语言信息（语气、声调、速度），仅有7%的意义来自语言信息（字词）。这就是著名的梅拉比安沟通信息模型
听到的不如看到的（百闻不如一见），面对面的沟通是最有效的沟通方法。
信息漏斗
我们想说的话的信息总量是100%，那么受到各方面的影响我们实际上说出来的话可能只有想说的80%。因为受到环境、说话人的语速、方言等各方面的影响，这些话被别人听到的可能只占我们想说的60%。同样，这些话的含义能被听到者准确理解的程度可能只占到我们原先想表达意思的40% 。理解之后，这些话能够让他们记住的也可能只占到原来我们想表达意思的20%。能够落实到行动中的起作用的信息微乎其微。
6.5 有效使用电子邮件避免邮件战争
写邮件之前，先停下来想想以下问题
收件人的期望和需求是什么？
您期望得到什么样的答复？
收件人是否有权限进行回应？
还有谁会看到这封电子邮件？
收件人可以从主题中获知什么？
有效的邮件应遵循下面的原则
明确说明信息主题；
确实紧急才标明紧急，十分重要才标明优先；
简短明了，段落简短，多换行；
切勿添加无用附件；
注意标点符号、拼写、语法和大写字母；
发送之前先停一停。
6.6 建立与他人良好的沟通模式
约哈里之窗是关于沟通的技巧和理论
公众自我：自己知道、他人也知道的信息。
盲区自我：他人知道、自己不知道的信息。
隐私自我：自己知道、他人不知道的信息。
未知自我：自己不知道、他人也不知道的信息。
在一个值得信任的关系中把自己公开地表露给另一个人是逐渐理解自我的重要一步；自我表露是改善个人适应的重要方式，当人们压抑自我的时候，他的自我也就停止前进了；通过自我表露，人们逐渐认清自己；那些倾向于隐瞒自己消极信息的人更可能遭受抑郁和焦虑；通过自我表露，促进沟通效果，增强人际关系。
建立与他人良好关系的沟通模式是：循序渐进地使用自己的隐私自我与他人的未知自我进行交换。
6.7 积极有效地倾听
很多沟通问题的根源都在于不良的倾听习惯。有效的倾听，不仅要听词语，而且要听词语所表示的意思，包括对讲话者感受的理解。而且，不注意讲话者的感受，可能会使其感到不被重视或不被理解。
沟通从“心”开始。
6.8 谨防“踢猫效应”
踢猫效应
自然世界中的个体不是孤立存在的，而是相互影响着生存的，每个个体每天都需要面对其他人，职场中要面对同事、领导，商场中要面对竞争对手、客户，家庭中要面对爱人、儿女……
心理学家研究发现，情感、情绪像细菌一样具有很强的传染性，而且传染的速度非常快。人们希望改变——本质上希望别人改变——但又害怕被改变！情感对我们顺应变化会产生种种限制，导致我们烦躁、有气无力。
6.9 先处理情绪再处理问题
对情绪处理不当时常会导致沟通障碍。一个常见的情况是对愤怒情绪的处理，有些人害伯别人认为自己的行为欠妥，就学会了压制愤怒情绪。但这会导致一个问题，就是会积累消极因素，至一定程度终会导致一次爆发。这种爆发可能是感情方面的，也可能是身体方面的。
感知“情绪”是项目经理重要的管理技能。“先处理情绪，再处理问题”是一个重要原则。情绪好了，问题都好解决；情绪坏了，一切都是问题。
与他人保持健康关系，适当表达感情是必要的。对如何处理情绪，我的建议如下：
首先要了解并承认你的情感和情绪，特别是那些所谓的“坏的”或不想有的感情。
为自己的感情用事承担责任，当需要表达情绪时要在头脑中想一下自己能否承受起相应的后果。
如果你信任他，告诉别人你的感受。同理心是沟通的一座桥。
不断学习了解自己的情感。思考一下是什么导致了自己当时的感受。
6.10 打破沟通转折
人们经常认为自己的行为是对他人行为的反应。在个体之间的持续交流中，这称为沟通转折。
一旦出现沟通转折，就很难停止，交流就变成永无尽头的游戏。不过，我们又不是在开玩笑或做游戏。这是许多冲突的本质，并且说明了冲突为什么很难解决——双方都认为自己的行为只是对另一方的反应，他们会告诉你：“如果他没有那样做，我肯定不会这样做。”
6.11 别人为什么帮你
作为项目经理，你必须要（或者说不得不）和部门经理有良好的沟通，除非你可以实质性地掌握资源。当然，即便是有很好资源，也应该保持良好的人际关系。
作为项目经理，有些想法是不应该有的
工作是他们分内的事，他们应该做。
领导安排了，他们必须配合（我反对“挟天子以令诸侯”，不是迫不得已不建议使用参照性权力，更不建议成为经常性行为）。
写在计划或者落实到字面上的，他们就会按时完成（必须告诉你一个事实，如果把每件事都写在字面上，职能经理会认为你是为后续吵架留证据，情绪估计不会太好，更重要是他们比你更懂得如何找借口）。
工作争取管理层支持、形成正式计划都是对的，但更重要的是和职能部门持续地沟通，维护良好的合作关系。组织的流程与制度是框架，人际关系是润滑剂，完全依靠程序未必行得通，毕竟我们的文化中有人情的成分。
6.12 与上司做好沟通
遇到问题首先应该专业地评估、有效地沟通、有力地执行。也就是评估和分析问题的影响并推荐可能的解决方案。
必须跳出问题细节的泥潭，从业务、管理、团队、计划、资源协调等层面对项目进行控制。你要保证每一个工作都有人在做，但不一定都是你在做。
你不是老板，是否过问细节是他的权力。
当然，你还必需明白一个事实就是“领导对细节关注的多少常取决于他对你信任的程度”。
6.13 项目管理者的本质是管理自己、影响他人
成为项目经理并不只是一次职位上的升迁，更是对你能力的检验——你是否具备领导跨部门、解决复杂工作的能力。你能成为项目经理，但你不一定能管好项目。
管理是建立在合法的、有报酬的和强制性的权力基础上的，但是项目管理者更多的是建立在个人影响权和专家权以及模范作用的基础上。说白了，项目管理者最需要的是“说不清道不明”的领导力。
一个人可能既是项目经理，也是领导者，但并不是所有的项目经理都能领导。合格的项目经理运用的是领导的方式，不合格的项目经理则是运用管理的方式。项目经理有能力管理的没有任何人，只有你自己。项目经理握有较虚的职权，只能通过自己的专家权力和影响力去影响别人。只有做到管理自己、影响别人，这才是合格的项目领导者。
项目经理应该具备一些基本的能力或者准则，这个基本准则的核心就是：只有被领导者（项目团队成员）成功，领导者才能成功。
一个优秀的项目经理应遵从以下准则：
提升你的团队；
正直，赢取他人的信任；
懂得工作的乐趣；
让团队成员拥有梦想；
学会分享工作的成绩；
善于倾听并敢于承认错误；
正视相左的意见和建议。
再重申一次，项目经理应该管理自己、影响他人。
第七篇、项目管理者的未来之路
7.1 过分关注于技术也许是一个坑
项目是面向业务而不是面向技术的。
技术专家型项目经理们身上常见的问题包括以下几点:
角色定位错误，过于关注技术；
只见树木、不见森林，关注局部而非整体；
刻舟求剑，静态看待技术外的事；
不愿低下高贵的头，排斥非正式沟通；
过于依赖正式权力，缺乏政治敏感性；
黑白分明，一元论；
缺少权衡、妥协、忍让，理想主义/完美主义；
藐视人情世故，忽视社会学范畴中常理高于一切的现实；
缺乏领导艺术。
请记住，即便是没有能力满足干系人的要求，也要予以适当的回应。
7.2 提高问题理解的层次
现在社会，文凭不代表水平，学历代替不了能力，知识不一定能转化为生产力！
7.3 国人亟待重视理论
按照中国老总的做法，这根针或许很快会找到，或许永远找不到。很难在任务开始前就估计出找到针的时间，也很难定义清楚谁能够找到这根针，只能靠“高素质的人”。按照德国老总的做法很容易对找到针的时间作出判断，也很容易确定能够找到针的人。而且德国老总的方法，可以确保找到。更重要的是，前者对针开展工作，后者对方法开展工作；前者解决一个问题，后者解决一类问题。
前者没有理论，后者有理论；前者属于解决问题的反映层（请参考《做项目，就得这么干》（人民邮电出版社，2015）第16章。），后者属于解决问题的系统结构层；前者需要“素质很高”的人，后者对人的要求不高；前者不能重复，后者可以重复做。
国内的企业管理者亟待重视理论，亟待掌握提炼理论的方法，亟待提升系统解决问题的层次。
7.4 短平快？——艰难的选择
现实中，我们时常鼓励“电风扇吹盒子”式的小聪明，美其名日“秘籍”，这是一个充满秘籍的神奇国度。问题是，这些秘籍经常是解决表象、不解决根源，舍本逐末。这在很多公司中甚为盛行。
解决系统问题的表象容易，解决系统问题的根源很难；而且，解决根源往往时间长、代价大，国人更喜欢“短平快”的方式和方法。
项目经理处理项目团队中的问题成员，也时常如此。面对问题成员，项目经理不会直接处理问题成员（他们往往也没有处理员工的权力；而且，即便是有这个权力也未必敢使用），而试图提高自己的人际关系技能。
当然也可能请职能经理或发起人找这个人谈话，结果仍无法改变此人（正如圣雄甘地所言：“改变别人很难，唯一可以改变的是自己”）。也许真正有效的方案是“开除此人”，但他真会这么做吗？
7.5 什么选择做项目经理？
美国人给出了一个所谓的终极版的定义：“项目经理是由执行组织委派，领导团队实现项目目标的个人。”
项目经理就是一个被组织上下所有人讨厌的人！
如果你喜欢一个人，就让他去当项目经理，因为项目可能会使他有业绩；如果你恨一个人，也让他去当项目经理，因为十有八九他会被失败的项目毁了。
7.6 什么技能对项目经理最重要
项目经理的什么技能是最重要的，我会毫不犹豫地回答“人际关系技能”。不会与人打交道的项目经理，会遇到很多麻烦。
人际关系技能在大多数组织都被低估了。我几乎没有见到因为项目经理不会制作甘特图而失败的项目，倒是常见很多项目因人际关系问题而陷入严重危机。
技术背景出身的项目经理从技术专家到优秀项目管理者，需要六个转变：
由专注技术转向关注拥有技术的人；
由理性转向感性和理性相结合；
由追求完美转向追求满意；
由做自己感兴趣的事转向做自己该做的事；
由着眼于项目工作转向着眼于项目的商业价值；
由技术权威转向管理能手
0 条评论
回复 删除
下一页
