回到主页

CX DevOps:数字化客户体验与研发运营一体化的融合(CX与研发效能篇)

 

编者按:作为一名混迹客户体验领域多年的实践者和旁观者,如果要总结企业在实施客户体验计划中的关键障碍,抛开文化和技术这些普遍基础性因素,具体操作层面可以归纳为五个主要方面:

 

1)从一开始起就缺乏整体的客户体验战略;2)未能实现向敏捷工作模式的转变(或者根本没有意识到);3)缺乏高效、有力的数据治理体系;4)缺乏端到端的数字化客户体验设计能力;5)自身的数字化研发效能低下。

 

在寻找以上五个方面的问题解决方案时,看到了很多不同专业领域的专家对这些问题的思考,挑选了其中比较有启发性的文章和报告陆续分享出来,本次是关于客户体验与研发效能提升的一篇文章:《The Emergence of CX DevOps: Integrating DevOps with Digital Customer Experience》,作者是半导体巨头博通公司(Brodacom)研发运营一体化首席技术官(DevOps CTO)Shamim Ahmed,以下为正文:

 

 

显然,DevOps也能很好地满足数字化客户体验的需求——通过让企业高速交付创新——这对于成功的数字化转型至关重要。同时,通过将客户体验作为主要(或附加的)的“质量”指标引入DevOps,将有助于团队在整个IT组织中创建以客户为中心的文化,这一点与DevOps本身同样重要。

虽然更容易理解客户体验是如何从应用DevOps中得到改进,但同样值得注意的是,DevOps(以及软件交付的基础学科)是如何从二者的交叉融合中得到提升的。例如,Standish Research的数据(见下图)显示,只有20% 的企业软件被实际使用频繁,而 50%的功能很少使用。这意味着,尽管我们尽最大努力定义以超高交付速度来交付适当软件的需求,但实际上我们提供的产品只有不到50%被消费者实际采纳和使用。这表明我们可能没有广泛采用以客户为中心的软件开发方法,而DevOps本身可能会通过采用客户体验驱动(CX-Driven)的方法而从中受益匪浅

broken image

 

鉴于CX和DevOps之间的这种共生关系,我们看到企业越来越多地将这两个学科融合在一起。在这一趋势的演变过程中,我们看到了一个可以被称之为“客户体验驱动的研发运营一体化(CX DevOps)”的新学科的出现。

 

最近流行通过在“Ops”前面附加一些流程名称来命名与DevOps相关的新学科——例如,测试运营(TestOps)、业务运营(BizOps)、智能运营(AIOps),这也仅仅是几个例子——所以有人可能会想称它为CXOps(甚至是DevCXOps),这在我看来都很好(一个名字能代表什么呢?)。但是,我们认为CX DevOps这个名称是最合适的,因为这意味着CX才是我们如何以与众不同的方式实施和应用DevOps的关键驱动力,反之亦然。

在本文中将就我们的这些观点进行讨论,即如何将CX集成到DevOps生命周期中,以提供更好、更快的数字客户体验——并在此过程中同时改进CX和DevOps。我们还将讨论可用于支持CX DevOps的具体技术和工具,但不会再单独讨论DevOps和CX各自作为一门学科的专业细节,因为这些内容在各自的领域都已经有非常详细介绍。

最后一点,由于讨论的关于“数字化”CX,我们不会讨论CX更“传统”的方面(例如,涉及客户服务代表、实体店等非数字渠道的实体交互)。然而,随着企业走向数字化,我们看到越来越多“传统”的客户体验正向数字化客户体验转型,或者受到影响(例如,现在可以通过麦当劳使用店内点餐机而不是在柜台下单)。在本文的其余部分,我们将使用CX来代表“数字化客户体验”。

此外,我们假设数字化用户体验(以下称为UX)是CX的一个子集(见下图)。在数字化CX的大背景下,数字化UX则与具体产品和服务的交互体验相关。

broken image


一/将CX集成到DevOps生命周期中

Integrate CX Into Devops

——————

就其本身而言,DevOps和CX的生命周期都已经是众所周知的成熟概念,这里不再赘述。因此,让我们看看关键CX流程如何映射到DevOps生命周期(见下图),以及原生DevOps流程如何随着对CX的关注而变化。

broken image

以下是每个映射流程的简要说明。

二/以CX为中心的规划和需求

CX Focused Plan&Requirement

——————

敏捷交付中的需求规划和定义通常侧重于特性(Feature)和用户故事(User Story)的开发,被用作为产品所有者、产品经理、开发人员和测试人员之间的一种协同训练。这些新需求(特性和用户故事)通常来自他们对用户和客户需求的理解,以及各种互动和反馈会议。通常,这些反馈机制是有组织和结构化的(例如,客户咨询委员会会议、客户提出的正式要求,或者来自客户支持的工单)。

基于CX的需求提供了一些额外的途径,从数字反馈渠道来收集以上这些数据。用户在多个渠道上提供各种反馈,例如社交媒体、应用商店和评论网站、购物网站(如亚马逊),以及应用或网站内部反馈渠道。这些非结构化的、数字化反馈渠道拥有大量宝贵的信息,用户在这些渠道里宣泄他们喜欢(或讨厌)的功能、存在问题的体验、他们希望看到的功能,以及与竞争对手产品和解决方案的比较,最后一点尤其有价值。

CX分析(如客户情绪分析和社交聆听) 允许我们分析这些数据,以得出可用于需求规划和验证的洞察(见下图)。

broken image

基于CX的需求必须重点考虑客户旅程地图(Customer Journey Map),以便更好地理解和优化用户与数字化系统的交互流程。客户旅程分析(Journey Map Analysis )通过在交互过程中接入有价值的数据,可以输出最常见的行为路径(以了解用户行为和性能测试需求)、阻碍因素(需要优化的路径)、全渠道交互模式(例如数字化渠道组合及其有效性)。这些数据可以从各种来源中提取,例如监控、操作日志、应用程序事务跟踪,甚至是Web网站的行为跟踪。(见下图)

broken image

对于以CX为中心的需求,一个非常关键的方面是对需求的早期用户验证(也就是说,我们是否构建了正确的东西?)。虽然特性和用户故事非常适合从开发人员的角度捕捉需求,但从用户角度很难解释并与之交互。更好的客户验证方法是使用基于模型的需求技术。为什么?因为一图抵千言!

基于模型的需求提供了用户工作流程(相当于旅程地图)的可视化表达(见下图),易于理解(无需阅读文本描述),修改起来更加容易(无需更新文本正文),允许快速迭代和实验。最重要的是,它提供了一种结构化的需求验证方法。还有一些其他方面的好处,我们将在稍后的测试部分讨论。

broken image

基于模型的需求实际上与我们开展敏捷计划的方法非常一致。这个过程不是从描述用户故事开始的,通常是“3 位老朋友”(产品负责人、开发人员和测试人员)聚在一起,在白板上画出流程草图(见下图);然后他们对流程进行拍照分析,并得出他们具体的用户故事、验收标准和测试用例。这个过程通常不仅会导致对需求的误解,而且一旦白板被抹去,还会限制协作(例如迭代出现变更)。

broken image

基于模型的方法提供了一个“实时”数字画布,以交互式的方式(在房间内或使用在线协作工具)绘制、讨论、更改和改进这些流程。从CX的角度来看,我们建议在三人组合(3-Amigo)中添加一个新角色——用户(或用UX/CX专家替代),形成一个四人团队(4-Amigo)(见下图)。

broken image

 

此外,将客户旅程图与需求模型集成起来,可以帮助跨越CX需求和系统需求之间的鸿沟——通过将流程信息(通常是客户操作和触点信息)导入需求模型。(见下图)

 

broken image

产品所有者和经理经常使用最小可行性产品 (MVP) 方法来确定发布中优先考虑的特性集。从CX的角度来看,我们还需要关注结合了MVP的最小可行性体验(MVE) 方法,MVE更关注解决方案从用户角度的可获得性。它考虑了基于人物角色(Persona)的客户旅程、易用性体验、个性化,以及最小客户期望(例如来自对竞品或类似产品的使用)。

我们建议结合MVP和MVE方法进行敏捷规划(见下图),这样可以提供一种更加平衡的方法来设计和交付最具吸引力的最小可行性体验和特性集。有关敏捷产品开发场景下此方法的更多详细信息,请参阅另外一篇文章:《Minimum Viable Experience (MVE): Balancing experience and features for your product / service》。

broken image

 

三/以CX为中心的设计和开发

CX Focused Design&Develop

——————

如MVE方法中所述, 以客户体验为中心的系统设计还需要考虑客户旅程、易用性体验 (UX)、个性化、提供反馈的能力,以及协作。设计思维是一个被广泛采用的学科,可以应用于整个软件生命周期。它涉及更多地使用同理心地图 (作为客户旅程地图的一部分)、故事板、原型设计和早期(以及持续)用户验证。

如上一节所述,这些资产可以与需求模型(我们在上一节中讨论过)相关联,因此它可以成为满足所有需求(包括CX和技术)的单一事实来源,并充当跨越两个学科的数字化协作和实验平台。

许多企业也开始利用低代码(Low-code)软件开发平台支持开发中的设计思维方法。实际上,低代码系统就是将代码抽象为设计模型。因此,需求模型和设计模型之间存在很大的协同作用——这样能促进在整个生命周期中进行基于模型的思考。

另一个有助于促进CX的关键DevOps开发实践就是基于API的开发。API不仅提供了快速构建全渠道应用程序的能力,而且还支持跨多个数字生态系统的数据连接,这是提供端到端无缝客户体验的必要条件。

四/以CX为中心的测试

CX Focused Test

——————

以CX为中心的测试通过对“形式”(除了功能和性能)的额外关注,对标准软件测试实践进行了拓展,标准测试和CX测试之间的一些主要区别如下所述。(见下图)

broken image

CX测试非常关注验证(即我们是否构建了正确的东西)上述CX需求形式表达的客户需求,测试过程中可能使用的方法包括用户评论、原型设计、最终用户测试、众测、beta测试、A/B 测试等。CX验证测试更侧重于确保满足CX设计规范(如上所述),包括符合UX设计标准、UX测试、个性化需求、最终用户性能测试等方法。

与经典的软件测试(特定测试与特定期望相关联以明确是否成功或失败)不同,CX测试在通过/失败标准的确定性通常较低。例如,来自UX测试或最终用户众测的结果通常是灰度和主观的(例如,“酷”、“有点”、“可通过”、“糟糕”等),而不是离散和明确的通过或失败,这类测试必须利用统计分析工具来输出一些结果,例如平均值、趋势、分布、范围等。

CX性能测试侧重于从用户的角度来感知性能,而不是用经典的性能测试方法来度量后端系统的响应能力,包括了解具有不同计算能力、并使用不同网络连接的数字访问设备(例如笔记本电脑、移动设备和可穿戴设备)的性能。最终用户性能测试的典型设置如下图所示,包括终端访问性能的测量、网络性能的模拟,以及对后台性能的测试。除了负载测试之外,还必须在生态系统的所有层面进行弹性测试。

broken image

在上一节中,我们讨论了将基于模型的需求形式与客户旅程图相结合,这实际上也可以帮助我们基于旅程地图进行更好、更有效的测试——从客户旅程地图模型自动生成测试,这些测试可以在每次地图发生变动时自动重新生成,也可以使用各种自动化测试工具实现自动化。(见下图)

broken image

我们知道CX/UX 测试需要对软件的用户界面(或 图形用户交互界面,GUI)进行大量测试,而经典的软件测试金字塔建议我们更多地关注单元和组件测试。使用功能性自动化工具(其中一些上文已经提及)开展自动化GUI测试模式通常很脆弱,难以创建和维护。那么,该如何解决UX/CX所需的更多更好的GUI 测试需求呢?答案可能在于更广泛利用人工智能和机器学习这些新时代的测试自动化工具,例如 Test.ai (其他类似工具包括Applitools、TestiM、mabl等)。这些工具使用图像/对象识别技术来自动生成健壮的、低维护的GUI测试,这对于CX测试自动化特别有用(见下图,由Test.ai 提供)。

broken image

例如,Test.ai 被用来创建测试机器人,在黑色星期五购物季之前自动计算三个最常用的在线购物网站(亚马逊、沃尔玛和塔吉特)的各种用户体验指标,具体情况请参阅下图中的结果。虽然这些测试可能看起来很简单,但这里的关键因素是这些测试不需要人工干预,机器人自主学习如何在这些不同的站点进行浏览(针对不同的客户旅程类型),并自动收集数据进行比较。我认为这些工具与经典的GUI自动化工具相结合后,在未来有很大的应用潜力。

broken image


五/以CX为中心的部署和发布

CX Focused Deployment&Release

——————

CX发布通常需要对多种选项进行试验,以更好地测量用户反馈和响应。可使用的常见软件部署和发布技术包括A/B部署(用于支持 A/B 测试)和金丝雀发布(又称为灰度发布,译者注)。这些技术在DevOps中的应用已经非常成熟,因此在支持CX目标方面能起到很大的协同作用。从CX角度来看,我们需要的关键扩展是作为这些实验的一部分,除了标准的IT监控之外,还结合CX监控(也就是客户体验领域常说的体验测量,译者注,参见下一节)

六/以CX为中心的监控和反馈

CX Focused Monitoring&Feedback

——————

我们已经利用传统的IT系统监控来实现更好的客户体验,例如通过更快的自动化根因分析(RCA)和修复、主动性能管理、真实用户监控 (RUM)、综合事务监控和交易监控来跟踪用户交互的每一步,从终端到应用程序,再到最终的业务结果。

以CX为重点的监控通过提供更多与CX问题相关的洞察来扩展IT系统监控,比如客户对产品或服务的满意度(例如,通过应用商店评论或其他数字化反馈渠道提供的反馈)、其他形式的情绪分析(例如来自问卷调查数据的反馈)、跨多个数字渠道的无缝体验(例如先试网络聊天,然后是电子邮件)、无法实现与客服代表的连接和交互(通过语音/网络聊天/短信/电子邮件等)、交互的质量,以及客服代表在聊天交互时的响应时长等。

例如,在我最近一次通过在线聊天中与客服代表互动时,我竟然无法通过在线聊天界面(!) 提供受影响产品的图片,最后我不得不通过电子邮件单独发送。但是,我很快了解到,我向在线客服提供的所有上下文材料都没有无缝地转移到通过电子邮件回复我的客服的代表(!!!)。尽管这在技术上只是一个IT问题,这两个渠道都是数字化的,但IT监控系统通常无法捕捉到这些类型的问题。

我们还发现,CX相关的监控数据通常来自市场营销(或来自CMO办公室的角色,如客户体验专家) ,而IT监控数据由CIO办公室使用(如站点可靠性工程师或SRE)。由于各种孤岛的存在,他们看到的仪表盘通常都是互不相通的。因此,有很多机会将此类CX监控数据与IT监控数据相关联,并使它们更好地协同工作,以实现整体的CX目标。(见下图)

broken image

例如,可以将应用商店(或Web应用)版本升级后的负面客户情绪数据(CX运营数据)与上次升级中包含的特定功能集(IT运营数据)进行关联分析,以加快回滚(或前滚)决策。


七/总结和关键要点

Summary

——————

将CX与DevOps相结合,可为两者都带来显著优势。CX计划显然可以利用DevOps的能力,以更快的速度、更高的可靠性地将创新推向市场。另一方面,将CX融入到DevOps实践中提供了度量数字化转型是否成功的真正质量标准——客户体验。

DevOps现在是一个相对成熟但发展迅速的学科,但数字化CX仍在走走向成熟过程中。随着越来越多的企业开始实施数字化转型,他们将意识到将CX和DevOps方法的中优点结合起来会带来的巨大好处。

——完—— 

 

关注UXTOOLS了解更多体验专业知识

broken image