Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Blogs Banner

从项目制到产品制(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的立场。

免责声明:本文内容仅表明作者本人观点,并不代表Thoughtworks的立场

及时获取最新洞见