摘要
于软件开发领域而言，敏捷已经被广泛认可为一个行之有效的应对快速交付和不确定性的指导方法，并有一系列相对成熟的模型和框架。而企业更为需要的企业敏捷和业务敏捷则仍在探索阶段。敏捷吸引软件开发工作者的原因，是它打破传统开发常规，用不同的思维找到更好的方法，取得更好的结果。同样的，如果要业务敏捷，就要探寻业务部门所需要突破的常规。本文将与诸君分享三类业务部门突破常规的故事。
在这个技术突飞猛进、环境瞬息万变的时代，能够快速响应变化并做出适当的调整，是关系到企业生死的基本能力。企业（enterprise）需要敏捷，业务（business）必须敏捷。但很不幸的是，现行的商业和管理理论和实践普遍相对落后，连彼得·德鲁克都曾感叹：“我们称之为管理的东西反而使人们做事更困难”，更不用说支持快速响应变化。请问各位，您所在组织的管理和运作模式是否支持快速实现客户需求，是否支持快速响应变化？有哪些规则妨碍你们的工作？要迈向更好的运作模式，首先必须打破那些不必要的常规。
探寻更有效的运作模式并非容易的事。幸运的是，软件群体已迎来新希望。交付周期缩短的压力下，软件团队已经成功的实践新的工作方式，我们将之统称为“敏捷软件开发”。敏捷团队能够高效有效地协作，产出客户满意的软件产品。敏捷团队惊人的效率和激情，对业务工作者是一种鼓舞。组织领导希望业务人员有同样的敏捷能力和效果。
但是，业务敏捷（business agility）并没有明确的定义。敏捷联盟（Agile Alliance）将业务敏捷定义为“业务能感知内部、外部的变化，并及时回应以便于为客户提供价值。业务敏捷不是一种具体方法，甚至不是一个整体框架，它是形容一个组织怎样在成长思维下运作，而这种思维很类似于敏捷软件开发群体形容的敏捷思维。”敏捷联盟进一步表示，没有固定的敏捷实践、角色、或者周期。因此，业务敏捷的组成可说是还处于探索阶段。因此，业务敏捷是什么，它的目标是什么，它的广度和深度是什么，还需要每一个组织自己去定义。目前，没有任何参考的模型，各组织需要自行探索，自己检验。
在敏捷软件开发方法体系，业界有不少通用的模型，比如Scrum、XP等，来指导敏捷开发的实施。以上模型以软件团队作为出发点。业务敏捷的出发点呢？它从哪里开始？业务部门的领域不同，需要的敏捷模式则不同。比方说：销售部门的敏捷可能就跟财务部的敏捷完全不同，采购部的敏捷和人力资源部的敏捷也应该不同。同样的，敏捷对于高层管理者和业务部门领导来说也有不同的意义和侧重点。
我们或许可以考虑让这些业务部门尝试成熟的Scrum框架，让这些部门有迭代运作的概念。这或许有用，但我觉得不能解决业务的根本问题。原因很简单，业务部门都有他们惯用的例行工作分配和跟踪机制。在这些例行会议当中，他们会讨论与跟踪问题，并商定改进措施。所以，如果跟业务人员只是谈论“一般”的敏捷迭代做法，持续改进，他们就可能会感觉“我们都知道，已经在做了，没什么新鲜的”。
敏捷吸引软件开发工作者的原因，是它打破传统开发常规，用不同的思维找到更好的方法，取得更好的结果。敏捷宣言中的四个价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
右边就是常规，左边就是崭新的思维模式。同样的，如果要业务敏捷，就要探寻业务部门所需要突破的常规。
敏捷宣言也提出“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观。”同样的，我将分享我的一些个人在业务敏捷经验和体会，供大家讨论，我把这些经历分为三类：
- 业务与IT的敏捷（Business and IT Agility）
- 客户参与的敏捷（Customer Engagement Agility）
- 业务自身的敏捷（Business Agility in Itself）
这三类经历都在说明，业务人员如何跳出他们存在的心态和思维，找到突破。
业务与IT的敏捷
谈到业务敏捷，很自然的就谈到业务部门和IT部门的合作。下面的场景相信大家都不陌生：业务和IT双方并不和谐，各自维护自己的利益，互相对抗。业务压需求，IT抵抗需求。其实，从企业整体目标的角度考虑，他们应该是相互合作的合作伙伴关系，没有高下之分。
这是很多企业里常见的做法：业务方希望以最低价格完成目标，所以跟许多供应商合作，让他们之间互相竞争价格。这些供应商，有些做开发，有些做所谓的“独立测试”，他们互相竞争报价。在极端情况下，一个业务部门有十几个供应商，分别负责开发、测试、用户体验等等不同的工作。在这种讨价还价，随时停止供应商服务的情况下，供应商怎么可能有热情和忠诚？有些业务部门不仅仅对供应商这样，甚至对公司内部IT的同事也一样。IT服务质量难免受损。
业务与IT的敏捷协作基础是互相尊重，互惠互利。我分享两段个人经历：
第一个经历是我2014年的一个大型敏捷转型项目，包括供应商大概有好几千员工，该业务在一年后扩张至约万人。当时我们提供IT组织敏捷转型方案，并且辅导团队落地实施。正好我辅导的某个团队，业务代表和IT代表水火不容，一开口就吵，几乎不说话，关系很尴尬。业务代表希望将70个左右的需求都要现实，但是IT方面抱怨说需求不明确，做不到。IT代表问我，到底他们哪一方合理，这让我左右为难，倾向哪一方都有损失。这时，我便问业务代表是否真的希望每一个想法（Idea）都实现，以及每一个想法当前的进展情况。如我所料，那些想法的进度并不相同，有些想法就是想法，业务代表只是想与IT代表共同讨论。说到这里，IT代表才平下心情。我们便建立一个想法看板（Idea Kanban），附有清晰的标准定义和具体的排序规则。这形成业务方和IT双方的合作基础。这个运作方式受组织的认可，并且变成了其他业务团队的参考模型。
第二个经历更是难以忘记。业务代表想创造一个B2B电子商务平台，向欧洲和香港市场发展，有大量的业务需求。IT方面正手忙脚乱地实施落地，工作量特别大，不少加班情况。为了满足业务需求，IT部门有并行的版本开发。这意味着业务方必须参与验收测试（UAT），而同时也需要投入准备德国和香港的演示和销售工作，所以工作量也很繁重。总而言之，业务和IT双方都被压得喘不过气。其实，对我来说，解决办法很明显：就是要聚焦，不要把精力分散。为了让香港客户演示的成功，应该把大部分精力集中在这里，不必要并行版本开发，反而应该舍弃一些已经计划发布的工作。我参加他们业务和IT的协作会议，并指出我的想法。业务方很果断的舍弃一个版本，并同意专注于演示的准备。取消一个并行版本之后，业务和IT突然感觉轻松多了，特别开心。为了纪念这次的决定，业务代表还提议在敏捷宣言前合影留念！
客户参与的敏捷
说到客户参与，我想把本文的重点放在线上和线下的“人为渠道”（human channel）方面。在目前提倡数字化背景下，组织提倡自动化和智能化，希望通过技术手段，更好的为客户服务。客户通过这些自动化智能化的渠道办理业务，不需要业务人员的参与，减少业务人员和客户通过移动或其他方式进行沟通。虽然，这将让客户更方便，但是在某种情况下，会失去跟客户人与人之间的接触机会。数字化和业务敏捷存在的意义就是让业务给客户更人性化的服务，如果要人性化，怎么能够完全没有人为的参与呢？所以，在本文当中，我分享两个相关经历。
在某家金融科技公司，客服人员每人每天有350次通话指标。其实，通话次数和通话质量是两回事。我便问他们是否有建立一些有意义的关系，解决他们的问题。这些一线客服人员便滔滔不绝的讲述他们与客户接触的感人故事：一名客户问客服夜间上哪里买药，另一名客户询问哪里能找到托儿服务、等等。很明显，这些都是超出客服的工作范围。在他们分享经验时，我能感觉到他们的热情，他们助人为快乐之本的心态。我相信他们的客户也会特别感激。在这分享中，客服人员理解他们的意义不是为了达到冷冰冰的通话次数目标，而是有同理心的帮助客户。客服人员不是接电话或拨电话的机器，他们是一群具有影响力的大使，帮助组织建立人脉，建立口碑。当业务意识到这一点，就会有更强大、更有创新力的服务。如果你想要客服更人性化，你必须关注他们，鼓励他们呈现人性化的一面。这是敏捷的基础——以客户为中心，以人为本。
这个故事是我在某家银行的经历。作为一个每月领取人民币薪资的新加坡人，还要把工资汇到新加坡，这手续其实很麻烦。在银行风险政策的要求下，每次境外汇款都要亲自跑支行两趟去办理手续，对我这样一个差旅频繁的人来说，这是个很大的问题。不过与支行经理商量之后，商定一个稍微简单的办法，将两次亲自现场办理手续减为一次。支行的王经理不仅满足我作为客户时间上的要求，在自己的工作上取得成就，更交了新朋友。这是个体现出一线人员寻找流程创新和突破的很好例子。
一线员工不是推销产品、提供信息的渠道。他们是真正能够与客户立建关系的大使，所以他们应该赋予更多权利。但是，不少企业往往对他们就像对待机器一般，完全没有决策权，完全百分百的遵循过时和不完备的流程制度。以上两个案例体现了一线的突破。这就是所需要的业务敏捷。
业务自身的敏捷
业务敏捷的第三方面是业务自身的质量和管理方式。这跟客户、合作伙伴和IT没直接关系。这是业务自身的核心，通常与领导层有关。业务的决策和经营体现了领导者的意愿。领导做事的方式对业务敏捷有很大的影响，通常表现在细节上。
我在知识共享领域有一段有趣的经历。客户所在的业务有不同产品线，规模很大。领导层希望不同产品线分享知识，让员工互相学习，找到更好的解决方案。但是，业务的安全部门有责任保护机密。因此，两个部门产生了冲突——知识管理部希望分享，安全部门需要维护保密性。讨论之后，最终没有将知识分享的项目交给知识管理部，而交给安全部门负责，这样他们就需要改变保密政策。这显然了创造共同视野的好方法。
在另一个组织中，不同额度的采购需要不同的级别的审批权限，这在某种程度上是有道理的，但却给带来巨大的问题。一个项目当中所需采购工作，就需要获得不同级别的批准。较小的采购交给较低管理层的批准，而较大的采购则交给更高管理层的批准。结果，经理们看到的是完全不同的采购，而不是一个项目的所有主要采购。经过一次改善活动之后，让每个项目都由一个单独的人来批准重大的采购，而采购业务的合作使他可以批准指定项目相关的所有其他采购。这大大简化了审批过程，将审批周期从最多21天缩短到最多3天。
最后一个例子是一家有很多个不同子公司的业务，每一个子公司经营的业务都不同，成熟度也不同。于是，我们合作设计了一个共同的绩效框架，用于管理不同子公司。这个框架基于麦肯锡的三维度、基于业务驱动变量，它们适用于B2B、B2C和混合商业模型。过去，他们集中于金融指标，经过共同的努力，他们得到了更好的领先指标，能够追踪客户和商业伙伴的成长。为总公司和子公司之间提高了急需的可见性，优于以往不透明的方式。
敏捷即打破常规
如果你已经尝试过敏捷，你可能会在开始的几星期或者几个月内感到很新颖。但是，如果在这期间没有任何突破，没有任何思维的创新，没有打破常规，团队就很容易回到老样子。团队们可能说他们有Scrum活动，有一系列的“敏捷”仪式，但是，我的经验告诉我，如果只有表面上行动，没有根本上的改变，这是很难持续的。若要真正的敏捷，就必须更上一层楼，就必须有思维的突破和创新。敏捷软件开发如此，业务敏捷也如此。
各位业务敏捷实施者，你们有哪些最关键限制因素?这些因素背后的原则和政策是什么？你可以做出哪些改变？你可以克服这个限制吗？要付出什么代价？如果你袖手旁观，后果会怎样？ 我们追求的是管理层面的突破。这些突破，往往就是一个简单的决定，就向打开一扇门那么简单。但是打开门后，海阔天空。
今天，你有没有尝试打破常规？欢迎分享。
文／ThoughtWorks黄邦伟 博士
原文：https://insights.thoughtworks.cn/key-point-of-enterprise-agile-is-break-the-routine/