最近还是听到了一些好消息，几个组织都开始把PO、BA正式纳入组织的HR岗位序列，为业务和IT的融合运作奠定了一个好的基础。有了融合机制，如何真正让业务从目标规划，到落地达成，能流畅地跑起来呢？

让我们继续以上篇提到的零售信贷域为例，并且虚拟代入其领域产品经理角色——“马小跳”，来看看怎么做。

 

1. 团队背景

马小跳是该组织零售信贷团队的老员工了。零售信贷业务发展历史长，算是零售条线的核心业务，包含了小微企业经营贷、按揭贷、消费贷等多种复杂业务。马小跳从最开始的审查审批和贷后管理流程线上化、到消费贷业务平台、再到风控数字化等，参与了多个项目的建设。

在业务侧，马小跳对接的主要角色包含了总行这些不同贷款产品的业务设计、营销策略、贷后及风控管理和分行客户经理等角色，日常沟通对象超过20人。在融合机制启动后，新补充了对应于营销及渠道、审查审批和贷后管理、风险合规相关的业务需求角色，和小跳一起来统筹数字平台的规划和建设。

 

在IT侧，负责所有渠道、业务系统和风控平台的研发有100+人。在融合机制设计的过程中，依据团队拓扑，把原来面向系统的开发小组划分成面向数字产品的敏捷团队，以最小化团队在开发交付过程中的相互依赖，促进在研发落地时的流畅进行：

 

1. 面客的各种渠道（手机银行、信贷APP、微信、小程序、网点客户经理PAD等）、提供客户经营与服务线线上化能力的客户经理工作平台、创新消费贷业务，各自形成融合的业务流团队，通常直接面向客户，变化多并响应快；
2. 提供全渠道服务、支持各类贷款业务线上化处理中台，则属于平台团队，与业务流团队之间的协同原则为“一切皆服务”, 所有能力形成中台服务提供给各个业务流团队；相对于业务流团队，在灵活响应业务变化的同时，也需要尽量在各个不同的贷款业务中抽象出统一规则；
3. 数字风控、资信数据、客户标签等团队属于复杂子系统团队，与平台团队为协作关系，与业务流团队之间则相对独立；
4. 平台运营运维小组是新组建的，在整个领域的角度来落地数字化运营和运维工作，包括运营监控、运营数据分析、自动化运维服务等，属于团队拓扑中的赋能团队，为其他团队赋能。

马小跳负责整个领域数字平台的规划管理，因为PO还是人手不足，同时也兼任了客户经营与服务团队、运营增长&运维服务小组的PO。队伍成型了，怎么开干呢？

 

2. 当前从规划到落地中的三大断点

在当前，从业务目标制定再到平台研发，之间的流程大致像这样：通常业务部门，会在年初围绕业务目标和KPI进行务虚会，提出很多业务举措，然后提请业务部门立项，再进行方案细化，拍一个“IT工作量”，然后提前IT立项决策，决策完之后IT进行需求分析并交付上线。

 

马小跳发现，在当前这个过程中，运作不流畅导致业务和IT相互抱怨、响应慢质量不高、用户体验不好等，主要是因为三个断点：

1）断点一：在提请IT立项之前，平台建设需求并未被真正识别

业务部门务虚会产出的业务举措，其中一些是业务运作的策略设计、一些是新的业务类型、一些则是概念和想法。在进行项目方案细化提前IT立项之前，因为业务部门缺少对平台架构、各个IT系统的了解，往往导致数字化平台建设需求并未被真正识别。要识别出数字化平台建设需求，通常要能大致上回答诸如下面的问题：

• 背后实际上需要IT平台提供什么能力？
• 这些能力在当前的IT平台上：是完全没有、部分有还是可能已经有？
• 这些能力建设有先后依赖关系吗？
• 实现新的业务流程/策略/规则，涉及哪些IT系统？
• 是要新建一个应用，还是在某个已有应用上做扩展？
• 需要依赖哪些内部外部服务/数据？获取方式可行吗？
• 与合规条款仔细对过了吗，新的线上化逻辑和规则是否有漏洞？
• 为A业务做的改动、会影响到B和C业务吗？是否要统一、规范化处理、避免将来的数据孤岛？
• …

但在实际过程中，往往是把这些业务需求直接给到了IT部门。这是第一个断点。

2）断点二：业务和IT的优先级信息不对称，IT的响应与业务的期待错配

业务部门给提请IT立项的时候，是从业务维度拆分的，并且各个子业务会根据自己的需求来提出优先级；而IT在接到业务项目时，会大致地映射出是哪些IT系统。IT在考虑优先级的时候，会先考虑对应的系统/模块是否有研发资源、从研发实现的角度是否有依赖关系、且是否有IT架构需要调整、一些基础性的IT战略举措（如上云、国产化改造、统一主数据）是否需要先满足等。但因为业务需求和IT需求这复杂的像蜘蛛网样的对应关系，导致各自的优先级信息完全不对称，相互抱怨：

业务视角：“A需求都提了多半年了，IT还没开始做！B需求倒是做了，可是是个半截袖根本用不了啊！”

IT视角：“天天996，业务的需求永远做不完，还总是变！”

 

3）断点三：IT急赶交付时间线，必要的需求澄清和体验设计不到位

 

等业务和IT终于相互妥协、勉强就优先级达成一致的时候，离业务预期的上线时间也没剩多长了——在IT立项后，研发团队“囫囵吞枣”地理解了一些业务需求、基于业务在三四个月前提供的页面原型开始了实现、顾不得深挖用户问题、顾不得提炼一致的业务模型、顾不得改造原有代码统一重复逻辑、顾不得是否存在重复建设，匆匆忙忙地赶在预期的时间上线。业务在开始使用时，会遇到各种断点、卡点，以及一些莫名其妙的bug，于是提更多的运维问题并吐槽。IT团队此时又手忙脚乱应付各种运维问题，导致其他业务需求更无暇顾及，形成恶性循环。

 

3. 四个关键动作，让规划到落地流畅起来

在业务侧工作的2年多，马小跳对三个断点深有体会。要去消除这些断点，第一，必须让IT伙伴往前站，尽早在业务规划时就参与进来；第二，这个新的流程必须尽可能轻，不能让业务和IT伙伴觉得是额外又增加了很多的工作环节和负荷；第三，要有明确、清晰的动作及责任人定义，以保证落实。

 

基于EDGE从业务规划到落地的轻量管理框架，马小跳制定了如下从规划到落地的端到端工作流程：

 

• 第一步：业务规划与之前业务自己务虚会不同，熟悉IT现状的各团队PO都会参与进来，共同围绕目标来进行规划，识别能够有效支撑业务目标达成的平台建设专题。
• 第二步：优先级决策业务和IT协同来对齐专题的目标成效、与业务目标的支撑关系，以此为依据评估其优先级和依赖关系，明确各专题的主办团队，形成业务演进路线。
• 第三步：专题方案分析细化针对近期高优先级专题方案，各主办小队PO和BA来分析用户场景和问题、设计交互原型和平台架构及技术方案，识别拆分出专题范围内的所有功能和非功能需求，制定出专题的迭代交付计划。
• 第四步：专题迭代交付各产品小队，把自己负责主办的专题迭代需求和自己负责产品的零星优化、日常运维需求统一归口，形成交付Backlog按照迭代节奏进行研发上线
• 第五步：持续运营在运营小组的协助下，业务PO和IT完成响应的营销推广、内容运营等举措，跟踪并监控平台运营成效
• 第六步：定期成效回检如每个季度回顾、分析过去季度的目标成效达成情况、各专题进展与预期成效的差距、必要时做出调整。

最关键的，当属前三步和成效回检。马小跳明确了如下四个关键动作，并在团队开始落地实施。