《漫画中国式项目管理》读后感锦集

　　《漫画中国式项目管理》是一本由蒋昕炜著作，东方出版社出版的平装图书，本书定价：38.00，页数：198，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《漫画中国式项目管理》精选点评：

　　●对工作思路有了重新的认识 有用

　　●项目管理入门书籍，通俗易懂

　　●很接地气！

　　●写得很不错，值得反复体会，实践

　　●很有实践性的一本项目管理教程~

　　●简要，有用

　　●以漫画的形式讲述项目管理是不错的想法。可惜的是书中的文字并没有为漫画增值。

　　●用来当做轻松愉快的职场小漫画看看还是挺不错的~ 但是话说回来，真正要能解决好问题的能力、软技巧都不是靠这种轻松愉悦的方法能获得的。

　　●非常不错的项目管理书籍，通俗易懂，简明扼要的介绍了项目管理的方方面面，重点部分突出。漫画部分可以忽略了，文字部分内容也可以快速浏览，但一定要结合之前的项目经验进行思考，对今后的项目管理会有所帮助。

　　●很实用的书

　　《漫画中国式项目管理》读后感(一)：通俗易懂的项目管理工具书

　　既然是工具书，下面就把学到的干货拿出来：

　　1、项目经理必须学会从业务的角度去思考问题，而不仅仅是技术实现，一定要把自己提升到业务的高度，有能力和业务层面的人直接沟通对话。所谓的成功追求的不是100分，而是可以复制的80分！复制性体现在流程、机制等！

　　2、项目经历切忌陷入大量细节当中，即使是专家要处理技术问题，但是项目经理这个角色要求你跳出这些问题，从业务、管理、团队、项目计划、资源协调等层面对项目进行控制！保证每个细节都有人在做就好！但是这里面还要重视写文档的重要性，体现价值的重要方式。

　　3、项目需求篇：项目经理要搞清楚为什么做，而不是怎么做。这里强调项目需求分析的重要性！而需求分析中最重要的环节是“可行性论证”，把客户的想法落地，是项目经理的首要任务！而且在项目开始之前，要确保所有的项目干系人对项目目标、需求达成一致！

　　4、项目计划篇：要高度重视里程碑节点，合理规划，确保具有可行性。项目计划阶段寻求妥协，达成相对共识（前提要考虑好对方的利益，而不是立场）！

　　5、项目控制篇：真正确保安全的是合理的流程和机制！制度也许很僵化，但是非常必要，而且大多时候只能先僵化、后优化！僵化其实是标准化的过程！项目启动阶段完成的标志并不是启动会（形式上也许是），而是项目经理是否可以说需求清晰了、授权拿到了（团队与资源）、流程与机制也确定了！项目经理在过程中要把握风险清单、问题清单。

　　6、项目团队与沟通：最理想的情况，事先和领导沟通好，让他按照你的想法去说；次之，清楚地了解他的想法，也确保他理解你的想法，可以合理地预期他在会上说什么；再次，完全被动！老板反对你，是因为没有提前沟通！因此沟通要主动、要提前！做事之前先做人！先情绪后问题是项目沟通中的重要原则！要注意感知团队情绪！要给人强势但是不强硬的感觉（良好的计划、有效的沟通、积极的协调、努力的推动，有变通，但更加坚持原则）！沟通中要理解对方的真实利益、而不是表面立场！

　　7、项目经理职业规划篇：技术专家是解决技术问题，需要客观、公正；项目经理是实现目标，需要灵活和结果导向。技术专家的职业安全感，建立在“我懂、我知道”的基础上，而项目经理的职业安全感，是基于业务导向的分析能力与良好的沟通能力！项目经理要帮助客户去思考去推动，把他们的想法转变为现实！

　　8、其它：

　　坚定比正确更重要！

　　项目经理是学出来的、是自我锻炼、积累出来的！

　　讲的愿望比技能更重要！

　　有所作为，但求无过！所有方法论的价值，都不是保证一定成功，而是力求不犯错误！

　　《漫画中国式项目管理》读后感(二)：项目管理の关键问题思考

　　注 ：本文并非书评，而是借助《漫画中国式项目管理》《项目管理知识体系指南》两本书，对“项目管理”这一课题进行的主题思考。

1.什么是项目管理

　　运用有限的资源，在有限的时间内，实现业务目标

2.项目管理的四个阶段

　　① 立项阶段

　　② 计划阶段

　　③ 执行与监控阶段

　　④ 收尾与复盘阶段

3.阶段一：立项阶段

　　① 明确业务背景、业务目标、业务模型、关键假设、风险

　　② 获取项目所需的资源

　　③ 理清分工与配合模式

4.阶段二：项目计划阶段

　　① 明确关键问题的共识： 业务目标的共识、分工的共识、风险的预判与共识、里程碑的共识

　　② 本阶段的重点是将目标共识、业务压力和主人翁意识传递给相关合作方

5.阶段三：执行与监控阶段

　　执行阶段的重点是监控过程进度 + 持续跟进风险，有效的工具是

　　① 定期例会：回顾上一阶段的目标实现情况，解决重点问题，跟进风险清单，明确下一阶段计划

　　② 周报：信息互通的重要工具

　　③ ☆密集的日常沟通

6.阶段四：收尾与复盘阶段

　　① 收尾：略

　　② 复盘：复盘关键假设与实际结果，反思经验教训输出可复用的迭代流程

7.其他重要问题的思考

　　① 好的项目管理的两个关键点是【共识】与【信息互通】。“共识”几乎涉及项目管理的每个维度，而“信息互通”则贯穿项目管理的从始至终。

　　② 项目管理的关键词另一个关键词是【资源】，包括对可用资源的【识别】【调用】【提效】。业务专家擅长“提效”，而项目经理还需要“识别”和“调用”资源；“识别”资源需要从高处着眼，而“调用”则需要对复杂的组织现状进行分析而后行动

　　（* 补充一位同事在一次沙盘培训的收获：协调资源要敢想。比如拼飞机，每个组都会有拼错的时候，但是不知道和谁去求救，其实可以问蒋老师）

　　③ 好的项目管理不是努力达成不可能完成的目标，而是事先识别资源与风险，制定客观的目标与计划。（项目管理的“客观求稳”并不与追求十倍速发展的愿景相背离）

　　④ 风险管理是一个持续的过程，贯穿从立项到计划、执行的每个环节

　　⑤ 好的人际关系对项目管理起正向影响。而《非暴力沟通》中的沟通模型是很好的工具。在项目管理中，沟通负面问题时，其模型被我调整为“描述事实，阐述影响，指明业务需求，共商解决方案”

　　⑥ 项目管理的另一个关键词是【确定性】，这也就串起了很多其他关键词 ，如：【计划】【风险管理】【共识】【信息互通】【里程碑】【过程监控】【例会】【周报】等

　　⑦ 一半产品经理一半项目经理的话，那么工作模型 = 干好自己的环节 + 让别人的环节正常进展

　　《漫画中国式项目管理》读后感(三)：又名《项目经理的沟通必备技巧》

　　书中更多地是讲项目管理中沟通的技巧。

立项管理

　　gt;> 在项目的启动阶段，项目经理要沉住气（有时要顶住压力），先把需求、方案与工作模式梳理清楚。这个阶段1天可以解决的问题，在项目的执行阶段有时要用3个月才能解决。

　　gt;> 拿到授权，不是老板告诉你，“你去做吧……”而是要用某种形式（比如项目启动会），让组织内的所有人都知道：老板把项目交给了你，你的计划是什么，老板授权你在需要时动用公司的哪些资源。

　　gt;> 理清工作流程与机制，比如：谁说了算？技术性问题最终决策人是谁？涉及业务与成本的谁来审批，审批的流程是什么？

进度管理

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

　　gt;> 眼睛盯住细节的，是工程师。眼睛盯住结果的，是老板。眼睛盯住过程的，是项目经理。

　　gt;> 对于项目控制来讲，里程碑就是最有效的过程控制手段。在计划过程中，要合理规划里程碑节点，使其有可行性，有验收价值。在执行过程中，要围绕每一个里程碑安排工作，找到项目的“节奏”。在沟通过程中，要将里程碑的压力传递给项目中的每一个人。当其他人不重视里程碑节点的时候，项目经理必须重视，而且要用最高的音量、最大的影响力，要求别人像你一样重视。

　　gt;> “里程碑达到率”是项目经理绩效考核的一个重要依据。

沟通管理

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

　　gt;> 学会重视每一个不同的声音。不同的声音有两种可能性：➊ 对方看问题的角度和你不同。➋ 对方的利益出发点和你不同。

　　对于第一种情况，毋庸置疑你需要认真去听取，这是基本素质问题，关键是第二种情况。对方和你的利益点不同。同样是加班，有人是无偿的（固定工资），而有人有加班费（按工时计费），你的想法总是有人支持有人反对。

　　◆ 项目中部门间的沟通

　　gt;> 例子：造船项目，一个子项目的项目经理在研究计划表后意识到，再过1个月工地现场的“龙门吊”将会成为资源瓶颈，于是他交给团队成员一项额外任务：每个星期都要请吊车班的人吃一次饭。一个月后，他的判断证明是正确的，而吊车班始终保证他们组的任务最先做完，甚至接别的部门的工作之前都会先询问他的意见。

　　这虽然是一个有些“粗糙”的案例，但是却非常真实。中国是一个讲人情的地方，在中国的项目管理体系当中，流程与制度是框架，但人际沟通是“润滑剂”，缺少了这一部分，你是会被流程“卡住”的。

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

　　◆ 项目经理的沟通模式

　　gt;> 案例：如果你安排每周五下午2～4点开项目例会，会议通知应该什么时候发？周四？周三？还是周一？

　　标准答案是，如果是项目例会，在项目开始的第一天，所有的会议通知就已经发出去了，应该显示在每一个人的日历中。那么，是不是每周五相关的人就会自动来开会呢？显然不会，日历中的会议邀请并没有约束力。所以，每周三的下午，你要再发一个“会议提醒”给每一个人。

　　怎么发呢？一个统一的邮件群发给所有人？那是没有用的，这种邮件很少有人会认真看。你要给不同的人分别发一个邮件，重要的是，你到底希望从他们那里得到什么信息，要清楚地写在邮件里。比如：研发部门、测试部门、财务部门分别要给你提供什么？

　　这样就够了吗？还不够，他们很忙，不一定有时间准备。所以你要帮他们做好前期工作，也就是把问题问得尽量具体，一定不要用开放式的问题，比如：“项目目前什么情况？”这样的问题是不会有人认真回答的。应该把问题细化到（理论上说）Yes or No, 或者A、B、C、D几个选项中选择一个这样的程度，也就是让对方能尽可能简单地回答你的问题。要是能画表让对方填，也许是一个好的形式。

　　这样就可以了吗？未必，你的邮件他们不一定会看。你需要在周四给每一个人打一个电话。如果他没有回你邮件，要求他看，要求他准备数据，如果他回了，和他作一些简单的讨论，同时要求他们按时参加会议。

　　gt;> 上述案例就是我所谓的“项目经理的沟通模式”，你没有强势的“职位权力”，所以一定要通过沟通技巧达到目的。

　　◆ 项目经理在沟通中的角色

　　gt;> 以下两种说法的效果是不同的：➊“所有测试周三必须完成”。➋“×××领导周五要看演示，直接影响预算的审批，客户希望周四进行预演，所以我们的测试工作周三一定要完成。”

　　一般来讲，简单下达指令，对于小的团队往往效率更高，但对于复杂团队、复杂项目，会导致更大的风险。

　　gt;> 当你意识到沟通出现问题的时候，首先要解决的是模式问题，然后才是具体的问题。

　　例如：你发现销售部门提交的客户需求，往往不能反映客户的真实意图，同时基于现有系统的技术现状也很难实现（销售部门对自有技术了解有限）的时候，你首先要解决的是什么？把真实情况反映给销售部门是一种简单、安全的做法。但作为项目经理，你应该意识到这种需求沟通的“模式”是有问题的，也许你应该和销售部门坐下来谈一谈，哪些会议是需要研发部门直接参与的，哪些技术问题需要先和研发部门进行沟通……

　　明确目标、理清模式，是项目经理在沟通中的主要工作。

　　◆ 项目团队的多样性

　　gt;> 这是我在外企工作时的一个真实故事。为了加快研发过程，我在一个细节问题上跳过了亚太总部（具体说是澳洲的一位同事），直接联系了美国实验室。问题很快解决了，但我的澳洲同事给我发了封邮件，“恭喜”我直接解决了问题，实际上是在表达他的愤怒。问题虽然解决了，但却为之后我同亚太总部间的沟通设置了障碍。

　　每个企业有自己的文化，特别是大的企业。每个部门、每个分公司、每个国家的文化都是不同的。中国人喜欢简单有效的方法，但西方人更讲究流程。我们这里不再讨论二者的优劣，但对于项目经理来讲，你改变不了别人，更改变不了环境，你必须做到的就是适应这种环境。

　　◆ 适应而不是改变他人

　　gt;> 对外向的人而言，讨论有时只是进行思考的一种方式，没有充分的讨论，他们很难理清自己的思路。

　　gt;> 当你和一个内向的人打交道时，最好的方式是什么？提前把所有资料发给他，给他去电话 “张总，这件事很重要，我已经把资料发给您了，请您抽时间看一下，明天开会我希望能听一下您的意见”。然后，在第二天开会时再尝试和他进行讨论。

　　gt;> 总之，你要给对方留出思考的时间，而不要在开会时强求对方表态。

　　◆ “讨价还价”并没有效

　　gt;> 你作为研发项目经理，预计项目开发周期为10个月。但销售经理找到你，因为客户时间紧急，希望能在4个月内完成开发。面对这样极为苛刻的要求，你会怎么办呢？

　　项目经理：我们在最后发布产品前最少需要六轮的Beta测试。

　　客户经理：我们没有那么多时间，客户在4个月内就一定要拿到软件。

　　项目经理：我能够保证的时间最少需要8个月。

　　客户经理：那是根本不可能的。我可以试着推迟到5个月，但这是极限了。

　　项目经理：也许7个月，如果我们足够幸运的话。客户经理：6个月！

　　项目经理：6个半月！

　　客户经理：好，那就6个半月，再长我就无权决定，只能要求高层解决了。

　　项目经理：好吧，但我们必须要拿掉一些产品的功能。

　　客户经理：我没问题，但一定不是主要功能。

　　……

　　而这样一个讨价还价的过程，最大的问题在于，破坏了工作关系（不愉快），没有考虑到对方的真实诉求。

　　我们可以采用这样的方式沟通：共同探讨以下几个问题：用户为什么一定要求3个月拿到产品？我担心这会对产品功能造成很大影响，你觉得这是否重要？如果我们先将测试版提供给用户的研发人员试用，你觉得怎么样？

干系人管理

　　◆ 老板为什么会反对你？

　　gt;> 对于重要的会议、重要的人，当他进入会议室之前，他的想法、态度、观点、会说什么样的话，你应该非常清楚，也就是事先要作充分的沟通。

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

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

　　➌ 最差的情况：就是老板直接在会议上反对你，或对你的方案提出你意料之外的问题。这时候我能给你的唯一建议就是，承诺认真研究，确保老板的“颜面”，但不正式形成结论，过几天再单独汇报。很多开会时不好谈的问题，单独沟通的时候是可以谈的。

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

　　◆ 客户什么时候会满意

　　gt;> 案例：客户的IT系统出现严重故障，公司派工程师到现场解决问题，2天后，问题没有解决，客户极度不满，直接向公司高层投诉。销售人员到现场后，问题依旧没有很快解决，但客户态度明显改善。

　　原因是，之前的工程师没有和任何人沟通问题解决的进展，只是专注于技术工作，而销售只做了一件事，就是每天两次将该问题当前的进展和客户进行沟通。即使问题不能很快解决，但当用户了解事情的真实情况后，多数人是会通情达理的。

　　gt;> 所以，干系人是否满意，很多时候不是取决于问题本身是否解决，而在于你是否与其进行了充分的、良好的沟通。

　　◆当你的想法被否定时

　　gt;> 我作为业务经理，曾经给某医院客户介绍过一款IT产品：“患者跟踪随访系统”。

　　当时我提出的建议是，通过一个筛选机制，把6万多病例中的绝大部分过滤掉，只留下3000多确实有必要进行跟踪随访的患者，通过系统提供随访服务（要知道，很多人感冒都会住院，为的是能报销）。但这一看似非常合理的建议被客户直接否定了。而我随之恍然大悟，客户想要的其实不是提供服务，而是政绩，他们购买这个产品是要“理论上”为更多的患者提供“院外随访服务”。

　　对客户来讲，报表与统计的功能其实是更加重要的。

人力资源管理

　　◆ 项目成员为什么要听你的呢？我给大家几个建议：

　　➊ 当你找人做项目的时候，想好这个项目可以带给他们什么？有时候一个人的意愿比经验更加重要。

　　➋ 要让大家信服你，包括你的技能、处事态度乃至人品（项目经理是一个非常锻炼“做人”能力的工作）。

　　➌ 和管理层保持充分的沟通（不要通过老板去“压”别人做事，而是先在道理上站住脚，“这些是你应该做的工作”，之后再用柔性的方法去推动）。

　　◆ 项目中的激励是因人而异的

　　gt;> 你试图说服一个技术骨干接手一个新项目，但他刚结婚，而你的这个项目需要经常出差，所以他非常抵触。你在短时间内很难找到更合适的人选，只能尽量想办法说服他，你觉得什么样的方式会更有效呢？➊ 画饼：你去做吧，项目只要成功，我保证你可以……➋ 给实惠：你去做吧，从下个月起每个月的奖金……➌ 晓之以理：这个项目只有你做最合适……➍ 动之以情：兄弟，无论如何你要帮我一把啊……

　　实际上，你可以了解该员工的真实诉求，提出解决方法，比如提供房子，让员工的妻子与他一起去。

　　◆ 别人为什么要听你的？

　　gt;> 什么是价值？这个因人而异，这里我只是分享一些个人经验：让别人认可你这个人，比让别人认可这件事情更重要。

　　➊ 通过良好的沟通能力，理解每个人的真实处境和动机。

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

　　➋ 力所能及地提供团队成员所需要的。

　　如果你能提供一些他们所真实希望的，哪怕不是眼前利益，有时也会非常有价值。比如，这个项目无法带给你更高的收入，但对你的职业转型很有帮助，可以积累很多有价值的经验，你是否会愿意尝试呢？

　　这一点反过来说有时更有意义：可能的情况下，从一开始就找合适的（有意愿的）人做事情。

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

　　◆政治敏感

　　gt;> 在管理学上，“政治敏感”至少是中性而不是负面的。作为项目经理，你必须要对企业内部的决策机制、管理流程非常熟悉，对各种表面的、潜在的影响决策的因素了如指掌，否则你是没有办法去争取资源的。

　　gt;> 如果你希望别人支持你，你必须先对对方有充分的理解，这个就是“政治敏感”，在中国的企业文化背景下，“政治敏感”还包括对各方（内外部、各个职能部门等）利益的深刻理解。别人为什么要做？为什么不做？他们最希望什么？他们最担心什么？

变更管理

　　◆ 项目变更真的不可控吗？

　　gt;> 研究数据：美国有一家公司作过一个著名的调查，他们用了10年的时间跟踪了30万个项目，其中一个结论是，完全成功的项目（成本、进度、目标都达成）不到17%，而导致项目出问题（或失败）的一个重要原因，就是需求变更。

　　gt;> 完全消除变更是不现实的，但至少有几点你应该力求做到：➊ 在需求阶段，尽最大可能把需求搞清楚； ➋ 在执行阶段，严格遵循变更控制流程；➌ 对于发生了的变更，相应地调整文档。

收尾管理

　　◆ 收尾阶段项目经理的工作

　　gt;> 一般情况下，项目经理是第一个投入到项目中，也是最后一个结束项目的人，那么收尾阶段应该做哪些工作？一是项目验收，二是文档。

　　gt;> 验收相关的工作是从项目开始的第一天就开始了的。一定不要等到临近验收节点的时候，再去和用户沟通细节需求和验收标准、方法。

　　gt;> 至于文档，这是很多人非常不喜欢的工作。我只强调一点，很多“个人”层面看似没有意义的工作，在“组织”层面是非常有价值的。很多文档工作，是在为组织积累过程资产，所以项目经理要学会按照组织的架构流程进行工作。

合同管理

　　◆ 关于项目合同的“敞口协议”

　　gt;> 典型的“敞口条款”有：客户满意、快速响应、稳定运行、有效控制……（什么是满意？多长时间算快速？稳定指哪些指标？如何算有效？

文档管理

　　◆ 关于项目文档

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

　　gt;> 善于用一些图表、插图，把复杂的内容简化，让不懂技术的人了解真实情况，让高层管理者了解项目的关键要点。

项目经理定位

　　◆ 项目经理的“专业性”体现在什么地方？

　　gt;> 经过评估该项目的成本在90万，但是老板要求必须在50万的成本内完成项目。当你面对这样一个看似“不可能完成的任务”时，如果你拍着胸脯对老板说：“老板，你放心，我一定尽最大努力，一定在50万元之内完成项目。”是对的吗？

　　我们说项目经理不是决策者，而是执行层面的推动者，所以项目经理的专业性体现在几个层面：

　　➊ 准确地评估。➋ 合理地规划（包括时间和成本、资源）。➌ 客观地进行风险预估。➍ 良好的沟通能力。

　　总之，“专业”的项目经理应该能够保证评估与规划是准确的，正确反映项目业务需求与潜在风险，并且通过良好的沟通，让管理层了解真实情况。从是否“专业”的角度看，能做到这几点就足够了。

　　所以，最好不要拍胸脯说保证50万成本内完成项目，而是给出专业的评估，把50万成本和90万成本的效果摆在老板面前，由老板做决策。

　　◆ 项目经理的价值是什么？

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

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

　　◆ 为什么选择做项目经理

　　gt;> 项目经理不是一个舒服的职位，权力小，责任大。当企业流程健全时受流程的制约，而流程不健全时，又往往受业务部门的制约。

　　gt;> 那我们为什么选择做项目经理呢？我试着总结一下，项目经理这个职位，带给个人的一些重要价值：

　　➊ 职业转型的重要过渡：项目经理要求的是“业务导向”的思维方式，这是与技术专家的重要区别。很多人通过项目经理，完成了从“专家”到“管理者”的职业转型。这一过程中最重要的，是自我价值的重新定位，与心态的调整。

　　➋ 锻炼真实的职场能力与生存技能：项目经理的“职位权力”较弱，这就要求必须通过软性的技能去推动项目目标的达成，包括：人际影响能力、组织影响能力、团队组织能力，以及计划、沟通、处理冲突的各种技能。当你能够很好地驾驭项目经理这样一个职位时，你的职场“生存能力”就已经大幅提升了。

　　➌ 培养强大的心理素质与良好的心态：从头到尾一帆风顺的项目是很少的，而项目经理需要一种“在挫折中解决各种问题”的能力，并在这一过程中形成良好的心理素质与承受能力。我经常对项目经理说的话是：一定不要抱怨，你需要通过强健的内心，为项目团队传递正能量，你必须让自己有价值。

　　《漫画中国式项目管理》读后感(四)：漫画中国式项目管理 读书笔记

　　漫画中国式项目管理 蒋昕炜 推荐序 项目管理，简而言之，实为“做事”与“做人”的规律方法。 自序 项目经理并不是老板，而是属于弱势管理者，实际权力比较小，但要对项目的成败负责，所以更多的需要软性技能，通过沟通解决项目中的各种实际问题。 0.1 什么样的项目是成功的？ 在中国这个市场里，要是你的项目连验收都过不去，我建议你就改行吧。 但是，当项目做完的时候，做到什么程度，你可以在心里对自己说，“哇，这个项目真的很成功啊！”成功的标准是什么，盈利？客户满意？实现了既定的目标？…… 项目管理“铁三角”， 只要完成了既定目标，没有超出预算，并且按照进度要 求做完，项目就应该算是成功的 ，至少你不用担心老板骂你了。 很多项目即使超支、延误，也依然是非常成功的，因为它实现了企业的“业务目标”。 当项目经理开始一个项目的时候，不论客户说什么，需求文档是怎么写的，甚至不管合同是怎么签的，你心里必须把一件事情想得非常清楚，那就是客户（老板）到底为什么要花钱做这件事？ 项目经理必须学会从“业务”的角度去思考问题，而不仅是技术实现。 成本超支了，但拓展了新的市场；进度延误了，但为公司带来了新的业务机会……真正成功的项目，重要的并不是你希望我做什么，而是“你为什么要做”！ 0.2 项目的成功必须是可以“复制”的 流程的价值在于结果的“可复制性”，或者说是可控性。 一切细节尽在掌握，完全不需要流程。但如果有大量项目同时进行，不可能对每一个细节、每一个人的能力都有准确的把握。这时候一套成熟的机制 与流程才是最为安全可靠的。 对于项目经理而言（特别是大企业中的项目经理），往往要适应在流程中工作。 你要学会的是在一系列的流程与管理框架中推动项目，提高效率。 对大企业来讲，再有经验的人价值也是有限的。而能把经验转化为流程，让其他人也能实现特定目标的人，才是最有价值的。 0.3 面对严重的技术问题，你应该怎么做 接到紧急电话，你匆忙赶到用户现场。 这是一个方案设计阶段的重大失误，现在暴露出来，导致项目中的所有工作全面停顿。 此时此刻，作为项目经理，你马上要做哪些事情？你想到了什么？· 组织技术人员进行讨论，对技术问题进行分析？非常好，这是必须要做的工作。· 寻找可能的解决方案，甚至是整个技术架构的替代方案？没错，这个也很必要。· 找到更有经验的专家，寻求外部帮助？对，这一点同样非常非常重要。还有什么？ 至少有几件事你应该非常明确： 专业地评估、有效地沟通、有力地执行。先说评估，这样一个问题，对项目计划有什么样的影响？进度是否会延误？成本可能超支多少？重要的里程碑节点（比如中期验收、领导视察等等……）是否受到影响？对于客户、下包商、合作伙伴会有什么样的影响？…… 评估的目的是为了有效地沟通。比如：你该如何向老板汇报这件事？ 出了什么事，为什么会出事，有什么样的影响，你打算怎么做，你的计划是什么，你正在做什么，你需要什么资源，当然最重要的是，你希望他出面帮你做什么。 作为项目经理，切忌不要陷入大量细节当中。 从业务、管理、团队、项目计划、资源协调等层面对项目进行控制。 你要保证：每一个细节都有人在做，但一定不能都是你在做。 1.1 项目需求分析是“业务导向”的 如果你认真分析每一个失败的项目，导致项目失败的原因都或多或少和项目的需求分析有关。 当你和用户坐下来谈需求的时候，应该谈什么？用户：“我们要建立一个办公管理系统。”项目经理：“请问要实现哪些功能？”“有多少人同时使用？”“您希望用什么样的数据库平台？”“您目前的IT架构是什么样的？”这些问题对吗？从技术上来说没有错，但是角度不对，或者说切入点不对。 项目经理一般都有很好的技术背景，但项目经理不是总工，不是架构师，不是程序员，而应该是一个“业务层面的管理者”。项目需求的切入点必 须在业务层面。 请问，我们为什么要建立这样一个办公管理系统？”“我们当前遇到的主要业务问题是什么？”“您最希望通过这一系统解决哪些业务问题？” 作为项目经理，当你选择技术方案、制定项目规划、确定验收标准时，客户的“业务目标”远比“技术实现”重要得多。 首先要搞明白的是为什么做，而不是怎么做。 1.2 老板说的话一定靠谱吗？ 老板把你叫进办公室，交给你一个重要的项目：升级公司的生产管理系统。他希望通过这个项目，能够将客户的订单响应时间大幅压缩，从现在的72小时缩减到24小时。老板滔滔不绝地把他的想法告诉你，为什么做、如何做、谁可以帮你……2个小时后，你记了满满3页纸。当你从老板办公室出来后，第一件事要做什么？ 也许你会想到很多事，计划、文档、资源……但是你有没有想过： 需求分析中最重要的环节是什么？是“可行性的论证”。 老板（或者你的客户）告诉你的，有的时候只是一个想法、一个思路。并不是说老板没有你聪明，而是因为他看问题的角度和你不同。你需要帮助老板（或客户）去论证这种想 法的可行性。 你应该做什么呢？和所有人沟通，形成自己的思路和想法。老板的想法能做到吗？如果要实现，需要哪些资源？如果这种想法不现实，什么是比较现实的？按照你的思路需要什么资源？比如，如果24小时响应订单难度过大，你认为48小时是否可以满足公司的业务需要？当你有了自己的想法之后，再去和老板沟通： 切忌不是坐 下来开上几个会，把老板（客户）说的都记录下来，然后把你记的那几张纸当成项目需求。需求来自反反复复的沟通，有的时候老板也未必清楚地知道他想要什么，以及会有哪些问题。论证项目的可行性，把老板（客户）的想法落地，是项目经理的首要任务。 1.3 需求是需要确认的 明知道老板不愿意签字，为什么还要逼他签字呢？我们真正想要的也许并不是他的签字，而是逼他认真考虑项目问题。很多时候你不逼他，老板是不会认真替你考虑问题的，最终的责任还是在你。 项目经理需要“强势”一些，但不是“强硬”，用各种可能的办法“逼迫”老板和你一起把问题考虑清楚。你可以要求他签字，可以软磨硬泡，可以晓之以理动之以情…… 不管是客户还是老板，不要被他们的强势压住。只要你是为了把项目做好，一般情况下，他们是会理解的。总之，不管用什么办法，在项目开始前，主要的项目干系人（Sponsor）要对项目目标、需求达成一致。 1.4 谁是真正的Sponsor？ 有没有这种情况，你和客户的一位副总沟通了很多次，确定了项目详细需求，形成了文档。但文档报到总裁那里，被全部推翻了，一切从头再来……高层审查时，如果有小的调整是正常的，但如果全盘推翻，说明什么？ 说明你谈需求找错了人……很多你感觉很容易沟通的人，未必是项目真正的Sponsor……如果是一个研发类项目，你和客户的研发部技术负责人沟通需求，你认为正确吗？多数情况下，需求并不来自技术部门，而是来自业务部门。作为项目经理，一定要能够把自己提升到业务的高度，有能力和业务层面的人员直接进行沟通对话。 注：Sponsor 指项目中有最终决定权的人，他们控制项目的经费、验收等。 业务层面的需求往往不确定、模糊，甚至互相矛盾（来自不同部门），而且往往和各方的利益纠结在一起。而你必须要有能力进行梳理、沟通、澄清、协调、妥协，最终达成一种“相对的共识”。 对于有些重要的Sponsor，即使不能经常见面，你也可以通过邮件、短信、QQ，哪怕是找其他人转达，来畅通地获得对方的反馈。沟通需求，针对的必须是项目的Sponsor，即使是间接的，你也必须要能够和这些人对上话。 1.5 需求阶段的争吵和争论 目目标是帮客户开发一套业务管理系统。客户要求在系统上线后对内部人员进行培训，这当然是合理要求。但细化需求时，你发现客户希望培训大量一线员工，很多人从来没有接触过计算机，也就是说客户希望你要从硬件、操作系统开始培训，而不仅是你们负责开发的应用。 ·如果你手里有足够的预算，也有时间，答应这个要求，完全没有错。·如果你没有预算和时间，拒绝客户的这个要求，只要很好地沟通，也没有错，毕竟这种计算机基础类的培训市场上非常多，客户很容易找到替换方案。 真正错误的做法是，你知道客户有这种需要，但并没有加以明确，而是把这个需求“虚”在那里。也许客户并没有强烈要求把这一点写在合同里，但在项目开始的时候对这一点并没有达成一致。 至有的时候，客户并没有想到，但你意识到了，这时候你是否要把这个问题拿出来和客户讨论呢？很多时候，我们不想过早地和客户纠缠一些问题，只是因为怕麻烦。不谈眼前还可以比较顺利地推进，一旦谈的话事情可能会变得更加复杂…… 有时候谈清楚是技术，不谈清楚是艺术。 从技术上讲有一点是肯定的，如果确实是问题，早晚是躲不掉的，假如争吵不可避免，早吵会比晚吵好：尽早暴露问题，吵完了可以安心做事。 1.6 关于项目合同的“敞口协议” 合同的“敞口协议” 如果条款中这么写“该系统必须满足客户方的业务需要”，是否合理？这是一种典型的看似非常合理，但是没有可操作性的条款。 项目合同中一定不能存在所谓的“敞口协议”，也就是无法量化进行验收的条款。 “敞口条款”有：客户满意、快速响应、稳定运行、有效控制……（什么是满意？多长时间算快速？稳定指哪些指标？如何算有效？） 很多项目的失败，是在签合同那一刻就注定的。 1.7 表面原因与深层次原因 在需求过程中，你需要的是耐心、技巧和深层次的沟通，搞清楚客户的真实想法。一定不要试图从技术层面去“说服”对方，也许问题本身并不是技术层面的。 需求过程中最重要的沟通技巧，是引导和聆听，阐述自己的观点只能是辅助性的 2.1 项目的渐进明晰性 项目刚开始的时候，风险大、不确定性强，但对项目的管理成本最低。 项目进行到中后期的时候，确定性加强、风险降低，但管理成本会变得非常高。 如果带着一大堆不确定性进入执行阶段，你会做噩梦的。 在项目开始的时候，要舍得花时间进行论证和规划，要不厌其烦地和所有干系人沟通，要顶得住压力把模糊的问题谈清楚。 2.2 里程碑节点比验收节点更重要 眼睛盯住细节的，是工程师。眼睛盯住结果的，是老板。眼睛盯住过程的，是项目经理。 验收节点带来的压力，属于“硬性”压力，没有回旋的空间，而“里程碑节点”有时是“软性”的，不属于“燃眉之急”。但是忽视项目的里程碑，则是一个将压力积累，将风险做实的过程。 作为项目经理：在计划过程中，要合理规划里程碑节点，使其有可行性，有验收价值。在执行过程中，要围绕每一个里程碑安排工作，找到项目的“节奏”。在沟通过程中，要将里程碑的压力传递给项目中的每一个人。 当其他人不重视里程碑节点的时候，你必须重视，而且要用最高的音量、最大的影响力，要求别人像你一样重视。“里程碑达到率”是项目经理绩效考核的一个重要依据。 2.3 项目规划应该是非常现实的 项目的计划过程是一个非常“现实”的过程，不要用“理想”的假设来骗自己。“如果用户验收不是很苛刻，我们应该可以……”“正常情况下……这个过程不会超过3周。”“××功能应该不是客户最关注的。”“那个时间段，测试部门应该不会特别忙，资源不会有问题。”当我们做计划的时候，是不是有太多“理想”的假设了？项目经理必须非常现实地去落实每一个细节，考虑各种可能的因素，这需要大量的时间。 当所有人都在逼你尽快启动的时候，你要能顶住压力，和大量的人沟通…… 当别人没有想到时你要能想到，当别人认为无所谓时，你要非常重视。 2.4 项目计划中的资源冲突 资源冲突在所有项目中都是非常常见的现象。有人问过我，如何能够避免项目中的资源冲突？坦率地说这是一个伪命题，如果企业有无限资源，还需要项目经理吗？ 关键的两点是：➊ 项目计划阶段，将资源“正式”落实到人（这有时是一件招人烦的事）。➋ 提前预见到可能的资源冲突。 完全避免资源冲突是不现实的，但如果你能提前发现问题，总是有办法可想的。如果事到临头才知道，就只有看你的运气了。 2.5 资源是要去争取的 项目经理要会“抢”资源，抢不代表不讲理，而是代表一种“劲头”。 要让项目团队中的人都看到，你是在为大家努力争取资源的，否则你会一点点地丧失威信。 一个好的项目经理，有时候会显得很“强势”，因为你始终在争取资源。当然“强势”不代表“强硬”，要学会掌握好方法与火候。 资源掌握在部门经理和高层经理手上，要学会和掌握资源的人打交道，不只是在你需要资源的时候，而是和他们始终保持良好的沟通。 2.6 你认为正确，还是大家认为正确 作为项目经理，你始终要表现出高度的自信。 不同的声音有两种可能性：➊ 对方看问题的角度和你不同。➋ 对方的利益出发点和你不同。 对于第一种情况，毋庸置疑你需要认真去听取，这是基本素质问题，关键是第二种情况。对方和你的利益点不同。 公司内部，部门之间的利益也往往是互相制约的。销售部门希望降低价格提高销售额，财务部门的考核指标则是利润率。 项目经理希望严格执行项目计划，而业务部门则希望有足够的灵活性。 绝对共识是不可能的，但在项目的计划阶段，寻求“妥协”，达成“相对共识”是项目经理的重要技能。 你首先要考虑的是对方的“利益”，而不是“立场”。换句话说，对方的核心动机是什么？他为什么坚持不同的看法？这也就是我们讨论过的表面原因与深层原因。 妥协之后的“相对共识”也许不是你最满意的，但往往是更加可行的。 2.7 计划要简洁 作为项目经理，你 一定要学会把计划文档写得简明扼要， 至少要把第一页纸的内容写得高度概括，当客户（或老板）看的时候，他们可以选择只看第一页。 ➊ 首先，如果提高计划复杂度带来的回报不是很明显，我宁愿选择一个相对简洁的计划，推动起来更容易，更没有风险。 ➋ 要善于用最短的时间、最小的篇幅，让客户（老板）以及所有相关的人理解你的意图。 给客户（老板）的文档一定要简明扼要，重点明确。但深入讨论的时候，你要有足够的细节去支撑你的观点。 2.8 风险控制一定要落实到计划中 风险控制计划 是给老板和客户看的。但作为项目经理， 需要把项目风险的应对落实到计划中，这对你自己是最安全的。 计划文档中必须是一些实实在在可以做的事情。 每一个风险应对手段，必须是项目计划中一项具体的、可以落实的工作项。 比如：针对老的下包商，每2周一次例会。针对新的下包商，每周一次例会。针对老的下包商，只在里程碑节点进行技术测试。针对新的下包商，在每个模块完成后进行验证性的测试。 3.1 风险控制是一个持续的过程 将该风险写入风险计划（风险清单）当中， 第一种是个人行为，也许非常有效；而第二种是基于管理流程的，一旦写入风险清单，在每次项目例会的时候都会被拿出来讨论，是一种更加安全的做法。 对于风险控制而言，真正靠得住的不一定是你的头脑、经验 和技巧。 真正确保安全的，是合理的流程与机制。 3.2 项目启动阶段项目经理的工作 在项目的启动阶段 ，先把需求、方案与工作模式梳理清楚。这个阶段1天可以解决的问题，在项目的执行阶段有时要用3个月才能解决。 ➊ 首先，把需求搞清楚，做什么？为什么做？如何验收？验收标准是什么？➋ 然后，拿到高层授权，建立工作团队，落实需要的资源。➌ 最后，理清内部分工、工作机制与流程。 拿到授权，不是老板告诉你，“你去做吧……”而是要用某种形式（比如项目启动会），让组织内的所有人都知道：老板把项目交给了你，你的计划是什么，老板授权你在需 要时动用公司的哪些资源。 项目启动阶段完成的标志并不是启动会（也许形式上是），而是你是否可以对自己说，需求清晰了，授权拿到了，流程与机制也确定了。 当没有产生任何实质性问题的时候，先把这些机制与流程谈清楚，而不是等到出现了严重分歧后，再去争论谁说了算的问题。 3.3 项目计划阶段项目经理的工作 以前一直有一种感觉，项目计划的过程，就是开会和写文档的过程。但后来发现，这个阶段真正需要技巧与智慧的，是协调、沟通与妥协，以达成一个现实、可行、有可操作性、为所有人接受的项目计划文档。 搞清真实动机，而不是表面的立场！ 技术过程需要服务于业务目标，项目经理始终要把业务目标放到技术实现之前。 在计划阶段，开会、写文档、汇报、再开会、修改文档、再汇报……这些都只是外在的形式，真正重要的是和各方进行深度的沟通，使项目计划在实质上达成共识，而不只是表面上的走完流程。 3.4 项目执行阶段项目经理的工作 100个项目经理，就有100种做事情的风格。 但不论什么样的风格，最重要的是要找到一种“节奏感”，也就是说是你推着事情往前走，而不是被事情推着走。 中长期靠里程碑，短期靠汇报周期，也就是项目的例会。 里程碑是中长期的控制节点 汇报周期（一般是周例会），是项目经理日常的管理机制。通过这一机制，要能够做到：➊ 按时拿到项目中的管理数据；➋ 分析与项目计划（基线）的偏差；➌ 找到产生偏差的原因；➍ 制定并采取相应的应对措施。核心目的是通过这样一种节奏，及时了解项目的情况，预见可能的问题，找到解决的方法，同时周期性地和主要干系人进行沟通（项目周报+面对面的讨论）。“后看一、前看三”， 每次例会回顾之前一周项目的执行情况，讨论未来三周会做哪些工作，以及有什么潜在的问题。 项目经理手上有两张重要的表，一张是风险清单，一张是问题清单。这两张表是每次例会必须要讨论的内容，也是通过这样一种机制，将项目计划落实到行动上。 3.5 基于项目汇报周期的风险控制 “项目汇报周期”是项目控制的一个基础过程，而风险控制是其中一个非常重要的环节。 所谓每周一次，很多时候指的是，在每周例会的时候，要把风险清单中的每一项再次讨论一遍，也许只需要几分钟（没有新的情况），但一旦有任何问题出现，项目团队就可以及时知道。 风险机制不一定能确保问题不出现，而是确保能够在最早的时间意识到问题的出现，及时采取应对措施。 项目经理手上有两张表，一张是“风险表”，一张是“问题表”，最理想的情况是多数问题都出现在“风险表”上，而“问题表”的内容很少。 3.6 收尾阶段项目经理的工作 项目收尾阶段的两个主要工作：验收和文档。 验收相关的工作是从项目开始的第一天就开始了的。一定不要等到临近验收节点的时候，再去和用户沟通细节需求和验收标准、方法。 在验收开始前一段时间，内部正式开会部署验收工作，讨论的内容应该60%是与业务相关的，也就是在验收阶段，如何同客户（验收方）进行沟通，在关键的问题上向验收方施加一些影响。 一定不要把眼睛只盯在技术细节上，项目始终是一个业务导向的过程，很多时候非技术手段可以更加有效地解决问题。 很多文档工作，是在为组织积累过程资产，所以项目经理要学会按照组织的架构流程进行工作。 3.7 关于项目文档 ➊ 项目计划不要长篇大论；➋ 项目文档是对组织过程资产的积累（形成企业知识库）。 同样一份项目计划，有人希望看懂要做什么，有人希望能核算成本，而有人希望用来汇报政绩……即使是统一的格式，但侧重点一定是不同的。 对项目经理来讲，不管你喜欢还是不喜欢，写文档是一种必须掌握的核心技能。对于一些你平时不容易见到的人（老板），文档是体现你价值的重要方式。 善于用一些图表、插图，把复杂的内容简化，让不懂技术的人了解真实情况，让高层管理者了解项目的关键要点。 3.8 项目中部门间的沟通 作为项目经理，你必须要（或者说不得不）和部门经理有良好的沟通，除非你可以实质性地掌握资源。 我们这种体系的缺点是，没有什么是一定应该的，但同样它的优点也非常明显，没有什么是一定不可能的。 3.9 项目成员的跨部门管理 在多数情况下，项目经理是非常弱势的，你很难影响团队成员的工资、晋升，那么项目成员为什么要听你的呢？ ➊ 当你找人做项目的时候，想好这个项目可以带给他们什么？有时候一个人的意愿比经验更加重要。（对于一个希望转型做咨询顾问的业务骨干，你的项目能否给他提供更多积累相关经验的机会？）➋ 要让大家信服你，包括你的技能、处事态度乃至人品（项目经理是一个非常锻炼“做人”能力的工作）。➌ 和管理层保持充分的沟通（不要通过老板去“压”别人做事，而是先在道理上站住脚，“这些是你应该做的工作”，之后再用柔性的方法去推动）。 项目经理未必是资源的管理者，但必须是业务的推动者，你的价值，需要靠自己去证明。 千万不要抱怨没有足够的资源，你必须首先证明自己的价值。 3.10 项目变更真的不可控吗？ 导致项目出问题（或失败）的一个重要原因，就是需求变更。 完全消除变更是不现实的，但至少有几点你应该力求做到：➊ 在需求阶段，尽最大可能把需求搞清楚； ➋ 在执行阶段，严格遵循变更控制流程；➌ 对于发生了的变更，相应地调整文档。 我要强调的依然是需求，问题也许发生在执行阶段，但根源是在需求过程中。你要了解的是用户为什么要做（业务动机），以及什么是可行的方案，而不仅仅是他让你做什么。 即使有销售或其他业务部门的人存在，但项目经理也必须直接参与到与客户面对面的需求过程中。 通过间接渠道拿到的需求往往是严重走样的，你也很难了解到客户的真实想法。 项目经理也许没有权利拒绝客户的某些变更要求，但你的权利是要求客户走流程，按照流程把变更提交到正确的层面去决策。 项目经理一般没有决策权，无论是谁提的变更要求，按一定的流程进行评估，有时是你对自己的一种保护。 3.11 做狼还是做羊——项目管理的规范化 项目经理做事情，是要在一定的管理框架下，推动项目的进展。争取资源、处理冲突、影响管理层与客户、灵活变通、妥协……这些都是项目经理所必需的。即使算不上狼性，但至少要强势、积极主动，甚至有的时候为了达成项目目标，可以“不择手段”。 把项目的运行约束到一个统一的架构下。其目的就是在组织级别达成项目过程的“可管理性”，也就是我们之前谈到过的“成功可以复制”。 当组织中只有一个项目在跑时，每一个细节管理层了如指掌，流程往往是多余的，项目操作可以高度灵活。但如果组织内有100个项目同时在跑，管理层不可能知道每一个项目的每一个细节。这时，管理的唯一方式就是统一管理过程（流程、控制机制、文档……），放弃100分，而追求一个可以复制的80分。 制度也许很僵化，但很多时候只能“先僵化、后优化”。僵化其实是一个标准化的过程，如果开始的时候就希望“优化”，事实上往往不是优化，而变成了“简化”，变相地回到了各自为战的混乱状态。 4.1 项目经理的一天 项目经理是业务导向的，不能过于细节化（特别是针对技术背景很强的人），一定要找对感觉，闷头做事一定会出问题的。 4.2 项目经理的沟通模式 项目经理的沟通模式 如果你安排每周五下午2～4点开项目例会，会议通知应该什么时候发？ 如果是项目例会，在项目开始的第一天，所有的会议通知就已经发出去了，应该显示在每一个人的日历中。 每周三的下午，你要再发一个“会议提醒”给每一个人。 要给不同的人分别发一个邮件，重要的是，你到底希望从他们那里得到什么信息，要清楚地写在邮件里。比如：研发部门、测试部门、财务部门分别要给你提供什么？ 要帮他们做好前期工作，也就是把问题问得尽量具体，一定不要用开放式的问题，比如：“项目目前什么情况？”这样的问题是不会有人认真回答的。你应该把问题细化到（理论上说）Yes or No, 或者A、B、 C、D几个选项中选择一个这样的程度，也就是让对方能尽可能简单地回答你的问题。要是能画表让对方填，也许是一个好的形式。 你的邮件他们不一定会看。你需要在周四给每一个人打一个电话。如果他没有回你邮件，要求他看，要求他准备数据，如果他回了，和他作一些简单的讨论，同时要求他们按时参加会议。 我所谓的“项目经理的沟通模式”，你没有强势的“职位权力”，所以一定要通过沟通技巧达到目的。 可以开会了吗？不行，你要把搜集到的数据先进行消化，找出需要讨论的问题，形成自己的初步想法。 会开完了， 你需要写会议纪要，也就是项目的周报，提交给管理层。 4.3 经验重要，还是工作热情重要 当你不能决定团队成员的绩效与业绩时，如何推动一个临时性的项目团队去做事情呢？一般来讲，调动每一个项目成员的工作热情，是项目经理的重要工作，但现实地说，这一点并不容易做到。作为一个弱势管理者，有时找到有意愿的人，比找到有经验的人更加重要。 有经验的人可以降低项目的技术风险，但往往成本较高， 而在风险大致可控的情况下，找到有足够意愿并易于管理的员工，往往可以达到很好的效果。 4.4 项目经理在沟通中的角色 对于有资深技术背景的项目经理，最容易出现的问题有两个：➊ 沟通以技术细节为主，而不是业务目标；➋ 解决具体问题为主，而不是建立良性的沟通模式。首先，你应该试图让每一个人都了解，我们的“业务”目标是什么，我们做的每一件事的真实原因是什么。 所有测试周三必须完成。”“×××领导周五要看演示，直接影响预算的审批，客户希望周四进行预演，所以我们的测试工作周三一定要完成。”两种说法的效果是不同的。一般来讲，简单下达指令，对于小的团队往往效率更高，但对于复杂团队、复杂项目，会导致更大的风险。 所谓沟通模式，指的是分工、流程、接口、模板、审批过程……这些影响部门间、团队间沟通的要素。当你意识到沟通出现问题的时候，首先要解决的是模式问题，然后才是具体的问题 也许你应该和销售部门坐下来谈一谈，哪些会议是需要研发部门直接参与的，哪些技术问题需要先和研发部门进行沟通…… 明确目标、理清模式，是项目经理在沟通中的主要工作。 重要的不仅是如何解决特定问题，而是如何在以后的项目沟通中不再出现同样的问题 4.5 项目团队的多样性 中国人喜欢简单有效的方法，但西方人更讲究流程。我们这里不再讨论二者的优劣，但对于项目经理来讲，你改变不了别人，更改变不了环境，你必须做到的就是适应这种环境。 4.6 项目中的沟通是因人而异的 坦诚地和对方进行沟通，不是推销你的想法，而是努力了解对方的想法，了解对方的性格，要确保你用的方法和提的建议是对方有可能接受的。一定不要用你认为好的东西去说服别人。 4.7 客户什么时候会满意 保证客户满意的基础是“良好的沟通”，特别是在项目出现问题的情况下。 即使问题不能很快解决，但当用户了解事情的真实情况后，多数人是会通情达理的。 所以，干系人是否满意，很多时候不是取决于问题本身是否解决，而在于你是否与其进行了充分的、良好的沟通。 4.8 老板为什么会反对你？ 项目经理的角色不是专家，也不是老板，是高度“沟通密集”的工作。 对于重要的会议、重要的人，当他进入会议室之前，他的想法、态度、观点、会说什么样的话，你应该非常清楚，也就是事先要作充分的沟通。 ➊ 最理想的情况：事先沟通好，对老板进行影响，让他按你的想法去说，告诉他你希望他怎么帮到你。➋ 你应该至少做到的情况：清楚地了解他的想法，也确保他准确地了解你的想法，可以合理地预期他在会上会说什么，以及事先想好该如何应对。 ➌ 最差的情况：就是案例中给出的这种场景这时候我能给你的唯一建议就是，承诺认真研究，确保老板的“颜面”，但不正式形成结论，过几天再单独汇报。很多开会时不好谈的问题，单独沟通的时候是可以谈的。项目经理要处理大量和人相关的问题，很多时候搞定人比搞定事情更重要，而最重要的就是“提前”沟通，“提前”协调，“提前”想应对的办法。 4.9 计划与变化 对项目团队来讲，需要的是各种不同的技能，以及与不同性格类型的人打交道。不要根据自己的喜好，排斥某些人的存在。不同类型的人，往往能带给项目不同的价值。 4.10 画大饼是不是有用 MBTI理论中另一个二分法：N（直觉型）：这种人，相信直觉、关注大局、更加在意事情发展的趋势和各种可能性。S（感觉型）：这种人，相信经验、关注细节、更加在意眼前发生的具体的事情。 重要的是，先了解对方，用不同的方式与不同的人打交道。作为弱势管理者，项目经理必须能够适应不同的环境，和不同性格类型的人打交道。重要的不是你认为什么重要，而是对方更关注什么。 4.11 项目汇报时，需要大量细节吗 如果你的老板是N型性格，没问题，你把要点说清楚，把他关心的细节谈清楚就足够了。如果你的老板是S型性格，虽然我很同情你，但你别无选择，要把每个要点，以及与之对应的细节都准备好，时刻准备他的“刨根问底”。还是这个道理，项目沟通中重要的是对对方的了解，用对方能够接受的方式，去影响对方。 4.12 适应而不是改变他人 当你试图和内向的人打交道时，你发现对方话少，不善于表达。原因是什么？内向的人（I类型）往往需要在心里把事情想清楚，才愿意和别人进行沟通，对于不是很清晰的事情，他未必会和你深入地交流。 外向的人（E类型）正相反，对他们而言，讨论有时只是进行思考的一种方式，没有充分的讨论，他们很难理清自己的思路。 当你不得不和一个内向的人打交道时，最好的方式是什么？提前把所有资料发给他，给他去电话 “张总，这件事很重要，我已经把资料发给您了，请您抽时间看一下，明天开会我希望能听一下您的意见”。然后，在第二天开会时再尝试和他进行讨论。总之，你要给对方留出思考的时间，而不要在开会时强求对方表态。最重要的不是你希望用什么模式，在项目沟通中，你一定要学会用别人所习惯的方式与每个人打交道。 4.13 动之以情还是晓之以理 思考型（T）的人，考虑问题“道理”很重要，他们关注的是正确性，而不是别人的感受。情感型（F）的人，考虑问题“人”很重要，他们关注的是别人的感受，为此甚至可以作原则性的让步。 当你试图在项目中影响别人时，尝试证明“道理”正确未必可以达到目的。而对很多人来讲，情感方面柔性的影响会更加有效。 对项目经理来讲，当你没有足够的职位权力时，一方面要证明道理是正确的，更重要的是让别人能够接受你这个“人”。所谓沟通，并不是就事论事地谈“道理”，而更多的是一种情感的 交流。好的项目经理，即使项目的工作很辛苦、待遇也不高，但大家都愿意跟着你做事，其他部门的人也都力所能及地愿意帮你（特别是那些不完全符合公司流程要求的事）。 有理未必能走遍天下，千万别委屈，因为虽然做事很重要，但做人更加重要。 4.14 让步了，问题就能解决吗？ “项目问题”与“团队问题” 区分 所谓团队问题，最常见的情况就是“情绪”问题。情绪是由某些事引起的。有时事情解决了，情绪并不会一同解决，而会对以后的事情继续产生影响。 比如在项目中，有人坚决反对你提出的某项计划，你感觉对方的反对没有实质理由，只是情绪性的“针对你”。这时你非常容易被激怒，用同样“情绪化”的方法反驳对方。于是，事情陷入了僵局。 你必须要搞清楚的问题是，对方情绪化针对你的原因是什么。这种原因很可能和你提出的计划没有关系，而是以前的某些事情引起的。 感知“团队情绪”是重要的管理技能。“先情绪、后问题”是项目沟通中的重要原则。当没有“项目问题”出现时，先解决好“团队情绪”的问题。否则当有实质性问题出现时，情况会变得非常复杂。 在团队中同样是这样，尝试解决任何实质性问题前，先要解决各种可能的情绪问题。 4.15 别人为什么要听你的？ 项目经理的 价值。 ➊ 通过良好的沟通能力，理解每个人的真实处境和动机。 首先，你必须真实地理解，别人最关心的是什么？他们部门的流程是什么？他们的绩效是如何考核的？他最希望的是什么？……很多时候，即使你给不了他什么，但“理解”本身就是一种沟通的力量。特别是针对情绪问题，“感情认同”往往会使人感觉受到尊重，产生帮助你的意愿。➋ 力所能及地提供团队成员所需要的。 如果你能提供一些他们所真实希望的，哪怕不是眼前利益，有时也会非常有价值。 比如，这个项目无法带给你更高的收入，但对你的职业转型 很有帮助，可以积累很多有价值的经验，你是否会愿意尝试呢？这一点反过来说有时更有意义：可能的情况下，从一开始就找合适的（有意愿的）人做事情。 ➌ 通过合理的渠道，向职能经理反馈项目成员的工作绩效。这一点要小心操作，最好是正式渠道，而不要让人感觉是“打小报告”。 让别人认可你这个人，比让别人认可这件事情更重要。 4.16 项目经理的人缘 你需要给人“强势但不强硬”的感觉，这种感觉来自几个层面：良好的计划、有效的沟通、积极的协调、努力的推动，有变通，但更加坚持原则。 4.17 当你的想法被否定时 事情往往有两面性，当你的想法被否定时，好的地方是什么？ 有时候，当你希望了解客户（老板）的真实想法时，对方未必对你如此坦诚。而当否定（或评价）你的某些想法时，往往更容易表露出他们的真实心态。 客户想要的其实不是提供服务，而是政绩，他们购买这个产品是要“理论上”为更多的患者提供“院外随访服务”。对客户来讲，报表与统计的功能其实是更加重要的。 当你的想法被否定时，千万不要沮丧，甚至有的时候，提出一个思路，主动让对方去批评也是一种很好的沟通策略，目的是了解对方的真实想法。 4.18 讨价还价是否有效 你作为研发项目经理，预计项目开发周期为10个月。但销售经理找到你，因为客户时间紧急，希望能在4个月内完成开发。 项目经理：我们在最后发布产品前最少需要六轮的Beta测试。客户经理：我们没有那么多时间，客户在4个月内就一定要拿到软件。项目经理：我能够保证的时间最少需要8个月。客户经理：那是根本不可能的。我可以试着推迟到5个月，但这是极限了。项目经理：也许7个月，如果我们足够幸运的话。客户经理：6个月！项目经理：6个半月！客户经理：好，那就6个半月，再长我就无权决定，只能要求高层解决了。项目经理：好吧，但我们必须要拿掉一些产品的功能。客户经理：我没问题，但一定不是主要功能。…… 和在菜市场买菜最大的区别是什么？ 区别在于：·如果是在菜市场买菜，你可以转身就走，永远不再和那个卖菜的打交道。·如果是项目沟通，当看似达成协议时，事情才刚刚开始。 一个好的沟通过程应该是什么样的？我们讲有几点是非常关键的： ➊ 营建良好的沟通气氛。➋ 认真了解对方的真实动机（需要理解的是利益，而不是立场）。➌ 试图共同探讨各种可能的选项。➍ 在能达成共识时，谨慎地承诺。➎ 在不能达成共识时，让对方知道你有“其他选择”，但一定不能让对方感觉到威胁。 尝试去探讨“真实动机”，而不是表面的“立场”，而真实动机往往 是和利益直接相关的。有时候尝试给一些试探性的建议，有助于理解对方的真实想法。 无论问题是否有办法解决，要保证良好的工作关系不受到破坏。 5.4 如何对待不可能完成的任务 项目经理不是决策者，而是执行层面的推动者，所以项目经理的专业性体现在几个层面：➊ 准确地评估。➋ 合理地规划（包括时间和成本、资源）。➌ 客观地进行风险预估。➍ 良好的沟通能力。 “专业”的项目经理应该能够保证评估与规划是准确的，正确反映项目业务需求与潜在风险，并且通过良好的沟通，让管理层了解真实情况。从是否“专业”的角度看，能做到这几点就足够了。 回到案例上，你需要确保你的成本估算是准确的，并让管理层了解你的思路，最为重要的是，将该问题列入项目的风险计划中。你要让管理层知道，如果按50万做预算，在什么时候，会出现什么情况，并且在每一个汇报周期就这个问题与管理层保持沟通。 你不是决策者，有些情况你可能不了解（今天没有钱不代表明天没有）。当老板作决策后，能做到上面这些点，应该说你就足够专业了，而一定不要承诺你自己都没有把握的事情。 5.5 从技术头脑到业务头脑 技术专家的价值是什么？是解决技术问题，需要客观、公正。项目经理的价值是什么？是实现业务目标，需要灵活和结果导向。 作为项目经理，你说的每一句话，做的每一件事，甚至每一封邮件、每一个措辞，都应该将项目向有利的方向推动，而不能基于你认为是否合理、技术上是否正确。 很多时候，你说了一句正确的话，却把事情搞砸了。 技术专家的职业安全感，建立在“我懂、我知道”上。项目经理的职业安全感，是基于“业务导向的分析能力与良好的沟通能力”上。 5.6 项目经理的价值是什么？ 一般而言，项目经理不是老板。在多数企业中，项目经理的实质权力很小，没有人直接汇报给你，决定不了人员的绩效、工资，同时，你能控制的经费也非常的有限。另一方面，项目经理也不是专家，至少你不能再把自己定位成一个专家，而应该更加关注业务与管理。 项目经理对于企业来讲是一种“推动力”，在大的企业中，很多事情如果没有人去“推”，是永远都不会动的。项目经理的价值就是帮助管理层推动事情往前走，特别是那些阻力很大的工作。 一定要记住，作为项目经理，你的价值不是别人让你干什么就去干什么，而是要帮助你的老板（或者客户）去思考、去推动，把他们的想法转变为现实。最重要的是头脑，而不仅仅是行动。 6.2 为什么选择做项目经理 总结一下，项目经理这个职位，带给个人的一些重要价值： ➊ 职业转型的重要过渡项目经理要求的是“业务导向”的思维方式，这是与技术专家的重要区别。很多人通过项目经理，完成了从“专家”到“管理者”的职业转型。这一过程中最重要的，是自我价值的重新定位，与心态的调整。➋ 锻炼真实的职场能力与生存技能项目经理的“职位权力”较弱，这就要求必须通过软性的技能去推动项目目标的达成，包括：人际影响能力、组织影响能力、团队组织能力，以及计划、沟通、处理冲突的各种技能。当你能够很好地驾驭项目经理这样一个职位时，你的职场“生存能力”就已经大幅提升了。➌ 培养强大的心理素质与良好的心态从头到尾一帆风顺的项目是很少的，而项目经理需要一种“在挫折中解决各种问题”的能力，并在这一过程中形成良好的 心理素质与承受能力。