QCon北京「鸿蒙专场」火热来袭!即刻报名,与创新同行~ 了解详情
写点什么

大规模产品技术团队需求管理实践

  • 2020-03-18
  • 本文字数:3132 字

    阅读完需:约 10 分钟

大规模产品技术团队需求管理实践

背景

随着业务的发展,组织会从创业期的一个主要产品,扩展到多个产品。从产品技术的角度,也会逐渐抽象出共享技术部门,进而发展为技术中台、业务中台。随着产品线的扩大,产品需求管理(背后是协作协同、资源调度),就变成了一件愈来愈复杂的事情。如果不能妥善处理,会造成协同困难、效率低下,无法支撑业务发展。本文介绍有赞从由单一产品到多产品线,产品技术团队从百人到千人规模的需求管理实践。

组织目标与产品需求待办列表之间的关系

成功的商业组织,未必是资源多,而是把资源用到了对的地方。一维之上有二维,系统之上有系统,在更高维度才能看清楚低维度系统的全貌。从产品看技术,从业务看产品,从行业看业务。产品需求,从源头上来看,承载的是一个组织的战略目标和客户的诉求。


有赞使用的是 OKR 来管理战略目标,我们常说不积跬步无以至千里, O 就是千里之外的目标,是指南针; 从 OKR 出发衍生的需求待办列表,就是使得我们至千里的跬步。以产品和服务为载体的商业组织,无论目标多么远大,最终是落实在一条条需求上。产品需求的取舍依据是组织的目标,要与这个源头对齐,也就是需要与 OKR 对齐,以避免资源和时机的浪费。


需求待办列表的产生与更新:多方做输入,产品负责人做决定

产品需求从”事“的角度来源于战略。从”人“的角度来自内外部客户、干系人,具体来说外部有用户、客户、合作方等,内部有决策者、产品、运营、服务等。如果不能有效统筹管理上游干系人的期望,就会产生如下的负面反馈。决策者:我的 X 需求很重要,怎么那么久了还没有动静?客服:客户关心的 Y 棘手问题,什么时候能解决?信息不对称,就会陷入混沌状态。


需求来源很多,但对产品需求待办列表负责的唯一 owner ,是产品负责人( Product Owner )。在输入端,要保障内外部干系人的信息都能被听到。但在决策阶段,不能是多头决策 (有赞有一个文化:不用投票解决问题。可以广泛吸收意见,但是靠投票或者平衡术来做决定,通常是因为缺乏方向性的认知和担当)。PO 要充分收集来自各方的诉求,但切勿被任何一方牵着鼻子走。PO 需要有自己对产品的 Vision ,独立的思考和判断。一部交响乐是由群体来演奏,但不是由群体来创作。作为产品负责人需要在其位谋其政,用产品需求待办列表来体现产品愿景和实现路径,这是不可推卸的责任。


对绝大多数组织而言,一个重大的问题和挑战,是如何把很多分散的、零碎的信息合为整体。这份需求待办列表,就是一个信息的整合。需求待办列表确认之后,就可以同步给决策者、运营、服务等角色。他们关心的事情,可以有一个确定性的结论和反馈。纳入规划的需求,可以有一个预期时间与节奏;没有纳入的,也能明确告知,以便他们调整策略。

需求优先级的排列策略

无论是 PMP 、敏捷或者精益等,背后都有一个假设,时间、资源、人的智力创意等都是稀缺的,需要有效地被利用。有限的资源与无限的需求之间,是一对矛盾,我们需要结合用户价值、商业价值及成本投入做综合考量。


需求优先级的排列策略,有比较多工具可以用,比如用户故事地图、影响地图、MoSCoW 等,有许多公开资料可以查到,不再赘述。比如有赞使用的用户故事地图(灰色卡片为优先级较低的需求):



这里需要特别关注的是,需求待办列表,需要有 more with less 的理念,因为战略的精髓是聚焦。需求列的很长是容易的,但是能聚焦到最有价值的需求,是很有挑战的。


需求待办列表本身是可以随时更新的,但下一个迭代或者研发周期的需求,需要有一个确定性。 Scrum 是通过时间盒, KanBan 限制 WIP ,都是在长期的不确定性和短期的确定性之间找到一个平衡。在有赞是采用固定周期的方式确定下一个研发周期的需求列表(月规划-周迭代-日站会)。


这里需要注意的是,需求规划应该是渐进明细的,不要追求长期且细致的需求规划,这样是很危险的。在瞬息万变的 VUCA 时代,需要在长期的远景规划与当前细致行动计划之间做好平衡,不断迭代。

不同规模产品的需求待办列表

单个小规模产品的需求待办列表

单个产品,团队规模也不大,有一个唯一的需求待办列表,按照优先级自上而下排列。比如有赞在早期,主要是微商城 SaaS 产品:


单个大规模产品的需求管理

随着产品功能覆盖的用户场景越来越多,团队规模扩大也越来越大,一个待办列表进行需求管理,排优先级、规划资源等都已经比较困难。


这个时候的策略是:按照业务、产品领域的特点,把产品待办列表分成多份。需要特别注意,不要按照职能团队来划分待办列表(比如前端、后端、测试各有一份,会造成职能深井,目标迷失)。比如零售业务和团队规模越来越大,划分二级:


多个大规模产品+业务中台的需求管理

当组织的业务线、产品线越来越多,会有越来越强的诉求,要建设公共的业务、技术支撑能力,以避免重复造轮子,特别是这些基础支撑能力还是对外建立生态的基础,中台业务线就产生了。比如在有赞,从一开始的微商城 SaaS 业务,发展出零售连锁、资产、美业、教育,及对外提供 PaaS 能力的有赞云等,都需要中台的支持。中台的出现,对于业务来讲是把双刃剑。一方面,中台可以提供许多基础支撑能力,当新起一个业务的时候,或者用到其他业务已经沉淀的能力,可以快速复用;另一方面,也会造成多个业务都依赖中台,会形成协作复杂、信息不对称等问题,中台需要做取舍,就会形成瓶颈。


在有赞的的实践是,各个上层产品都有自己的需求待办列表,中台也建立自己的产品需求待办列表。多个业务/产品团队都把自己对中台的需求提过来,中台基于自身建设规划及其他业务的价值优先级进行排序。综合客户诉求、业务战略规划、中台建设规划,对中台的需求待办列表进行排序、排期。


组织形态对需求管理策略的影响

有许多组织是采用职能型的组织结构,比如产品、技术等是不同的团队,技术内部按照前端、后端、移动等分成不同的团队。但是在需求层面,需要始终保持用户视角,不要过早从职能视角来拆解需求。如果非要做取舍,宁可这个需求保持较大颗粒度,也不要让客户视角碎片化淹没在多职能团队(比如前端 后端 移动端等)的技术视角任务里。这样以客户、战略目标为导向的需求待办列表,有利于组织形态从深井向 Feature Team 的演进。

需求待办列表的承载工具

君子善假于物。做组织效能提升,不能仅坐而论道,需要把理念落到实处,落到太阳每天照常升起,落到我们协作的每一个日常。空谈不会误司,但止于空谈会误司。文章前面提到的策略设计,基本在有赞效能平台有产品化的落地,支撑需求相关理念在操作层面有效实施。


比如除了为各产品线建立唯一的产品待办列表,待办列表之间也会根据需求之间的关联关系进行互动,方便协同。比如共同依赖中台的需求,需求卡片上会标注多团队依赖需求的排期情况。如下图所示的 3/3 ,意味着需要 3 个产品线共同协作完成的需求, 3 方都已纳入各自的需求待办列表。如果显示的是 2/3 ,会提醒 PO ,具体是哪个团队还未将该需求纳入待办列表。



产品、技术、服务运营、市场、管理者等不同角色,会有不同视角的诉求。我们基于同一套需求待办列表看板,配置出不同视角的信息。比如服务运营市场等业务侧视角,希望看到各类需求的上线时间,我们会配置出“上线日历”模块方便查看。



用电子看板可视化整个需求流转的过程,相关过程节点会有时间和状态的记录,可以自由地生成各种报表。不同角色的干系人,可以看到他所关心维度的数据报表,检视需求待办列表的吞吐、周期等情况,用于决策或者调整改进。


后记

从开始做整体的需求管理策略设计及落地,至今 2 年多时间,整体的策略与框架没有大的变化。但大的需求管理框架,只能保障有一个整体的运作体系,过程中仍需要解决许多具体的问题。每个阶段,团队都会解决 1-2 个核心的过程障碍与问题,但仍然在需求颗粒度、价值闭环等方面有不少改进空间。以上总结,供大家参考,欢迎交流。


2020-03-18 19:541243

评论

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

【LeetCode】数组的度Java题解

Albert

算法 LeetCode 28天写作 2月春节不断更

2020回顾,2021学习目标

叫练

学习 2021年展望 2020年度总结

可能是Java 8 Optional最佳实践

ES_her0

28天写作

读书总结2020

IT民工大叔

#读书

大小厂必问Java后端面试题(含答案)

yes

Java 面试 后端

产品训练营--第四期作业

曦语

产品训练营

Java实体映射利器---MapStruct

是小毛吖

Java MapStruct

APM 行业认知系列 - 二

东风微鸣

APM Trace 可观察性

滚雪球学 Python 番外系列,自动化测试是个啥?

梦想橡皮擦

Python 28天写作 2月春节不断更

Angular性能优化实践——巧用第三方组件和懒加载技术

葡萄城技术团队

angular SpreadJS

2021版最新!字节跳动3面+腾讯6面一次过,谈谈我的大厂面经

Java架构之路

Java 程序员 架构 面试 编程语言

《经济学人》2021年2月20日刊精彩文章导读及资源下载

wbliu85

SpringBoot之自定义启动异常堆栈信息打印

false℃

EMC设计中电缆屏蔽使用方法

不脱发的程序猿

二月春节不断更 电路设计 EMC 电子产品 电缆屏蔽

如何 0 改造,让单体/微服务应用成为Serverless Application

阿里巴巴云原生

Docker Serverless 容器 微服务 云原生

某某大龄程序员被字节面试官怒喷“废物”,他得知真相之后都懵了

Java架构之路

Java 程序员 架构 面试 编程语言

架构设计篇之微服务实战笔记(一)

小诚信驿站

架构师 刘晓成 小诚信驿站 28天写作 架构师成长笔记

APM 行业认知系列 - 四

东风微鸣

APM Trace 可观察性

MySQL事务浅析|由浅入深

MySQL 编程 架构

面试官:Java性能调优你会多少?一个问题就把我问的哑口无言,哭了!

996小迁

架构 面试 Java性能调优

神级!字节2-4大牛出品:分布式技术笔记,让你在分布式的路上如履平地!

Java架构之路

Java 程序员 架构 面试 编程语言

APM 行业认知系列 - 三

东风微鸣

APM Trace 可观察性

技术资讯 | BML CodeLab发布重磅更新!!

百度开发者中心

AI 工具软件 #百度#

电子产品中EMC隔离设计的方法

不脱发的程序猿

二月春节不断更 电路设计 EMC 电子产品

全网最新、最全面蚂蚁金服面经分享:简历模板/面试题库/Java核心技术笔记

比伯

Java 编程 程序员 面试 技术宅

APM(应用性能监控) 行业认知系列 - 一

东风微鸣

APM Trace 可观察性

环信助力中国游戏社交类APP出“东南亚”记!

环信

LoadRunner测试中遇见的不可思议的问题及其解决方法

陈磊@Criss

IDEA 敏捷开发技巧——后缀完成

程序员小航

Java 后端 IDEA

Elasticsearch踩坑记之深度分页

topsion

大数据 elasticsearch 深度分页

你的面试专属!JVM G1GC的算法+实现,90张图+33段代码

Java架构追梦

Java 架构 JVM 调优 G1GC

大规模产品技术团队需求管理实践_文化 & 方法_弋戈_InfoQ精选文章