如何基于数字化运营进行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成本更高？又有人说，可以岗前培训。说的好，已经有进步了，但是也过于理想化了，简单的几小时培训就可以copy一个合适的PM吗？
那么如何应对变化，应对老PM的调岗呢？计划性的梯队建设+AB角。所谓计划性的梯队建设，是指对于内部资源进行人才盘点，主动计划性的进行赋能（内外部培训），使更多的资源具备项目管理者的能力，作为后备资源池。所谓AB角，就是常说的备份机制。重要岗位必有备份。在有突发状况发生的时候，B角可以马上顶上，PM轮岗也可以通过AB角顺滑交接。这里涉及的人力资源管理项很多：比如绩效管理，任职管理，人才发展，人才配置等等。
其次是资源的共用。对于SA，UCD，特殊测试等岗位，在项目中属于阶段性投入的角色，建议共用。既可以节省成本，又可以保证投入资源的专业度。这个同样需要在绩效考核，客户沟通，汇报关系上做好规则，方便兼职的执行性和交付质量的可靠性。
2.2 项目人员募集
招聘永远跟不上需求，这是一个永恒的话题。如何破局，如何缓解？
从需求端尽量做到滚动预测刷新，建议每个月刷新基于角色的人力资源计划。
从承接端优先进行内部资源协调。这里再强调下，对于核心岗位，特殊技能并不是简单的资源池空闲资源协调，而是新项目用老人，老项目用新人的方式来推动资源的内部盘活。
社招，校招培养这不仅仅是项目管理的范畴，今天就不在这里多讲，可以作为专题来探讨。
2.3 项目人员维稳
在项目交付周期内的人员变动影响很大，特别是敏捷交付，人员切换即便不考虑成本，交付质量/交付进度都很难满足。项目人员的有限维稳也是项目管理的一个核心工作，是项目成功的关键。
为啥叫有限维稳。对于软件行业，流动性较大，期望一个资源在一家企业干一辈子是不现实的。控制计划外离职是项目人员维稳的核心工作。做好项目维稳的关键：把握员工的欲望（钱，企业文化，学到东西等）+责任田方式。稍微详细说下，对于中大型项目，由于人数众多，PM一个人很难把控所有人的动态，可以采用责任田的方式，分区分片的进行把控。根据以往的离职分析，完全由于收入离职的员工比例不超过30%，说明软性因素，工作环境，职业发展，企业文化等对员工的稳定性也有着很大的影响。这里推荐HRBP的方式加强员工沟通和思想的刷新（俗称洗脑）。
对于【如何基于数字化运营进行FP项目管理】在上篇
如何基于数字化运营进行FP项目管理
中讲到了报价，进度管理，风险管理，进度管理，今天在续集里又讲到需求变更管理和人力资源管理。最后用小篇幅来聊聊什么样的项目适合采用FP的商业模式进行合作：
1 需求管理成熟
需求管理成熟度=需求相对稳定+需求清晰+变更流程明确
这个对需求的owner要求很高，甲方如果能力不足，乙方一定要投入资源协助甲方承担起需求对接，需求管控的责任。如果项目规模可以，即便是免费投入也要做。磨刀不费砍材功，需求的频繁变更造成的re-work成本会远高于BA的投入。
2 需求价值价格的共识
由于是fix price，到底需求列表的需求该值多少钱？这是个行业难题。目前还没有行业标准，只有一些评估的方法论，没法很好的做定量分析。这就造成了甲乙双方会经常就需求的价值和价格的匹配扯皮。
成熟的接包公司需要结合自己公司的交付能力建立报价模型，如果差异较大的客户（项目），或则连续数期不能共识的客户（项目）需要考虑放弃。
3 灰度管理
由于项目的复杂度，需求的不确定性，项目的预算要有一定程度的buffer来平衡变更和re-work造成的影响。甲方在申请预算对比PO包的金额要留有buffer，应对各种不确定因素的影响。对于预算紧张，0buffer，后续不清晰的FP项目，如果预期毛利率不高，建议慎重。
