腾讯产品方法漫谈银行产品设计

本篇开始，尝试与业内同仁探讨银行产品设计相关内容。笔者从业经历主要在IT，但曾长期为银行产品团队提供开发服务，并曾有幸跟随非常优秀的业务领导和产品同事下业务一线拜访客户，直接参与了多类产品的方案设计，期间所受教益匪浅。后又曾在腾讯有过一段产品工作经历，并深受腾讯8分钟产品课和腾讯产品法的启发，腾讯对产品的理解，及形成的各种理念、方法论、案例等等，对指导商业银行产品体系构建、产品设计，也都很有参考意义。相关经历，值得进行一些总结，不妥之处，请读者置之莞尔即可。

产品为王

银行产品的内涵与外延

虽然在系统建设中，我们总是想办法去建构“产品工厂”或“产品中心”，但实际上，即使是对银行产品下定义都是非常困难的。与手机、电脑等显而易见的有物质实体承载的产品不同，商业银行的“产品”，多数时候实际上是一揽子为客户提供的服务的组合，而服务通常极其复杂。《设计心理学》一书中，作者诺曼不无吐槽地指出，“我们最常见的服务，驾照、护照签发、缴纳所得税…都有庞大的官僚主义规章制度，一大批机构内部的人，经常还有公司里面都会有的很多个部门，声称负责所有非常规性问题。….所有那些在幕后的东西–那些神秘地运作着，形成顺利、高效或者令人困惑的运作效果的东西，被称为’后台’….”

循着诺曼对服务的解释，银行产品的定义从狭义上可以做如下概括：“银行产品，是银行基于特定金融需求，面向特定客户群体（个人或企业），设计并提供的、具有明确功能、使用规则、定价机制和服务流程的金融服务方案。它本质上是银行与客户之间围绕资金流动、风险管理、价值增值等核心金融活动所建立的契约化服务载体”。在这一定义中覆盖的产品包括两类，一种是面向规模化长尾客户提供的标准化产品（比如微粒贷、余额宝）；另一种是面向特定行业，甚至个别客户定制的，但又具备可复制、推广的金融服务解决方案/产品，比如面向特定行业，甚至特定核心企业的定制化现金管理、分级账簿、供应链金融解决方案等。

面向客户的银行产品可以做以上定义，但因前、中、后台的存在，银行产品常常在内部管理及部门协同过程中造成困扰，一款产品，你是站在客户视角，还是中台业务，或是后台运营、财务视角，看到的情况是不一样的。银行中对客户来说是后台的部分对业务管理部门来说就是前台，而对业务管理部门来说是后台的部分，对运营或者财务来说，又是前台，每个角色都有自己的前台和后台。举个例子，以最近国内新能源汽车供应商应收账款账期问题为例，在此案例中，供应商可以向商业银行转让对整车厂的应收账款债权而获得现金流。在这个业务中，供应商，即银行的企业客户感受到的产品是“应收账款债权转让融资”，而在银行中台–一般是负责贸易融资管理的中台部门（如交易银行部或贸易金融部、企业金融部之类的），这个产品一般被定义成“保理融资”（并细化成有追索权、无追索权、需要进行债权转让确权的明保理，或者无需确权的按保理等等），而到了财务部门编制会计科目时，这个产品可能就变成了“前收息模式的预支价金”，最后在IT系统中，这本质上与一笔预收息的贷款没有任何区别…

从上述例子中不难看出，正如诺曼所言，“成功的产品必须合并内部和外部成分的所有不同层面，协调地支持所有可见和隐藏的服务和操作。产品存在于一个复杂的交互网络中….”

为什么需要重视产品

其一，做好产品论证与分析，有利于资源的有效投入，获得正向回报。有过银行系统的开发经验的工程师们或许都有过这样的经历：一个被催的十万火急，必须限期完成的项目或者需求，在项目组人员加班加点、蓬头垢面地忙活一圈，上完线后过几个月一统计：新增客户数0，新增收入0，业务价值0。随之而来的解释通常是这样：业务效果未达预期，是因为这是一次“快速试错”，潜台词则是“因为是试错，所以没有业务效果是正常的”。只不过，如此试错的代价是银行的宝贵预算，以及其他更有价值的项目或产品被影响，还有倒霉的程序猿们的加班加点。

当然，这里面，有一部分的确是面对不确定的市场，不得不付出的试错成本（毕竟成功很大程度上是概率事件），又或者是为了营销客户，必须付出的成本，即某个产品或解决方案，你有，客户不一定选择你，但如果你没有，客户连机会都不会给你。有问题的是不经研究和论证，拍脑袋决策、仓促开干的项目和产品，提出者将开发压力交给IT，将客户经营压给分支行，将业务效果交给天意。

其二，银行产品不仅仅是功能工具，更是银行定位战略的载体和品牌形象的关键塑造者，通过产品建立的印象有利于建立正面的客户心智。特劳特在《定位》一书中，提出企业成功的关键，就是“如何在潜在顾客的心智中占据一个有利位置”，而在“信息传播过度的社会里，传播简化的信息是唯一有效的方法。” 产品便是那个能够简化信息传播的关键抓手。“微粒贷”的成功，不仅仅是为webank的资产规模、利润规模作出重要贡献，其形成的客户对微众银行提供的服务便捷、科技、专业、普惠的印象，也被投射到微业贷、微众银行智能存款等产品中，奠定了微众银行在客户心智中的整体印象。

其三，银行产品不仅是满足需求的工具，更是低成本、高效率获客的核心引擎。原因有三：1）、一款具有强吸引力的“钩子”产品，本身就是最低成本的获客广告。2）、产品体验（流畅度、功能满足度、收益/利率竞争力）是用户是否留下的关键。糟糕的产品体验会让辛苦营销来的客户瞬间流失。3）、产品内设计交叉销售路径（如理财用户看到专属贷款优惠、贷款客户引导开通关联还款账户/信用卡）和用户分层运营机制（如VIP等级体系对应专属产品/服务），可以提高客单价，让存量用户产生更多价值。

产品设计需要关注的高阶问题

大多数机构的没有华为那种可以建立IPD（集成产品管理）的能力，也没有腾讯那种刻在基因里的产品文化。有什么办法能够一定程度上做到“谋定而后动”呢。这便是通过一定的流程和机制设计（比如产品审批、产品委员会审核），确保在一个需求或一款产品开始建设前，一定要将如下问题回答清楚，即经典的5W1H分析法：

WHO：产品为谁设计？目标客户是谁？目标客群有什么特点？购买者和使用者是同一个吗？目标客群有多大规模？最乐观与最悲观的情况下，分别的转化率与留存率预计有多少？

WHY：我们的产品有什么差异化竞争优势？客户为什么选择我们？产品有哪些竞品？有可替代产品吗？（比如信用卡与花呗）

WHEN：用户什么时候使用我们的产品？多久用一次？产品有政策窗口期吗？（商业银行产品必须非常关注的，比如票据市场、外汇市场、债券市场的阶段性机会）产品有市场窗口期吗？（比如ETC扣费的短暂窗口期）

WHERE：产品有可能完全线上化？用手机用方便还是电脑用方便？（这在企业银行业务中，尤其是中大型企业中特别需要关注，因为企业员工坐班原因，网银比手机银行更受青睐，再大的企业，则需要银企直连，因为企业员工只想在自己的ERP等内部系统上操作）可以使用H5进行场景投放吗？

WHAT：产品的具体形式，或载体是什么？产品要做成怎么样？产品的定价如何？

HOW：用户怎么交互？交互设计涉及的概念模型、示意符号、功能入口布置等等。（在互联网想方设法投入巨资仅仅是为了客户少点一下手机的当下，商业银行的很多设计还是不惮于打扰客户，有些交互的设计简直就是为了刻意给客户制造麻烦….）

在”5W1H分析法”之外，还要考虑产品建设的“时间成本”、“资金成本”、“风险成本”与“行动成本”等等。一份需求也好，一个产品也罢，事前做好分析论证：判断要不要做，值不值得做，做完了怎么获客，怎么演进，比知道产品和需求怎么去做更重要。如果说IT的能力养成是为了能够“正确的做事”，那么，产品论证分析则指向一个更重要的命题–如何尽可能保证“做正确的事”。一件事不值得做的事，自然就不值得做好。

产品团队责任重大

在传统商业银行的组织架构模式下，以前、中、后台条块化组织的一个机构中，要确保“做正确的事”殊非易事，如果组织不能实现有效的协同，就会出现好像个个部门都在认真履职，而最后什么事都做不成的情况。而要做好这些，除了董事会及经营管理层的决策部署外，在执行层面，需要有人来完成“市场分析、用户研究、收益成本分析”，并对“产品定位、产品设计、产品推出时机、产品营销方案”等进行说明，最后还要想办法协同相关部门，取得配合部门的支持。总之，要向前能够连接起分支行，向后能够协调好风险、财务、法规、营运、IT，为达成一个共同的目标而努力。这在商业银行，从来都是一个不易解决的问题。

在商业银行的机构设置中，处于“中台”位置的总行业务主管部门，比如零售的消费金融、财富管理、汽车金融、信用卡，对公的交易银行、贸易融资、国际业务、商业汇票专营等部门，以及具有全线上产品设计、运营职责的网络金融部门，专注SME经营的小微或普惠金融部门，天然具备深耕本领域业务，知晓领域业务特性，向前可连接并向分支行下达经营指标，横向可以拉通兄弟部门，实现公私联动、存贷联动产品设计，向后可以拉通风险、财务、法规、财务、IT等的能力，作为利润创造中心的特点，这些部门也最有能力和动力通过整合资源达成业务目的。统筹产品设计与经营，中台产品部门责任重大、使命光荣。

要完成如此重要的工作，对产品经理的能力要求自然被显著地放大了。与风险、IT、法律、财务等仅需要专注于某一领域的专业技能不同。一个好的产品经理，除了需要对本领域的银行业务有深入且独到的理解外，通常还需要具备一定的法律基础知识，比如知道《民法典》中关于合同、担保、物权的法律条款。如果产品经理正好对会计知识有所了解，那么在跟财务部门争取更优惠的FTP定价，在思考如何通过非融资性保证业务降低RWA占用方面，就会占有优势；产品经理如果有IT背景，知道一个功能大致的实施难度与实施周期，就能避免“这个需求很简单、怎么实现我不管”的冲突；如果产品经理对设计有基本的了解，就能在产品设计中很好地完成关于等待、推荐、反馈、提示及概念模型的设计；如果产品经理对宏观经济学、货币银行学、监管法规有好的了解，那么就更能敏锐的发现监管政策窗口与市场机会。最后，产品经理还需要有天然的直觉，对人性的洞察，以及卓越的沟通能力。

“With great power comes great responsibility”，这也正是乔布斯、马斯克、马化腾、雷军、余承东、张晓龙等一众大佬，都被认为是大产品经理的原因。

产品思维

产品设计者面临的困境

在“传统”商业银行中，产品部门、产品经理要做成一件事，需要有效协调前、中、后台部门的支持，需要识别市场机会，又要面对监管约束，常会面临三重困境。一是专业深井困境。在商业银行中，一款产品通常涉及的风险、法规、财务、科技等部门，各有各的专业语言，比如风险中的PD、LGD、EAD、M、RAROC、EVA、FPD、DPD、AUC、KS等；法规中关于要约、承诺、无因性、善意取得、质权、债权、留置权、一般保证、连带责任等；财务中的各种资产、负债、收入、支出、费用、未分配利润、表外、FTP定价、利率重定价曲线等等。IT则自不必说，从应用架构到数据模型，知识体系纷繁芜杂。也因此，产品也成为“翻译损耗”的重灾区。所谓对“跨界复合型人才”需求最高的领域，产品类岗位首当其冲。二是创新悖论困境。商业银行因为其经营特点的特殊性及对国民经济的特殊重要性，受到央行、金融管理局等的强监管约束，以巴塞尔协议“资本约束 – 监管干预 – 市场制衡” 为内核的三维监管体系需要商业银行的“创新”活动必须在规定的框架内进行。而与此同时，一些泛金融机构，如商业保理公司、金融租赁、消费金融公司、网贷公司、第三方支付公司等，其监管约束（从监管主体到监管细则）与商业银行不可同日而语。部分机构因此得以进行的“擦边球”创新，对商业银行构成极大的竞争压力，此其一；其二，以互联网，尤其是头部互联网公司为代表的，金融产品获客、交互体验创新，则对商业银行形成了降维打击。因此，对商业银行而言，一方面需要“守正”，一方面又需要“创新”。三是价值量化困境。财务可以通过利润表直接记录收入、支出和利润，风险可以通过五级资产分类和不良率计量损失，IT可以通过刚性费用衡量投入，而产品价值却往往与市场、营销、内部的资源投入及协同等众多因素相关，因此难以剥离归因。产品部门的绩效计量，在缺乏产品基因的机构，向来都不容易。《人人都是产品经理》一书中提出：“产品是解决问题的载体”。而银行问题的复杂性在于——它既是数学问题（定价模型、资本计量）、工程问题（系统架构、流程耦合）、行为问题（用户心理、组织协同），更是哲学问题（风险与效率的永恒博弈）。

五大产品思维

在2015年“互联网+”时代前后，商业银行曾掀起一股向互联网学习的热潮。彼时，”互联网的13种思维”，”互联网独孤九剑”等曾被商业银行奉为圭臬。其中的内容鱼龙混杂，不少指向的不是踏踏实实的价值创造，而更像某种方式的割韭菜指南。当然，其中也不乏值得学习借鉴的，但那并不仅仅是互联网特有，而是各行各业的普遍性真理，也即《腾讯产品法》中提到的五项思维模式，分别是：第一性原理思维、系统性思维、相对思维、抽象思维和演进式思维。在“技术可购买、流程可复制、客群需要争夺”，金融产品同质化加剧的今天，产品设计者这这些方面的思维认知能力，对构建商业银行全局或局部竞争优势十分关键。第一性原理思维。第一性原理思维要求只采用最基本的事实作为依据，在传统的产品设计的前提下重点观察它的前提条件是否发生了变化、是否有优化的空间、是否还有更优的解决办法。通过不断追问的方式，剥离所有表象后，识别产品解决的最原始需求是什么。第一性原理最需要挑战的，是对商业银行“传统”做法的挑战–即“祖宗之法可不可变”的灵魂追问。以笔者曾经历过的一个项目为例，因为历史上票据贴现账务在核心的贷款模块记录的原因，即使在投产了商业汇票系统后，这一“传统”仍然被保留，因而导致客户每次在申请票据贴现时，运营部门都需要先为客户开立一个贴现账号。但实际上，贷款业务首先从本质上就不需要所谓的“账号”，而只需要编列“借据–IOU”，其次，贴现业务与贴现票据强相关，其明细账在票据系统分录，科目账在总账系统反映即可。基于这一原理性分析，后来我们在方案实施过程中，就直接取消了贴现账号，既减少了系统间交互（信贷、票据与核心之间的多次交互），又简化了作业流程。

系统性思维。银行产品的本质是多重复杂系统的耦合体，其跨度涉及用户行为系统（心理学、社会行为学范畴）、金融基础设施系统（如支付清算体系）、监管政策系统（动态变化的合规边界）与商业价值系统（FTP定价、RWA占用、客户LTV等）。以一款高利率存款产品的发行为例，在系统工程视角下，除了存款部门的考虑外，还需要如下的考虑：从资产负债角度，会否在未来导致资产负债期限错配？从流动性角度，会否在产品到期后因赎回导致流动性风险？会否导致全行FTP定价失效？对全行利润的侵蚀度如何？是否会引致监管处罚？总而言之，传统的线性思维模式–要揽存就提高利率，已经越来越需要让位于系统性的思维，即将产品置于生态网络中做整体性思考。相对思维。相对性思维是摒弃掉非黑即白的二元对立思想，不轻易贴标签，不轻易下论断，看到事物之间的内在关系和动态变化，以此来指导产品设计。相对性思维在银行产品设计中的核心运用，是需要把握银行产品的”最优解”只存在于具体约束条件下，在约束条件下需求“整体收益、风险成本、监管合规”的有机统一。监管约束下的相对思维运用，反而会成为机构获得差异化竞争优势的突破口。比如，“宝”类产品在表面上会导致商业银行存款搬家，但如果能够获得货币基金的代付资格，则通过基金公司的托管，活期存款的“流失”则可以得到超额补充，产品竞争力带来的流动资金池（当日购买与赎回的差额），事实上对活期存款的损失可能会非常小，而商业银行则能获得资金托管带来的存款、客户粘性、费用收入等一揽子收益。
抽象思维。抽象思维通常与系统性思维相辅相成，是指在产品设计及实施过程中，需要提取不同事物性质相同的内核;通过功能与能力要素的抽象，支持产品的快速组装。这一思维，不仅是产品经理的契约，更应是IT架构师们的圣经，在分布式微服务架构中经常提及的共享服务抽象，以及前些年被推崇备至的“中台”，本质上都是在产品或者系统实现过程中，需要进行充分抽象，在不同产品、不同功能间寻求最大公约数，将公约数沉淀为稳定的，后续可复用的产品功能。比如在融资业务中，对押品管理、额度管理、核算账务的共性抽象和服务共享，可以实现对消费信贷、汽车金融、小微信贷、对公信贷的普遍支持，避免重复造轮子。
演进思维。演进思维是商业银行在面对不确定的宏观经济环境、快速进步的技术条件、不断变化的产业环境等情况下，结合用户认知和竞争对手情况，依靠快速试错、快速选代、用最小可行性验证产品假设的一种产品思维。这种思维模式下，要求产品经理对产品核心功能有高度的提炼能力，技术能力上能够支持AB测试与灰度流量验证等。以互联网贷款为例，在演进思维指导下，对风险控制指标的预测、验证、反馈、调整需要反复不断地进行，通过A/B测试，选择最优解。

局中人的破壁之道

银行产品创新的最大障碍，往往不是技术瓶颈或资源限制，而是对问题本身的错误锚定。爱因斯坦说，“我们不能用制造问题的同一思维水平来解决问题”。当我们能够新的思维模式重新审视产品，那些曾经的困境，就可能显露出隐藏的破局点。但“you can’t be what you can’t see”，思维模式的建立依赖于认知，而认知的建立需要大量的训练，对身处局中的我们（产品经理、架构师、开发工程师）而言，或者可以在如下方面进行努力：一是尽可能建立跨学科的知识体系。除自身岗位的专业技能外，通过在金融工程、法律法规（比如民法典、人民银行发布的各项法规）、用户体验（交互设计）、技术架构等方面，尽可能地进行积累，形成跨学科的知识体系。突破性创新通常来自跨学科的灵感启发，一专多能不但有利于跨越专业深井，还有可能为产品创新提供火花。二是基于“压力测试”的思维训练。在产品设计或需求分析过程中，通过“三问”不断强化思维练习。包括：本质之问–今天我们讨论的“账户分级”需求，用户想解决的原始问题是什么？系统之问–这个功能上线，关联到哪些系统，有更简单的设计方案吗？抽象之问–这个功能有现成的功能可以复用吗？新建功能能否沉淀为标准组件？三是对成功经验和失败教训进行复盘与解剖。“案例教学”是最直观、最有体感的认知体验。通过问题复盘过程中的五步法：问题定位–根因分析–思维盲区–制度改进–能力沉淀，建立制度化的事后学习机制，让成功的经验得到推广，失败的教训不再重演。

洞见需求

要做成一个项目，或一个产品，通常需要做3段式的准备，即：需求定义–“define what you want”，清楚地知道要解决的问题、痛点是什么； “know how” –有能力进行可行性评估、知道怎么做任务分解、以及有能力完成总体设计和子系统的设计；“enable”–执行、完成实施、达成目标。三项工作可以简单地分别对应为产品经理的工作、架构师的工作与程序员的工作（画外音：要让一家银行的产品/系统好用，服务体验如沐春风，你需要同时拥有优秀的产品经理、架构师、以及程序员）。其中，需求定义是任何复杂工程或产品项目的基石，它直接决定了项目/产品能否成功、做的工作是否具有价值、付出的成本是否值得，以及问题是否真的得到了解决。需求是所有产品设计的起点，“修炼对需求的认知，是所有产品设计者的终身课题”。

需求通识

《人人都是产品经理》一书中，将需求定义为“用户的问题”，产品经理的使命是“发现问题、定义问题”，通过产品“解决问题”，最后为用户“创造价值”。

如雷贯耳的马斯洛需求层次理论，是大家最耳熟能详的“需求”定义，马斯洛将人的需求分为5个层次：生理需求、安全需求、社交需求、尊重需求以及自我实现的需求。汉语中有于此对应的另一句话，“仓廪实而知礼节”。马斯洛定义的需求，是从心理学角度描述的需求。而在经济学意义上，《腾讯产品法》一书对需求做过非常简单精炼的概括：需求，是想要，且要的起的产品或服务。“想要”是需求的起点，“要得起”才构成真正的有效需求。对身处商业组织中的管理者、产品经理、架构师、程序员来说，更重要的是，是“借我一双慧眼”，能够在纷繁芜杂的用户诉求中，判断哪些是“显性需求”，哪些是“隐性需求”，哪些是“刚性需求”，哪些是“弹性需求”，总而言之，在商业机构中，需要产品经理能够“去伪存真”，通过表层用户直接表达的需求，挖掘用户行为背后的真实目标或痛点，最终回归人性的底层动机–本质需求。
那么，在一般性方法论的层面，可以这么做呢？通常涉及到4个步骤，分别是挖掘和识别需求，定义需求，方案设计，以及持续验证。

在需求挖掘和定义阶段，需要回归第一性原理，通过追问“为什么”，挖掘表象背后的真正问题，弄清楚用户真正想要的是什么。当拿到一份需求，通常可以做如下发问：用户为什么会有这样的需求？提出这样的改造，是基于什么样的前提条件？这些条件至今没有变化吗？有其他替代方法吗？随着技术、经济、文化潮流的发展，有引入新的变量吗？….《腾讯产品法》一书中，用微信群的案例举过一个经典的案例：我们知道，在微信群之前，腾讯其实是有QQ群的，QQ群需要由发起人在群功能中创建一个群，让后将群ID分享给需要入群的人，经过群主审核后，才能入群。如果是一般的产品经理，在设计微信群的时候，将不可避免地受到QQ群设计的影响，但是。运用第一性原理的追问：QQ群设计时的目的与微信群一样吗？不一样，QQ群更像是满足某种特定功能或提供特定服务而存在的，微信群则与大家聚在一块聊天没区别；QQ群设计时的情景与微信一样吗？不一样，QQ是“虚拟社交”，微信则是“实名社交”；使用环境变了吗？当然，QQ群时代以PC为主，微信时代则是手机入口为主。于是，情况一目了然，微信群是为了满足熟人社群互动而存在的，他的特点与线下社交一样，需要支持可以随时随地，几个人聚在一块就可以聊天，也不需要有所谓的群ID，于是，微信群的形态就是我们今天见到的这样。

商业银行的“需求”

商业银行的需求，在具备需求的一般通识性特征外，回到第一性原理视角，还带有大量的行业特征。本文试仅就银行零售与对公业务作少许讨论：

零售银行。零售银行中的产品需求，追根溯源后，金融需求是第二位的，其第一推动来自人的需求，即“生、老、病、养”，“衣、食、住、行”，与社交、娱乐等的需求，由这些需求衍生出个人客户需要的资产增值需求、资产保障需求、交易需求、消费信贷需求、信用卡需求、汽车金融需求、住房信贷需求，最后以存款、汇兑、基金、保险、理财、消费贷、汽车贷、信用卡、房贷等产品的形态体现。

这些需求的特点，对商业银行的产品设计和业务拓展而言，最终被归纳为业内常见的一个词–“场景金融”。在零售业务中，需要追求让金融服务无感地嵌入到场景之中。而场景资源通常是宝贵的，在互联网时代，优质的场景入口，几乎都被互联网巨头或垂类的公司所占据，而场景拓展的难度，常被商业银行简化为“开放银行”的建设，甚至是进一步简化为“openAPI”建设。“开放银行”从第一性原理视角，是毫无疑问的本末倒置，是银行中心论在今时今日仍不能放下身段的表现。openAPI在产品设计上，从银行的视角，试图通过封装银行内部的金融服务接口，提供标准化的对外服务暴露来支持任意第三方按需适配。问题在于，是银行需要场景，而不是场景需要某家发布了openAPI的银行，所谓的ApiBanK，在逻辑上并不成立。不信的话，去看看微信、支付宝的绑卡，是按银行的标准来，还是按两个巨头的标准来，联合贷的话语权是在银行还是发起方。因此，在零售银行领域，面向个人客户的场景拓展，以及开发适配具体场景的产品，比搞开放银行重要。而在技术准备上，不要去试图制定标准，而应该通过适配层的抽象，通过sdk / h5等，考虑如何敏捷、快速、低成本地接入场景。

企业金融。与零售金融的需求围绕个人的需求展开不同，企业金融业务的第一驱动来自于企业经营过程中的金融服务需求，它包括企业的“生产制造”、“贸易结算”，以及企业运营过程中的企业并购、补充资本、税费缴交、招投标、采购、销售、发薪、福利报销等等。企业金融服务的需求，根据企业类型、企业规模的不同，体现出明显的产业、行业甚至个性化特点。

也因此，企业金融业务中的需求提炼、挖掘，其实更考验产品经理的能力。以广义的贷款业务为例，假设某个企业提出需要一笔“流动资金贷款”，对客户经理而言，站在客户角度，则需要了解，这笔“流动资金贷款”的用途是什么，如果是用于向上游付款，该产业链上可以接受商票吗？如果可以接受商票，是否可以改为签发银行承兑汇票？对应地，融资品种一换，企业就可以将需要付息的贷款，转变为无需付息的银承，减少有息负债，对优化企业的资产负债表，显然更有价值。又比如，在为客户办理信用证开证时，要求缴纳的保证金，银行是否有能力分户核算到企业自己的账户上，而不是都缴纳到内部户中，不同的缴交方式，虽然对银行都是一样的存款，但对企业而言，保证金存款将仍然体现在企业的流动性中，这显然对企业资产负债表、现金流量表都更有价值。
不同于零售业务，在企业金融业务中，光融资工具就有贷款（可进一步根据具体的场景细分为一般性贷款、贴现、预支价金、押汇）、票（商票、银票）、信用证、保函，以及由此衍生的各种担保承诺类产品。在支付工具中，在普通账户之外，则有票据、信用证；在公私联动中，有代发、代扣的专门解决方案；在存贷联动解决方案中，有法人账户透支等等…也因此，企业金融业务尤其需要回归企业的需求本心，真正深入企业，针对性地提供金融解决方案（内容太多，未来专题讨论）。

需求分析的若干案例

商业银行中，除了上述面向客户的产品化需求外，还有一类面向内部作业的需求，这一类需求提出时，通常从提出者的视角出发，基于其岗位痛点提出需求，是最需要回归第一性原理，进行全局性考虑的一类需求。看几个具体案例：

CASE1：保证金开户同屏授权改异步。

需求背景：在银行承兑汇票业务中，保证金开票时需要开立保证金账户，保证金账户的开立需要同屏授权，由于业务量大，主管需要频繁离开座位，进行同屏授权。因此提出需求：请将保证金授权由同屏授权改为异步授权。根因分析：银承汇票业务保证金开户过程中，因为保证金账户业务业务合同一一对应的关系，当银承合同多的情况下，需要频繁开立保证金分账户，每次分账户开立，不只是需要授权，还需要填写申请表，并经支行行长签字，开立时不仅是需要主管授权，操作人员还需要录入一系列开户信息，并验证支行行长签字。所以，这个需求的根本痛点其实是，在银票业务中“开立保证金账户的操作十分复杂，影响作业效率，最终影响银票的签发效率”。方案设计：完成根因分析后，我们继续追问，保证金账户的开立只是银行承兑汇票签发的其中一个环节，在开户申请前，还做了什么？了解后发现，在开户前，客户经理已经录入了银承业务合同、为客户开立了结算账号，保证金开户的所有要素都已经具备了，银承业务合同在业务审批过程中，本身就需要支行行长及放款中心线上审批。这也即意味着，保证金开户的要素已经全部具备，保证金开户可以随业务合同一起审批。于是，这个需求被调整为“银行承兑汇票签发的流程优化”，将保证金开户、应解汇款户开户，与银承业务合同的审批进行了自动关联。改造完成后，不仅仅是保证金开户不需要同屏授权，是保证金开户的所有操作直接变成了线上化，客户经理不需要再去柜面，运营同事也不需要再操作开户，对应的签字、验签，线下资料存档等所有内容，也都被撤销，银票签发效率大幅提升。

CASE2：帮我做个RPA，支持开户信息录入。
需求背景：某银行开户，采取线上预约机制，客户预约填写的开户信息及开户资料，在完成审核后，需要通过手工重新录入到交易系统，十分繁琐。
根因分析：这看起来是个开发RPA的需求，但RPA是否能够彻底解决问题，是值得怀疑的。问题的根本在于，预约开户信息及资料，为什么不能直接传递给客户信息系统与账户系统，需要反复多步操作的客户信息录入与账户开立，综合签约等，可以通过服务调度，完成自动化处理吗？
方案设计：答案显然是可以的。于是，需求转变为“实现预约开户的全流程线上化”。负责实现的系统，从RPA，改为预约开户系统，通过打通预约开户系统与后台交易系统，实现信息传递的线上化，并通过预约开户系统实现服务接口的编排，将开户变成客户申请、运营检查、自动开立的自动解决方案，大幅提高了开户效率。

复杂系统

简约崇拜天文学家开普勒说，“大自然喜欢简约和统一”，哈代也宣称，“美是首要的试金石，丑陋的数学不可能永存”。数学和物理学中那些充满美感，而又蕴含宇宙普遍真理的方程–如爱因斯坦质能方程、麦克斯韦方程组、欧拉恒等式等等，常常被用来证明–简单的才是美的。（下图为欧拉恒等式，它将数学里最重要的几个数字联系到了一起：两个超越数：自然对数的底e，圆周率π；两个单位：虚数单位i和自然数的单位1；以及被称为人类伟大发现之一的0。在数学分析领域，以及复变函数论中都占有非常重要的地位，被称为“上帝创造的公式”）

“奥卡姆剃刀原理”同样强调“若无必要，勿增实体”，主张剔除冗余，直击事物本质，避免引入不必要的复杂性。在产品设计哲学中，“简约”也经常被作为衡量产品设计成功与否的标准之一，尤其在消费者业务（to C）中，以苹果、腾讯等为代表的产品设计，充满了简约的美感。有如此多的珠玉在前，于是在产品设计中，“简约”常常被作为“产品经理”的追求之一，只是这种“简约”经常被有意或无意的曲解：其一，数学与物理学中的简约，是对本质和原理的解释，其推导、论证过程充满了复杂性，混沌系统的复杂性研究，甚至发展出了一门专门的学科–混沌工程；其二，产品中的简约是对用户而言的，要达到对客户简约呈现的目的，产品设计者需要有效管理和整合后台的复杂；其三，并不所有的产品都可以做到“简约”，比如下图这个：

管理复杂

事实上，工程领域，以及我们生活中的大部分场景，复杂才是常态，无论是操作一台汽车，还是理解一款金融产品，或是管理一个大型项目。唐纳德·诺曼曾一针见血地指出：问题不在于复杂本身——复杂是客观存在的常态——而在于我们如何理解、沟通和驾驭这种复杂。对产品设计而言，复杂并不是问题，令用户困惑，甚至导致用户不会使用，才是问题。关于复杂的一个例子，是男士们的书桌或房间，在一堆乱七八糟中，主人总是可以很容易地找到需要的物品，但经过太太的精心收拾后，很多东西通常神秘地不知所踪。

糟糕的设计，无论是物理产品、数字界面、流程还是组织架构，会将本源的复杂放大成令人望而生畏的困惑，而优秀的设计则能化繁为简，让复杂变得驯服、透明，甚至富有力量感。管理复杂，并非追求绝对的简单，那往往不切实际，而是追求“可理解的复杂”和“可管理的复杂”。诺曼为我们提供了几个至关重要的手段：

建立有效的心智模型。 这是管理复杂性的基石。用户需要一个关于系统如何运作的“模型”。这个模型需要能预测操作的结果。优秀的设计通过界面、反馈、文档甚至隐喻主动提供并强化这种模型。这个最佳的例子是最近华为推出的尊界S800，通过手势可以开关车门，控制车窗的亮度，将操作与大脑的自然反应进行了映射，当然前提是有黑科技支撑。

合理的分层。分层简直是解决复杂问题的不二法门，面对庞大的复杂性，人类认知的天然策略就是分解。比如，以JAVA编程为例，可以分层为：JAVA源码、.class字节码、JVM、操作系统、计算硬件资源；银行应用架构中，我们将系统分层为渠道层、产品层、风控层、账务层及数据层；管理大型项目时，WBS也是典型的层级化应用，将大目标拆解为可执行的小任务。模块化降低了认知负担，使聚焦和掌控成为可能。

设计及时且明确的反馈。在复杂系统中操作，用户需要清晰地知道“发生了什么”以及“我做得对不对”。反馈是建立和修正心智模型的关键。 优秀的反馈是即时的–操作后马上有反应，在银行应用系统的异步响应模式中，通常以“请求已受理作为即时ack的反应”、明确的–清晰地指示状态变化或结果，银行系统如果报错，得给出明确的报错提示、匹配的–反馈的形式和强度与操作本身相称。下载文件时的进度条、提交表单后的成功提示或错误信息框，都是反馈的体现。缺乏反馈（点击后没反应）或反馈模糊（提示不清晰）会极大增加不确定性。让用户感到失控，是导致问题的常见源头。

利用约束引导行为。复杂系统中存在无数可能的操作路径，但并非所有路径都是正确或安全的。优秀的设计通过物理约束，比如特定形状的插头只能插入对应的插座；逻辑约束，如必须先填写A才能填写B，常见于客户填写表单信息时进行关联检查；文化约束–比如通用的红色代表停止/危险，以及语义约束（如旋钮的箭头方向指示旋转效果）来限制可能的操作选项，引导用户走向正确的行为。这些约束像无形的轨道，防止用户误入歧途，减少错误和认知负担。例如，转账提交后，一定时间内将按钮置为“灰色不可点击”，就是运用逻辑约束和文化约束建立心智模型的典型案例，常用于避免重复转账。

善用默认值与预设。面对大量可选项时，用户容易陷入“选择悖论”的焦虑。优秀的设计提供经过深思熟虑的、适合大多数场景的默认值或预设方案。这并非剥夺用户的选择权，而是提供一个安全的、合理的起点。用户可以在此基础上轻松地进行个性化调整，而不是一切从零开始。例如，软件的“推荐安装选项”、银行系统各种产品、核算、费用参数的初始化，都大大简化了初始操作，降低了入门门槛。

标准化与一致性。当不同的系统、不同的界面、不同的流程遵循相似的规则和模式时，学习成本会大大降低。一致性是易用性的核心原则之一。相同的图标代表相同的功能，相似的操作产生相似的结果，术语的使用保持统一。这使得用户可以将在一个系统中习得的经验（心智模型）迁移到另一个系统，形成规模效应，有效管理跨领域的复杂性。想象一下，如果每个网站的“保存”按钮图标和位置都不同，那将是多么混乱。

容错设计。 在复杂环境中，犯错是常态。优秀的设计能预见到可能的错误，并使其可逆或易于纠正。典型的如“撤销”功能、“幂等”设计银行应用系统是容错设计的典范。清晰的错误提示、提供简便的修正方式、以及防止灾难性后果（如删除前的二次确认），都能极大降低用户面对复杂操作时的恐惧和挫败感，鼓励探索和学习。

商行产品缘何复杂

以上是产品设计的一般通识，是需要在产品或方案设计中遵守的常识性守则。而对商业银行而言，因为行业的特殊性，使其产品或方案设计，更加不可避免地具备复杂系统的特点。这些特点体现在：

需求的多元性。不同于一般行业直接面向客户需求，以解决客户痛点为核心诉求的产品设计原则，商业银行的产品设计，需要根据产品特性，同时考虑“客户、合规内控、监管”三方面的需求。其中，客户需求自然是毫无疑问的，满足个人客户在日常生活、工作、学习中面临的支付结算、保值、资产增值需求，满足企业客户在生产经营、贸易结算中的金融需求等等；但在满足这些需求的过程中，因为银行业的特殊性–经营和管理风险，对应标的是“资金”，因此，对应的内控合规、营运安全求，同样非常重要，比如流动性安全、不良率的控制、审贷分离原则等等，均需要在产品需求中得到充分考虑；在内控合规之外，商业银行还面临不同于其他行业的强力监管要求，包括巴塞尔协议中对rwa、ifrs9等相关的刚性约束，以及不同国家、地区监管机构要求的诸如窗口指导、贷存比、mpa考核、信贷行业投向、占比等要求。举个例子，以设计小微企业贷款产品为例，需要统筹考虑3个方面的需求：

• 客户需求包括：目前客群画像、申贷方式（H5、APP、小程序…）、核身方式（五要素核身、活体检测….）、风控批核模型申请评分卡设计（不同指标的权重测算）、选择何种的还本付息方式、客户申请到放款的周期和流程设计、还款方式（是否支持快捷代扣等等）；
• 内控合规需求：贷款合同的条款设计是否合规、事前反欺诈方式、行为评分卡的评分模型设计、贷后预警信号的设计，放款是否需要人工审查等内部流程设计；
• 监管需求：信用贷款的报送口径，企业规模、类型的认定要素，是否符合产业政策等等，相关贷款产品的rwa、ftp、i9的影响以及对应的数据下送等等。

内部流程设计将直接影响客户体验。与一般的物理商品不同，商业银行的产品实际是一揽子服务的集合，在物理产品的世界中，如果一款产品品质极其过硬，后续客户与商家/厂家发生联系的概率不大，但银行产品与此不同，包括开户、大额汇款、贷款申请等在内的服务，都会涉及到流程设计，部分需要与银行的营业网点、反洗钱部门、集中作业部门发生联系，此时，流程设计中，哪些可以由计算机自动化，哪些需要人工进行审核，就不仅仅是银行内部降本增效的问题，而是会直接影响到客户的使用体验，比如一笔开户申请，A银行依靠技术手段，可以实现秒开，而B银行手工操作，需要个几天，客户会选择谁将显而易见；同样的例子是贷款（包括开票、开证）申请，如果一家银行依靠技术手段，可以做到秒批、秒贷（在有效实现风险控制的前提下），其带来的产品竞争力讲师不言而喻的。因此，从客户与银行建立联系开始，针对客户旅程的全生命周期进行有效的流程设计，将是产品设计面临的必然命题，而这通常涉及多个节点的跨系统交互。

差异化竞争优势获取需要跨域联动的设计。高维打低维的降维打击模式从来都是产品创新的灵感来源，微信红包的社交打金融，余额宝通过将货币基金的投资功能叠加支付功能的产品升维，都取得了巨大的成功。这种现象级的产品当然可遇不可求，但是商业银行中存在大量的存贷联动、公私联动的产品却是不争的事实，比如代发薪、担保承诺类业务中，授信业务与保证金存款的联动，法人账户透支产品中负债产品与融资产品的联动等等，这通常会涉及到跨业务形态、跨业务领域的复杂设计。

银行业系统架构分层的必然结果。在商业银行长期的组织架构和IT系统应用架构的演进过程中，逐步形成的“前、中、后”台模式，天然地需要进行跨部门、跨系统的协作以有效支持一款产品的有效实现。商业银行常见应用架构的分层分布，如下图：

从这一分层架构看，负债产品的产品实现，将不可避免地需要统筹考虑渠道层、公共服务层、账务作业层、数据层的功能需求；而融资产品，则在负债业务的基础上，还需要考虑风险控制层的功能实现；跨域联动类产品，则在以上两者之外，还需要考虑产品层的跨域联动，如果涉及支付业务，还需要考虑与外部的适配等等。

应对之道

商业银行的行业特点决定了银行产品不可避免地需要管理复杂，而在可操作性层面上，有什么可行的办法来管理这种复杂性呢，分为组织层面与个人层面。

组织层面。首先仍然是人才先行，针对性地建立一支优秀的跨领域复合型人才队伍（产品经理、体验设计师、流程设计师、业务架构师、开发经理等等），通过轮岗、深度参与大型项目等方式，培养队伍成员一专多能的专业素质；其次是有条件的情况下，建立有渠道、产品、风险、财务、运营、IT、合规人员组成的产品委员会，对新建设产品，充分听取各不同专业委员的意见和建议，对产品差异化竞争优势、预期回报、合规可行性等进行充分讨论和论证，产品建设做到谋定而后动；再次是有效的需求流程设计，比如最简单的，一份需求在签批环节，比如按流程经过风险、合规、相关配合的业务单位、营运、财务等的审阅，并充分发表意见，才可以进入到产品实施环节；最后，需要有充分的需求评审，将需求对应的业务背景、增长预测、功能说明、关联需求等，向相关方进行完整的阐述并取得支持，需求评审时可以要求需求以模版方式呈现，如下图所示需要覆盖的内容：

个人层面。无论是产品经理、业务架构师还是开发负责人（一般也是技术方案设计者），首先是需要具备一些关于产品设计的通识性知识，比如知道基本的关于反馈、约束控制、有效心智模型设计的知识，了解基本的交互设计基础知识；其次是需要养成系统性思维能力，多以全局视角审视和思考问题，强迫自己尽可能“知其然，且知其所以然”；再次是不断学习，在深化本专业知识的基础上，尽可能拓展“多能”的跨领域业务能力，在知识的深度和广度上，都有所精进（毕竟艺多不压身）；最后是要多实践，尽量多地主动请缨，参加一些大型项目或产品研发，如果条件允许，可以考虑在一个领域待够3~5年后，寻求感兴趣的领域转岗锻炼，“纸上得来终觉浅、绝知此事要躬行”，理论无论写的多好，都不如动手来得更有体感。

显性与隐性特征设计

每一个让用户感觉“简单好用”的产品或功能背后，都是产品设计者对产品显性特征和隐性特征的统筹考虑，并通过一体两面的兼顾实现和谐统一的最终结果。

产品经理的双面视角

如何做好用户体验设计

怎么抽象复杂系统交互

持续敏捷

演进思维要求在面向不确定的市场与激励的竞争时，需要快速低成本试错、快速迭代，即用最小的可行性产品验证假设，总之，需要进行敏捷。这一源自互联网行业的方法论，在印象中应该偏稳健、保守的商业银行，也被越来越多地推广及运用。

为什么需要敏捷

商业银行的产品敏捷，最直接的原因大概是“卷”，这大概是中国大陆，或者是带互联网基因的商业银行–比如Shoppee Bank，特有的现象。“卷”是竞争，有竞争才会有进步，物竞天择，面对市场的波动性、不确定性、复杂性和模糊性（VUCA），那些能够比竞争对手更快学习、决策和行动的机构，将获得显著的竞争优势。除了竞争之外，商业银行的一些经营特点，也是对敏捷能力的现实要求：

因应监管政策变化的要求。金融行业的强监管特性、央行的货币政策变化，都要求商业银行的业务开展需要迅速适应政策变化的要求。如2013年至2016年期间狂飙突进的影子银行业务中的“产业基金”模式、“票据资管”、“黄金租赁”业务等等，都是只在一定时期内被允许的业务，在一定时期内为开展这类业务的商业银行创造了客观的利润。其他的，诸如央行LPR利率的推出、针对小微的再贷款专项计划、再贴现利率调整对票据市场的调节、国家金融管理局对消金公司杠杆率、同业拆入规模、担保增信的限制及由此影响商业银行联合贷、助贷业务的发展，都需要商业银行进行快速的反应，在资源投放、政策修订、产品调整、系统开发等方面，快速作出反应。

市场时机的的快速把握。包括以下几类，1）、面向特定热点事件、或者特殊时间窗口的产品设计。比较有代表性的，如AlipayHK为香港地区年底缴税专门推出的缴费易产品（包括营销补贴）、银行当港股行情好时为投资者开发的IPO融资产品及专项孖展授信产品、因应黄金行情而开发的积存金产品等等；2）、以快制胜的市场竞争需要。以对公业务领域为例，高价值头部对公客户通常会成为多家商业银行的潜在竞争客户，此时，而他们需要的产品通常都需要定制化，谁能以最快的速度满足从一线客户经理传递上来的客户需求，谁就可能获得先发优势，获得更多的业务机会。

经营特点的客观需要。商业银行生息资产投放的特点及KPI的考核需要，尤其是在信贷投放领域，新产品的建设往往需要在年底前完成，并在来年通过开门红，甚至在上一年年底就产生足够的规模，然后在未来一年中的尽可能长的时间内，带来经营收益。这种情况在贷款产品领域经常发生，常常需要贷款产品的产研团队能够对业务作出敏捷响应。其他因诸如适应季末、月末存款规模等考核要求而进行的产品开发，也在此列。
当然，最终还有一点更现实的，就是强KPI考核下的压力传导。大致有如下几种情形：第一自然是自上而下的压力传导。来自于行长、分管副行长、各业务部门总经理依据全行经营战略，分解落地而需要研发产品，在相当一部分机构中，管理者似乎缺乏耐心，大多按“一万年太久、只争朝夕”进行要求，一旦提出，就希望尽快看到成品；二是产品团队本身，在对产品团队强考核的商业银行，产品团队需要要么通过质量（产品完成的营收、利润数字）、要么通过数量（没有功劳，总要抢个苦劳），作为KPI的关键支撑，由此带来的所谓“敏捷响应”需要；三是业务一线，分支行、客户经理发现的市场机会（或误以为的市场机会），其中一部分除了需要关系营销外，还需要银行中后台以最快的速度为前线提供好的产品、解决方案以满足前线的需要。
总而言之，”持续敏捷”能力建设，对银行产研团队而言，早就不是一个选择题，而是银行产研团队生存与发展的必修课。

敏捷的误区

然而，在实际工作过程中，“敏捷”却常常被玩坏了：将违反科学规律、极致压缩研发周期的蛮干当成敏捷；将缺乏规划的功能堆砌，以战术勤奋替代战略懒惰当成敏捷；将scrum的引入，完成各种敏捷工具的部署，实则不计效果的形式主义当成敏捷；将频繁的变更、碎片化的优化当成敏捷，勤奋地对客户进行打扰。几种在工作过程中常见的敏捷误区包括：

多加资源就能缩短产品研发周期。这一点常见于很多银行业机构，当一个产品、项目研发需要8个人，3个月的周期时，业务方、管理者经常会产生的一种迷思是，加到20个人，能不能将研发周期缩短到2个月？这就好比一个妈妈要怀胎10月，才能生出1个孩子，现在给你两个妈妈，能不能帮忙将生孩子的周期压缩到6个月？这一误区不仅见于银行产品、项目研发，也常见于银行战略中的所谓加大对“金融科技战略”的支持–让科技部门多招人。事实上，团队也好、项目也罢，人都不是越多越好（当然更不能人手不足），维持一个“小而精”的团队，是研发团队或者项目组织的最佳策略。《人月神话》一书中，弗雷德里克・布鲁克斯提出，向进度落后的项目中增加人手，往往会使进度更加落后。这是因为软件开发是一种复杂的创造性工作，随着团队规模的扩大，沟通和协调的复杂性会呈指数增长。团队成员之间的沟通渠道数量可以用公式n(n−1)/2来计算，其中n为团队成员数量。例如，当团队有5名成员时，沟通渠道有5×(5−1)÷2=10条；当团队扩大到10名成员时，沟通渠道则增加到10×(10−1)÷2=45条。如下图示意，曲线处于最低点时的人员规模，才是最佳规模，跨过最低点后，随着人手的增加，效率反而下降：

碎片化需求而非价值交付。敏捷多数时候离不开迭代，迭代最终表现为做了多少次发布，这最终导致很多产研团队有意或无意地误入歧途：将需求拆得稀碎，发布的内容能不能给客户带来闭环的价值不重要，重要的是完成了多少次需求发布。这种本末倒置的做法，本质上是一种”交付的幻觉”——团队沉浸在频繁交付的成就感中，却忽略了每一次交付是否真正解决了用户的问题或带来了业务价值。其典型的症状包括：1）、功能肢解。一个完整的用户旅程被拆分成多个互不关联的迭代，用户需要等待数月才能体验到一个完整可用的功能；2）、指标异化。团队关注的不再是“是否提升了客户满意度”或“是否增加了业务转化”，而是“本期完成了多少个用户故事点（需求点）”；3）、伪敏捷。保持着两周一次的发布节奏，但发布的内容多是 Bug 修复、体验调优或边缘功能，核心痛点始终得不到解决。

形式主义敏捷。形式主义敏捷是许多组织在推行敏捷过程中最容易陷入的误区，通常是在“领导的亲切关怀下”，引入所谓的“敏捷教练”，然后将Scrum的几件套–站会、看板、待办事项清单一一执行到位。笔者的亲身经历，本来运转良好的产研团队，在敏捷教练的一通指导下，搞得怨声载道，开发效率急剧下降。其问题表现包括：1）、晨会是形式主义的重灾区。一群人神经病式的围成一圈本身就挺有喜感的，每个成员再按顺序讲一圈“昨天做了什么、今天要做什么、遇到什么问题…”，这简直是荒谬。第一，这么公开的场合，能听到多少真话？第二，产品负责人或者研发负责人，如果连团队成员的工作进度、项目风险都不掌握，还要通过晨会了解的话，那就要赶紧换人了。如果领导者只是想通过晨会搞服从性测试，那请继续，如果是为了敏捷，赶紧取消才是正道；2）、看板成为额外的负担。除了给领导表演外，谁会真的通过看板去了解项目进度。真实的项目进度只在钉钉、企微的聊天记录中，只在实实在在的文档和代码中，只在团队日积月累的相互信任中。所谓看板，不但增加成员的双重填写压力（他们还得在项目管理工具中再填写一遍），还常常弄成表演者的舞台–代码一般是没有领导看的，看板可不一样，做的花样百出指不定哪天就被表扬了。凡此种种，不一而足…敏捷的本质是适应性和快速响应变化，而不是对特定流程的宗教式恪守。当团队忙于完美执行敏捷仪式而忘记了为什么要这样做时，敏捷就已经失败了。

勤奋的懒惰。在腾讯的产品哲学中，有一条非常令人印象深刻，即“避免勤奋地打扰客户”。我们看到，腾讯系的产品很少会发生那种交互习惯被改的面目全非的情况，这后面一定包含着对产品迭代的严谨论证和产品功能上新、体验改变的充分论证。但与此相对，银行业机构似乎并不如此，笔者自己用过的手机银行app，都经常出现过段时间就改头换面一次的骚操作，一个手机银行app，居然一路从1.0，发布到1x.0…事实上，在产品进入成熟期后，更多的精力应用用在功能细节、交互体验的反复雕琢，对特别成熟、用户早就已经习惯的产品而言，什么都不做，也比瞎折腾要好。在”敏捷”的旗帜下，产品很容易陷入功能主义的误区，堆砌功能（甚至是堆砌产品）本质上是用“战术的勤奋掩盖战略的懒惰”，不仅浪费大量宝贵的开发资源，还会让产品变得臃肿不堪，给用户带来困扰。

实现持续敏捷

事实上，真正的敏捷必须是以价值交付和用户体验优化为中心的。每一次迭代都应回答一个问题：”这次发布为客户或业务带来了什么新价值？”如果答案不明确，那么这次迭代可能就是不必要的。
实现持续敏捷，不能仅仅停留在引入Scrum仪式或部署管理工具上。这些形式若没有内在能力的支撑，终将流于表面。真正的敏捷源于以下核心要素：

建立良性的敏捷评价机制，始终坚持价值驱动下的敏捷。1）、迭代评审机制。每次迭代，都需要向管理者及敏捷小组成员说明这个迭代“可验证的用户价值”是什么，而不仅仅是以提出需求，完成开发任务为目标。哪怕这个价值很小，它也应该是一个完整的、可用的功能切片。2）、建立清晰的价值评估框架。在迭代开始前，要明确“如何验证这个功能成功？”–是通过用户反馈、业务指标还是A/B测试？3）、敢于说不。对那些不能带来明显用户价值或业务价值的需求（如一味的领导偏好、盲目的竞品跟随），产品经理、研发经理要勇于拒绝，保持团队的专注力。4）、用成果而非产出衡量敏捷的成功：团队追求的不应是发布了多少功能，而是通过这些发布获取了多少用户增长、提升了多少客户满意度或降低了多少运营成本。

充分的组织准备，跨职能团队与授权机制建设。传统银行科层制组织结构是敏捷的最大障碍。组建跨职能的特性团队(feature team），将产品经理、体验设计师、运营经理、开发工程师、测试工程师（在融资业务中，通常还会加入风险人员）等凝聚成一个目标明确、被充分授权的小型作战单元，是进行能力闭环，形成团队默契，通向敏捷的重要保证。互联网企业中，除了按矩阵模式进行临时的团队编组外，还常常将一个个跑出来的产品线固化下来，形成有福同享、有难同当的利益共同体。这种”产品+研发+运营”的铁三角团队，在被赋予明确的业务目标和对实现路径的决策权后，需求决策周期、需求澄清周期、研发周期、发布周期都将得到大幅压缩。

服务抽象与架构支撑。后端架构的灵活性是前端业务敏捷的基石。以信贷业务为例，通过共享服务抽象，可以将指标模型、决策引擎、账务记账、额度计算、押品管理、客户评级，分别抽象成独立的共享服务，在零售信贷、小微融资及一般企业级授信业务中，共享这些能力，支持信贷类产品在推陈出新时，只需要改变准入模型、变化还款周期或还款方式、变更担保模式等等，极大压缩产品研发周期，实现有效敏捷。

需求分析与分解。Scrum从来都不是敏捷的核心，需求的分析与拆解，按冰糖葫芦式组织一个一个交付闭环的功能点，才是敏捷的核心与关键。它要求产品经理能够精准捕捉用户和业务痛点，确保解决真正有价值的问题按MVP（最小可行产品）思维，优先被交付；它还要求产品和交付团队，能够将大型需求拆解为独立的、可交付的小用户故事。以下是腾讯8分钟产品课中分享的产品迭代原则，以支付业务为例：

他将产品需求分为“安全可用”、“使用体验”、“扩展兼容”、“生态体系”四级，与马斯洛需求层次理论类似，因为支付涉及到资金安全，支付资金的安全、避免陷入反洗钱的麻烦，就成为支付产品的最基础需求，这个都做不好的话，遑论其他；之后是使用体验，而使用体验的核心便是支付成功率，Lucy（彭蕾）在带支付宝团队的时候，其重要贡献之一，就是大幅提升了支付宝的支付成功率；再之后是能力的扩展，对多类型支付工具的兼容；最后是构建庞大的生态，形成产品的深度护城河，在支付业务中，这包括线上、线下收单场景、商户的推广，用户使用习惯的培养等等。

Devops体系的构建。如果说服务抽象为敏捷提供了可复用的能力积木，那么DevOps体系则是确保这些积木能够被快速、可靠、高质量组装和交付的流水线。如果一次需求上线需要经历冗长的部署文档编写、人工申请、多环境手动部署与测试，那么敏捷必然就会以IT人员的加班、人肉运维为代价。Devops体系的构建需要在至少3个方面完成能力建设：1）、自动化工具链贯穿全过程。从开发人员提交代码开始，通过版本控制工具(如Git）、持续集成（CI）工具自动触发编译、单元测试与代码质量扫描；通过持续交付（CD）工具自动完成测试环境、预生产环境乃至生产环境的自动化部署与回归测试；最终通过自动化监控工具持续观察应用性能。这条工具链将人工从重复、易错的流程中解放出来，使数小时内完成一次高质量发布成为可能。2）、实现基础设施即代码。通过代码来定义和管理基础设施，使得服务器、数据库、负载均衡器等资源的申请、配置与销毁均可通过自动化脚本完成，实现基础环境的版本化、可追溯和快速重建，为业务的快速弹性扩缩容奠定基石；3）、构建完备的可观测性体系。构建包括日志、指标核对与链路追踪的全方位可观测能力。实现从敏捷开发态下，生产运维由“被动救火”到“主动预警”乃至“故障自愈”的演进。

结语

在组织架构设计、文化特点、支撑体系迥异于互联网的传统商业银行，持续敏捷对身处前线的产品经理和开发人员而言，多数时候是一种无奈的奉命行事。但在局部的微观生态中，它仍然应该是产品经理、开发经理、运维经理应该努力追求的目标。因为要达成真正的持续敏捷，它要求我们能够练就一双慧眼，能够洞悉用户真正的问题和关键痛点，对最小可验证需求进行提炼；它还要求我们不断掌握更多的业务知识，在专业能力的牵引下，去规划产品的迭代方向；它还要求我们去理解和驾驭复杂，养成“系统化”、“结构化”思考问题的习惯；它更不断启迪我们不断去思考如何构建能够快速响应的团队、架构与文化。而所有这些方面的历练，终将会千磨百炼出一个更好的自己。

作者：高尔斯基