1 我眼中的PM

1.1 人云“一个管理，半个专家”，我说“一个管理，两个专家”

如今，我发现我们不得不面对这样一个现实——角色兼职。我习惯上把项目分为三类：性命攸关的项目（涉及到人身安全的项目，如铁路项目）；使命攸关的项目（具有明确时间节点的企业级信息化项目）；普通项目（中小软件项目）。我相信大多数PM都同我一样，奋战于使命级和普通级项目。虽然，从软件工程角度来讲，我们需要外科手术式的团队，人人各司其职，以专注于不同的方面。但事实是，我们的大多数雇主不会雇佣他们眼中“多余”的人员。这时，就需要由PM进行兼任。从广义上讲，PM除了管理以外，常常会兼任两种角色——设计者和开发者。很多时候，我们不得不面对这样一种尴尬的局面，就是我们花费大量的时间在设计和编码上，而不是项目管理。我也时常在反思，作为PM，我的知识体系应该是何种结构呢？

我想大多数的开发者都认同，PM需要具备一定的技术实力，否则就会发生外行管理内行的悲剧。从我的经历来看，在技术领域，有两方面知识对PM来说最为重要。其一，软件设计领域知识（需求分析、架构设计、数据库设计、UI设计）；其二，软件实现领域知识（开发语言、测试调试、IDE的使用）。之所以，我认为这两点很重要，是因为PM需要承担责任。很多时候，需要我们在没有技术总监支持的情况下来完成项目。

1.2 不是所有人都适合PM

我认为PM需要具有以下天生的品格：

真诚 真诚自不用说，这是每一个管理者都应该具备的，最基本的不能被后天习得的能力。

骨气 血气之怒不可有，义理之怒不可无。PM必须有勇气对不合理的要求说“不”，必须敢于维护团队的利益。

坚毅 PM必须能抗压力，即使是项目这条大船正在沉没，PM也应该以超乎常人的勇气与决心来发号施令。

1.3 虽然理论很重要但更重要的是经验

书上的东西是死的，如何有效地将理论知识转化为生产力需要的是长期的经验积累。理论必须联系实际，管理没有攻略。

1.4 管好项目首先要管好自身

我不相信一个连自己都管理不好的人，能够管理好一个团队。一个人的为人处世透露了这个人的性格特点。我觉得一个对自己都不负责任的人，如何能负责一个团队呢？一个经常迟到的人，项目进度可以保证吗；而一个生活邋遢的人，可以保证项目质量吗？

1.5 找寻平衡而不是最优

范围、时间、成本、质量，我们受制于这4个维度。现实中，我们必须认识到，我们的项目成败决定于这四个维度的平衡。所以，更提倡的是，找到这四个维度的平衡点，而不是力求把这四的方面都做到最好，那是不现实的。

1.6 “四拍主义”不可留

“四拍主义”是最另我反感的做法，但的确在身边屡见不鲜。“一拍脑门干了；二拍胸脯没问题；三拍大腿出事了；四拍屁股走人了。”身边见过的听过的这样的例子不少。面试官的能力不足以及背景调查的不彻底，助长了这些不负责任者的气焰。把一个项目做臭了，丢下个烂摊子就走， 不断地从一个项目换到另一个项目，换了几次简历上很漂亮，工资上涨也很快，但管理能力名不副实，很难理解这样的人却有很多企业抢着要。

2 Open Mind

2.1 海纳百川，取长补短

不管是对过程管理或者是对人管理，不同阵营之间的争吵越来越激烈了。不论你去参加何种认证考试，或已经处在某个阵营中，常常都会被像洗脑一样被灌输了某种模式或理论体系比其他的更好。但其实真的没有必要，把项目管理风格划分的如此对立。如同软件工程的核心目的是降低软件开发的复杂度，我们不断探寻项目管理模式为的也是最大可能地促成项目成功。所以，我认为任何好的，被广为认可的，能够促成项目成功的实践，在公司允许并且风险在可控范围内的都应该被实践和推广。比如，我在项目中，虽然是对过程进行管理，但我仍然在不断地实践敏捷开发中的“持续交付”思想，我也得益于此。

2.2 学会思考

思考大有玄机，人不是天生就会思考，我们需要规避某些陷阱。

偏见 人是爱面子的动物，人容易被感情左右。当我们听到反对的声音时，多数人会本能地进行抵抗，而不是接受意见并进行深入思考。诸如此类的偏见还有很多，未经训练或者缺乏相关知识的人，很难把持中立地去看待问题。

片面地思考 乐观的人只看到问题好的方面而容易忽略风险，悲观的人则只看到问题的风险，忽略潜在的价值。

从众心理 人是群居动物，不擅长独立思考，人类需要社会，需要朋友。在思考时，人更倾向于选择大众说接受的，而不是思考者内心所真正认同的观点。这就是人的从众心理，但很多时候真理只掌握在少数人手里。

2.3 心理学其实很有用

几年前，我看到我熟悉的某位前辈在看心理学书籍。当时我很困惑，我不理解他的业余时间为什么要花费在和IT毫不相关的书籍上。但当我在某些思维或者项目管理书籍上，发现了心理学的影子，我才感觉到——心理学其实很有用。举一个例子，如下：

当我进入某个项目后，我发现了一个已经蔓延的低级缺陷，这出现了一个奇怪的现象，就是同事们有不少都发现了这个问题，并且认为有更好的写法，但是却没有人反应给设计组，而原因惊人的一致——“这问题太菜了，肯定别人有去反应的！”在心理学里，这就是“旁观者效应”。关注一些知名的心理学实验，有助于我们正确地审视团队，发现某些问题背后的本质。

2.4 前期准备为自己

项目前期，我们面临着一个巨大的压力，雇主在催促我们尽快开始编码。如果，我们不能劝说雇主，并且学会向不合理的要求说不，那么很可能为后期的项目失败埋下伏笔。软件项目，反应着这样一个本质——工作项之间有强硬的逻辑存在，而且，越是项目早期解决缺陷的成本越低，我们左右项目的方向也越容易。因此，如果项目的前期准备不够充分，便草草开始编码，很可能会在项目的中后期暴露出大量缺陷，进度、士气、质量、成本都将受到损害。所以，为了团队考虑也为我们自己，请做好前期准备后再开始编码。

2.5 质量很重要

质量这一关键核心维度，往往成为我们追赶进度的牺牲品。在范围、时间、成本都能检视和追溯的时候，会有人去牺牲那个最难以检视的质量。从开发者角度，我们不断地强调代码质量，但是到头来，那些真正地敢于面对不合理设计说“不”的，努力维系代码质量的程序员，却得不到重视。进度固然重要，但很多没有技术基础的PM，特别是不了解程序员文化的PM，正在牺牲质量来掩饰他们对项目进度管理的无能。

对质量的第一层认识——我们可以交付低等级的软件，但不能交付低质量的软件。

对质量的第二层认识——质量不是无止境的，满足需求即可。

对质量的第三层认识——低质量会造成优秀的开发者情绪低落。（如果让优秀程序员长期面对糟糕的代码，开发低于他自身质量标准的软件，会让那些真正热爱编程的人情绪低落，甚至质疑团队的技术实力并选择离职。）

2.6 落地的才是成果

忘记你的甘特图吧，在UAT没有通过之前，你的努力仅仅是一堆调试通过的代码。别被图表上漂亮的进度所欺骗，因为很多时候，进入UAT才会发现潜在的缺陷（尤其是前期准备不足的时候）。我们如果对账面上的进度过分地乐观，往往会造成对风险管理上的疏忽。所以，保持一颗理性的心，UAT通过才算落地。

2.7 代码审查好过测试

不要过分地依赖测试，好的代码审查和快速反馈机制能够在早期缺陷还没有蔓延的时候就将其修复，而且根据我了解到的一些数字，代码审查发现的缺陷数量要远远高于测试。

3 工具

PM需要掌握常用工具的使用：

开发工具 如VS，Blend，代码生成器等。

管理工具 如SVN，TFS，Project等。

文档工具 如Visio，Rose，Excel等。

部署和发布工具 如IIS，Sql Server，Win Server等。

4 团队建设

4.1 尊重你的同僚

人人生而平等。当读者读到这段文字，或许会认为自己已经足够足够尊重我们的同僚，但事实真的如此吗？很多时候，当我们自认为自己身经百战，能力高人一筹时，我们真的能够秉承原则吗。下面列举的话语很极端，多少有些夸张，但我建议，同时也是真切地希望，PM们不要做下面的事情，因为那样真的会伤害他人。

“这代码写的什么呀！” 不要去否定他人的劳动成果，如果开发者的代码无法达标，请说：“你的代码存在缺陷，我有更好的建议。”
“设计我说的算，开发你闭嘴！” 不要遇到反对的声音就一概否定，开发者才是最前线的士兵，不论我们有多大自信，我们也应该倾听反对的建议，并进行公允地评估。

“这东西你要用一天写完？” 不要当众让开发者难堪，情绪低落只会让开发者向项目引入更多的缺陷。如果开发者没有完成进度，我们应该找到原因，解决问题，而不是一味地指责。

“你能力不行！” 对开发者自身价值的完全否定，此话一出，等着应对离职吧。

4.2 了解你的同僚

就像销售把客户分群一样，我们也应该学会将干系人分群。在这里我不想探讨如何进行干系人管理，这个话题太大了，我想说的是如何管理团队。归根结底，PM是在对人进行管理。我们需要了解我们的同僚，不仅是其技术上的能力，也包括他们的性格和心理需求。人和人不同，有人图钱，有人为了学技术，有人工作求稳，有人追求认同感等等。我们的同僚有不同的心理需求，在我们使用管理方法时需要结合实际情况加以调整，而不是一味地按照教科书照本宣科。很多时候，技术培训，授权比加薪更能稳定人心。

4.3 永远追求多赢

“真正的团队需要同舟共济。”

项目的成功不能以牺牲开发人员利益为代价。我们购买书籍，参加培训，考取认证，出席峰会，花费大量时间来完善和实践项目管理方法，为的是能够在不损害团队成员的利益前提下，控制成本，确保项目成功。很多时候，PM的绩效工资与利益挂钩，但我们不该为了个人利益而牺牲质量或者团队成员的利益。我们不站在公司、团队、客户任何一方，而是站在三者的中心，以平衡矛盾。秉承职业道德，并不容易，会有同行的嘲讽，领导的评评或者客户的谩骂，但真诚和职业道德是我们立足于业界的根本，仅仅这一个原因就足够了。

5 效率

5.1 高效会议

“当一艘大船即将沉没时，需要的是发号施令的船长，而不是坐下来开会。”

现实中，我们往往把大把的时间都浪费在了低效的会议上。很多公司都不会开会，也丝毫不会发现低效会议背后的成本问题。我一直在实践高效会议的方法，以下是个人的经验分享：

常开会，开小会 这里所说的小会，其实更准确的说法应该是“快速简报”。定期进行快速简报，做到问题早发现，小的问题早期处理，大的问题集中开会讨论，可以减少“重型”会议的频率，并缩减缺陷修复周期和成本。

六顶思考帽 在会议上，使用“六顶思考帽”方法，可以使会议更为高效，结论更为可靠，利于解决实质问题。（我的博文“六顶思考帽”给我的启示”）

抓住本质 不用花费精力过分地修饰会议上使用的文档，尤其是技术会议，我们需要的是准确的图和表，而不是动画。文档主次清晰，结构分明，字体大小合适即可。

5.2 高质量文档

文档体积不等同质量 本着“没功劳也有苦劳”的想法，大量低质量文档全无重点，废话太多。

格式不可少但内容更重要 满足范本要求只是最基本的，内容才是文档的核心。

不能超越文档的范围 只写该文档包含的内容，不写多余的。

应该主次分明，而非流水账 把每一个小事情都汇抱的很负责，只会挑战读者的耐心。

图表更有力 多用图和表。

5.3 快速反馈

复缺陷的成本随着“从引入缺陷到检测到缺陷这间的时间”变长而急剧增加。（就像放射性物质在食物链中的沉积一样）

类似的，在项目管理中我们需要建立数个快速反馈环，诸如：

开发团队与测试团队之间 实现缺陷的跟踪、指派、追溯，提高缺陷修复率，防止蔓延。

测试（部署）团队与关键用户之间 快速搜集用户反馈，对用户进行指导，并及时通知用户发布新版本的时间，更新内容。

PM与关键用户之间 及时收集和处理变更，及时通知用户变更的处理情况，让其了解项目的进展（主要是让其知道我们在做事，从而放心）。

PM与开发团队之间 了解团队现在，倾听内部的声音，及时沟通并收集意见，预防人员流失。

6 沟通

6.1 入职座谈不可少，离职座谈更重要

入职一周后与离职前需要进行座谈。

每个人到达新环境都多少会有些不适应，加之程序员喜欢独自闷头做事，新人入职后需要额外的关注。需要在一周左右，与新人谈心，了解其是否遇到问题，并征求其对项目团队建议。这样既可以，让新人尽快融入集体，减少团队震荡的时间，又可以进行过程改进以提高功效。

离职谈话比入职谈话更重要。人员非正常流失，一定有其原因，必须通过离职谈话找寻问题的症结，好对症下药，进行持续的过程改进。此外，对销售来说的“每一个人都是潜在的客户”同样也适用于我们，也许下个项目他就是你的项目干系人，IT圈子本就不大，我们需要朋友。

6.2 驾驭“牛仔”

“牛仔”特指那些在团队中，特立独行的硬手，他们精通领域技术，有出众的能力和工作热情，而且多少会有些难以融入集体。虽然，牛仔们与PM的战争时常爆发（主要是技术上争论），但我认为他们是真正的团队之宝。因为他们是真正的资深专家，而且往往具有更高的质量标准，他们常常发现那些别人容易忽视的质量缺陷，或者有更好的写法，能够提出中肯的建议，能在技术问题上提供比较可行的解决方案。但是，性格使然，大多数“牛仔”都多少会有这样一种想法，别人的技术不如我，我说的才是正确的，我不能降低自己的标准。这种心理导致了他们难以融入团队，并时常引发争论。以下分享我与“牛仔”接触的方法：

认同“牛仔”的能力，尊重他们的建议 大多数牛仔追求的是团队的认同感，而不是薪水，认可他们就是对他们最大的尊重。

让其独立完成某些复杂的核心功能 他们喜欢挑战复杂的任务，而那些C\V（复制、黏贴）的工作让他们感觉自己在浪费生命。

量才使用，酌情授权 他们在某些领域往往能达到一定的程度，根据其能力可以授权其负责某些代码质量或设计方面的工作，这样不仅能让他们感觉自己的能力被团队认可，同样也能利用他们的“高质量标准”心理来提高代码质量（注意凡事有度，让“牛仔”做代码审查需要事先与其沟通，因为他们可能不会顾及别人的面子，而采取非常直接的沟通方式，比如激怒那些年纪大的开发者，所以相对于“代码审查”他们更适合“技术培训”以及“设计评审”。）

6.3 如何面试

首先，我们只负责技术面试不要和应聘者沟通工资问题；其次，以下步骤，如果有未通过的，就没有下一步了。

第一步：破冰 消除面试者的紧张感，一般是让面试者自我介绍下。

第二步：试探简历是否造假 方法一，人对数字的记忆比较模糊，如果简历造假，那应聘者就会对简历上虚构的数字比较模糊；方法二，对简历上的项目经验有针对性地问询，看是否符合行业惯例。

第三步：能力评估 结合笔试内容和岗位要求考核应聘者是否有能力胜任当前岗位，一般是纯技术性的探讨。

第四步：答疑 介绍岗位或工作描述并回答应聘者问题 。

6.4 排除“资源”是最坏的做法

当我们的开发人员无法胜任他的角色时，我更倾向于安排培训，而不是招募新人。说实话，看不懂现在的行情。大量的开发者涌入社会，他们对新技术夸夸其谈，但确不明白自己写的代码在干些什么。我也负责面试，在年轻的程序员中，基础好的已经越来越少了。所以，不要寄希望于能通过裁员并从新招聘来解决资源技术能力不足的问题。看过《人月神话》的同学们，都应该知道——往一个进度落后的项目里注入资源，只会使进度更加落后。所以，当发现“资源”能力不足，请优先考虑培训，培训老员工的成本和周期要比新员工低的多，若培训不合格再考虑进行招募。