低代码到底是不是行业毒瘤?一线大厂怎么做的?戳此了解>>> 了解详情
写点什么

如何基于 PDCA 思想进行发展型产品管理

2011 年 3 月 15 日

一、 产品规划思想

Dubray 最近有一篇不错的文章《可伸缩系统的设计模式》,文中有一个观点:“过去十年所取得的一个主要成就就是面向大众的可伸缩系统的广泛应用,尤其是云系统和某些高可伸缩的 Web 应用。”伴随着互联网面向服务的转变,面向需求细分的转变,互联网产品逐渐向“伸缩系统”转变,产品规划也必须以“发展的眼光”看世界。什么是“发展的眼光”呢?假设我们有一块土地,当我们预测到未来市场的对白菜的需求比较高时,我们更愿意种白菜,当需求变更为土豆时,我们便更愿意种土豆。在这个案例中我们发现土地本身是不变的,而在土地上种什么产品则是灵活的,其变化的动因来自于市场的需求。当我们进行产品规划时,其理论是相似的——如何设计灵活的产品,并能伴随需求的变化而升级。因此优秀的产品规划人员必须具有非常好的眼光和判断力、优秀的数据分析和挖掘的能力、缜密的思维、较强的执行力、对“变化”较强的管理能力,把产品规划的执行变成一个“搭积木”过程。那么如何进行产品规划呢?我们发现灵活的产品一般有几个特征:

产品规划是分层级的,基础是体现了产品未来的发展方向,而丰富的应用需建立在坚实的基础之上

优秀的产品规划有两个着眼点,一个是现在,一个是未来。如何在满足当前用户需求的情况下,使整个产品基础符合未来发展的需要,同时有计划的进行干预产品线的发展方向,这是一个需要具有非常好的眼光的艺术性工作。很多理论的实践发展也证明了这个观点,比方张亚勤博士在其书中提到的近十年来的云计算理论和尝试——从.NET 架构,到“按需计算”(On-demand)、“效能计算 (Utility Computing)”、“软件即服务”(Software as a service)、“平台即服务”(Platform as a service) 等新理念、新模式。我们并不难发现其发展的轨迹遵循从整体的计算逐渐到“云 + 端”共存,并且逐渐走向以“云”为核心“端”为服务的架构。在这样的架构下,我们更强调的是基础的坚实,服务的丰富,并可以遵循用户需求进行不断进化,创造良好的用户体验。

虽然很多企业并不需要“云计算”,但我认为“云 + 端”思想可以基于现实状况加以演绎应用于企业 IT 实践中。”云 + 端“思想的本质在于能够灵活地满足用户需求,以服务用户为主导的思想。服务 一般包括检索、发现、关联、处理和加工,以应用的形式构建,其本质是服务用户,但其核心在于需要依附能够较好的支持其发展的平台。这个平台就好比可以耕种果蔬的土地,可以灵活的支持服务的实现,所以我们必须强调灵活坚实的平台,我们可以理解为灵活智能是产品规划之魂,坚实高效是产品规划之魄。

应用是可以进行用户行为数据跟踪的,用户和市场需求的改变可以通过数据分析而捕捉到。

用户行为数据跟踪是企业进行数据管理的第一步,能够实时把握用户需求变更的企业必须拥有非常完善的数据监控和分析工具,并且只有通过用户行为数据跟踪我们才能发现问题的本质。因为应用是与用户数据交互最多的地方,所以我们强调应用需要具备用户行为数据跟踪的特性,在此基础上我们便能够进行企业数据管理实践。在一个较为完整的数据管理体系中,用户行为数据的分析至少需要包括几个方面:

  • 核心洞察数据
    • Click Density Analysis 点击密度分析(可利用 Google 分析等工具)
    • Visitor Primary Purpose 访客首要目的(简单的调查,勿依赖页面浏览行为)
    • Task Completion Rates 任务完成率(调查,可用性测试等方式)
    • Segmented Visitor Trends 用户分层(ClickTracks 等工具)
    • Multichannel Impact Analysis 渠道分析(监测渠道投放前后数据发化)
  • 指标型数据
    • Click stream Data 点击流数据【直接输入 URL 数量、访客来源、访客地理位置】
    • Outcomes Data 结果型数据【访客(初次访问数、访问总数、平均回访数、关注点)、页面浏览(平均浏览数、总 PV、访问超过一页的访客比)、时间(全局、人均)、关键行为(如:注册、购买)、转化率、相关(Keyword、趋势、网站)】
    • Research Data 体验研究数据【调查、启发式评估、可用性测试、访客属性】
    • Competitive Data 竞争性数据【“面”数据测量、网络服务提供数据测量、搜索引擎测量】

当我们通过严密的测量发现这些数据变化与时间的关系时,我们通常可以通过简单的对比和测量发现问题,再通过启发式评估或者调查测试等手段通常可以发现问题存在的原因以及表现,或者发现新趋势的到来。很多问题或者机会都躲在数据背后,但只有认真细致的收集和分析才能够发现。

此外,在过去的大多数案例中,我们发现很多企业在执行数据分析方面是消极的,更多的是对数据视而不见,对用户需求的变更视而不见,这是不仅仅是国内互联网企业的通病,也是互联网企业短命的主要原因之一。我们建议数据分析工作的执行程度一定要与产品团队的 KPI 体系结合起来,形成较好的激励和惩罚机制,这是形成职业化产品团队的基础。

应用是有生命周期的,是伴随着用户需求的变化而从产生到消亡并被新应用替代的过程。

没有任何产品可以一成不变的。伴随着各种技术的发展,用户需求的不管改变,新的商业模式的不断产生,所有产品都是在不断改进中优胜劣汰,产品更迭不可避免。当我们意识到产品生命周期的必然,便可以知晓任何产品都是在不断的竞争中,尤其是面向用户的竞争中主动改变以更加适应市场。产品规划并不是特意的寻找差异化,而是面向如何更好的服务用户,比如更积极的进行用户中心的设计,更快的调整产品线,提供更符合用户期望的产品概念等等。

我们并不认为好的产品规划是一次性行为,其应该是多次的不断迭代的结果。同时在产品规划中,我们不仅仅需要产品思想和未来形态的表达,还需要与之配套的产品改进计划,譬如数据分析方案、用户体验体系建设方案、产品持续改进方案等等,将产品规划变成“产品发展动态计划”。事实上,我们会发现符合现在用户及市场需求的产品的诞生一定是产品规划不断发展的结果,如果我们在具体的实施过程中完全能够遵循用户需求进行产品持续改进一般都能取得比较好的效果。由于通常产品概念的提出是基于当时环境和用户需求等多种因素,而产品规划则是基于产品概念对核心产品理念不断丰富的过程,所以产品规划往往是有时间版本的,不同的时间版本符合不同阶段的用户和市场需求,当然也可能因为需求发展方向的不一致衍生出不同的分支,我称其为为发展型产品规划。

二、 PDCA 的产品管理执行

当我们提出了发展型的产品规划思想时,我们面临着一个新问题——如何执行不断变化中的产品规划呢?PDCA 的产品管理思想是一个不错的选择。1950 年,美国质量管理专家戴明(Edwards Deming)博士重新提出了 PDCA 改进循环,并广泛宣传和运用于持续改善产品质量的过程中,其不仅仅对工业生产产生了非常大的影响,在之后其成为企业管理的最重要的部分,并且充分应用于各行业的产品管理中。在过去的实践中,我们发现 PDCA 思想对变化中的规划执行非常有帮助,我在我的书《精益求精——卓越的互联网产品设计与管理》中详细提到过 PDCA 的产品管理方法。这里,我们重点说明 PDCA 的产品管理思想对发展型产品规划的实践意义。

在上图中,我们可以发现 PDCA 管理不是运行一次就结束,而是周而复始的进行。当一个循环完成后,一些问题得到了解决,而未解决的问题则进入下一个循环,整个管理行为必然使产品阶梯式上升。同样的,发展性产品规划也是不断循环的结果,我们只要持续推行产品管理循环思想,产品便能够进入到持续改进循环中,具体的管理行为包括以下几个部分:

1. 计划(Plan):

把握产品开发节奏,将整个规划合理的变成产品开发地图。在产品开发地图的设计中,我主张先对规划进行系统分析,基于产品远期构想来设计灵活的底层应用,而基于当前的用户需求来设计外围应用。我们可以理解为产品开发地图的每个区块设计拆分为几个要素:

  • Who:其服务对象以及相关角色
  • Why:其存在的意义和价值
  • What:具体内容
  • Where:其产生与支持环境
  • When:其出现的最佳时机
  • How:其开发计划

我们如果将每个应用都以开发地图的形式表现出来,我们会发现实际上整个产品开发过程就是不断征服每个区域的过程,伴随着产品开发的进行,这个产品开发地图逐渐被实现。如果我们对有竞争力的点分别进行标记的话,我们会发现伴随着市场环境的变化不断进化,整个产品的竞争力是带状分布的,而且是相互关联的。

此外,在产品规划中我们需要考虑到用户行为数据的跟踪,即哪些数据是需要重点跟踪的,是否满足阶段性数据指标,用户行为是否与我们的预期一致等等。我们会发现用户需求变更,竞争者行为等等都可能反应在数据中。我们可以通过数据跟踪以及数据周期性表现来制定数据指标,我们可以通过数据管理进而指导产品线的管理,同时我们的产品持续改进也必须以数据为中心。

2. 执行和检查(Do & Check):

产品开发的过程不仅仅是计划执行的过程,同时也是检查的过程,我们需注意到执行和检查是应该并行的,问题的快速发现与及时的产品计划改进效率往往反映出企业产品管理的职业化水品,改进效率的高低往往决定了产品是否能够持续满足用户需求。

对执行而言,我们需要的重点关注两个部分:开发执行和运营执行。在开发执行中,执行的效率以及执行的结果是否和产品中心概念相符合是执行的关键。我们在产品开发执行的过程中通常会碰到几个问题,如业务需求难以理解,需求变更失控等,对这些问题的管理直接影响到执行效率和开发成本控制。在过去的产品开发经历中,我发现当业务需求描述比较困难时,通常是业务需求说明书并没有基于真实的用户需求或者业务逻辑存在问题,与之此类似的,需求变更过快的原因往往也是没有完全理解用户需求导致的。在运营执行中,我们需要关注的包括各种数据指标是否符合预期,哪些地方影响了数据的增长性等等。面向运营的执行总是有解决不完的问题,我们需要将存在的问题进行优先等级排序,挑选出重点的问题针对性的产生渐进式的解决计划,逐个解决。

对检查而言,我们考虑的重点在于指标的达成,包括产品用户体验指标,开发效率指标,运营指标等。高效发现问题的关键在于建立数据指标分析框架,基于完整的数据分析框架我们可以发现大多数问题。数据分析框架设计的重点在于问题的结构化,也就是将每个问题的分支进行研究,比如我们通常使用的鱼骨图分析发等等都是比较不错的分析方法。我们会在分析中发现每一个问题的存在并不是独立的,而是一连串原因堆积的结果,比如当我们发现用户购买转化率不高,那么可能是购买流程过于复杂,也可能是购买页面安全体验差导致用户认为不安全,也可能是由于购买过程中用户受到了其它因素的吸引而没有完成购买任务等等,任何可能性的因素我们都需要使用我们的数据分析框架进行仔细的分析。我们会发现在大多数情况下当我们找到关键问题的症结时,解决方案也就自然产生了。

3. 处理(Action)

问题的处理是一个有条不紊的过程。麦肯锡有一个经典的方法叫做”假设——证明”,一般情况下,问题的根本原因一般都是一个或者较少的几个,我们在改进时可以参考这样的方法,假设是某个局部发生的问题,然后设计改进方案进行局部改进,再观察数据是否有质的改变,证实或者证伪我们的假设,最终一步一步的发现引起问题的根本原因,达到产品的持续改进。当然,我们在进行问题改进时需要注意改进必须是有计划的,按部就班的进行,将问题解决进行计划管理,避免今后再出现类似的问题。

此外,通过产品生命周期管理,我们会发现任何产品都是具有生命特征的,伴随着用户或者市场需求改变或者技术进步等,旧产品逐渐被新产品代替,即使我们能够不断的发现问题解决问题,但是伴随着市场的发展应用的整体淘汰是不可避免的,就好比电灯代替煤气等一样。面向问题的持续改进只是持续循环改进的一个方面,另一方面我们需要通过用户行为分析发现一些需要改进的痛点或机会点,这些点通常是需求变更的起点,同时也是产品规划向下一版本改进的起点。

三、 职业化产品团队建设

虽然从 50 年代开始 PDCA 的管理思想便已经成为管理学经典,但建立 PDCA 的产品管理组织并不是非常容易的,其产生需要产品组织中有适合的土壤,即标准化的产品管理,其难点在于其标准化是建立在动态的基础上的。

在 PDCA 产品管理循环指导下,除内部因素之外,通常计划的变更以及新产品计划的产生总是外部需求发生变化的结果,整个变更过程在大循环中是被动态管理的,所以我们可以认为 PDCA 产品管理循环为发展型产品规划的科学管理提供了工具和标准,其标准就是用户数据是否符合预期,而工具则是持续改进循环,下图为 IPMT 集成组合管理团队产品管理流程,该流程的核心思想为产品的持续改进实践:

在 PDCA 产品开发管理实践中,我们会发现具体的问题往往来自于企业产品管理组织中是否存在以数据为中心的对话平台。为建立以数据为中心的产品管理组织,我们建议以实践为手段,通过不断的项目实践来建设用户(客户)驱动创新体系(UDI+CDI),通过持续改进实践,建立科学的 PDCA 产品管理体系,实现科学化的产品管理。

此外,我也比较赞成使用外脑来进行 PDCA 体系建设,以下是过去一些比较成功的流程方案可供参考。

关于作者:

罗旭祥,现为独立咨询师,专注于产品管理、数据分析和用户体验研究,著《精益求精——卓越的互联网产品设计与管理》。用户体验咨询师出身,UPA 中国成员,曾于某知名 IT 集团互联网事业部任职产品总监,曾为广东发展银行总行、中国工商银行总行、宇信易诚、支付宝、太平洋电脑网、艾瑞咨询、中国移动、中国电信、家庭医生在线、蚁集网、星期八网、和茶网等企事业单位提供服务。2010 中国软件技术大会演讲嘉宾。


感谢朱永光对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者 朋友交流。

2011 年 3 月 15 日 00:003168

评论

发布
暂无评论
发现更多内容

IT自由职业者是怎么样的感受和体验

古月木易

IT职场

架构师训练营第一周-食堂就餐卡系统设计

王铭铭

【话题讨论】「世界上最好的语言」?25周岁的 PHP “配” “不配”

InfoQ写作平台官方

php 写作平台 PHP25周年 活动专区

《Web全栈实用编程》一书征集意见

老魚

程序员 前端 Web 后端 全栈

极客大学架构师训练营第一周学习总结

竹森先生

学习 架构设计 极客大学架构师训练营

基于UML的食堂就餐卡系统设计

王海

极客大学架构师训练营

架构师训练营-第一周-食堂就餐卡系统设计

Anrika

架构师 极客大学架构师训练营

区块链技术如何应用于版权保护?

CECBC区块链专委会

区块链技术 维权 著作权 版权保护 侵权

IT自由职业者是怎么样的感受和体验

奈学教育

IT

ZooKeeper核心原理及应用场景

奈学教育

zookeeper

谈谈阿里云发布新一代容器、Serverless 等云原生产品

关贺宇

阿里云 容器 云原生 中间件

架构师训练营第1周作业二:学习总结

sunpengjian

架构师训练营第一周命题作业

兔狲

干货|微服务线上生命周期管理

博文视点Broadview

容器 微服务 微服务架构 微服务冶理 架构师

从软件架构说起

傻傻的帅

架构 架构要素 架构设计原则

第一周课后作业——食堂就餐卡系统概要设计

jiangnanage

week1-食堂就餐卡系统设计

不在调上

食堂就餐卡系统设计

hellohuan

架构 极客大学架构师训练营

ZooKeeper核心原理及应用场景

古月木易

架构师训练营-第一周学习总结

hellohuan

极客大学架构师训练营

ChaosBlade:从零开始的混沌工程(二)

郭旭东

云原生 混沌工程

Week01 学习笔记

任小龙

产品路线图–您的产品战略路径指南

涛哥

敏捷 产品经理

食堂就餐卡系统架构设计文档

hifly

极客大学架构师训练营 UML 架构文档 部署图 时序图

极客时间 - 架构师训练营 - week1 - 食堂就餐卡系统设计

毛聪

极客时间 极客大学架构师训练营 食堂就餐卡系统设计

架构训练营第一周学习总结

陈靓-哲露

架构师训练营第1周作业一:食堂就餐卡系统设计

sunpengjian

架构师训练营第1周_学习总结

方舟勇士

课程总结

设计模式之单件模式

Geek_896619

Java 设计模式

我们需要干货吗?

Neco.W

能力提升 经验分享 干货

食堂就餐卡系统架构设计

任小龙

2021 ThoughtWorks 技术雷达峰会

2021 ThoughtWorks 技术雷达峰会

如何基于PDCA思想进行发展型产品管理-InfoQ