案例精粹——产品化管理的顶层设计与落地实践

导语

数字时代，软件行业正处于快速发展的浪潮之中，金融科技领域的软件服务商在众多机遇之中也面临着诸多内外部挑战。为了在激烈的市场竞争中生存和持续发展，企业需要拥有持续迭代精进的技术研发能力、领先的业务认知，以及能够快速响应市场变化。同时，保持成本的领先优势也至关重要，这样才能在市场中占据一席之地并不断壮大。

在这样的大背景下，对于ToB的软件服务商来说，必须在定制化开发和标准化产品之间寻找平衡。定制化服务虽然能够满足客户的个性化需求，但随之而来的IT人力成本上升成为了一大挑战。此外，定制化开发越多、响应越快，产品就越碎片化、维护成本越高，难以在市场上获得更多的话语权和竞争优势，反而有损为客户提供专业化服务的能力。

为了避免陷入这类困境，加强产品化能力成了软件服务商绕不开的课题，这不仅仅是从提升企业利润空间的角度考虑，更是为了使其保持市场竞争力和持续发展的能力。

相较于定制化开发，强调产品化能力可能会在短期内影响客户满意度，而且对于产品整体设计和管理能力有较高的要求，需要其在「交付项目的短期压力」与「打磨产品的核心能力」之间寻找平衡。这并不是一件容易的事情。

作为国内领军的金融科技全领域服务商，深圳市金证科技股份有限公司（以下简称金证）深谙行业之痛与平衡之难。在夯实行业领军地位的同时，金证不断思变，探索更先进的数字化产品研发管理方法，以实现资源的价值最大化，提升服务质量和管理效率，同时也能够更好地把握市场机遇，保持在激烈竞争中的领先地位。

具体怎么做？下文将分享金证的探索过程和实施效果。

实与虚：虚实结合的组织阵型与角色体系，为产品研发管理规范化打下基础

大部分企业，通常采用「部门-科-室」的方式划分管理组织层级。这种职能组织架构主要是考虑资源整合管理、人才培养与晋升、员工绩效考核等因素，相对稳定。然而，随着市场和业务需求的变化越来越快，传统职能架构无法满足人员高频协同所需——对软件服务商而言，软件产品的发展通常是由一个个项目推动的，产品的长生命周期与项目的短期高效交付的属性，对组织的快速响应与有序协同提出了更高要求。

为解决这一难题，金证从组织阵型调整与角色体系梳理入手，以新清算产品为试点，探索更适配产品化发展的组织形式，将产品线的组织阵型调整为「产品线-产品部落-小队三层复合结构」，其中产品部落与小队均为虚拟组织，仅从产品管理的实际需要划分团队人员，不改变其原有的职能部门结构。具体落地过程如下：

首先，对于产品线级的主要角色与职责进一步明确，并根据产品化管理需要，在产品线级增加效能教练角色：

产品线负责人对产品线整体发展方向和业务价值交付负责，把握产品线整体的发展目标与路线图并负责拆解落地，确保各产品的发展路径符合产品线整体规划；

产品线架构师主要负责产品线的整体架构和技术演进方向，引领产品线技术架构和标准的制定，把关产品线技术质量；

效能教练负责协助提升产品线的产品化管理能力，为团队引入优秀的管理和技术实践，指导团队落地各项实践活动，支持组织产品化管理机制的规模化推广。

其次，在产品线下设立虚拟的产品部落，将服务于该产品的不同职能和角色人员划分至对应的产品部落，并明确产品部落级的角色要求与职责：

产品负责人主要负责把握产品的发展方向与路线图，负责建设并守护产品的核心能力；

技术负责人主要负责产品的技术实现方案设计，根据业务场景给出合适的系统解决方案，把关产品研发的技术质量；

产品经理主要对需求的质量负责，把关需求交付，负责需求的分析与实现方案的细化设计；

测试负责人主要负责制定产品测试策略和测试资源协调，确保交付质量。

最后，在产品部落下，进一步划分虚拟小队作为端到端交付的最小单元，包含小队长、研发和测试人员：

小队长负责组织小队交付产品故事，并管理研发容量、进度和质量；

研发小队按要求完成故事和任务的研发测试。

图1：产品管理组织阵型与角色体系

这样一来，在不改变原实体职能部门设置的前提下，通过虚拟的组织阵型，匹配业务形成面向交付的产品化组织，构建了更符合组织需要的产品管理度量视角。此外，将产品核心管理人员集中在部落级，更有利于产品的长期规划和产品功能建设的把控，而基础的交付小队则可以专注于相对清晰的故事研发，稳定输出价值，为产品研发管理规范化奠定了基础。

短与长：注重短期需求交付，深谋长远产品能力

在变革的第二步中，我们审视了产品研发的核心对象——需求的管理规则。以往，金证以产品故事为主要的需求管理单位，部分故事可根据需要拆解子任务。这种简单的需求管理模式在一定程度上降低了基层管理成本，但难以满足中高层对产品方向、产品路线发展等更高层次管理的需求。因此，我们在原有的产品故事基础上，扩展了需求管理的层级结构，向上增加了业务需求层，向下增加了个人任务层，构建了三层需求管理体系，并根据协作过程配套设计了价值流，增加了需求优选、评审等关键环节。

这一需求体系与调整后的组织阵型相适配。产品部落级的角色主要工作在业务需求层，主要强化产品的方案设计，及对需求优选和评审的流程把控。小队级角色主要工作在产品故事层，产品故事由业务需求经过评审后拆解而来，颗粒度较小，需求内容相对清晰，很大程度上减少了边研发边分析需求所带来的返工情况；研发小队的开发和测试人员还可根据需要继续在产品故事下拆解个人任务。

三层需求体系加强并规范了需求交付的流转过程，在此基础上，我们进一步将产品规划的管理单元引入体系，将产品的年度目标和季度主题进行线上化，并将业务需求与其进行关联，透明产品的目标实现情况与演进过程，为产品负责人进行相关决策提供了参考数据。

图2：五层产品研发管理体系

两层产品规划单元（目标、主题）加三层需求交付单元（业务需求、产品故事、任务）形成的五层产品研发管理体系，兼顾产品的长期能力管理与短期的需求交付管理，大大提高了上下对齐的效率。一方面，业务需求与目标主题的关联打通了规划与实际执行之间的数据链，结合对业务需求的分类标识（产品需求、定制需求、技术需求等），可以让产品管理人员及时获取产品功能建设与资源投入的情况，从主动规划的角度把控产品核心能力不偏离，有的放矢地调配资源。另一方面，从上而下的规划分解和需求方案的决策把控，使得需求在被拆解为产品故事时已经经过一定程度的论证和方案澄清，有助于提高研发团队的效率和交付质量。

快与慢：团队分层运转，快慢结合的有序迭代促进交付效能提升

对于复杂庞大的组织，确保高效运转的关键在于建立和遵循流程标准，利用规范化的操作和节奏化的运转降低复杂性和不确定性，组织规模越大，愈是如此。前述关于组织架构和角色职责的明确以及产品研发管理体系的优化，已经为交付团队的规范化管理奠定了基础。在此基础上，我们在试点团队进一步建立起敏捷迭代节奏。

在此之前，团队的版本与迭代合一，以一个月交付一个版本为目标。然而，在一个月时间窗口内，需求往往会频繁变更和增加，迫于交付压力，团队急于开始，在边分析需求边开发的过程中经常需要返工，造成效率降低和质量下降，反而事与愿违——导致计划延期。

在试点过程中，我们尝试将产品版本与迭代进行解耦管理，将小队调整为以双周为一个迭代进行交付。产品经理需要在至少一个迭代之前准备好下个迭代需要交付的需求的实现方案或分析文档。在每个迭代开始前几天，产品部落层的主要产品管理人员和小队长对已明确的需求进行评审和排期确认，并将其拆分为产品故事，将大事化小、虚事变实，以确保小队在本迭代开始时研发的内容相对清晰。

小队长在迭代开始前组织迭代计划会与小队全员进行进一步澄清并确认分工安排与工作量估算。此外，以每日站会对齐进度和识别风险，通过回顾会进行定期检视与反馈改进，逐步建立起团队的工作节奏。经过多个迭代的运转磨合，产品部落层和小队层面的活动越来越规范和高效，稳定的交付节奏减少了摩擦成本，提升了协作效率。而且在迭代时间盒稳定、小队人员相对固定的情况下，小队的迭代研发容量也逐步清晰，促进迭代计划更加合理，交付周期与质量更加可靠，团队运作进入良性运转。

图3：稳定有序的迭代节奏

在变革过程中，扩展需求体系的层级、在迭代前增加更多的需求评审环节活动等等，这些做法看似增加了管理复杂度，然而在整个产品研发过程中，前期适度的论证与评估大大提升了后续环节的效率，此时的慢即是快，更有利于在有限的资源约束下，尽早高质量地交付高价值的成果。

结语

金证在上述探索过程中，所有的管理对象和管理机制都利用工具实现了线上化，通过可视化促进协同的同时，针对不同管理层级的关注视角，聚合数据形成度量管理大屏，透明现状，持续改进。

接下来，我们将继续加强产品研发管理的规范化，并进一步探索更多场景的跨团队产品研发协同模式。用更优质的服务和更具竞争力的产品为客户赋能的同时，不断提升产品化管理能力和研发效能，为持续创新和领先发展夯实基础，以应对不断变化的市场挑战，为金证的未来发展注入持续的活力和动力。

END

感谢本文贡献者：

王海浪

尹学罡

以及金证的一众同仁

点分享

点收藏

点在看

点点赞