只是现在想起来的，不保证的啊

1. 考评管理，现在部门的考评制度交给我来组织，跟人力资源部学了点皮毛。
2. 给供应商下套。和供应商交道过程中，可以用的一点技巧。
3. IT和职能的关系。也或者叫做IT和职能谁主导的问题。

最近做一个部门的考核制度，和人力资源的聊了聊，觉得很多DD也可以用到PM上来。

首先确立考核的目标，我们的考核目标是
1.压力与责任的传递
2.实现目标，执行计划
3.体现合作与分工

所以建立了考核的几个原则
1.分层执行（部门长考评组，组长考评组员），部门长平衡。
分层执行让中间层有了资源和权利，于是中间层可以实现自我管理，压力和责任又可以从中间层传递到底层。

2.关注目标与里程碑，体现整体价值。
考核是一种导向，考得越细，导向性就越强，因此考，就要考得粗。所以项目考核就考核里程碑和目标，所有的细节、activity都是为了实现目标衍生出来的。因此，关注目标、强调目标。
过程采取一种同志式、老师式的关心，帮助member解决问题，关注有什么做不到的、有什么难题，帮助他们解决，和他们站在同一战线上。不要用考核这种居高临下或者叫做立场不同者的态度来看待。赢取member的buy-in。

3.上级对下级垂直考评，体现团队合作；季度经验交流，实现共同进步。
360度的考评非常不利于团队合作，所以都是上级对下级的垂直交流，加上前面的分级管理，矛盾都是内部解决，对外就是一个团队。
季度进行一次经验共享、教训交流，大家都说自己做得好的和不好的，但一定不要对此考评，否则就会引导大家把不好的地方全部隐藏起来。鼓励交流和共同进步。

这个让我联想到PM在人力资源上可以做的一些事情
1）对项目member实行目标管理。一方面要放权，另一方面过程的监控改为过程关心，改变自己的立场，不是考核或者监督，而是帮助他们发现问题。这就是人力资源中说的激发他们的“自我管理”，这个时候他们感受到被重视，不仅会管理好自己，还会反过来帮助PM发现PM的不足。

2）过程中团队气氛的建立很重要，一种真正的交流、共享气氛是非常重要的，PM要学会做 team building，建立一种团队气氛。学会当领导。

3）如果一个团队比较庞大的时候，比如，有技术经理之类的角色的时候，分层管理是很重要的，PM要忍住掌握权利的感觉，学习“无为而治”，把权利分割和下放。如果真的要体现自己的权利，可以采用掌握资源的方式，让他们做什么资源的审批都从自己手上过，就掌握住了关键环节，千万不要用不停的换人或者安插人的方式来打击员工的积极性。

4）和大家一起分享，总结，引导别人的思考的同时也启发自己的思考。
听说微软的考核，分成4个等级，业绩好、说得明白的是A，业绩不好、说得明白的是B，业绩好、说不明白的是C，业绩不好也说不明白的是D。有意思的是B和 C的划分，据说微软认为说得明白就是这个人能知道问题在哪里就有很大的改进空间，于是可以得B，而说不明白的这个，可能就是蒙的，也可能是外界环境好，总之似乎他没法复制自己的成功，于是就是个C。
不时的交流就是启发自己和别人的思考，知道为什么，这样成功才是可控和可以复制的，否则就是一次性的行为了。

说到底，激发员工的“自我管理”，他们爱上了自己的工作也就爱上你了，你既获得了团队的buy-in，还能游刃有余呢。

居然开头的空格没用，看上去就不够清楚了，sigh

这个话题好像有点大了，我的理解也不过是新手冰山一角的总结，非常欢迎大家共同讨论。如果我们想成为优秀的PM，我想第一步应该是知道需要学习什么吧。

首先明确一下，PM不包括做系统的、coding、数据库、网络等等的，如果你做这些，只是说明你身兼数职了，这里说的就是PM本身的能力。

1、沟通能力。好像所有的人都会赞同沟通能力最重要，可是什么是沟通能力的内涵呢？我觉得是：清楚的表达、传递，并引导人们的表现朝你的期望发展。怎么才能沟通好呢？可以简单的分为：
A) 领导沟通
a 管理你的领导
PMBOK说PM有权利调配资源，不够就要去要。现实中，基本上我们的项目最大的限制除了钱就是资源，资源很多情况都被领导掌握，PM哪有随便调资源的权利？但是领导们都常常觉得，够了啊，总之你给我搞定。

PM要学会说不，制定计划的时候就要否定老大们不切实际的想法，但是绝对不是上去就狂喊，而是你的说法上要有技巧，说目标-步骤-难点-计划-资源，领导们会容易接受一些。就是说：我们的目标是，要达到什么效果，还有范围是什么——步骤是1、2、3、4，先做什么再做什么——难点是什么，哪个地方容易出错，不管是技术难点还是管理难点，PM都要考虑在内，比如技术上大家都没有做过，就是难点，比如管理上没有某个规则等等——因为有了这些难点和目标，我们觉得时间计划是什么（保留适当的储备）——因为要实现这个计划，我们需要什么资源。

领导们听到最后，嗯，很有道理，他就要权衡了，给你资源么，不给？不给重新讨价还价，目标要不要改，时间要不要延长，范围要不要缩小？给？给当然好了，PM要到自己的东西了。

无论是制定目标还是过程中，你需要资源的时候都可以尝试用这种方法。
虽然很多时候资源是被领导掌握，但是身为PM要记着，领导也是我们的资源，你用他的思维方式，引导他去思考。你要学会管理你的领导。

b 向领导暴露问题
就算这些资源都要到手了，我们就是承诺项目没问题吗？当然不是啦。领导们还是聪明而有经验的，他们都知道项目一定会有问题，他们不期望不出问题（他们基本都认为，不出问题的项目一定是有虚假信息，项目不可能不出问题），他们只是希望可控（问题可以被解决、知道对现有质量、进度、资源、budget的影响）。

所以PM千万不要心虚说，因为前面我要了这个那个，后面我就不可以出问题了，有问题就隐瞒。恰恰相反，PM就是要在过程中暴露问题。你说出来了，领导就是再不开心也知道解决问题最重要，所以他就会帮你解决问题，你就多了一个powerful的资源了。

暴露问题是要说：问题是什么——为什么会出——如果不解决，对目标、范围、进度、质量、客户满意度、预算影响是什么——你觉得解决方案是什么？（或者好几个）-各自对上面6个维度影响是什么，各自都有什么局限和好处？——领导决策。

如果你也没解决方案（这样不算好的PM，但是没辙的时候也是会有的），你就做前面两步好了。问老板，怎么办啊？

但是无论是谁给的解决方案，也无论这个方案是什么，你最后都要向你的领导（当然包括你的所有stakeholder）说清楚，这样一个变更对目标、范围、进度、质量、客户满意度、预算影响是什么。

让你的领导感觉，虽然会出问题，但是你至少让问题的影响可控了。他在下一个问题出来前可以睡觉了。

c 什么时候汇报？
这个问题在2007年7月22日想起来了，所以补充一下。呵呵。好像有点晚。

虽然我认为很少有PM会犯这个错误，但是今天突然想起来了，觉得还是说一说比较好。周报是干嘛的？其实很多时候虽然是一个formal written的DD，但是最大的作用我认为是保持所有人对项目的关注度。让一些更大的BOSS、边缘的team member、边缘的stakeholders保持对项目的关注度；让 core team有成就感：我们做了那么多，还报告领导了。我认为，周报或者叫周期性报告不是解决问题的，只是陈述性、总结性的。

一旦有了问题要马上汇报！当然还要考虑上级领导的风格（他是事无巨细都关注型还是抓大放小型）和PM的权利（什么样的问题有决策权）。但是一旦有了 PM搞不定的问题是要马上汇报。你想周期性报告一周一次？一月一次？那时候黄花菜都凉了。所以马上汇报！不要怕你的领导。耽误了时间更可怕。

总结一下，有了PM搞不定的问题要马上汇报！周报、周会做什么用的？保持所有人（包括非core team）的关注度，这个会不是解决问题的，是讲讲总结（上一个周期干什么了）讲讲计划（下一个周期每个人要做什么）讲讲问题（上个周期出什么问题了，我们怎么解决的）和讲讲风险（下一个周期可能出什么问题，要注意什么）的，总之不是解决问题的。出了问题要随时解决、即时解决。

怎么写了那么长的？下面的先给个提纲，后面再慢慢写。

B) 同级、下级、供应商
C) 解决冲突

2、全局的掌控
A）理解目标，宣导给team member
B）解决方案的全面理解
C）控制变更

他们需要被夸奖。听说教育小孩的经典之一是“好孩子是夸出来”，你的member是一样的，好member是被夸出来的。只是他们不像小孩子那样可以说谎的夸，你需要认真的动脑筋想怎么夸才不会显得言不由衷。夸他们除了真的做得好之外，就是你需要他们做得更好的时候了。做得更好其实并不表示他们现在做得很好，恰恰相反，可能他们做得非常糟糕，根本达不到你的要求。

但是发火是于事无补的，甚至可能激起team member的反感，都这么大人了，谁都有个面子问题的，所以我们只是要达到目标，发火不过是手段，不到必要的时候不需要发火，一来让自己心情不好，二来偶尔发火才是杀手锏，发火多了就不值钱了，你已经没有太多可让人畏惧的东西了。

夸他们是要有技巧的，你可以说：做得好啊，我们已经实现了什么什么（他的确有做的东西）——现在该我们考虑下一步的时候了，下一步我觉得还需要做什么什么——这些由你来做？因为前面做得不错。

看上去我们在夸他们，实际上，我们在给他们下套，套住他们，让他们高高兴兴的去实现我们的目的。你不需要说太多的“但是”，这会让你听上去有点虚伪，但是你可以把你的目的拆成两个来说，他实现了第一步，那么第二步不是就该接着做了吗？

b 翻译能力
PM是什么呢？好的翻译官。客户说的都是他们的业务语言，供应商有的时候说的是技术的语言，PM是什么？多语言外交官。PM有责任将不同团队之间的语言翻译成大家都能正确理解、没有歧义的语言。

只有语言统一了，大家才有交流的基础，否则是鸡同鸭讲，彼此谁也不知道对方说什么。

还是COPY之前已经用到的例子，丰田开发凌志的案例：

日本鬼子做凌志的时候，目标就是改变大家对丰田中档车的观念，要做一款高档车，他做的需求调研就是为客户为什么觉得奔驰、宝马高档，得到的答案就是
（1） 身份地位与尊容的形象
（2）高品质
（3）转售的价值
（4）性能（例如，操控、乘坐、马力）
（5）安全性
最后他根据客户这些感性的词语，翻译出了凌志的目标
（1）最高时速：250 km/h（比奔驰多28，比宝马多30）
（2）耗油量：每加仑行驶23.5英里以上（比奔驰多 4.5，比宝马多4.7）
（3）噪音情形：100km/h 时速为58分贝，200km/h为78分贝（奔驰为 61/76,宝马为63/78）
（4）空气动力……
（5）汽车重量……

项目经理就有必要将交流的内容明确化、易于沟通，常用的就是量化和名词解释，重点说名词解释。要进入一个行业就要先了解这个行业的术语。所以供应商、客户之间说不清楚多半都是名词不了解，举个例子，我们说备份好像很easy，觉得根本没有可解释的地方，可是客户根本听都没有听过。

我们首先要察觉困惑的情绪，当一个人脸上呈现出茫然的时候，我们就可以问了？有什么不明白的么？通常他们都可以清楚的说出没听懂的地方。可以看看当中有没有专有名词，有的话，就解释一下，什么意思，最好打个比方（尤其是要客户明白IT名词的时候）——作用是什么——它的变化带来的影响是什么——我们现在讨论它是为什么——你觉得呢？

举个例子备份，备份就是把每天的数据做一个COPY保存在另外的地方，好比你把重要文件COPY在U盘上，万一你硬盘坏了，可以从U盘上COPY回来，保证文件没有丢——就是保证万一服务器坏了，我们做的历史记录都在——备份保存的时间决定你可以恢复到什么时候的数据，比如，我每天备份，备份都保留15 天，如果现在是2月16日，我可以恢复到2月1日、2月2日……2月15日，任何一天的状态，但是想恢复到1月30日就不行。所以备份保存的时间就是可以被追溯的时间。——我们现在就是在讨论这个系统的数据备份应该保留多长时间——你觉得你们希望可以被追溯多少时间前的数据状态？

此外，关于项目干系人方面，有几点建议：
1、项目的发起人是项目非常重要的干系人，他的需求是非常重要的。
2、如果项目发起人是老总，就可以扯虎皮做大旗了，把各部门的头都圈进项目组，一旦他们进了项目组，需求就是他负责了，管理人员嘛，具体工作可以由底下人做，但必须他来拍板。

3、对于企业IT 部门，业务需求是业务部门提出的，一定要把握住自己所处的位置，IT部门很大程度上相当于内部的IT 监理。当然，如果需要对业务进行了解，是另外一方面的情况了。

个人建议，供讨论。

冲突在项目中定然是无处不在的。甲方和乙方虽然说是一家人，业务部门和IT部门是利益共同体，可是老婆会向着娘家，老公会向着婆家也是不争的事实，所以大家因为某些利益一定会摩擦。

a）老大观点不同，却要你传话

如果是你的老大告诉你说你要这么这么做，然后你发现乙方的老大或者业务部门的老大其实基本不同意怎么办？老大们之间常常有冲突，可是总是把我们这种小卒推到前面，我们怎么做才不会破坏自己和其他方的关系，但是又完成老大交代的任务？

其实也很简单，你直接告诉其他的头们你的老大要求你这样做，问他们怎么办？一般说来，其他的头们都会直接找你的老大沟通，你就免受夹板气了。万一他没有找你的老大，你就乖乖传话，多的事情最好不要做。

这样说毕竟有点无奈，可是本来很多事情都是我们不能左右的。

b）平级间的冲突

我过去的经验是，这种冲突有很大的概率是沟通不明。人好像都有坏习惯，明明担心某件事，但是不明说，就是绕着说，说来说去，大家就为了绕着的那个东西吵架了，目的是一点没摸着边。所以摊开问是个不错的办法，你就问他，你到底担心什么。一般说来，这样能问出80%的真实目的，当然你事先要卸载他的心理包袱，比如说，你们总部不给资源，我们也能理解，我们的项目小，你们总部不重视也是情理中的，但是不知道问题在哪里我们很难解决不是？态度要诚恳友好。

沟通中很多时候好像方式比内容重要，本来你想关心人家，结果用一种很凶的口气说，人家也不会买账的。所以表述的语气、表情一定要控制好。

问明白人家的担心顾虑是什么，常常解决方案也找到不少了。再不行还可以上报，让你的老大帮你解决。可是你知道根结所在，才能让你的上级帮助你解决吧，不知道根结就走错了方向只能越走越远了。

所以，甲方还要多用些心思，抱着合作的态度，而不是指手画脚的指挥。这样自己的风险才能小些。

见到很多这样的项目，由于乙方的沟通不顾，于是甲方开始不信任乙方，对一些自己不清楚的内容强制指挥，乙方不得不听，其实效果也不是很好，这样做的结果是使乙方意识到自己沟通不够而加强沟通方式，这是好的一面。可如果乙方没有意识到这点，在甲方的指挥下工作，风险是非常大的。去年有个项目就是后者，结果费了很大精力才扳过来