首页  ·  知识 ·  IT治理
从业务规划到IT落地,如何才能流畅运作?
Thoughtworks中国  知乎专栏  IT规划  编辑:不死鸟逆   图片来源:网络
业务和IT的融合,其实不仅仅是因为要协作,而是数字化技术改变了我们运营业务的方式。当IT建设不再是持续把流程从线下搬到线上时,用数字化思维进行好业务治理不是简单的事情。

1. 团队背景

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

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

image.png

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

image.png

  1. 面客的各种渠道(手机银行、信贷APP、微信、小程序、网点客户经理PAD等)、提供客户经营与服务线线上化能力的客户经理工作平台、创新消费贷业务,各自形成融合的业务流团队,通常直接面向客户,变化多并响应快;

  2. 提供全渠道服务、支持各类贷款业务线上化处理中台,则属于平台团队,与业务流团队之间的协同原则为“一切皆服务”, 所有能力形成中台服务提供给各个业务流团队;相对于业务流团队,在灵活响应业务变化的同时,也需要尽量在各个不同的贷款业务中抽象出统一规则;

  3. 数字风控、资信数据、客户标签等团队属于复杂子系统团队,与平台团队为协作关系,与业务流团队之间则相对独立;

  4. 平台运营运维小组是新组建的,在整个领域的角度来落地数字化运营和运维工作,包括运营监控、运营数据分析、自动化运维服务等,属于团队拓扑中的赋能团队,为其他团队赋能。

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


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

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

image.png

马小跳发现,在当前这个过程中,运作不流畅导致业务和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,业务的需求永远做不完,还总是变!”

image.png

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

image.png

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

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

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

image.png

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

image.png

  • 第一步:业务规划

    • 与之前业务自己务虚会不同,熟悉IT现状的各团队PO都会参与进来,共同围绕目标来进行规划,识别能够有效支撑业务目标达成的平台建设专题。

  • 第二步:优先级决策

    • 业务和IT协同来对齐专题的目标成效、与业务目标的支撑关系,以此为依据评估其优先级和依赖关系,明确各专题的主办团队,形成业务演进路线。

  • 第三步:专题方案分析细化

    • 针对近期高优先级专题方案,各主办小队PO和BA来分析用户场景和问题、设计交互原型和平台架构及技术方案,识别拆分出专题范围内的所有功能和非功能需求,制定出专题的迭代交付计划。

  • 第四步:专题迭代交付

    • 各产品小队,把自己负责主办的专题迭代需求和自己负责产品的零星优化、日常运维需求统一归口,形成交付Backlog

    • 按照迭代节奏进行研发上线

  • 第五步:持续运营

    • 在运营小组的协助下,业务PO和IT完成响应的营销推广、内容运营等举措,跟踪并监控平台运营成效

  • 第六步:定期成效回检

    • 如每个季度回顾、分析过去季度的目标成效达成情况、各专题进展与预期成效的差距、必要时做出调整。

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

1)关键动作1:季度业务规划

image.png

动作目标:

  • 综合业务和IT的视角,探索识别出支撑业务目标达成的平台建设专题

动作产出:

  • 支撑业务目标达成、且经过初步可行性验证的平台建设专题举措

  • 每个专题,有粗颗粒度的方案,说明方案关键要点及支撑目标达成的逻辑

动作输入:

  • 顶层业务战略和目标

  • 业务市场洞察输入

  • 上周期成效回顾结论

负责人:

  • 各融合产品团队PO

参与人:

  • 业务负责人/业务专家(必须)

  • 各融合产品团队BA(必须)

  • 用户代表、设计师、数据分析等(可选)

完成时间:

  • 产出需在季度专题优先级决策工作坊一周前完成

产出质量:

  • 过程和最终产出材料在整个领域进行公开晾晒,以确保PO不是临时抱佛脚、随意写几个凑数

通过这一关键动作,确保平台建设需求被提前识别出来、且避免立项后发现技术不可行导致的磕绊。

2)关键动作2:季度专题优先级决策

image.png

动作目标:

  • 由业务和IT决策人构成的VRT团队来统一优先级评估,做出专题决策

动作产出:

  • 业务领域的精益价值树

  • 高优先级的专题待办清单

  • 业务领域的演进路线

动作输入:

  • 各PO牵头进行规划识别出的专题

负责人:

  • 领域产品经理

参与人:

  • 领域VRT成员(必须)

  • 核心业务干系人(可选)

  • 各团队BA(可选)

  • 领域其他相关骨干,如运营、数据分析、设计师、资深技术等(可选)

完成时间:

  • 产出需在每个季度开始后,第二周内完成

  • 建议时长~2天

产出质量:

  • 精益价值树、高价值专题清单和演进路线会通过数字工具平台对领域全员进行宣导并透明展示

业务和IT的优先级不对称,还来自于业务只关注业务指标、而IT关注效能和质量指标。在进行优先级评估时,基于价值三角,聚焦用户价值并用延迟成本方式来评估优先级。

另外结合领域特点,预先对价值成效实现和IT技术战略分类来确定投资比例分配,对相应的业务和技术类专题分别来排优先级,也能促进业务和IT结合短期和远期目标来明确优先级。

这些方式结合,可以有效地消除业务和IT的优先级错配。

image.png

3)关键动作3:专题分析工作坊

image.png

动作目标:

  • 将专题需求进行细化拆解,明确专题方案要点和需求清单,确保拆解需求对齐专题目标成效

  • 如果专题需要多个产品团队协作完成,明确专题拆解出的用户故事是由哪个团队完成,并在专题用户故事全景中注明依赖关系和由哪个团队完成

动作产出:

  • 专题整体方案和架构(涉及到的IT系统、应用、及交互关系)

  • 用户交互原型

  • 关键技术实现方案

  • 需求全景-用户故事地图

  • 依赖清单

  • 专题迭代交付计划

动作输入:

  • 专题画布(对应于优先级决策后的高优先级且自己团队作为主办的专题)

  • 用户及业务调研旅程和痛点分析等

负责人:

  • 专题主办团队的PO

参与人:

  • 主办团队BA(必须)

  • 用户代表、数据分析、设计师、运营、技术和测试等(可选)

完成时间:

  • 产出需在第一个月内

  • 建议时长~3天左右

产出质量:

  • 过程和最终产出材料在整个领域进行公开晾晒,并由领域产品经理不定期抽查

动作提示:

  • 专题大小建议在不超过 团队人数*2 人月范围之内;比如一个加上PO、开发和测试等的10人团队,建议专题粒度在20人月以内;这样一来小不快跑、专题方案不至于过于复杂,二来可以更早获取成效反馈,及时迭代调整。

4)关键动作4:每周专题实时进展和成效更新

image.png

动作目标:

  • 及时识别交付风险、障碍和问题

动作产出:

  • 迭代进展演示,风险、障碍和问题清单及应对措施和状态

动作输入:

  • 领域成效指标、各专题成效指标、其他过程运营数据跟踪及统计

  • 需求看板中各专题关联故事卡的实时状态及统计

负责人:

  • 领域产品经理

参与人:

  • 各团队PO

完成时间:

  • 每周固定时间站会,建议15分钟左右

  • 建议每双周在进展更新时融入一次进展演示(Showcase),建议1小时

以这四个关键动作为抓手,以前的三单断点得到了有效缝合;从业务规划到IT落地、也显得井然有序,从领导到业务和IT的伙伴,都得到了不错的反馈。


4. 小结

业务和IT的融合,其实不仅仅是因为要协作,而是数字化技术改变了我们运营业务的方式。当IT建设不再是持续把流程从线下搬到线上时,用数字化思维进行好业务治理不是简单的事情。作为这样一个业务的核心推动者,在这繁乱的事务中,需要能把握核心原则、掌握管理抓手,才能拨云见日。


注:文中案例和角色均为虚构。


本文作者:Thoughtworks中国 来源:知乎专栏
CIO之家 www.ciozj.com 微信公众号:imciow
   
免责声明:本站转载此文章旨在分享信息,不代表对其内容的完全认同。文章来源已尽可能注明,若涉及版权问题,请及时与我们联系,我们将积极配合处理。同时,我们无法对文章内容的真实性、准确性及完整性进行完全保证,对于因文章内容而产生的任何后果,本账号不承担法律责任。转载仅出于传播目的,读者应自行对内容进行核实与判断。请谨慎参考文章信息,一切责任由读者自行承担。
延伸阅读