弱矩阵下的项目经理困难处境分析

背负收款压力

首先有由于公司对于资金的需求，会背负收款的压力，这时候乙方项目经理就与甲方项目处于对等的地位。

如果收款时间点是甲方也关心的时间点，例如甲方KPI，或者甲方领导KPI，则平衡很多。

失去谈判筹码

作为谈判桌上乙方的代表，项目经理需要筹码。一般筹码包括对任务的紧急安排、新需求、变更的承接、临时性的响应、技术支持等。

这些筹码是通过在项目执行过程中，通过范围管理、任务管理、人员管理逐步积攒出来的。

如何积累筹码

1、在与客户协商好整体计划后，客户突然要求调整计划，就需要求乙方项目经理【对任务的紧急安排】，筹码+1。

2、在需求冻结之后，客户会经常发现遗漏了一些重要的需求，就有需要求乙方非正式添加【新需求】，筹码+1。

3、在功能按照要求上线发布后，客户觉得想法发生了变化，但是之前需求、设计白纸黑子都写了，乙方也按照规格实现了，那么客户就会求着乙方做【变更修改】，筹码+1。

4、在正常的进度下，客户突然又一个临时的事情，足以打乱当前研发计划，导致乙方产生交付风险，乙方按道说可以拒绝，最少可以拖延，那么客户就会求着乙方做【临时性的响应工作】，筹码+1。

5、在新项目研发中，遇到了一个技术难题，责任不在乙方，已经严重影响到了甲方，例如环境问题，那么客户就会求着乙方做【技术支持】，筹码+1。

有了以上筹码后，谈判就会变得容易一些，收款也会准时很多。

那么如何破坏（放弃）以上筹码呢？

1、废掉对任务的紧急安排的办法：甲方直接联系乙方开发人员，调整项目进度，并且不予项目经理沟通，（同时）整体计划未通过双方共同认可，（同时）双反未约定变更任务优先级的办法

2、废掉新需求的办法：项目整体需求作为需求冻结，（同时）未与甲方做新需求变更的规则约定（包括审批流程和补款方式），（同时）对于甲方的新需求修改行为未指明是新需求。

3、废掉变更修改的办法：与甲方的需求从不定稿，（同时）对于甲方的需求修改行为不指出是需求变更，（同时）未与甲方做需求变更的规则约定

4、废掉临时性的响应工作的办法：通过公司高管直接安排临时工作，或者直接抽调走开发人员

5、废掉技术支持筹码的办法： 甲方直接联系乙方技术人员解决问题，并且不予项目挂钩。

失去对团队掌控力

在弱矩阵的管理模式下，对研发人员的调用是通过研发组长完整的，往往对于人在项目的投入和离开时没有直接控制权力的。这样导致人力投入计划（如有）无法贯彻执行，经常会出现人员被临时调走的场景，导致项目进度的延期，甚至是已经承诺客户的关键时间点延期。

客户很容易通过其他渠道（例如直接联系高层、开发主管、开发人员）等方式，绕开项目经理，解决临时任务、新需求、变更以及技术问题，导致项目谈判筹码流失。

项目中天生存在的劣势

作为项目，天生存在一些劣势，这些劣势更加剧了在项目谈判时的困难程度。包括，短时间内质量难以控制、客户业务不能够充分理解、客户需求源无法把控、业务导向低于技术导向、技术人员对业务理解度低等。

过度依赖研发流程

在弱矩阵的管理模式下，对类似质量、需求调用、整体设计等工作，都高度依赖组织自身的成熟度，如果缺乏流程化管理、标准化管理，那么bug率基本上就是一个常数。通过运动的方式很难改变。

持续走高的bug率、整体需求的缺乏控制力、以及多系统之间关联设计、这些常态都进一步对项目交付产生了负面影响，使最终的验收谈判处于不对等地位，要么乙方强势逼人，以不合格的产品进行验收，要么甲方拒不让步，必须达标后才可以交付，直接导致漫长的收尾流程。

综上

弱矩阵的项目经理，需要的是一个具有强大研发能力的团队，也需要一个懂得项目需求范围边界、与项目经理配合的任务优先级安排、拒绝客户随意调用，并且提供稳定质量、按时交付的团队。