天真的答案

为了让业务敏捷起来，需要面向业务建立融合的、跨职能的团队， 使得业务和IT完全一致目标，这几乎已成共识。但在实际落地中， 即便已经开始敏捷转型超过5年的组织， 都回头来让我们解决这样的问题：“如何让业务和IT一致目标?PO和BA到底哪边来出?”刚开始被问到时，我特别上头：这问题不是早都回答过了吗?用统一的价值三角模型统一定目标和MoS(成效度量)， PO和BA不就是哪边有胜任的人、哪边出就行了吗?

时至今日，才明白自己当时太过天真。这是一个要抓破脑袋的问答题啊，怎么能直接填空。

从组织架构说起

通常来说，我们接触到的转型组织，有三种架构模式：

模式一：业务主导型，IT部门嵌入到各个业务公司/单元中。这多见于一些多产业的集团公司。集团组织往往有个很薄的科技部，只负责集团级的IT规范、 架构流程，每个业务板块的子公司会自设IT部门， 有的转型比较快的板块比如地产，会有相对成熟、 几百人的IT团队，数字化平台的建设、 IT项目的实施往往是子公司自有IT团队来完成。模式二：科技中心型，集团公司有统一的科技中心， 在数字化转型落地中起主导作用， 对每个业务会设定相对应的研发团队， 或者派驻核心成员到业务部门。大多数的股份制商业银行， 比如招行、中信等都是这种模式。

模式三：科技子公司，把科技部分单成立为子公司， 业务数字化转型主要向科技子公司采购，也可以外采。这三种模式本质不同，在于转型项目的出资预算、转型成本计入、 成效评价的不同，也各有优缺点。

业务主导型：预算出资和成本计入、成效评价的主体都是业务部门， 最大的优点是对业务响应快;但缺点是会在各个业务之间造成孤岛、 难打通，而且IT始终是从属地位、没能发挥出最大效力。

科技中心型：预算出资是集团的、成本计入主要是IT的、 成效评价归属于业务。最大的优点是科技中长期战略部署更易落地， 比如上云;但缺点是，这种责权利的不一致， 导致业务和IT之间形成隔阂。

科技子公司：项目预算出资、 成本计入和成效评价的主题都是子公司，有更大的自主权， 从长远来说是好的;但短期内无疑对科技子公司提出了更高的要求， 科技和业务变成了两个公司之间的协同，业务响应上也未必能很快。

业务和IT目标不一致，最突出的就出现在“科技中心型”组织中。

看起来很美的跨职能团队

在面对这种“科技中心型”组织时，转型的第一步便是设计“融合的跨职能团队”。以银行的零售条线为例，每个独立的业务领域如财富管理、 零售信贷等，在业务领域设置融合业务和IT的管理角色， 形成领域铁三角领导团队，把相对长期、 主要负责相关领域工作的研发小组聚合在一起， 作为融合团队的核心成员。

在每个领域团队中，依据团队拓扑划分成若干个跨职能的敏捷产品团队， 每个产品团队也是设置业务、 产品和技术构成的铁三角作为团队牵头人，配置必备的研发人员， 再按需设置体验设计、测试、数据分析、DevOps、 运营运维等人员。

与团队配套，也会设计一套从领域规划到敏捷产品迭代落地的运作流程：

这个方案看起来很美。但到落地的时候，问题来了：

 

要让这个团队能正常运作，需要设置：1个全职领域PO、 1个全职领域BA、6个全职团队PO、5个全职团队BA、 3个兼职团队BA，共13个全职角色、3个兼职角色。

业务：我们业务已经卷得飞起，出2个兼职的PO差不多， 再多真没人了。

IT：我们如果出了这么多PO和BA，投入研发的人肯定就少了、 导致研发考核指标降低(如功能点产出)怎么办?即使帮助业务达成成效，到时也不算我IT的功劳，那我何苦呢?虽然“往前站、配合业务"是政治正确，表面表示配合， 但内心动机却明显不足。

总之就是：业务和IT两边都出不了人;临时需要一段的话我们尽量凑一凑，时间长了不行...

到此刻，作为转型顾问的你，是不是也恍然大悟， 很多平时遇到的问题，本质上可能都与此有关：

“业务和IT的需求共创会开不起来”

“需求共创会开了，但需求文档没人整理;业务觉得应该IT做、 IT觉得应该业务做”

“IT抱怨：业务不理解系统逻辑，导致需求遗漏或需求重复;业务需求理得太粗，没法开始开发”

“业务抱怨：我们一个人对接好多个IT团队， 还有很多业务本身的策略方案工作需要做， 每个需求都理得很细根本没时间啊...”

“业务抱怨：我们想探讨方案设计的时候IT没空， 总是拉他们也是挺费劲的，一起讨论的时候效率也不高”

“业务抱怨：之前有个BA帮忙挺好的，但是兼的， 做了一段时间好像又去做开发了...”

“业务和IT：之前教练在，带着做了这个流程挺顺的， 后来靠我们自己，大家都是兼着角色做，一忙就都顾不上了， 所以现在看这些实践都没做起来...”

“...”

融合所需的资源投入不被认可、再美的团队设计和工作流程， 没有人来落地开展，就等于空中楼阁。

4

解决核心矛盾：

明确的融合角色资源配置、

一致的出资预算和成效评价

01 设置跨业务和IT的决策组织，来统筹业务和IT决策

在科技中心型组织中，即便是业务部门一把手， 能调动的也仅是业务部门资源， 业务的优势在于对业务市场和客户的把握、 了解如何设计业务策略和方案，但对于IT资源该如何配置却并不清楚;类似地，科技负责人也是仅能调动IT资源， 优势在于IT整体平台/系统架构、角色配置， 但如何根据业务设计和动态变化来实时调整决策， 需要业务和IT决策者紧密协同，动态规划、动态决策、动态调配。这个是转型能有效落地的前提。如在一些银行中，在条线设置“ 转型委员会”;在另外一些组织中，则是根据EDGE方法， 由核心决策者构成价值管理团队VRT，统筹重点转型项目落地管理 ，定期回检并进行动态资源调配。

融合业务和IT的决策组织：条线转型委员会

 

 

融合业务和IT的价值管理团队：VRT

 

 

02 在业务条线转型规划时， 预先做好融合角色配置计划

作为转型推动者，需要更早地意识到， 在转型落地过程中融合角色不可或缺的作用，提早对如业务领域PO、业务领域BA、 兼顾业务和IT的架构师、 各个产品团队PO和BA等融合角色资源做出规划安排：总共需要专职/兼职各多少人、 哪些空缺由内部转岗、哪些从外部补充/什么时间补充、 准入和退出机制如何、激励机制如何。

这里建议IT部门转变思维、主动往前站， 主动多让一些资深的开发、测试伙伴走向前，转岗担任PO或BA：

 

团队中原来的X个资深开发转岗专职做PO/BA，当业务目标- 用户需求-IT需求这个过程运转更加高效时，一定会减少返工、 让IT更高效;

越来越收紧的IT投资，研发团队势必会面临灵魂拷问——“ 投了这么大团队、这么长时间，究竟产生了什么价值?”， 此时作为研发团队不可能用“交付了多少功能点、bug率多少等” 这些指标来回答，不如早点主动去参与定义共同的、 面向客户的价值成效。

03 一致的目标和成效评价

 

从根本上解决动机问题，需要匹配责(预算/成本)权(动态调配)利(成效评价)。

 

首先，在资源预算上，由融合业务和IT的条线局EVE组织来规划资源预算投入;每个条线的各个融合领域，建立独立的成本代码，相应的融合角色PO和BA等的投入都在这个成本代码跟踪;

在每个阶段定期进行成效回检后，条线决策组可以根据回检结果动态调配各个融合领域的资源;除核心成员外，如果增加投入则从条线资源池中补充;如果减少或停止投入则释放资源回资源池;

在各个领域做规划时，由领域的业务和IT负责人组成的领导团队牵头，综合客户、业务、生态伙伴一起设定阶段目标和价值成效指标，并作为团队的OKR;在定期成效评价时，以OKR达成情况(结果)、结合上一周期中的学习成长/假设验证和问题发现(成长)、以及融合实践的落地情况(行为)做评价，确保整个团队目标和动机一致。

一些领域团队如果觉得，一致成效指标和OKR暂时做不到，也可以用指标互换作为过渡，促进融合。

注：关于责权利匹配和不同考核方式的选择，这里有一篇有精彩论述，可以作为延伸参考。

 

5

小结

转型过程中，流程的落地，本质还在于管理机制。新建管理机制，需要组织领导者的决心、动力和韧劲，过程可能会一波三折。在一些日常转型工作中，作为咨询顾问，有的时候可能太陷入推动执行，往往忽略了机制。但没抓住机制，往往舍本琢末、转型收效甚微，对于组织内的转型推动者也是如此。变革不易，愿组织内外的转型推动者齐心协力，早日让业务乘上敏捷的快车。