FP项目作为甲乙双方的一种商业合作模式被诸多企业采用。作为弱矩阵管理（结果导向，买方弱管控）的商业模式，对于卖方（接包方）的管理能力要求远高于TM模式（强矩阵管理，买方强管控，卖方以供人为主）。就FP模式的项目如何基于数字化进行运营，上个月发过一个基础篇，这里讲到如何管理报价，进度，风险和绩效，可以参考下面的链接。
如何基于数字化运营进行FP项目管理
结合最近参加的一些FP项目管理回溯会以及网上的热帖，想针对一些FP项目的坑点（难点）再分享下心得体会，供各位管理者参考。
1 需求变更管理
何为FP？fix price，固定金额，为什么可以固定金额，因为固定了合作的边界-需求范围。理论上，固定金额项目，需求不可以变更。实际上，现实很残酷，不仅需求会经常变更，甲方粑粑还经常赖账不给钱，上线日期不变，造成很多项目trouble甚至流产。
老哈的经验主要在软件领域，软件研发项目的需求变更源于软件项目的复杂性，模糊性，不确定性等，引用军方的叫法VUCA。很难有人在项目的初期想的非常明白，可以让需求一成不变。有些同学马上会跳出来，搞“敏捷”呀，小步快跑，支持试错。从软件项目开发本身没毛病，但是回到今天的主题FP项目如何管理（这是甲乙双方合作的商业模式），试错成本谁买单？
甲方粑粑会大胆承认都是我的错，所有变化我买单吗？（这里还有变更内容的价格共识问题，后面再详细讨论）既然游戏规则在这里，我们要尊重，就谈谈在这样的环境下，乙方可以做什么？管理不要有洁癖，即便不能在根本上解决，能缓解也是好的方案。
1.1 火车容量的把控
什么是火车容量？在一定期间内（项目的起始周期内），本团队所能完成的交付量（通常用标准人天衡量）被称为火车容量。
先谈火车容量在于：超员了，就是无法上线，无法保证交付质量。即便甲方粑粑愿意结算，项目完蛋了，大家都完蛋了。容量是底线。
如何度量火车容量，上篇已经讲过，有：个人产能，团队产能，需求评估标准人天等概念，清晰的度量火车容量是需求变更是否接受的基础和前提。这意味着当有新的需求变更到来的时候，如果有必须上车的需求就要有下车的需求作为平衡。
1.2 需求变更的共识
在实战中，乙方的PM经常遇到的困惑是：需求变更客户不认；认可的需求变更，价格对不齐。这就引来一个话题：需求变更如何被共识。有四条经验分享给大家：1 需求变更的收集在日常来做，不要在项目结项才做 2 需求变更的确认（跟客户共识），要放在日常来做，如果能有邮件确认最理想 3 需求变更的价格评估（人天评估）要放在日常来做，至少要知会客户干系人知道（比如通过周报的方式）4 良好的客户关系（这是要到钱的核心。前面三条都是为了要到变更的费用做准备，最终还是要客户拍板，良好的客户关系可以最大程度的保障利益。如果客户没预算，也要通过客户关系提前了解，提前跟主管汇报风险，进行决策。没钱还要不要继续了）
1.3 需求变更的受入机制
如果是小项目（10人以内）需求变更的受入owner应该是PM，如果超过10人的项目可以是PL（各个组长）。受入的评判过程：是否超火车容量->是否加班可以完成->是否有预算保障->是否需要调换需求->是否要接受需求变更->是否需要叫停项目
需求变更是否接受的基础仍然是我们基于数字的运营，基于我们对于团队产能，客户预算，烧掉的成本，预期的毛利之间的平衡。由于这些都是动态变化的，造成了管理的复杂度。及时性，准确性，完善的升级决策体系是做好需求变更管理的关键。
PM不要怕变更，不要怕亏损。我们需要做到的是可视化，准确的，及时的进行升级。项目是否做，是否亏着做，是中高层管理需要决策的。我们追求的不是一本万利的项目管理，我们能做的是透明，共识的运营管理。
2 人力资源管理
软件项目是以人为本的。同一个人心态不同做出的产出物都是不同质量的。作为软件项目的主导者-人力资源也是FP项目管理的难点。下面围绕人力资源的各个环节谈谈心得体会：
2.1 项目人员配备
也可以叫项目的排兵布阵。项目团队是个群体作战的游戏，越大的项目，个人英雄主义的效果越差。成熟的项目管理，应当基于体系的，组织级的管理方法来体现团队作战的能力。
作为项目的领军人物PM，老哈给出的建议：使用同一个甲方客户的经验者，从其他项目的PM进行协调。最差从公司其他团队进行协调。使用社招的PM做新项目，特别是新领域是非常忌讳的。
这里有人会说，老项目的PM协调走了，客户会投诉，交接成本高等等。换个思路想一下，换个成熟项目的PM的交接成本高，还是让一个新人无客户经验，无内部协调能力，不懂客户和自身规则去承接一个新项目造成的re-work
