乙方的项目经理在跟甲方对接的过程中，一定会有被压工期、降成本、加需求、难验收搞的痛不欲生的时刻，尤其在互联网行业中，甲方美其名曰”敏捷“，但都是用来当做虐我们的合理理由。每每到了这种时候，苦逼的乙方项目经理一般都会选择心里MMP，然后回去给项目成员们打一波鸡血，开始了无休止的加班。
其实在整个项目周期中，乙方项目经理是完全可以提前做好应对，转变一直处于被动的局势，而这只需要掌握几个做项目的基础逻辑，分别是：
- 项目一定是资源受限的
- 客户需求是要分类和分级的
- 销售是项目经理最可靠的战友
项目一定是资源受限的
首先我们讲第一个概念，叫做“项目一定是资源受限的”，这是项目管理领域一个比较基础的逻辑，核心就是项目制约因素的三角形。
项目制约因素三角形
项目制约因素三角形
如上的三角形中，核心的是质量，三边分别为金钱、范围、时间，或者可以理解为成本、范围、时间。“项目一定是资源受限”的这句话的意思，就是对于每一个项目来说，成本、范围、时间三要素一定不会都是充足的，如果要调整其中的任何一个因素，就一定会影响另外两个因素中的至少一个因素。而质量位于三角形的中间，三边上的任一个因素产生变化，都会对质量产生影响。
项目制约因素三角形之所以重要，是因为放之四海皆准，不但对乙方项目有效，对于甲方项目来讲也有效。对于甲方项目经理来说，资源也是受限的，承担着不亚于乙方项目经理的压力，这么想的话，心理会不会好受许多？
项目妥协优先级
正是由于资源受限，我们在项目进展过程中不得不对某一些方便进行妥协，可能是成本、范围、工期、质量的任一个因素。由于行业、项目背景、公司流程、项目经理权限等不相同，各个项目中的妥协优先级也不同。
对于甲方项目经理来说，大多数情况下，妥协的先后顺序会是：范围、成本、质量、时间，根据项目具体情况不同，成本、质量、时间的优先级会有调整。比如，集团采购的业务中，成本是死线；APP开发项目中，时间不可妥协，发版deadline就是天；一些批量标准化的产品项目中，质量红线一步都不能跨。
而对于我们很多乙方而言，项目妥协的优先级会有很大不同。很多经验不足的项目经理会选择一条极为诡异的妥协道路，当项目受阻时，第一时间想到的是额外花时间或者花钱去解决问题，调用自己手上本不富裕的时间和成本缓冲量，甚至向项目发起人或公司高层申请资源。
这对于客户、项目本身、以及项目经理自己的成长来说，都不是一个好的选择。对于客户来讲，你在一个时间非常重要的项目上对时间做了妥协，耽误了客户发版时间，造成的损失远不是一个交付延误的问题；对于项目本身来说，制定了一个错误的优先级，会对于整个项目小组后续的工作安排和进展产生一系列连锁影响；而对于项目经理而言，选择了一个最不是办法的办法来解决项目问题，对个人成长丝毫没有帮助，反而还会让上级觉得你只会伸手要资源。
那么正确的项目妥协优先级应该是什么呢？之前我们讲过，客户也是资源受限的，也会有自己的妥协优先级，而对于乙方项目来讲，最优的选择就是跟甲方爸爸同步。甲方觉得时间最重要，一定要保障及时交付，但由于资源受限的，其余三个因素您看是不是可以妥协一下，是砍几条需求呢？还是加点钱呢？还是验收交付的时候审核标准松一点呢？这个时候，我们就可以根据客户方的实际需求来进行项目方案的调整。
甲方和乙方不同的妥协优先级
项目经理的核心价值
我们本文的基层逻辑是项目一定是资源受限的，在这种情况下，项目经理的价值就体现于在资源受限的情况下，最大化的规避风险，保障项目的完成。如若项目是资源充裕的，那么谁都可以没有风险的完成任务，那这就变成了”无差别的劳动“，是资源受限改变了这种情况，让项目管理变成了”有差别的劳动“，也赋予了项目经理存在的意义。
而项目经理的价值不仅限于完成单次项目，更在于在资源受限环境下进行的创造，可能是项目流程、管理方式、工具技术等方面的，这些创造可以被复用在其他任意数量的类似项目中，也就创造出了项目经理的倍数级甚至指数级的增值。
这是《论乙方项目经理的自我修养》系列的第一篇，之后会不断更新，先行谢过大家的关注和支持！
网友评论