从项目制到产品制（1）：确定正确的产品边界

IT不是成本中心，而应该是利润中心——这几乎成为转型企业的共识。实现这一跨越，从项目制转向产品制，则是必经之路。在产品制开始落地时，第一个问题往往是：到底什么是一个“产品”？一个系统是一个产品吗？一个团队/项目对应于一个产品吗？一个大的特性能不能算一个产品？“产品”的正确边界又在哪里？

一直以来，业务与IT的关系是建立在职能分割的基础上，无论直接或间接，IT作为收单的乙方来承接业务甲方过来的投资项目。但是，项目制的思维，以管理确定性驱动，强调计划、预算、分工、人员利用效率，带来了很多问题：

• 从想法产生到上线产生效果的周期大大加长；
• ​目标割裂，各职能做局部优化，组织整体业务成果大打折扣；
• IT团队只是疲于完成任务，并没有得到有效激励，无法变成高绩效团队；
• 每次都是打完就撤，交付完事，缺少核心能力沉淀。​​

(图1 项目制中的资源及时间分配：仅有40%投资在真正的价值交付上)

随着组织的规模化越来越大，这些挑战将越来越严重，成为组织应对不确定性、持续创新的严重掣肘。大多数IT组织都意识到了这个问题，在敏捷转型的同时，也开始了由项目制到产品制的转型。

项目制与产品制，本质不同是什么？

产品制的思维和项目制思维最本质的区别是，项目制是以确定性（IT要解决的问题是确定的）为基础的，因而注重计划、预算、执行效率（人力利用率）；产品制的基本观则是，IT所要解决的问题都是高度变化的，因此应该不断挖掘客（用）户的真正需要，持续迭代更新解决方案，一切以提供给客（用）户的价值为目标。

(图2 项目制与产品制的本质区别)

疫情当前，互联网公司积累的响应力势能引人瞩目，美团"无接触配送"从确定需求，到上线只要了24小时，一周内覆盖到全国重点城市；腾讯从采购、到直接配送45000套防护服至医院也就是3天左右的时间。

这是长久锻炼出来应对突发情况的“高响应力肌肉”——投资能够持续创新的基础平台和能力、以响应力和业务成效为导向、跨职能的团队（从供应链到硬件到软件全通路协调）、鼓励团队自主决策（让一线听见炮火声音的员工直接做决策）、快速上线迭代优化方案。

对比于当前很多企业中的IT还在运行的方式——业务和IT完全就像是甲乙双方两家公司、规划时主要看是否符合预算要求、是否能达成当前KPI、以“人均交付功能点”和“人员利用率”为绩效、开发测试完全各顾各、领导必须通过层层审批需求文档来获得安全感——差距之大，上下立见。

产品制转型第一关：到底怎么才算是一个“产品”？

大多数敏捷转型的IT组织，理念上非常接受“产品制”。等到落地时，第一个问题往往是：我们这里有项目、平台、组件、功能特性、团队......那到底怎样算是一个“产品”？一个项目对应于一个产品吗？一个团队是一个产品吗？一个大的特性能算一个产品吗？“产品”的正确边界又在哪里？

数字产品的定义

在当前数字经济上下文里面，我们所说的产品肯定有别于传统的有形产品（比如杯子、肥皂），我们先称其为“数字产品”以与传统意义上的产品相区别。那么，怎样才算是一个“数字产品”呢？

首先，我们认为，数字产品具有两个本质特性：

1. 软件做为关键要素之一，是数字产品的核心组成部分。
2. ​具有独特的价值主张，是组织为某类客(用）户提供独特价值的载体。

(图3 数字产品的两个本质特征)

数字产品的不同样态

如果具备了前两个本质特征，在业务定位、服务对象、表现形态、业务模式、渠道、范围、生命周期，则可能具有不同的样态。以一个大型金融企业为例：

• 在组织整体业务中的定位：可以是用来直接创造营收（如线上贷款平台），也可以是仅用来降本增效（也可以是内部视频会议应用），也可以是作为加速器平台提升组织响应力（如内部的DevOps平台）。
• 服务对象：可以是外部的客（用）户，如电商平台，也可以是内部客（用）户，比如内部员工使用的移动办公应用（类似钉钉）。
• 表现形态：可以是一个系统应用，比如CRM，也可以为一组可为多用户重复使用的API服务（如用户身份认证与授权服务）、一个触点应用（如移动APP）、一个对接多方的平台（如对接资金需求方和投资方的投融资平台），还可以是一个IoT设备（如展厅的机器人客服）。
• 业务模式：可以是直接创造营收（如线上贷款平台），或者以订阅或使用许可等模式收费（如以SaaS方式提供的金融云平台），也可以是以内部结算/投资的方式获得营收，比如（DevOps平台、AI平台）。
• 关联渠道：一个数字产品有可能是基于一个渠道，也可能是跨越多个渠道，比如承载着同一价值主张的应用，有一个Web端，一个Android应用端、一个iOS应用端，我们还认为它是一个数字产品。
• 范围形态：数字产品的范围和形态，可能是随着时间，有可能延展扩大、也可能缩小。比如一个业务中台产品，一开始只支持存款业务、后来支持信用卡业务，再后来部分支持对公业务；到最后发现零售业务和对公业务的价值主张还是有很大差异，就又拆分成两个产品。
• 生命周期：所处的成熟周期可能不同，一个可能是从0到1还在开发（孵化期），一个是刚刚上线了一个版本价值有待验证（引入期），一个已经上线很久持续演进了若干版本（成长期或成熟期），一个则要逐渐被新的数字产品取代（衰退期或转型期）。

(图4 数字产品的不同表现样态)

（图5 数字产品、渠道、触点的区别）

如何确定数字产品的边界？

由项目制转为产品制，不是一个“革命”的过程，一夜之间城头变幻大王旗，由若干个XX项目，变成了若干个XX产品（如果真地这样，那多半是假的产品制），而且也不存在绝对的产品态——组织中总有一些本质上就是应该用项目来解决。

这种情况下，要落地产品制，需要有个逐步演进的过程：

• 先识别组织中符合数字产品定义、且对组织战略有着核心影响的产品（比如Top 10 或前20%），先对这些产品覆盖的范围进行明确定义，并围绕其构建跨职能的产品团队，以产品制的原则进行运作。
• 以半年或一年为周期，再进行下一轮Top 10的或20%的来以产品制运作。

（图6 从项目制到产品制不能一刀切（刚开始->一年后->两年后）

所以，”如何确定数字产品的边界“，本质上不是”如何切（划分产品团队）“的问题，而是识别出战略性产品，为这些产品配齐从需求到价值角度端到端的能力，构成真正的跨职能产品团队。

同样，以如上的金融企业为例，首批可能识别出了10个左右的战略产品，他们可以分成5种类型—R - 业务营收型，E - 体验关系型，A - 使能业务型，C - 降本增效型，T - 加速上市型。

（图7 Top 10 战略产品识别示例）

从产品形态上覆盖了系统应用、触点应用、平台、API服务等；从产品生命周期来看覆盖了从孵化到成熟期的四个阶段（处于衰退期往往趋近于停止投资，所以不会是战略重点）。这在第一期足以支撑在产品制实践落地措施的方案反馈和验证。
这些产品的团队构成现状总体来看分为三种类型，各自的能力配备措施如下：

（图8 为数字产品团队配齐端到端能力）

这在真正落地中，即使在IT内部，当涉及到人员的调配、职责的调整，也会受到当下现实的各种约束和阻碍。这种配齐也可以先由”虚拟岗“和”虚拟团队“（比如保留原职责岗位归属，但给定办公空间，让这些人坐在一起），逐步过渡到真正的跨职能团队。不过无论如何妥协，都要先保证开发和测试归属于同一团队。

当然，怎样认知一个数字产品、怎样识别组织中的战略数字产品、怎样识别战略数字产品所需要的能力是简单的，真正的落地挑战还有很多：数字产品团队，该有怎样的工作流程和实践？实践如何一步步真正把产品制的原则落地？如何衡量数字产品管理的成熟度？数字产品的成效和进展如何度量？如何动态调整持续积累”高响应力肌肉“，如美团一样？让我们持续探讨。

免责声明：本文中的陈述和观点均为作者的观点，并不一定反映Thoughtworks的立场。