IT项目管理实践经验分享

dinner1007

呵呵，后面的乱了一点
不过ＬＺ写的很好

HackerXP

跟自己现在做的很类似，看了很有收获，谢了。

ccjjgg79310

说说人力资源的考核

最近做一个部门的考核制度，和人力资源的聊了聊，觉得很多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，还能游刃有余呢。

oraclesea

lijinshansir

没人性，最好不要得罪搞技术的，他万一在里面做了手脚，你们就完了！！！

ccjjgg79310

楼上的，我得罪你了么？
为什么渗得慌？……

lawer-bbc

再次支持！

ccjjgg79310

项目经理最应该具备的能力是什么？

居然开头的空格没用，看上去就不够清楚了，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）控制变更

lawer-bbc

对上沟通总结得不错！

zy270517

好,我是新手学习一下