写点什么

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

  • 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:541641

评论

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

华为云新一代iPaaS全域融合集成平台全新升级

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 4 月 PK 榜

Gradio:快速构建你的webApp

AIWeker

Python 三周年连更 Gradio

阿里大神整理的Java核心知识点和面试官常问到的知识点,压压惊

会踢球的程序源

Java 面试 求职 java面试 Java构架

接口设计文档的12个注意点

Java 后端开发 接口设计

如何用scrum敏捷工具做迭代规划及迭代执行。

顿顿顿

Scrum Sprint 敏捷开发管理工具 敏捷工具 迭代规划

【堡垒机小知识】堡垒机能记录操作时间、操作数据等等吗?

行云管家

网络安全 堡垒机

GitHub和 Gitee联合编写最新版20w字Java全栈面试手册,简直无敌!

Java你猿哥

Java java面试 SSM框架 Java面经

安装Zookeeper和Kafka集群

Java你猿哥

Java kafka zookeeper SSM框架 Java工程师

Linux:管道命令与文本处理三剑客(grep、sed、awk)

会踢球的程序源

Java Linux

从零学习SDK(7)如何打包SDK

MobTech袤博科技

挑战 30 天学完 Python:Day9 条件语句

MegaQi

Python 挑战30天学完Python 三周年连更

Kurator v0.3.0版本发布!助力企业实现多云异构管理

华为云开发者联盟

开源 后端 华为云 华为云开发者联盟 企业号 4 月 PK 榜

BT!GitHub开源阿里Java性能调优百宝书仅3小时,标星竟超过30k

Java你猿哥

Java JVM 性能调优 SSM框架 Java工程师

Apifox 更新 | WebSocket 接口调试功能上线!

Apifox

程序员 开发工具 Apifox API 接口工具

阅读完synchronized和ReentrantLock的源码后,我竟发现其完全相似

Java 源码 synchronized ReentrantLock

行云管家堡垒机有免费的吗?谁能告诉一下!

行云管家

高新企业 堡垒机 行云管家

硬核!万字神文精解高并发高可用系统实战,分布式系统一致性文档

Java 高可用 高并发 分布式一致性

带你一同认识和使用JPA框架进行开发你的应用服务

Java你猿哥

Java SSM框架 jpa Java工程师

全量通过,华为云GaussDB首批完成信通院全密态数据库评测

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 4 月 PK 榜

阅读完synchronized和ReentrantLock的源码后,竟发现其完全相似

Java你猿哥

并发编程 并发 synchronized SSM框架 ReentrantLock

字节面试官:你没有高并发、性能调优经验,为什么录取你?

Java 高并发 性能调优

火山引擎云原生数据仓库ByteHouse技术白皮书V1.0 (Ⅲ)

字节跳动数据平台

数据仓库 云原生 白皮书 数据仓库服务 企业号 4 月 PK 榜

GitHub上线重量级分布式架构原理设计笔记,开源的东西看着就是爽

Java你猿哥

架构 分布式 分布式架构

女朋友要我讲解@Controller注解的原理,真是难为我了

Java你猿哥

Java spring Spring 配置解析

Scrum敏捷研发和项目管理

顿顿顿

Scrum 敏捷开发 敏捷开发流程 leangoo 敏捷开发管理工具

热榜!Alibaba最新发布「10亿级并发系统设计文档」Git狂揽9000星

Java你猿哥

数据库 架构 分布式 架构设计 并发系统

火山引擎 DataLeap下Notebook系列文章一:技术选型之路

字节跳动数据平台

notebook 数据研发 企业号 4 月 PK 榜

Java中线程的6种状态详解(NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED)

共饮一杯无

Java 线程 线程状态 三周年连更

ChatGPT无需API开发连接第三方系统,让舆情自动监控

集简云开放平台

数据集成 数据集成平台 Chat

从源码角度深入解析Callable接口

华为云开发者联盟

后端 开发 华为云 华为云开发者联盟 企业号 4 月 PK 榜

火山引擎DataTester:让企业“无代码”也能用起来的A/B实验平台

字节跳动数据平台

AB testing实战 无代码 A/B 测试 企业号 4 月 PK 榜 企业增长

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