本文主要是介绍读书笔记——漫画中国式项目管理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
引子
- 项目经理必须学会从“业务”的角度去思考问题，而不是技术实现
- 对项目管理来说，所谓的成功追求的不是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个月后会提供测试版，同时我们会安排人员的培训…
- 我会确保测试版包含所有的重要功能，同时会安排人员准备培训方面的资料。
点评:作出承诺时，一定要谨慎
项目经理职业规划篇
政治
如果你希望别人支持你，你必须先对对方有充分的理解，这个就是“政治敏感”，也是最为典型的“中国式的项目管理”技能。
在中国的企业文化背景下，“政治敏感"还包括对各方（内外部、各个职能部门等）利益的深刻理解。别人为什么要做？为什么不做？他们最希望什么？他们最担心什么？
从技术转为业务
技术专家的职业安全感，建立在“我懂、我知道"上。
项目经理的职业安全感，是基于“业务导向的分析能力与良好的沟通能力”上。
项目经理的价值
你的价值是，推动事情向前走，而不仅仅是完成老板给你的工作。
一定要记住，作为项目经理，你的价值不是别人让你干什么就去干什么，而是要帮助你的老板（或者客户）去思考、去推动，把他们的想法转变为现实。
最重要的是头脑，而不仅仅是行动
这篇关于读书笔记——漫画中国式项目管理的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
