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

阅读数:1 2020 年 3 月 18 日 19:54

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

背景

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

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

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

有赞使用的是 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 个核心的过程障碍与问题,但仍然在需求颗粒度、价值闭环等方面有不少改进空间。以上总结,供大家参考,欢迎交流。

评论

发布