项目经理必须对项目有最大影响&50%的负荷是最佳负荷

这是我真实的经验总结。

在R项目刚开始的时候，有3个模块，有3.5个开发人员（包括架构师兼管理人员我自己，0.5是某人半路插入）。

图左边是任务计划情况，右边是任务实际完成情况。

计划情况

1，能力最强的徐洪彪和王林负担最难的监控和检测系统

2，最简单的和任务量最大的由聂震和贺泳完成

3，徐王有50%的利用率，剩余时间作为机动、管理时间和项目buffer，还可以去支援web系统

实际情况

1，管理层觉得设计时间可以再长一点，开发时间可以压缩。王认为设计已经很详细了，很多问题要在开发中暴露、解决。建议立即开始开发……

2，徐觉得项目很难担心影响KPI考核，消极怠工希望调换项目组，和我发生矛盾。项目初期离职，任务由王邀请来的黄接手。完成情况5%不到。黄的进度比计划中要慢100%，正好在deadline完成

3，王（我）提前完成任务，web系统中反映有几个模块比较复杂，王去支援，完成进度比计划慢100%（计划这几个模块5天，实际10天）

4，测试阶段开始以后，黄的模块bug修复一个，又爆出另一个。修复另一个，原来的又冒出来，经过检查发现黄开发的代码耦合度过高（实验某设计模式的后果），如果要修正，必须推倒重来。

黄表示原因不是这个，而是需求不清晰，测试就在这种不顺利的情况下delay了15天没有结束。王顾虑不能否定来帮忙的人，因此也没声张，但私下里重写了这个系统。并在项目delay及其趁着修复某bug时替换了原系统，之后测试顺利，5天后结束。

————————————————————————————————————————

项目延迟一个月完成，等待的肯定是批斗会，测试组等殃及的池鱼等对开发组及其不满，首要不满的肯定是技术负责人。

开发人员压力山大，觉得都是技术负责人的问题。

后，开发人员黄离职，对王颇有不满，觉得管理不善。

MB，我委屈死了，总结教训

根本原因

1：项目负责人应该在项目中对人员有最大的影响。而不是公司管理层在任何时候任何场合对开发人员有最大影响。开发人员应该明白自己的绩效和自己的直接上司有关。

2，公司管理层控制欲不能太强，不可能所有项目管理方式都按照你说的方式进行。

3，项目负责人和公司管理层沟通不足，矛盾暴露的短促而激烈

————————————————————————————————————————

一些最好的做法

1，项目管理者对项目没有最大的权利。整个项目的运作不可能以最佳状态进行。必然充满了各种人、事麻烦，或明或暗或大或小的影响着整个项目。

这时，项目管理者要多喝管理层沟通，事先声明这种问题，不管他们同意不同意，先说了再说。

2，徐离职的时候，不要贸然友情去拉赞助，要发邮件告知管理层资源不足要延迟等风险。招不到人是公司的问题，人不合适，bug多就是你的问题。而你不代表你一个人，整个team也要跟着你受累。

3，部分系统开发人员能力不足，不要贸然补充上去，要发邮件告知管理层资源不足要延迟等风险。能力不足，资源不足时公司问题。放弃任务管理、质量监控等等管理职能去弥补部分开发任务，是因小失大。

4，由于任务比较急，开发压力比较大，开发质量不高，后续问题很多，反而导致效率过低。

5，项目中个别人的问题，公事上的，要点出来，但是证据要充分，如果预计到有争议，要在后果很明显后点出来，不要不明不白帮别人含着。事后别人不一定知情，领情，反而可能怨你。

转载于:https://my.oschina.net/wanglin/blog/260824