引子

项目经理必须学会从“业务”的角度去思考问题，而不是技术实现
对项目管理来说，所谓的成功追求的不是100分，是可以复制的80分
有问题：先搞清楚出了什么事，为什么会出事，有什么样的影响，你打算怎么做，你的计划是什么，你正在做什么，你需要什么资源，当然最重要的是，你希望他出面帮你做什么。

项目需求篇

需求分析是“业务导向”的

项目经理一般都有很好的技术背景，但项目经理不是总工，不是架构师，不是程序员，而应该是一个“业务层面的管理者”。项目需求的切入点必须在业务层面。

请问，我们为什么要建立这样一个办公管理系统？
我们当前遇到的主要业务问题是什么？
您最希望通过这一系统解决哪些业务问题？

老板说的话一定靠谱吗

论证项目的可行性，把老板（客户）的想法落地，是项目经理的首要任务。

老板（或者你的客户）告诉你的，有的时候只是一个想法、一个思路。并不是说老板没有你聪明，而是看问题的角度和你不同。你需要帮助老板（或客户）去论证这种想法的可行性。
如何做：和所有人沟通，形成自己的思路与想法。将老板的想法当做需求。

需求是需要确认的

总之，不管用什么办法，在项目开始之前，主要的项目相关方（Sponsor）要对目标、需求达成一致。

我们真正想要的也许并不是他的签字，而是逼他认真考虑项目问题。很多时候你不逼他，老板是不会认真替你考虑问题的，最终的责任还是在你。

谁是真正的Sponsor

多数情况下，需求并不来自技术部门，而是来自业务部门。作为项目经理，一定要能够把自己提升到业务的高度，有能力和业务层面的人直接进行沟通对话。

沟通需求，针对的必须是项目的Sponsor，即使是间接的，你也必须要能够和这些人对上话。

需求阶段的争吵和争论

真正错误的做法是，你知道客户有这种需要，但并没有加以明确，而是把这个需求“虚”在那里。也许客户并没有强烈要求把这一点写在合同里，但在项目开始的时候对这一点并没有达成一致。

有时候谈清楚是技术，不谈清楚是艺术。

关于合同的“敞口协议”

项目合同中一定不能存在所谓的“敞口协议”，也就是无法量化进行验收的条款。

需求必须是量化的、可操作性的。比如“该系统应保证200人同时上线操作”
典型的“敞口条款”有：客户满意、快速响应、稳定运行、有效控制…

表面原因与深层次原因

在需求过程中，你需要的是耐心，技巧和深层次的沟通，搞清楚客户的真是想法。一定不要试图从技术层面上去“说服”对方，也许问题本身并不是技术层面的。

需求过程中最重要的是沟通技巧，是引导和聆听，阐述自己的观点只能是辅助性的。

项目计划篇

项目的渐进明细

在项目开始的时候，要舍得花时间进行论证和规划，要不厌其烦地和所有相关方沟通，要顶得住压力把模糊的问题谈清楚。

里程碑点比验收节点更重要

验收节点带来的压力，属于“硬性”压力，没有回旋的空间，而“里程碑节点”有时是“软性”的，不属于“燃眉之急”。但是忽视项目的里程碑，则是一个将压力积累，将风险坐做实的过程。
“里程碑达到率”是项目经理绩效考核的一个重要依据。

项目规划应该是非常现实的

项目的计划是非常“现实”的过程，不要用“理想”的假设来骗自己。
当所有人都在逼你尽快启动的时候，你要顶住压力，和大量的人沟通…
当别人没有想到你要能想到，当别人认为无所谓，你要非常重视。

项目计划中的资源冲突

完全避免冲突是不现实的，但如果你能提前发现问题，总是有办法可想的。如果事到临头才知道，就只有看你的运气了。

关键的两点

项目计划阶段，将资源“正式”落实到人（这有时是一件招人烦的事）

提前预见到可能的资源冲突。（如闲聊）

资源是要去争取的

一个好的项目经理，有时候会显得很“强势”，因为你始终在争取资源。当然“强势”不代表“强硬”要学会掌握好方法与火候。

你要让项目团队中的人都看到，你是在为大家努力争取资源的，否则你会一点点丧失威信。
要学会和掌握资源的人打交道，不只是在你需要资源的时候，而是和他们始终保持良好的沟通。

你认为正确，还是大家认为正确

绝对共识是不可能的，但在项目的计划阶段，寻求“妥协”，达成“相对共识”是项目经理的重要技能。

妥协的基础，是对方的“利益”，而不是“立场”。

不同的声音有两种可能性
对方看问题的角度和你不同。（认真听取）

对方的利益出发点和你不同。（相对共识）

首先考虑的是对方的“利益”，而不是“立场”。换句话说，对方的核心动机是什么？他为什么坚持不同的看法？

计划要简洁

首先，如果提高计划的复杂性带来的回报不是很明显，我宁愿选择一个相对简洁的计划，推动起来更容易，更没有风险
要善于用最短的时间、最小的篇幅，让客户（老板）以及所有相关的人理解你的意图。

风险控制一定要落实到计划中

项目风险控制的基础，就是良好的风险规划，有时候保证你安全完成项目的，不是聪明才智，甚至不是你的经验，而是一个看似刻板，但是实实在在，能够很好落实的风险管控计划。

项目控制篇

风险控制是一个持续的过程

真正确保安全的，是合理地流程与机制。

将风险计入风险登记册，每周例会进行讨论。可以做到一旦发生问题，团队会在第一时间知道。

项目启动阶段项目经理的工作

项目启动阶段完成的标志并不是启动会（也许形式上是），而是你是否可以对自己说，需求清晰了，授权拿到了，流程与机制也确定了。

把需求弄清楚，做什么？为什么做？如何验收？验收标准是什么？

拿到高层授权，建立工作团队，落实需要的资源

理清内部分工、工作机制与流程

需求：上述已经讲到。
授权：老板把项目交给了你，你的计划是什么，老板授权你在需要时动用公司的那些资源
理清工作机制与流程：比如，谁说了算？技术性问题最终决策人是谁？涉及业务与成本谁来审批，审批的流程是什么？

项目计划阶段项目经理的工作

了解真实动机是沟通的基础，以业务为导向是妥协的基础。

项目执行阶段项目经理的工作

核心的目的是通过这样一种节奏，及时了解项目的情况，预见可能的问题，找到解决的方法，同时周期性地和主要相关方进行沟通（项目周报 + 面对面讨论）

中长期靠里程碑，短期靠汇报周期（项目例会）

汇报周期（周例会）

按时拿到项目中的管理数据

分析与项目计划（基准）的偏差

找到产生偏差的原因

制定并采取相应的应对措施

“前看一，后看三”，每次例会回顾之前一周的执行情况，讨论未来三周会做哪些工作，以及有什么潜在的问题。（风险登记册、问题日志是每次例会必须要讨论的内容，通过这样的机制，将计划落在实际上。）

基于项目汇报周期的风险机制

风险机制不一定能确保问题不出现，而是确保能够在最早的时间意识到问题的出现，及时采取应对措施。

收尾阶段项目经理的工作

一定不要把眼睛盯在技术细节上，项目始终是一个业务导向的过程，很多时候非技术手段可以更加有效的解决问题。

有一个经验性的方法，在验收开始前一段时间，内部正式开会部署验收工作，讨论的内容应该60%是与业务相关的，也就是在验收阶段，如何同客户（验收方）进行沟通，在关键的问题上向验收方施加一些影响。

关于项目文档

对项目经理来说，不管你喜欢还是不喜欢，写文档是一种必须掌握的核心技能。对于一些你平时不容易见到的人（老板），文档是体现你价值的重要方式。

项目计划不要长篇大论

项目文档是对组织过程资产的积累（形成企业知识库）

最重要的是，搞清楚文档给谁看？目的是什么？管理层（或客户）最希望看到的文档是什么样子？
即使是统一的格式，但侧重点一定是不同的。
善于用一些图标、插图，把复杂的内容简化，让不懂技术的人了解真实情况，让高层管理者了解项目的关键要点。
项目文档，既要符合内部对文档规范的要求，也要对相关方有价值，同时更重要的，能够帮助你达成你希望的目标。

项目中部门的沟通

我们这种体系的缺点是，没有什么是一定应该的，但同样它的优点也非常明显，没有什么是一定不可能的。

使用人际关系（吃饭等）——你必须要（或者说不得不）和部门经理有良好的沟通，除非你可以实质性地掌握资源。人际关系是润滑剂，缺少这一部分，就会被流程卡住。

项目成员的跨部门管理

千万不要抱怨没有足郇的资源，你必须首先证明自己的价值。

在多数情况下，项目经理是非常弱势的，你很难影响团队成员的工资、晋升，那么项目成员为什么要听你的呢？
我给大家几个建议：

当你找人做项目的时候，想好这个项目可以带给他们什么？有时候一个人的意愿比经验更加重要。（对于一个希望转型做咨询顾问的业务骨干，你的项目能否给他提供更多积累相关经验的机会？）
要让大家信服你，包括你的技能、处事态度乃至人品（项目经理是一个非常锻炼“做人”能力的工作）。
和管理层保持充分的沟通（不要通过老板去“压”别人做事，而是先在道理上站住脚，“这些是你应该做的工作"之后再用柔性的方法去推动）。

项目经理未必是资源的管理者，但必须是业务的推动者，你的价值，需要靠自己去证明。

项目变更真的不可控吗？

项目经理一般没有决策权，无论是谁提的变更要求，按一定的流程进行评估，有时是你对自己的一种保护。

完全消除变更是不现实的，但至少有几点你应该力求做到：

在需求阶段，尽最大可能把需求搞清楚；
在执行阶段，严格遵循变更控制流程；
对于发生了的变更，相应地调整文档。

我要强调的依然是需求，问题也许发生在执行阶段，但根源是在需求过程中。你要了解的是用户为什么要做（业务动机），以及什么是可行的方案，而不仅仅是他让你做什么。

这是技术背景的项目经理们最容易出现的错误。即使有销售或其他业务部门的人存在，但项目经理也必须直接参与到与客户面对面的需求过程中。通过间接渠道拿到的需求往往是严重走样的，你也很难了解到客户的真实想法。
对于变更流程，我要强调，项目经理也许没有权利拒绝客户的某些变更要求，但你的权利是要求客户走流程，按照流程把变更提交到正确的层面去决策。

做狼还是做羊——项目管理的规范化

制度也许很僵化，但很多时候只能“先僵化、后优化”。僵化其实是一个标准化的过程，如果开始的时候就希望“优化”，事实上往往不是优化，而变成了“简化”，变相地回到了各自为战的混乱状态。

项目团队与沟通

项目经理是业务导向的，不能过于细节化（特别是针对技术背景很强的人），一定要找对感觉，闷头做事一定会出问题的。

当事情千头万绪的时候，你一定要有清晰的思路，什么是最重要的？

首先，如果流程出了问题，必须首先解决（早上开会发现两个部门间流程出现问题，当天就要想办法解决）；
与重要的干系人沟通、协调、妥协““向管理层争取资源（重要的是在干系人中寻求“相对共识"）；
写文档（这同样是非常重要的，必须保证文档与项目现状保持一致）。

这是一个典型的“项目经理的一天"面向全局但同时也要关注细节，通过不断地沟通推动项目向前走。

项目经理的一天-暂无

项目经理的沟通模式

项目经理的沟通模式，你没有强势的“职位权力”，所以一定要通过沟通技巧达到目的。

每周五项目例会
项目开始的第一天会议通知已经发出去了。
需在每周三下午，发送“会议提醒”给每个人

经验重要还是工作热情重要

与部门经理相比，项目经理在团队管理方面往往是相对比较弱势的。
当你不能决定团队成员的绩效与业绩时，如何推动一个临时性的项目团队去做事情呢？一般来讲，调动每一个项目成员的工作热情，是项目经理的重要工作，但现实地说，这一点并不容易做到。
作为一个弱势管理者，有时找到有意愿的人，比找到有经验的人更加重要。
有经验的人可以降低项目的技术风险，但往往成本较高，并且不容易管理。调动一个有经验的资深员工的热情，需要多方面的因素，很多不是项目经理所能够提供的。而在风险大致可控的情况下，找到有足够意愿并易于管理的员工，往往可以达到很好的效果。

重要的不仅是如何解决特定问题，而是如何在以后的项目沟通中不再出现同样的问题。

项目团队的多样性

在一个多样化的团队中，重要的是要适应各种不同类型的人，并最大限度地使之为项目服务。

技能不同
性格不同
地域不同
文化不同

项目中的沟通是因人而异的

一定不要用你认为好的东西去说服别人。

坦诚地和对方进行沟通，不是推销你的想法，而是努力了解对方的想法，了解对方的性格，要确保你用的方法和提的建议是对方有可能接受的。

客户什么时候会满意

相关方是否满意，很多时候不是取决于问题本身是否解决，而是在于你是否与其进行了充分的、良好的沟通。

保证客户满意的基础是“良好的沟通”，特别是在项目出现问题的情况下。

老板为什么会反对你？

老板为什么会反对你？多数情况下，只是因为你没有努力去沟通。

对于重要的会议、重要的人，当他进人会议室之前，他的想法、态度、观点、会说什么样的话，你应该非常清楚，也就是事先要作充分的沟通。这件事有几种可能的情况：

最理想的情况：
事先沟通好，对老板进行影响，让他按你的想法去说，告诉他你希望他怎么帮到你。

你应该至少做到的情况：
清楚地了解他的想法，也确保他准确地了解你的想法，可以合理地预期他在会上会说什么，以及事先想好该如何应对。

最差的情况：就是案例中给出的这种场景
这时候我能给你的唯一建议就是，承诺认真研究，确保老板的“颜面"，但不正式形成结论，过几天再单独汇报。很多开会时不好谈的问题，单独沟通的时候是可以谈的。

项目经理要处理大量和人相关的问题，很多时候搞定人比搞定事情更重要，而最重要的就是“提前"沟通，“提前"协调，“提前"想应对的办法。

计划与变化

对项目团队来讲，需要的是各种不同的技能，以及与不同性格类型的人打交道。不要根据自己的喜好，排斥某些人的存在。不同类型的人，往往能带给项目不同的价值。

MBTI
P（认知型）：这种人没有“计划"的意愿，做事随心所欲，总喜欢把事情拖到最后一刻才作决定。
J（判断型）：这种人喜欢做严谨的项目计划，希望完全按照计划工作，当一切处于“确定"状态时他们会感觉舒适。

画大饼是不是有用

作为弱势管理，项目经理必须能够适应不同的环境，和不同性格类型的人打交道，重要的不是你认为什么重要，而是对方更关注什么。

MBTI
N（直觉型）：这种人，相信直觉、关注大局、更加在意事情发展的趋势和各种可能性。
S（感觉型）：这种人，相信经验、关注细节、更加在意眼前发生的具体的事情。

项目汇报时，需要大量细节吗

还是这个道理，项目沟通中重要的是对对方的了解，用对方能够接受的方式，去影响对方。

MBTI

适应而不是改变他人

重要的不是你希望用什么模式，在项目沟通中，你一定要学会用别人所习惯的方式与每个人打交道。

MBTI
I （内向型）：往往需要在心里把事情想清楚，才愿意和别人进行沟通，对于不是很清晰的事情，他未必会和你深人地交流。
E（外向型）：正相反，对他们而言，讨论有时只是进行思考的一种方式，没有充分的讨论，他们很难理清自己的思路。

动之以情还是晓之以理

有理未必能走遍天下，千万别委屈，因为虽然做事很重要，但做人更加重要。

MBTI
思考型（T）的人，考虑问题“道理”很重要，他们关注的是正确性，而不是别人的感受。
情感型（F）的人，考虑问题“人”很重要，他们关注的是别人的感受，为此甚至可以作原则性的让步。

让步了，问题就能解决吗

作为项目团队的负责人，感知“团队情绪”是重要的管理技能。“先情绪、后问题”是项目沟通中的重要原则。当没有“项目问题”出现时，先解决好“团队情绪”的问题。否则当有实质性问题出现时，情况会变得非常复杂。

其实，你必须要搞清楚的问题是，对方情绪化针对你的原因是什么。这种原因很可能和你提出的计划没有关系，而是以前的某些事情引起的。

别人为什么要听你的

让别人认可你这个人，比让别人认可这件事情更重要。

你必须让自己有价值
什么是价值？这个因人而异，例如：

通过良好的沟通能力，理解每个人的真实处境和动机。
首先，你必须真实地理解，别人最关心的是什么？他们部门的流程是什么？他们的绩效是如何考核的？他最希望的是什很多时候，即使你给不了他什么，但“理解”本身就是一种沟通的力量。特别是针对情绪问题，“感情认同"往往会使人感觉受到尊重，产生帮助你的意愿。

力所能及地提供团队成员所需要的。
如果你能提供一些他们所真实希望的，哪怕不是眼前利益，有时也会非常有价值。
比如，这个项目无法带给你更高的收人，但对你的职业转型很有帮助，可以积累很多有价值的经验，你是否> 会愿意尝试呢？
这一点反过来说有时更有意义：可能的情况下，从一开始就找合适的（有意愿的）人做事情。

通过合理的渠道，向职能经理反馈项目成员的工作绩效
这一点要小心操作，最好是正式渠道，而不要让人感觉是“打小报告"

项目经理的人缘

你需要给人“强势但不强硬”的感觉，这种感觉来自几个层面：良好的计划、有效的沟通、积极的协调、努力的推动，有变通，但更加坚持原则。

有时候，当你坚持自己的原则时，只要方法正确，更容易赢得别人的信任。
你需要说"No”，但是必须有技巧。

当你的想法被否定时

当你的想法被否定时，千万不要沮丧，甚至有的时候，提出一个思路，主动让对方去批评也是一种很好的沟通策略，目的是了解对方的真实想法。

讨价还价是否有效

最重要的是：沟通中需要理解对方的“真实利益”，而不是“表面立场”。无论问题是否有办法解决，要保证良好的工作关系不受到破坏。

那么，一个好的沟通过程应该是什么样的？有几点是非常关键的：

营建良好的沟通气氛
认真了解对方的真实动机（需要理解的是利益，而不是立场）
试图共同探讨各种可能的选项
在能达成共识时，谨慎地承诺
在不能达成共识时，让对方知道你有“其他选择"，但一定不能让对方感觉到威胁

示例：

我必须坚持尽快完成这一产品
我理解客户给了你很大的压力，而我的压力在于必须保证产品的质量。我今天来的目的，就是想认真听听你的理由，为什么必须坚持4个月完成。讨论完后我希望我们分别和项目团队、客户再进行一次沟通，我相信应该能够找出双方都接受的方案

点评：坦诚以及表达足够的理解，有时可以有效地建立良好的沟通氛围

用户为什么一定要求3个月拿到产品？
我担心这会对产品功能造成很大影响，你觉得这是否重要？
如果我们先将测试版提供给用户的研发人员试用，你觉得怎么样？

点评：尝试去探讨“真实动机"，而不是表面的“立场”，而真实动机往往是和利益直接相关的。有时候尝试
给一些试探性的建议，有助于理解对方的真实想法

我们力争在7个月后提供用户试用版，但仅供他们技术人员的测试，正式版本将在8个月后完成，你觉得是否满足客户的要求？
我觉得用户有可能会接受，如果我们在这期间给用户提供一些培训，帮助他们完成后续的计划，他们应该会满意…

点评:切忌不要在"Yes，，或者"No”这样的极端选项中进行争论，尝试探讨一些双方都有可能接受的方案，
当然，这需要对对方的想法有深刻理解。

如果你的团队3个月无法完成，我可以申请将该项目的后续部分外包…
你确实有这样的选择，但我担心外包的招投标过程本身也会耗费很长时间，同时工作的衔接也非常复杂…

点评：让对方知道你有其他选择，但一定不能是威胁。任何威胁的成分（哪怕是语调）都有可能导致沟通的
彻底中断。在沟通中，你需要给对方留下让步的台阶，否则你就是把自己的路堵上了

我会和用户沟通，8个月后提供正式版本，但在3个月后会提供测试版，同时我们会安排人员的培训…
我会确保测试版包含所有的重要功能，同时会安排人员准备培训方面的资料。

点评:作出承诺时，一定要谨慎

项目经理职业规划篇

政治

如果你希望别人支持你，你必须先对对方有充分的理解，这个就是“政治敏感”，也是最为典型的“中国式的项目管理”技能。

在中国的企业文化背景下，“政治敏感"还包括对各方（内外部、各个职能部门等）利益的深刻理解。别人为什么要做？为什么不做？他们最希望什么？他们最担心什么？

从技术转为业务

技术专家的职业安全感，建立在“我懂、我知道"上。
项目经理的职业安全感，是基于“业务导向的分析能力与良好的沟通能力”上。

项目经理的价值

你的价值是，推动事情向前走，而不仅仅是完成老板给你的工作。

一定要记住，作为项目经理，你的价值不是别人让你干什么就去干什么，而是要帮助你的老板（或者客户）去思考、去推动，把他们的想法转变为现实。
最重要的是头脑，而不仅仅是行动

读书笔记——漫画中国式项目管理相关推荐

漫画中国式项目管理摘录
2017年的最后一天,适合总结2017年的得失,展望2018年的美好.之前有幸拜读了蒋昕炜老师的<漫画中国式项目管理>,受益颇多. 随着书籍内容的展开,一篇篇的小插画让人很是欣喜,很有趣. ...
读漫画中国式项目管理总结
最近公司项目管理交流会议分享了一本项目管理类的书,书名为<漫画中国式项目管理>,挺有趣的,一看书名,我们就知道,这肯定又是一本通俗类的抒理书籍,类似<大话设计模式>. 全书内容 ...
《漫画中国式项目管理》总结
<漫画中国式项目管理>是由蒋昕炜人编写的一本介绍中国式项目管理的漫画书籍. 在这本书中,作者以生动有趣的漫画形式,阐述了中国式项目管理的核心理念和方法.这些理念和方法包括: 以人为本的管理 ...
《漫画中国式项目管理》----蒋昕炜，读书笔记
引子什么样的项目是成功的项目的成功必须是可复制的面对严重的技术问题,你应该怎么做项目需求篇项目需求分析是"业务导向"的老板说的话一定靠谱吗? 关于项目合同的" ...
漫画中国式项目管理重点总结
引子 1.什么样的项目是成功的? "理论上的"成功标准,项目管理铁三角: 一个项目完成既定目标,没有超出预算,按照进度做完,项目就算成功了吗? 项目经理心里必须把一件事想的非常清楚 ...
读书笔记《敏捷项目管理》第七章定义产品愿景和产品路线图
敏捷项目中的计划价值路线图有以下7个阶段: 阶段 1:产品负责人确定产品愿景(Product Vision) 项目的目标产品是什么产品如何支持公司或战略谁会使用产品,为什么人们要使用阶段 2 ...
软件项目管理0718：读一页项目管理读书笔记
软件项目管理0718:读一页项目管理读书笔记 1.项目经理沟通技巧分成三种类型:(1)对上:与高层监督和管理者之间的沟通.(2)下:与下级之间沟通:(3)外:和同事.同伴.同级别之间的沟通,再组织层级 ...
《漫画线性代数》读书笔记用矩阵解方程组
<漫画线性代数>读书笔记用矩阵解方程组太阳火神的漂亮人生 (http://blog.csdn.net/opengl_es) 本文遵循"署名-非商业用途-保持一致"创 ...
《漫画算法》读书笔记
<漫画算法>读书笔记在图书馆借阅算法书时,看到了一本非常吸引我的算法书--<漫画算法>.算法还能以漫画的方式展示出来吗?我带着我的疑惑翻开了这本书,里面的语言非常接地气,通俗 ...

读书笔记——漫画中国式项目管理

引子