OurStory

大家都知道PMO = Project Management Office（注：这里指的是交付项目中的PMO，不是研发项目），但是应该没有听过DMO。DMO（Delivery Management Office）是交付管理办公室，是管理ToG/ToB交付活动的组织。

为何要有DMO？交付PMO通常是从项目管理角度对交付活动进行定义和管理，管理的对象也主要是PM。但是，交付活动涉及多条职能线和多种活动，PM、架构、开发、运维、售后等，将这些交付团队视作一个整体、统一管理交付的活动会更加有利于提高交付效率和提升客户满意度，这就是DMO存在的价值。

DMO具体能解决哪些问题？很多交付团队甚至企业存在的问题是：

答案十分简单，被充分整合与激励的交付团队可以解决上述问题，而DMO起到的作用就是整合并激励交付团队。

那么，DMO具体能做什么？

1. 定义、管理交付框架和规范

交付框架和规范的制定一定要从多个纬度加以考虑：

• 所在组织的战略和业务策略
• 行业特点
• 所在企业的组织文化和能力边界
• 交付团队的使命和工作目标
• 项目全生命周期
• 客户全生命周期
• 产品全生命周期
• 评价体系

简单来说，

1）交付是服务于组织的战略和业务策略，支持产品落地、赢的客户、获取收入。因为企业目标及其业务所处的阶段不同，每家企业的策略也会有所不同，例如，打磨产品、验证商业模式、赢得战略客户、扩大市场规模、提升客户粘性、提高利润率、挽救业务，等等。面对不同的目标，交付部门应该有相应的组织架构和工作框架，例如是需要多些高水平高薪资的人应便应对无时不在的挑战，还是多招收工资低一些同时经验和技能也相对弱一些的人以降低成本；流程上是应该简单激进一些以快速抢占市场，还是应该保守全面一些，来降低风险。当交付团队面对管理层的各种要求时，略微分析一下公司的业务情况，就能理解了，甚至能预测公司老板的行为。当然，这种方法不仅交付团队能用，其他团队一样适用。

2）不同的行业有其特点，成熟行业、新兴产业、ToG、ToB，等等。成熟行业通常会有成熟的模式和规范，而新兴行业则需要更多的摸索，缺少业界统一的标准；ToG行业重视政府关系，ToB行业里帮客户赚到钱则是王道……面对这些不同的要求，交付团队的工作模式和人才结构都会有所差异。

3）所在企业的组织文化会深刻影响所有部门包括交付团队的工作方式、沟通方式、工作效率。例如，一个讲求互信高效的企业，可以大大简化流程和检查节点，而在一个喜欢甩锅的组织中，流程不得不包含自我保护的成份，这也会导致流程的冗长和效率的下降。企业的能力边界则包括组织能力和产品能力，交付团队需要在实践中摸清这个边界。在边界内做事相对安全，不能向客户过度承诺边界外的需求。为了提升企业的能力，有必要突破边界，不过，产品边界通常（不是绝对）要靠产品团队来突破。但是，交付团队必须要认识到自己在突破边界，其做事方式与在边界内活动差异很大。

4）交付团队的使命和目标是用来凝聚交付团队的重要方式。适当的使命感和目标可以增强团队成员的自驱力，降低管理成本，提高敏捷性和创新性。交付团队可以有哪些目标？以下为一些选项：

• 产品落地。公司一般愿意开发和销售标准产品或平台，因为边际利润高。但是，在ToG、ToB市场里，客户的需求是差异化的，产品或平台与客户需求之间通常存在着一条鸿沟。越新的技术，鸿沟越明显（详见关于AI的另一篇文章     ）。填平鸿沟的方式无非是客户自己定制化开发、公司找第三方定制化开发、公司自己定制化开发。不管哪种，都需要交付团队的支持

• 呈现公司产品与服务的价值。客户最初接触公司的途径通常是广告和销售，看到的也是PPT或产品演示，并不确切知道产品到底能给他们带来什么样的价值，毕竟广告和销售会夸大“功效”。直到产品被交付和部署进客户的环境，客户才有机会真正看到产品的价值，但是能看到多少，很大程度上取决于交付的方式。同时，交付团队是客户在实际工作中接触最多的人，他们的表现代表着公司的形象，他们为客户解决的问题反映公司服务的价值。客户是否愿意持续购买公司的产品和服务，一方面取决于产品本身，一方面取决于他们享受到的服务。这其中，产品的价值不是产品自己说了算，而是客户看到和感受到的，这就需要交付团队来帮助呈现。
• 帮助客户成功。客户达成业务目标，才有动力和预算继续购买公司的产品和服务。坑蒙拐骗只能做一锤子买卖。如果设定这个目标，就一定要真诚，听起来很滑稽，是吧？因为在实践中会发现，客户成功与公司的短期目标有时会存在冲突，如果没有真正地将客户放在心中，很容易走偏。

• 帮助公司实现可持续的收入。公司毕竟要盈利，但如果能够做到前三点，可持续收入的目标就不难实现了。这里说的“可持续”，是在一个领域里、一群客户身上，持续获得收入，而不是打一枪换一个地方。那样，即使不断有收入进来，也是不健康和不可持续的。

5）DMO的管理对象是项目，自然要考虑本公司的项目全生命周期如何定义，分哪几个阶段；项目服务的对象是客户，客户也有其生命周期；提供服务的工具是产品，产品也有其生命周期。项目、客户、产品都有各自的生命周期，有不同的阶段，每个阶段有其特性，需要不同的工作方式，三者不同的阶段组合在一起，再叠加业务所处的阶段，交付团队的做事策略和内容就比较清晰了。

6）流程是否适合业务需求，流程执行情况如何，资源是否满足要求，甚至业务情况如何，这些都需要一个评价体系，确定评价的环节、评价指数类型和参考值，并呈现决策视图，方便DMO实时了解情况并做出调整：对项目进行干预，调整资源投放。

如果可能，可以定义一下交付的工作和任务内容，并针对每项内容做个自我评估，与业界的差距，以及重要性。这个评估每年做一次，其结果可以作为团队建设的重要输入，也是对能力边界的一个认知。

与PMO不同，DMO制定规范和流程时不仅要针对项目管理活动，也需要扩展其范围到开发、运维、售后、服务管理等，以及与商务、产品、财务、供应链等部门的无缝衔接。必要时，还要影响其他部门的流程制定。流程的制定可以参考 — 流程“河”。

2. 定义、管理交付资源

交付资源是交付活动的执行者，他们的技能类型、高低、数量和在项目中的分布，对于交付的质量、效率、速度、成本都有重大影响。

因此，DMO需要根据业务需要，与职能线共同制定专家模型、技能栈和级别，以及不同级别对应的技能分数，然后对团队做一个评估和摸底，再根据结果安排培养计划。

从个人技能来说，很多企业有一个误区，觉得越专业越好。如果在传统的行业、传统业务中，这不是什么问题，因为业务、流程都很稳定，对创新的需求少，每个人就是一个螺丝钉。但是在日益变化的环境中，业务在快速迭代，工作内容和流程也不成熟，一个人经常面对各种情况，必须具备多种技能。传统的要求，就像以前的陆军，每个岗位职责和技能要求十分分明；创新型业务其实要求特种部队一样的员工，每个人都具备多种技能，能够独立应对各种突发事件，只不过每个人各有专长。

例如，如果PM懂一些架构、开发、运维的知识，他很多时候也可以独自与客户讨论或处理技术问题，不需要每次都带技术人员同行。如果运维具备一些项目管理以及与客户沟通的技能，也可以独自去客户现场，自行管理简单的项目。这样可以显著提高工作效率，降低成本。另一方面，大家具备相互领域的知识，讨论的效率也会更高，更容易相互理解，达成一致。同时，多维度的知识相互碰撞，更容易激发创造性。

顺便说一下，当代教育届已经意识到目前的培养专才的主流教育只适合传统的工业社会，无法适用于创新性社会，未来的人才在知识层面必须是通才。对于将“创新”挂在口边的企业，如果依然延续以往的人才机制，将人视为工具，就很难将“创新”落实到实际中。

除了个人的技能，人才分布也是资源管理中的重要事项。不同的业务需要不同类型和不同级别的人。例如，一家公司内，成熟业务线的交付难度应该相对较低，效率相对较高，同样的业务量，需要的人数应该少一些，人员级别可以低一些。新兴业务线的不确定大，工具和流程还在创建或磨合中，需要的资源相对多一些，需要更多的有经验的人员（级别高一些）。根据业务线的情况，分析人员投入的分布，就能识别一些人员配比的问题，提前布局或实时调整。下图中，成熟行业与新兴行业的PM配置就有疑问，技术人员的级别比例就比较合乎清理。

3. 管理项目、客户组合（portfolio），支持产品运营

项目组合管理是企业战略的一个载体，通常掌握在管理层手中，不过DMO毕竟有丰富的一手信息，可以辅助管理层进行项目组合管理。

项目组合应当服务于组织的长期战略和中期策略，管理内容涉及项目优先级、项目顺序、项目资源分配等。DMO（也包括一些PMO）应明白上述情况，然后监测项目的信息与状态，例如项目类别（尤其要区分POC和合同项目）、项目等级、项目健康状态、项目所处的阶段（按照项目生命周期）、项目当前milestone、项目区域、项目对应的业务线，决定哪些项目需要介入，哪些需要投入更多的资源，哪些需要提交给管理层讨论。同时，还可以从总体分析项目群状态，例如上述项目的百分比，还可以按照时间轴来分析项目群的发展趋势，是否需要对资源进行调配等等，进而，也能看出公司的业务发展趋势。

每个项目背后都有一个客户，所以交付团队也会有这些客户的一手信息供DMO收集，例如，最终客户名称（不是代理商），客户行业，客户区域，客户所处生命周期阶段（这个需要特别定义），客户健康状态，客户处实施了几次项目，客户都购买或部署了哪些产品，友商在客户处的情况，等等。这些信息可以分析得出公司的市场情况，业务是否聚焦，客户忠诚度，核心客户比例，以及客户离开的成本等等。客户的情况，对于项目组合的决策也会产生影响，例如，不同生命周期阶段的客户的项目出现问题，其重要性是不同的。这些客户信息也会有益于客户画像，帮助相关的面向客户的部门（可能就是交付自己，也可能是销售）及时跟进客户情况，处理潜在风险，识别潜在需求。

交付过程中一定会知道公司产品的使用情况，从产品纬度，可以知晓产品在哪些行业发展得不错，哪些行业还比较欠缺，哪些产品组合销售得比较好（这个可以帮助纠正解决方案的偏差），产品哪些功能比较受欢迎（这个数据还需要进一步核实原因）。这些都是对产品运营有价值的信息。

以上这些信息都可以用dashboard的形式呈现。

4. 提升交付效率

提升效率可以从这几个方面入手：

1. 持续优化流程。每个流程的制定都有其适用范围和条件，一旦这些条件发生变化，就应该更新流程。同时，推广流程时，不能为了推广而推广，一定要和业务实践结合起来，确保流程能够促进业务，也要让流程的实施者明白这个道理。这个过程在初期会比较痛苦，但是越往后会越感受到这样做的好处。
2. 结合移动、远程办公工具将重复性的办公工作自动化。这个过程中，一定要避免工具产品经理的认知与交付业务的脱节，也不必要追求大而全的工具，毕竟工具是为一线交付工作服务的。因此可以尽量采用已有工具，如果自研，也要坚持敏捷与快速迭代的方式。前面提到的组合中的数据的采集与dashboard的生成，都可以在工具中实现。同时，工具架构设计也很关键，不仅要将各个模块放进一张全景图里，还要将工具与流程对应起来，明晰工具和流程之间的关系，然后沙盘演练一个业务在不同工具间流转是否顺畅。
3. 将面向客户的交付动作尽量工具化，例如，重复的定制化开发需求可以做成一个半成品，工堪检测和问题诊断的工作做成脚本或小工具。在交付团队内培养开发的技能很重要。

结语

标题虽然是讲DMO，其实花了大量篇幅介绍交付团队的工作，正是因为交付团队对于很多产品或平台公司的重要性，如何整合交付团队、发挥交付的价值才显得十分重要，也就有了DMO存在的必要性。