在数字技术对我们有颠覆性影响的时代，当新创业公司从不同角度挑战现任市场领导者时，当消费者和市民希望对影响他们的决策有更多控制权的时候，当改变的步伐不断加速的时候，当我们希望付出更少、更快同时实现更多的时候……我们的业务不再跟以往一样，因此为什么我们还要像以往一样做业务分析呢？
当企业、家族生意和政府机构在逐步探索新技术的时候，那么为什么这么多企业在实施这些变革的时候还使用传统思维和传统方法呢？
软件开发项目经历了一些重大的重构：构建自组织的团队模式，以增量和迭代的方式构建健壮的产品，从客户那获得快速反馈从而通知正在进行的工作。
在这样的背景下，那么对于需要自适应、发散和探索性方法的项目，为什么项目管理和业务分析仍然按照计划使用顺序思维模式呢？
有感于此，在 2015 年年末，Assurity 的 Luke Johnstone 在 AgileNZ Conference 上公布了精益业务分析宣言，接着是我在 BA Development Day 的演讲。这些会议上的讨论使大家产生了足够的兴趣，促使我们写一篇文章对这些理念进行解读。
(点击放大图像)
不断增强的颠覆性环境
精益业务分析的发展是如何响应不断加速的变化步伐的？
全球趋势
在全球范围内，人类的历史一直是一种进步变革，充满了突如其来的革新。过去千百年来，狩猎- 采集者开始定居成为农民。在过去的几百年中，土地工作者不得不重新接受培训，进入工厂工作。然后大约 50 年前，电子计算机化使得知识性工作者越来越重要。
每次变革都使得工作模式和可能性发生变化。Gordon Moore 发现技术能力大约每年提高一倍（摩尔定律），其描述了环境会以不断加速的步伐改变自我。如今我们已经经历了一波又一波的数字化浪潮，造成了一个以可穿戴设备、物联网和大数据为主的世界。
现在我们正处在一个‘数字化颠覆’、功能不断变化的时代，并期望引起动荡的商业环境。一旦组织确定了如何为客户提供服务，世界将围着它们而改变——越来越复杂的技术开发组合、监管的变化、自然灾害、全球经济危机和客户期望的改变。
局部问题
在较大的全球画布内，局部尺度上也发生着重大的颠覆性事件。
在 2010 年 9 月和 2011 年 2 月，新西兰南岛被两大地震重创，导致 Christchurch 和 Canterbury 周围区域大量的人员死亡和基础设施（公用设施、道路和建筑物）的严重破坏。
在第一个100 天的初始响应中，组织需要_ 明确、迅速的指导_——比如当帮助保险公司处理几乎一夜之间出现的成千上万的索赔时。
随着复建工作的开始，人们越来越将注意力集中在必要时生产必要的东西，与合适的人在合适的时间携手合作，从一开始就内置质量，和避免不增加价值、不必要的步骤。这四种价值在如何处理我们工作中越来越根深蒂固。
例如，复建涉及到史无前例的拆迁、维修和建设活动，需要协调才能成功。新西兰土地信息部门发起了 ForwardWorks 项目，为即将开始的工作建立一个基于地图的查看器——包括地上和地下。这项工作的紧迫性、复杂性和重要性意味着需要一种全新的业务分析方法。
涉及第三方服务的政府资助的项目应该遵守正式投标申请书（RFP）流程。然而，这是一个新颖的解决方案，不可能被事先定义。因此我们使用轻量级的文档来描述我们的需求，这足以让供应商了解我们希望实现的价值，和需要解决的问题，同时又不会限制他们的创造力。
涉及到的利益相关者非常多：从建筑工人、设计师和规划师到地方和中央政府。在交付过程中我们必须让所有这些人参与进来，同时还要考虑到很多人没有任何定制软件开发项目的经验。
为了确保内置质量，我们构建了功能原型以此获得共同的理解，和在生产过程中进行微调。
最后，为了维持最低限度的报告和治理，我们授权主要负责人决策的权利，并将他们与正式项目管理办公室流程进行隔离。
如何应对变化
当遭遇任何类型的颠覆时，我们要有能力感知变化，迅速评估影响，发现其中的机会，探索可能性，选择一个解决方案，比其他任何人更早进入市场，甚至是在市场变化之前。
虽然业务分析的发展是通过明确需要变化的内容来帮助变化，但是它出生在一个契约驱动的世界里，在这个世界里，在任何人开始工作之前每件事都必须确定和协商一致。这种严格的治理手段减缓了工作进度，比如获取所需变化，了解对人们、流程和技术的影响，制定交付价值的方法同时将影响降至最低的工作进度。
随着组织使其方法适应变化和发展，以应对数字化颠覆带来的挑战和机遇的过程中，他们发现传统的业务分析和项目管理实践妨碍了价值的交付。
在此背景下，_ 精益业务分析_ 概念找到了一个现成的家。精益业务分析首次公布在 AgileNZ Conference 会议上，主要原则被表述成四种价值观（作为对敏捷宣言本身表达敬意之意）——目前这一方法被认为适合和有益于使用任何方法、任何类型的项目。。
‘精益’业务分析
使用术语“精益”是一个谨慎、有意的决定。该术语起源于日本的精益生产方法，其是组织采用的一套系统方法，通过识别不能向制成品添加价值的作业，消除浪费。我们已经重塑了最初的七种浪费形式（Muda），使其在一定程度上有意义于知识型学科，比如业务分析。
未成品
太多的在制品会限制开始新的产品，对生产率有着显著的影响。我们需要确保产品已经准备好能够为团队所使用，在 JIT 基础上为事情考虑一个合适的细节层次，将其留到最后责任时刻而不是最后一刻。
不必要的特性
从事不必要的特性会浪费能够增加价值特性的时间。有时我们的动机是付出额外的努力，做出使客户惊讶或者取悦客户的特性。如果这些是客户需要使用的特性，那么没有问题。特性使用报告表明接近三分之二的特性很少或者从来没有使用过，而只有五分之一的特性总是或者经常使用。我们需要关注那些能够构建最小、讨喜产品的特性。
以竖井的方式工作
当人们不坐在一起工作时，移交工作时通常需要附带文档以说明怎样会更好，从而覆盖面对面的移交。每当我们这么做时，在翻译中我们会丢失一些内容，造成项目延期。因此，我们需要与团队在一起，至少在一起的时间要等同于花费在利益相关者和客户身上的时间。
不必要的流程
强制完成不增加价值的步骤减慢了进度并降低了生产力。例子包括不必要的治理，欠妥当的测试或者额外的署名（sign-offs）。我们需要有足够的自信向其挑战，倡导更简单的流程（一些 BA 擅长的）。
环境切换
在同一时间忙于太多不同的事情效率是低下的。每次我们在不同任务环境中切换时，我们会浪费从心理上放下某一环境的工具，和从心理上为下一个环境工作做好准备的时间。某些报告指出每次大环境的切换浪费的时间高达 20%，因此如果我们同时忙于数个项目，我们会冒着拥有极少生产时间的风险。为了取得任何进展，我们需要组织我们的工作，这样我们可以每次专注一件事情，至少45 分钟。
排队等候
我们会把时间浪费在以下几个方面：等待利益相关者做决定，等待关键人物可用，或者在开始我们工作之前等待更早工作任务的完成。这往往会导致人们急于完成任务，进而导致犯错误。我们需要将工作分解成更小的块，提高工作流程，进一步加强协作，这样就不会有人没事干或者事情太多。
返工
如果没有从一开始就内置质量，就会出现问题。越晚发现问题，修复的代价越高。糟糕的需求会带来糟糕的设计，模糊的需求可能是不可测试且不合适的。这会减慢交付和影响客户。我们需要花费足够的时间第一次就将其做对，并意识到这不单单是我们的责任，还涉及其它规范，因此这是一个团队的努力。
知识的囤积
最后，对于最初的这七种浪费形式，第八种浪费形式，知识的囤积变得越来越普遍。在知识密集型的工作中，比如软件开发，组织变革或者工艺改进，分享知识是至关重要的。在跨职能团队中协同工作，我们需要分享我们的知识，提供结对工作使我们可以互相学习。
有哪些变化
在你的组织内执行精益业务分析时，以下这些变化是你希望看到的：
最后责任时刻
我们第一个价值宣言是‘必要时再生产必要的东西’：
这样做的实际影响是，重新思考活动和产量的时机和频率。按照传统方法，很多时候在开始任何设计之前，我们会提前进行所有的分析。一旦设计、开发或者测试已经开始，当发现新的范围或者变化会造成大量的返工，或者因反馈导致大量的返工。
按照‘最后责任时刻’的原则，我们应该专注于仅仅当必要时才生产必要的东西。有时，在项目开始的阶段最后责任时刻做事也是正确的。例如一个复杂的架构决定将会对许多依赖区产生影响。
及时协作
我们第二个价值宣言是‘与合适的人在合适的时间携手合作’：
这样做的实际影响是，重新思考我们如何合作的时机和频率。按照传统方法，很多时候我们都以竖井的方式工作，可能会跟一些关键利益相关者讨论业务，但是直到万事俱备我们不会跟其他任何人讨论。这往往会导致所做的决定无视约束和依赖，导致进一步的变化和返工。
按照‘及时协作’原则，我们应该识别并将交付领域的关键利益相关者与上下游的关键利益相关者集中在一起。例如邀请产品经理与销售、营销、结算和客户支持的利益相关者一起——当然算上交付团队的代表。这会带来更好的“联合思维”和更早识别并缓解风险。
一次做对
我们第三个价值宣言是‘从一开始就内置质量’：
这样做的实际影响是，重新思考我们如何确保我们的生产符合目标。按照传统方法，我们通常会遵循需求文档模板，然后在将其传阅给更广泛的利益相关者之前拿给同行评审。这往往会导致为了完成模板而填写章节，而不是专注获取什么能够代表业务价值。
按照‘一次做对’原则，从一开始我们就要明确定义可交付成果、验收标准和参与人员。例如我们如何获取该解决方案需要实现什么——无论是需求文档或者具有优先级的特性、史诗和故事的待办事项。在考虑我们需要如何做才能完成这个时，我们应该同意验收标准，它使我们知道完成的标准。最后，通过及早让关键利益相关者参与，在进展中我们能够验证和确认我们的工作。
根据需要尽可能减少步骤
我们最后的价值宣言是‘避免不增加价值、不必要的步骤’：
这样做的实际影响是，重新思考我们遵循的流程，以支持交付的努力。按照传统方法，通常我们必须遵守软件交付生命周期，它是由项目管理办公室定义的。这意味着我们经常为了表象而‘做表面文章’。我们不是去挑战现状，而是为节点评审会议准备文档，结果却发现与会者还没读过这些文档。
按照‘根据需要尽可能减少步骤’这一原则，我们努力减少或者删除不能增加价值的流程步骤。例如倡导以风险为基础的质量方针，这样使得较简单区域的规范和测试更简明扼要，而高风险区域的规范和测试更详细。
除了具体化价值宣言中的四项原则外，还有一些其它方面你也应该期待看到变化。
一图抵千言
业务分析已经发展成一种文字游戏，一种平衡做法（尽可能准确地捕捉人们的需求和进行清晰的沟通以确保最终产品满足这些需求之间的平衡）。这就是为什么经常我们会有如此冗长的需求文档。然而，最成功的业务分析从业者能够将语言与视觉语言技术相结合。
按照‘一图抵千言’这一原则，你可以用更简洁的方式使沟通比只用文字更加生动。视觉促进技术方面好的案例有，影响地图、关系图、故事板、价值流或者流程图。在白板周围面对面站着，我们可以记录我们听到的并立即确认我们的理解，然后简单地拍张照就可以捕捉商定的成果。
着眼于大局
由于我们的角色需要我们分析性思维，因此我们不得不思考系统的组成部分和它们应该如何协作，这样如果需要改变，我们可以了解改变造成的影响。然而，深入关注使我们很难看到大局，意味着我们不能感知趋势或模式，不能对此作出适当的响应。
按照‘着眼于大局’的原则，我们需要培养我们全面思维的能力。我们应该努力从大局入手，即使是有人带着他们需要的、具体、详细的解决方案过来——因为这通常能够解决错误的问题。我们也应该努力维持对更大的局面的感知，甚至是当我们从事一些细节工作时。有助于全面性思维技巧的好案例有，目标对齐工具，能力分析或者业务价值界定。
从顾客的角度考虑问题
我们的利益相关者和赞助商几乎都深埋于组织。这意味着，改变或者改进通常是基于使事情更有效率、由内而外地思考系统如何与客户交互的基础之上。然而，仅仅更快或者更廉价地交付一个糟糕的客户体验最终不会起到帮助作用。
按照‘从客户的角度考虑问题’的原则，我们需要鼓励‘由外而内’思考问题，优先考虑客户为什么选择使用我们，他们有哪些经验，我们需要从哪里改进，然后识别浪费并找机会改进。客户思维艺术的好案例有，卡诺分析、角色模型或者客户体验旅行地图。
跳出条条框框思考
按照惯例，我们常常使用工具和技术，这使我们能够放大问题，从整体到细节，从而找到问题的正确答案。很多时候，这种线性收敛思维限制我们的选择，使我们陷入开始的地方。
按照‘跳出条条框框思考’的原则，我们需要从发散的、非线性方式开始，通过探索相邻（甚至是以外）范围内的思想，与关键利益相关者协作，引入不相关的人员从而获得全新的视角。一旦我们已经探索过不同的组合，发现暴露的问题，那么我们就应该仍然采用收敛法来缩小问题空间和潜在的解决方案。幽默思维技巧的好案例有，比如‘时间机器’的商业管理策略，‘脚本撰写一个电视节目’，‘Brain Swap’或者是‘Show Me The Money’。
迈向精益业务分析
如果你觉得上述价值和原则是令人信服的，那么精益业务分析就适合你，你需要考虑如何开始。不管你是承包商、长期职员或者就职一家咨询公司——所有的旅途都始于足下。
当期待将其作为组织范围内的改变引入时，我们强烈建议首先要确定有对改变的渴望。考虑组织对改变的准备程度如何时，有一个强大的工具是 ADKAR 变更管理模型。该模型可以帮助我们思考是否能够意识到机会，是否渴望改变，是否知道需要改变什么，他们是否具备做出改变的能力，或者改变是否已经开始和需要加强以维持改变。
一旦我们了解到人们已经在做准备，我们就应该寻找一个事件或者目标帮助人们了解改变的紧迫感。有时这些是大量的外部事件，但是往往我们必须着眼于内部，找到让事情成真的证据。例如，当感知到项目过分拖沓时，是否是因为花费了太多的时间才让产品交付到真实客户的手中？
小步骤，快速见效
我们强烈建议采取小步骤，实现快速见效。即使你想要进行重大的改变，也应该将其分解成能够尝试和获取反馈的小块增量改进。
庆祝胜利非常重要，并商定如何在成功的基础上继续实施改变。透明化哪些不起作用，了解如何回滚和考虑如何调整方法也很重要。
建立一个粉丝基地
如果你希望实现实质性的改变，那么你需要能够支持你和指导你的赞助商。
不管怎样，重要的是寻找志同道合和同样对改变有需求并乐于贡献的人，即使只是赞成尝试不同的活动和你将生产的可交付的成果。
结论
最后，重要的是坚持下去，继续寻找下一步可尝试的微调。与你的同事讨论成功，推动有成效的实践使其成为更常用的实践，倡导定期回顾，讨论精益业务分析是如何被接受和如何继续发展。
更多有关精益业务分析宣言的信息，请访问 Assurity 网站。
关于受访者
David Morris是 Assurity 的首席顾问，一名工作在新西兰的交付顾问。他带领了一个顾问团队，提供流程、项目和组合分析的交付；战略咨询、实践和变更管理的交付；并提供课程、教练和指导的交付。在项目交付上拥有超过 30 年经验，他曾按照结构化、迭代和敏捷的方法跨战略、业务和技术项目工作、带领团队和运营自己的业务。David 拥有国际商务 MBA，是一名经过认证的 BA 专家，ICAgile 认证从业人员，经过认证的 ScrumMaster，职业 Scrum 产品负责人，和 IT 认证专家。他经营着学习小组、职业发展研讨会和训练营，帮助组织 Agile Auckland 和 IIBA NZ 会议，曾在欧洲和澳大利亚会议和活动中演讲。他还撰写并促成了数本图书（包括 Agile Project Management in easy steps，Agile Project Estimation and Planning，和 the Agile Extension to the BA Body of Knowledge）还是一名活跃的博主、Tweeter 和维基百科编辑。
评论