我的老朋友Max，一年前意气风发地跳进了一家大型的IT金融外包公司，担任大项目经理。前段时间他小孩满月酒，我才知道他已经裸辞了……

Max是个80后IT宅男，本身性格就比较保守，再加上面临房贷、车贷和小孩。就算要换工作，也一定是找好了下家再辞职。而让他裸辞的原因，正是大项目经理这个岗位的工作内容。

对外，他要独当一面，沟通和处理客户提出的所有问题和修改意见，全面接住客户的抱怨与投诉，想尽办法让客户接受交付掉项目……他这个“大项目经理”在客户这头，基本等同于“客服”。

对内呢，什么提高效率和质量，把控项目周期，说得漂亮而已。每天实实在在要面对的，是沟通安排工作任务，应对项目组的抱怨和老板的各种质疑……

Max自嘲说，自己就好像夹心饼干，两边都很硬，只有自己很柔软。

我认为Max的选择非常正确。他做的压根就不是大项目经理，而是一个“具有人工智能的服务交付管理系统”。

上一篇文章中，我们说过，软件项目要交付的不仅仅是软件产品，还有具有产品属性的服务。这两个合在一起，便构成了客户的服务交付需求。公司无法识别出产品属性的服务，便会觉得客户一会要这，一会要那，以至于需要一个“大项目经理”来专门应对。可“大项目经理”也无法识别清楚产品属性的服务，面对客户提出的要求，他便无法甚至无理由拒绝，只能像个传话筒一样，向项目组不停地派任务。

尽管服务交付需求千人千面，不过大致上还是有迹可循的。从业务到项目，不同的层级有不同的服务交付需求。

Fancier凡奉信息版权所有

一般来说，业务层面的交付需求在合同阶段就基本确定了。而项目层面的服务交付需求，则会随着项目的推进逐渐展开。因此，很多公司都会用类似Max这样的“大项目经理”来处理这部分黑盒🙈问题。这种做法治标不治本。想要改变“大项目经理”的困境，关键还是要将服务交付需求的黑盒变成白盒👀。

白盒化服务交付需求，必须要弄清5个W：

WHAT：交付什么

HOW：如何交付

WHY：为什么交付

WHO & WHOM：由谁向谁交付

WHEN：何时交付

系统化这5个W，会形成3个核心，便是服务交付管理体系。

Fancier凡奉信息版权所有

服务协议

服务协议不等于项目合同，而是所有描述服务交付需求的正式文件。- WHAT

服务协议存在的意义，在于最小化项目组与客户之间对，于服务交付需求的误解程度。- WHY

因此，服务协议不仅要包含交付的工作产品，还应包含流程、工具、方法、消耗品等。- HOW

在项目过程中，项目经理要求客户签字的所有文件，都是服务协议的组成部分，比如需求文件、进度计划，甚至是会议记录。之所以签了字也没有约束力，是因为这些服务协议都没有起到至关重要的作用——最小化服务交付需求的误解。因此，签不签字不重要，重要的是通过签字这个环节，项目组要与客户之间，达成对服务交付需求的明确且一致的理解。

服务干系人

服务干系人不仅包含提供服务的人力资源 - WHO，还包含负责验收服务或授权付款的客户，以及最终使用服务的用户 - WHOM。

客户可以是具有完整决策权的个人，也可以是由多个决策干系人构成的小团体，他们界定服务的需要，购买服务，定义服务等级与目标。

用户在项目过程中可能并不会直接参与，但他们对于服务使用的反馈，将直接影响客户判断服务交付需求的满足情况。

因此，在进行服务干系人管理时，一定不能只看到接口人，而是要全面识别服务干系人。

服务请求管理

服务请求有两种形态 - WHEN。

一种，是在服务协议中，已经确定好的那些持续的或者按照项目进程逐渐开展的服务请求。另一种，是由客户或最终用户，不断地定义为服务交付需求的服务请求。无论是哪种形态的服务请求，都应被记录、追踪和解决，这便是服务请求管理流程。

“服务请求管理流程”的方法论有很多，在这里我只强调3点：

1. 如果服务请求的体量不大，那么流程越简单明了就越好，可能一个《问题记录和追踪单》，或者一个《工作状态公布栏》就满足了。如果公司的业务已经从比较静态的项目或者产品，走向了动态的需求派单方式，那么就需要使用软件系统，来支撑服务请求的管理。这两点，可以确保服务请求得到快速响应。

2. 为了有效地处理服务请求，应该归纳和整理服务请求的类别，并制定出不同的处理办法。比如需求变更的服务请求，应按照需求变更流程来处理；数据备份的服务请求，应按照配置管理的流程来处理……

3. 分析两种不同形态的服务请求（确定的和不确定的），将具有统一性和典型性的不确定服务请求，补充进服务协议，以确定的方式呈现给客户，提升服务交付的稳定性。

Ok，我们来总结一下：

以前，我们专注于软件项目的需求，而忽略了具有产品属性的服务需求。后来，我们意识到客户还需要很多其他的服务，便指派了“大项目经理”。“大项目经理”搞不定，不是单纯地因为他能力不够，而是客户的服务交付需求是全方位而立体化的（5Ws）。

因此，不要寄希望于一个Super PM，而应该系统化地管理服务交付。