决胜未来:银行重塑的5个原则

[摘要]

金融科技的浪潮彻底革新了人们对金融服务的认知。银行必须将其商业模式,从传统的赚取差价和隐性收费,转变为未来超个性化的模式,提供更公平的金融服务产品,为用户提供新的不同方式的价值。在接下来的几年中,银行利用其体量、规模和资产优势,并提供不同于新兴金融科技公司的差异化服务,未来可期!

“客户对服务的预期不再拘泥于行业传统。我们的金融服务水平如何,与非金融数字化品牌打几个回合下来便见分晓。”

——桑坦德银行首席运营官,MICHAEL HARTE

引言

传统大型银行的市场,正在被一寸寸蚕食——无论是小而美的初创企业,还是科技巨头组成的金融科技新势力,都想要来分上一杯羹。这局面好似“毕加索吃鱼”,风卷残云。传统银行怕是要从未来人们的生活中消失了吧?如此前卫的畅想,你我可能感到过于激进,而33%的千禧一代则认为,哪怕一辈子不踏进银行的大门也无妨。如此一看,这想法似乎并非无稽之谈。

谁对银行构成了威胁?可能并不单单是Amazon这个体量的竞争对手。相反,银行的收入来源正被一系列新对手不断侵蚀:SquareStripe改变了企业的收款方式;StarlingRevolutSimple打破了银行需要分支机构的执念。Facebook和Google之类的已知巨头,正迫切想控制客户的钱包,改变人们对支付、使用金钱和信贷的方式。传统银行的业务正在被全方位侵蚀。

花旗和汇丰是竞争对手吗?当然。但最激烈的财富争夺战,却来自一些不常见的竞争对手。桑坦德银行的首席运营官Michael Harte说得很形象:“客户对服务的预期不再拘泥于行业传统。我们的金融服务水平如何,与非金融数字化品牌打几个回合下来就见分晓。”简单说,人们对花旗和苏格兰皇家银行这些传统金融机构的期望值,与世界上Google、Facebook和Uber等科技巨头相当。更可怕的是,当前全球四分之三的千禧一代表示,比起传统的银行服务,他们对谷歌、亚马逊、苹果、Paypal和Square提供的金融服务更感兴趣。

除了新竞争对手入场,监管机构也开始对银行进行全方位轰击,这让银行不得不改变思维,拥抱变化。即将生效的《通用数据保护条例》(GDPR)迫使欧盟的银行重新考虑获取和处理客户数据的方式。同样地,《欧盟支付服务指令》(PSD2)削弱了银行对其客户账户信息和支付服务的垄断地位。

形势是瞬息万变的。中国自不必说,仅仅移动支付支付宝和财付通就占据了90%的市场。在韩国,其最受欢迎的消息应用程序Kakao推出了一项银行业务。在短短五天内,Kakao银行累计注册80万个账户,获得6.15亿美元存款,放款5.6亿美元。

(Kakao银行在运营3个月内揽得435万用户)

大局如是。银行业应当如何应对?金融科技并非全新的产物,银行业大佬与科技界新秀对弈也算不上是新闻了。我们认为,银行必须将其商业模式,从传统的收费和隐性消费,转变为未来超个性化的模式,提供更公平的金融服务产品,为用户提供新的不同方式的价值。在接下来的几年中,面对重重挑战,银行业有望利用其体量、规模和资产,提供不同于新兴金融科技公司的差异化服务,后发制人,决胜未来。

“传统银行需转变观念。是要做“银行”还是“信用卡”公司,或者想要成为客户的合作伙伴,通过提供现金和投资专长帮助客户和企业实现资产管理目标?”

——ThoughtWorks金融服务产品组合总监,ANEESH LELE

那么,

银行服务能够渗入到客户日常生活的方方面面吗?

银行能否重构自己的商业模式,为各类群体提供更好的金融服务?

银行能否实现革新,变得更智能、更公平、服务体验更流畅?

答案是肯定的。从下列五项原则入手,银行可以实现业务重塑。

原则1:挖掘客户意图和期望

银行向客户推出特色服务并不算什么新鲜概念。但 “特色” 仅仅是就产品本身而言,并不聚焦到特定的客户群。比如,向刚办理过信用卡不久的客户推销新的信用卡,给当下正积极储蓄的客户提高信用卡额度,再如对不开车的客户赠送燃油积分等等,这样 “不在点上” 的特色服务比比皆是。银行是金融数据盛宴的特权嘉宾——客户喜欢在哪里用餐、喝酒和购物都在数据中反应,银行可完全了解。然而,这些数据尚未被合理利用,历史数据既未曾被银行主动挖掘产生价值回馈,也没有将客户潜在数据收集并不断扩充。

何不对交易和财务数据进行分析,为客户提供个性化的指导?美国Mint和Clarity Money这样的公司已经在为客户提供这些银行业的周边服务,帮助他们的用户设置预算,支付水电费,并告知他们在哪些方面可以降低花销。如果想做得更好,何不将这些服务与客户的意图进行关联?为银行业服务的聊天机器人公司Personetics的报告显示,54%的客户期望银行理解他们的长期财富增值目标。银行可以使用会话界面了解客户想要实现的目标。顾客可能会说“我想九月份去罗马旅游”或者“我想存款,在2022年供我女儿上大学,不用贷款”。如果是银行可以帮助他们实现这些任务呢?银行可以创建一些特殊优惠和自动储蓄计划,于发薪日在独立账户预留资金。有许多应用程序可以帮助用户做预算,总结分析和展开投资,但这些服务是碎片化割裂开来的。银行有这个条件将这些业务串联起来,成为人们金融生活的中心。

传统银行拥有大量消费者的数据,这是一个巨大优势——比如,摩根大通应用程序每月有2500万活跃用户!初创公司及各种新对手,如果能有这种级别的用户量,简直要笑开了花。但正如Kakao的例子所示,境况可能是瞬息万变的。银行需要不断迭代其数字体验,成为客户日常生活的场景中的高频交互对象,可以通过多种渠道挖掘客户的意图,如:呼叫中心、银行应用程序或其分支机构。会话式界面将在这个场景中大有助益。

LEMONADE

想到保险时你会想到什么?首先想到的肯定不是速度和效率。然而,这却是客户对Lemonade的反馈。这家纯线上保险公司承诺通过人工智能技术实现快速承保和理赔。这是使用科技重新规划客户体验的优秀典范。

等理赔结果时,再没有繁琐的文件材料和漫长的等待了。

通过简化理赔流程,公司开门见山处理问题,切中客户的需求痛点。流程中集成了会话界面、视频聊天和智能图像扫描,公司可在几分钟内支付理赔款——这与通常理赔时无休止等待形成了鲜明对比。

(Lemonade几分钟就可以处理保险理赔)

原则2:将产品转型为平台

现今世界上市值最大的10家公司中,有五家(即苹果、谷歌、亚马逊、Facebook和微软)是从他们的平台战略中挖掘巨大价值。平台思维更是颠覆了零售业、音乐产业乃至CRM产业。这些企业的特点是拥有多重市场和API,其他企业可以采用“即插即用”的形式接入他们的平台,在这些平台构架基础上协力创造新价值。最典型的例子是亚马逊,亚马逊开放了自己的云基础设施,提供AWS服务。优步创立之初,使用的是谷歌地图开放的API接口来运营自己的业务。与垂直行业中的同类竞争对手相比,平台模式的企业可以获得更高的市价总值,所需雇佣的员工也更少(我们可以对比下Instagram和柯达,或者拿Airbnb和万豪酒店比下就一目了然)。

银行业是否能从中得到启发,借势一跃? 没有必要一切都推倒重来,未必必须从零开始创新。相反,对创意人员和合作伙伴开放你自己的平台,推动基于你平台的创新。Open Banking API可以让银行集成各类合作伙伴的数据和数字服务,为客户提供端到端的服务体验。而且银行拥有从平台战略获益的先天优势。他们自己本身就拥有海量数据,而现有的合作伙伴关系可以让生态系统加速发展。但是,若想转型成为一个基于平台的业务模式,这需要管理者从思维上进行改变。要放弃“我们的主业是为客户提供金融产品”,转向“我们也为开发人员、金融科技公司和其他企业提供接入银行API、SDK和匿名数据的机会”。如果能够为合作伙伴提供打造新型服务的便捷平台,那么这些银行将拥有先发优势——因为这可以快速累积网络效应,而网络效应也是平台能否成功的关键所在。

银行必须借用、购买或聘请技术骨干帮助银行从线性业务转向平台业务。采用平台策略后,就有了为优秀合作伙伴提供生态系统的可能性。银行因此就不需要方方面面都自己去创造、开发,事事擅长。相反,银行可以成为一个创新的平台。有时银行可能还需要包容竞争对手的产品,所以银行应该对“合作竞争”战略保持开放态度,以最大化发挥自身平台的优势和效用。

Starling Marketplace

Starling是英国一家新兴银行,致力变革银行服务方式,为所有人提供健康的金融产品。Starling的“Marketplace”是平台型API战略的最高表现形式。这样公司的客户就可以在一个APP内查看和管理他们的金融业务。好比一个专门集成金融服务和银行业务的应用商店。通过这种方式可以将其他金融科技公司和银行纳入Straling的生态系统,而不是将他们视为竞争对手,从而为客户提供更全面互补的产品组合。例如,信用评分供应商、贷款供应商和其他信贷服务方可以集成到Starling的API,然后展示在Marketplace界面上。客户随后可以选择符合自己需求的“应用程序”,定制他们的Starling体验。例如,居住在海外的客户可能选择Transferwise应用,通过这个应用能够以较低的费用迅速进行国际汇款。

(Starling银行的Marketplace将金融服务融入类似应用商店的界面中)

“Marketplace让我们专注于建立世界上最好的活期账户,同时为我们的客户提供市场中最好的产品和服务。”

——Starling的首席平台官 MEGAN CAYWOOD

原则3:投资隐私、安全和透明度

你的客户是否知道银行如何利用他们的数据?如果答案是否定的,那么英国和欧盟的银行就面临极大不合规风险——2018年5月25日,《通用数据保护条例》这个法规就要生效,它强制要求银行、比较网站和保险公司彻底重构客户获取和市场营销的策略。

但是顶级银行将不仅着眼合规,还将客户的隐私、安全和透明度作为一项资产。银行可以提供一个全面的数字身份,结合付款和行为数据来提高安全性并节省客户时间。想象下,数字身份证可以解决各种站点和商店频繁的密码输入需求。这样的身份证(ID)可以对用户进行身份验证,并可以让用户快速方便地获得电力、医疗保健乃至新话费合约等(没有繁琐的文件和审批周期!)

德意志银行

德国最大的银行正在为跨平台银行业务和服务创建单点登录数字身份。用户将能够使用一个安全的主密钥注册并登录各种服务。他们期望为数字支付提供一个单一源头。值得注意的是,德意志银行目前面临Facebook的正面竞争,因为Facebook也在做同样的事情。但德意志银行认为自己在客户账户安全性和隐私保护上更胜一筹,从而使自己的产品可信度更高。

原则4:拥抱市场迭代

各大品牌逐渐开始采用精益、敏捷的方法来改善他们的产品。这通常需要经常收集反馈意见和想法,并据此改进产品和功能。

在产品上市后,通过从社交渠道倾听和反馈更新产品和功能,改善后的产品就不会随着时间被堙没。这还有助于省去“发布-推广-维护-再次发布”这一昂贵的周期。收到反馈后可以开发更符合客户需求和利益的第二代和第三代产品。银行可以利用这种反馈决定是否“追加”或“中止”投资。如果在产品开发生命周期的更早期增加用户测试,可以避免产品经过漫长、昂贵开发周期后沦为败笔,并能在产品投入市场后对其进行改进。

特斯拉

埃隆·马斯克(Elon Musk)最近在推特(Twitter)上回应了客户的建议,并告知客户其反馈的意见将纳入即将发布的软件版本中,这一举措震惊了特斯拉公司的股东和支持者。

这一事件表明,产品的更新迭代和共同创造是一个连续的过程,不仅仅是停留在产品开发阶段。

(埃隆·马斯克倾听客户的反馈意见,改善上市的特斯拉产品)

原则5:提升品牌忠诚度

忠诚是由人文关怀、便利程度以及情感驱使的,而不是靠积分和可预测性。你的数字策略是什么?让你的策略更简单些。没有人愿意带着大量文件去银行开一个账户。想下哪些科技可以提升客户的体验,缩短乏味繁琐的环节。当Starling推出迅速响应的移动应用时,正是解决了这个痛点。新客户可以在3分钟内使用手机开设一个账户。客户不需要去银行分支机构跑一趟,也没有必要一张纸单据签字。最重要的是让客户满意并节省他们的时间,同时与有吸引力的福利和奖励计划相结合。未来客户在选择银行的时候,不会问“哪家的抵押贷款业务最便宜?”,他们的问题是“我的银行可以为我提供哪些服务?”以及“这家银行能够给我的生活带来什么便利?”

亚马逊Prime会员

当亚马逊(Amazon)要求其顾客通过付款获得特权的时候,亚马逊就颠覆了业界对客户忠诚度的传统定义。杰夫·贝佐斯(Jeff Bezos)非常相信这项服务的价值,如果没有加入这项服务他会说“你这个人不可靠”。与亚马逊网络服务(AWS)一道,亚马逊Prime一直是亚马逊主要的增长动力之一。会员的行为真的不一样,他们认为自己与亚马逊有着某种关系,因为成为Prime用户带来的心理影响,会员几乎不会考虑去其他零售商购买产品。会员资格使他们享受到一系列特惠,既有闪电般的快递,也可以在Prime视频上欣赏电影和节目。

为金融服务业找一个类似的方案将很有前景。银行可以通过付费会员项目向客户提供什么服务,使得客户不想离开呢?一揽子的旅行、房屋和人身保险,免费理财咨询,研究加密货币和初创投资,数字身份证——有许多服务可以添加!

(亚马逊Prime将客户锁定在亚马逊的生态系统中)

结语

未来已来,银行业的创新变革只争朝夕:金融服务应该是普惠的,所有客户都应该能在银行业务中享受到无缝的体验。终结Blockbuster命运的并非Netflix,而是用户对更好服务体验的青睐;在Netflix出现后,依旧固守付费模式的Blockbuster犹如经历一场困兽之斗。同样,在复杂的竞争局面中,面对客户众多的选择,银行服务需要围绕客户需求进行重组,避免客户流失。

你准备好迎接变革了吗?如果你已经尝试并失败过,不要有所怀疑。怀抱紧迫感,再尝试一次。大型零售商、媒体和交通运输企业的倒闭就是一个预警:没有任何企业因为自己伟大的过去就一定永存。变革不会按战略套路出牌,没有必要“单打独斗”,找到能引领你交付和执行的创新合作伙伴。银行不需要拥有创新能力去开发一切。相反,银行可以提供“创新即服务”,构建一个整合客户金融生态系统的平台。银行业现如今是在技术和文化层面战斗,因此需要升级团队和系统来体现以客户为中心的理念,并加快产品上市速度。问问自己:“我该如何帮助客户提升体验?如何帮助他们实现目标?”那些对“客户至上”和技术同样重视的银行,将重塑银行业,而跟不上变革节奏的银行将被时代遗忘。未来可期,祝你好运!


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

前端不止:Web内容的无障碍性

网民统计报告

根据2017年7月份发布的第40次中国互联网络发展状况统计报告:

截至 2017 年 6 月,中国网民规模达 7.51 亿,中国手机网民规模达 7.24 亿, 中国网民中农村网民占比 26.7%,规模为 2.01 亿。

截至 2017 年 6 月,中国网民通过台式电脑和笔记本电脑接入互联网的比例分别为 55.0% 和 36.5%;手机上网使用率为 96.3%,平板电脑上网使用率为 28.7%;电视上网使用率为 26.7%。

截至 2017 年 6 月,我国非网民规模为 6.32 亿。上网技能缺失以及文化水平限制仍是阻碍非网民上网的重要原因。调查显示,因不懂电脑 / 网络,不懂拼音等知识水平限制而不上网的比例分别为 52.6% 和 26.9%;由于不需要 / 不感兴趣而不上网的比例为 11.2%;受没有电脑,当地无法连接互联网等上网设施限制而无法上网的比例分别为 9.3% 和 6.2%。

提升非网民上网技能,降低上网成本以及提升非网民对互联网需求是带动非网民上网的主要因素。

信息无障碍

今天,我想讨论一个关键的词语——信息无障碍。

信息无障碍,英文词语来自“Accessibility”,是指任何人(注意是任何人,无论是健全人还是残疾人,无论是年轻人还是老年人等等)在任何情况下都能平等地、方便地、无障碍地获取信息、利用信息。

首先,我们要对Accessibility(无障碍)的一些错误认识进行一些纠正:这样一个词,很多人自然地跟残障人士联系起来,因为经常可以看到无障碍坡道、无障碍洗手间这样的词语。

信息无障碍更多强调的是对所有人都平等,方便的获取信息。比如:键盘上的F和J的凸起基准键。它的作用就是方便任何人可以精准的找到键盘字母的位置,从而可以在不看键盘的情况下,快速的打字,俗称“盲打”,大家都知道它的含义,没有人会把这个词理解为“盲人打字”吧。

(键盘基准键)

我国非网民规模为 6.32 亿,由于个人主观意愿,比如:不需要 / 不感兴趣而不上网的比例仅仅占11.2%。

那么,剩下的88.8%,也就是大约5.612亿人,是有上网需求的,但因为其他各种原因而不能上网。信息的公平使用和访问,是所有人的基本权利,如果你不能像身边其它人一样公平的获取信息,那意味着你不能公平接受教育、就业、独立生活等等。

我为什么会注意

我是谁?我为什么关心这些?这不是个哲学问题。每个人身上都有很多的标签,但在这里,我的标签是一个普通的Web开发工程师,一个新科技产物的使用者,一个信息的生产者和使用者,一个能“无障碍”获取信息的个体。而我的生活和我的工作让我开始关注“无障碍”这样一个词。

在互联网的大环境下,所有人的生活都方便了不少,我们可以远程办公,远程接受教育,网上购物,现在甚至连买菜、买水果都不需要出门,就这段时间,我妈有时都会直接在网上买菜和水果。

在我们享受这种生活便利的同时,我们也常常听到一些声音,比如:“这些都是年轻人的东西”,“我家小孩手机app玩的可溜了”。

前几天,我去办理港澳通行证,其实已经比我五年前办护照时方便很多,然而,在市政府政务中心的自动办理出境机器旁边,我会听到有几位年长的人说“这个机器不会用,怎么办?”,另一个人说,“没事,有个警察在旁边帮你操作”。这就意味着,如果旁边没有那个警察帮着操作,那么就不方便使用了,至少不是对所有人都方便。

科技的便利性看来还不是对所有人都便利,其实它还是需要一定的学习成本。

因为在外企的缘故,我有幸参加过一些海外的项目,在需求的实现过程中,客户对应用的无障碍性都会有一定的要求,于是我从中学习到了不少的相关知识。当然我也去过一些其他国家,跟不同国家的同事讨论过这方面的问题,也听他们介绍了一些做的不错的项目。所以我来举个例子:

比如,澳大利亚政府的“网络可访问性国内过渡战略”(NTS)规定,所有政府网站及其内容必须在 2012 年 12 月 31 日以前达到 WCAG 2.0 的 A 级合规要求,并在 2014 年 12 月 31 日之前达到 AA 级合规要求。

WCAG是万维网联盟(W3C)发布的一套名为“Web Content Accessibility Guidelines (WCAG) ”的网络内容可访问性指引。该指引目前是网络可访问性的国际标准。合规等级分为三级(A、AA 和 AAA)。

相关达到 WCAG 2.0 的 A 级合规要求的网站,例如:澳大利亚官方政府网站澳大利亚政府留学网站等,体验一下他们在Web内容无障碍性的一些实践,比如:只通过tab和enter来导航到不同的网站区域。

如果反观一下国内的一些相关网站,无障碍访问的体验感一下就降低了不少。

是能力问题还是被忽略了?

有时候,我在想这样一个问题,到底是我们的能力问题,还是问题被忽略了,当然大部分人的答案会是后者。

但我有时候会认为是前者,因为我们忽视了这个问题,所以导致其实我们也缺乏这方面的能力,无论是开发还是设计。

“目前我国99%的网站,由于没有实现无障碍,盲人难以正常浏览访问网站。”省盲协主席、中山大学工学院教授富明慧于2013年说的。富明慧本身就是一名盲人,他失明后发明了电脑盲文输入法。他说,加快网站无障碍改造,政府部门网站应该先行一步。

如果你在一个互联网公司工作,你大可在周边一问,比如:你听说过Web Accessibility?或者你知道怎么做才是最佳的方式吗?我们的产品里面有做这个?会作为代码和质量审核的一部分吗?

从哪里开始

连续追问这几个问题,的确会让不少人哑口无言,包括我自己在内。首先,我要承认这个不是一件容易的事情,否则不会有今天这样的一个讨论和思考。

我认为无障碍性的实现,应该是一个端到端的过程,不是设计师(UX/XD),不是开发(Dev),不是质量分析师(QA)某个人的责任,而是整个产品研发过程中所有人的责任,也许从产品构思的那天的就要开始考虑(比如:用户群体)。

其实这是个如何去做的话题会比较大,但是我想在这里举几个简单例子,让大家产生一些共鸣,也许从明天开始,在写代码和设计的过程中,你就会注意这些小的细节。

例子:通过Tab切换聚焦的的顺序

由于行动障碍而无法使用鼠标的人,会使用键盘进行页面的浏览。而页面上DOM的顺序会决定Tab切换时聚焦(focus)的顺序,我们知道CSS可以改变DOM在页面上的显示位置逻辑,但是DOM本身的顺序没有改变,这就容易导致Tab切换时给键盘使用者带来困惑。比如:

<div style="width:200px">
  <button style="float: right">右边菜单按钮</button>
  <button>左边</button>
  <button>中间</button>
</div>

当使用tab进行切换时,并不是最先聚焦到“左边”这个按钮,而是右边菜单,这就和页面上看到的逻辑产生了冲突。

例子:通过tabindex聚焦弹出框

你有没有注意到Bootstrap的模态框是这么写的:

<button type="button" class="btn btn-primary btn-lg" data-toggle="modal" data-target="#myModal">
  弹出
</button>
<div class="modal fade" id="myModal" tabindex="-1" ...其他属性省略>...</div>

当tabindex=-1时,表示当前元素必须要被聚焦,如果是元素弹出框,就需要使用tabindex,这样才能保证使用键盘的用户可以理解通过tab切换到模态框中的各个元素。如果你没有使用像Bootstrap这样的框架,那么当用其他前端框架实现自定义的模态框时,请务必考虑这个细节。

例子:请自定义元素的outline样式

你知道CSS中{ outline:none }对于网站的无障碍访问性是一个致命的做法吗?为什么我们还会这么做呢?因为元素在被聚焦时,会有一个蓝色的轮廓,而出于视觉效果的考虑,被认为是“不好看的”,所以被去掉了。

于是,当通过tab进行页面浏览时,很难立刻知道光标当前聚焦在哪一个元素(链接或者输入框)。这种情况,我们需要为它的聚焦效果提供一个另外的设计,以便同时保证它的功能性和视觉效果。更多关于{ outline:none }的内容,大家可以参考:http://www.outlinenone.com/

例子:设计页面时,请满足文字上的前后景颜色的对比度

(文字和背景的颜色对比)

WCAG 2.0 的1.4.3条对页面上文字的对比度有一个最低的要求4.5 : 1,目的很明显是为了保证色盲/色弱人群可以无障碍的访问网站的内容。假如说你是产品经理,有一天设计师告诉你,这个设计可能导致10个用户里面有1个用户存在访问障碍,阅读困难,你能接受吗?我想谁都接受不了。

有什么工具可以帮助检测网站的无障碍性吗?

对于普通使用者,可以使用Chrome的审计功能和Accessibility Developer Tools(Chrome插件),它能帮助你自动的检测网页的的可访问性问题,以及帮助你提供相关的修正信息。

(Chrome的审计功能)

Accessibility Developer Tools(Chrome插件)

对于开发人员,可以做一些自动化的检测,比如:使用pa11y这样一个工具,它是基于HTML codeSinffer以及PhantomJS制作而成的网站内容A11y(Accessibility,无障碍性)自动化检查工具。pa11y出现在ThoughtWorks 2017年3月的技术雷达中,我的同事写过一篇详细的文章来介绍这个工具:《无障碍性测试工具 Pa11y》

当然,最重要和最有效的检验方式是用户测试,比如:假设你自己是一个纯键盘的网站浏览者,尝试一下用键盘浏览自己开发的网站,是否能够方便的导航到网页的各个部分,并进行无障碍的阅读和交互。

还有其他一些重要的关注点吗?

有的,比如:基本HTML的语义化,alternative text的使用,ARIA标签属性的使用,都可以帮助屏幕阅读器有效的告诉使用者当前的元素类型和作用。

不要小看这些细节

​不要小看这些细节或者说基础功能,它涵盖的人群非常大,根据国家统计局最新数据,在中国,单是65岁的老年人已经超过1.5亿人口。加上其它障碍人群,以及第二语言学习者,等环境障碍人群,粗粗一算,这么简单的特性就能方便好几亿的用户,为什么要省略呢?

我在写这篇文章的时候,也去查了不少的资料,我觉得知乎上有一个人说很好:对无障碍性一个最大的误区是,将信息无障碍,当做产品的情怀功能,而非基础功能或Bug去对待。


更多精彩洞见,请关注微信公众号:思特沃克

Share

CEO要学习写代码吗?

法国兴业银行的CEO在努力学习Python

偶然间看到一篇文章,法国兴业银行的CEO Frederic Oudea,说54岁的自己正在学习写代码

“数字市场瞬息万变,必须努力学习来适应变化。我们正在认真对待这一挑战,并认识到有必要改变模式,并在文化上接受新技术。对于我来说,了解编码手段的确切性也非常重要,所以我花了几个小时用Python编写代码,这是数据技术的两种语言之一。”

——法国兴业银行的CEO Frederic Oudea

Frederic Oudea并不是唯一主张学习写代码的CEO。Mana AHL的CEO Sandy Rattray,通用电气公司的前CEO Jeff Immelt,苹果的CEO Tim Cook,都持有此主张。

(图片来自:http://t.cn/R3uvOwL

技术出身的CEO们还将领衔下一个十年的技术发展

当今科技巨头的CEO们,微软的比尔盖茨与现任纳德拉,Google的拉里佩奇和现任皮查伊,Facebook的扎克伯格,Amazon的贝佐斯, Adobe的纳拉延,SpaceX的埃隆马斯克, 中国的雷军、李彦宏、马化腾,都是技术背景,能卷起袖子解决问题。

《软件随想录》中这样记录比尔盖茨,“你不要糊弄他,哪怕是一分钟,因为他是一个程序员,一个真正、现实的程序员”。作为十大巨头里唯一不是技术出身的马云,则在公开演讲中表示:“因为我不是技术出身,所以我对待技术的态度更严谨认真。”

这些工程师出身的CEO们,不仅仅在过去的10年中创造了商业奇迹,更重要的是,在未来10年的演进式交互、增强人类、平台兴起、安全和隐私、智能机器人等重要科技领域,这些科技巨头更是遥遥领先。在Google I/O 2018大会上,靠预约订座“语惊四座”的Google语音助手、应用AI+AR的提供智能推荐的Google地图导航,都令人惊叹不已。

非技术背景、没碰过代码的传统CEO们,面临难题

科技公司技术大会的狂欢,皮查伊们的风度翩翩侃侃而谈,不免让过去未学过技术、没碰过代码的传统CEO们,坐立难安。

除了意识上的焦虑和强烈的危机感,欠缺技术认知的CEO常常也会面临以下难题:

  • 无法评估创意风险,错失创新时机或者被人忽悠。传统公司深知创新的重要性,但当面临一些新创意时,因为不懂技术无法评价技术风险、判断可行性。要么被忽悠——“伟大的创意就差一个程序员了”,实际结果也许是这伟大创意只能写个科幻小说;要么“我们再看看吧”,错过最好的市场时机。
  • 无法做出新业务的成本核算,进行业务决策。很多传统企业里面IT很弱或者原来IT都是外包。自己也不懂的情况下,很难评估研发工作量、技术要求、研发节点,导致人员规模,成本核算都不靠谱。因而无法做出决策,指导战略项目的进行。
  • 无法构建业务必须的团队和能力。想建立一个符合要求的研发团队,可招人都不知道怎么招;想找一个懂技术的来当合伙人解决上述问题,却没有能力评估他是否有能力干这事。

CEO是否要学习写代码?扎克伯格说YES

虽然大多数人倾向于“CEO对技术有良好直觉和敏感性”就够了,但Facebook的CEO扎克伯格,却坚持CEO应该向开头提到的Frederic Oudea一样学习写代码。其中有三个理由值得深思:

(图片来自:http://t.cn/R3u4qY5)

  • 学写代码,能够提出好问题,“防忽悠”。“如果你聘请某人为你建造房屋,但你从未试图自己建造房屋,你将不知道合理的成本和应该花多长时间。任何涉及编码的项目都是如此。如果你没有知识基础,那么你有被误导的风险。花时间学习基础知识可以帮助你提出正确的问题,并确定你知道他们在做什么。”
  • 理解市场上的技术。阅读技术理论是一回事,辨别其是真正创新还是市场炒作是另一回事。任何一个新技术从提出到创造商业价值会经历一个烟斗曲线。在AI大火的2017年和全民热捧区块链的2018年,ThoughtWorks技术雷达则指出“太火的东西,我们往往需要克制对待”。技术商业化的时机是否真地来到?只有“亲手实践”一下才能领悟。
  • 学编程会迫使我们将自己置于“学习者”模式。过去线性逻辑的思维,在AI的时代,似乎不适用了。比如,过去谈起预测,大家就觉得应该预测得准确;当CEO想启动采纳机器学习技术时,出于惯性思维会问:“这个预测的准确率可以达到多少呢”。然而,这却是个错误的命题。“机器学习是一种优化任务。优化任务的目标不是找到‘正确’的答案,而是找到一个‘看起来不错’的答案。” 单看书很难理解,只有动手去了解背后的算法逻辑,动手让代码跑一跑结果,才能理解从此切换思维模式。将来类似的技术还会有很多,必须通过实践体验来学习适应新的思维模式。

对技术拥有好奇心、拥抱学习新技术,已经是CEO们的共识

是否真地要去写代码,可能是一个问号,但毫无疑问,“对技术保持好奇心、拥抱学习新技术,跟上技术趋势”已经是CEO们的共识。 麻省理工学院的研究科学家斯蒂芬妮沃纳说:“技术就是一切。”在她的研究结果中,数字技术深深扎根于业务中,其影响非常广泛,是CEO必须明确关注的问题。

商业云通信公司Vonage,不断发展的技术促使消费者的语音互联网协议(VoIP)平台在短短几年内发生了巨大的转变。该公司的CEO Alan Masarek,也是前谷歌高管,表示:“我们绝对需要去了解科技的任何变迁,了解如何最好地采用科技来改进我们的工作。”

麦肯锡的一份CEO指南中,则建议CEO应该深入了解软件开发的技术,学习软件产品的依赖的基础设施、如何开发和如何管理的具体实践。

我们曾看到一位传统公司的CEO,在他的案头,放着亚马逊的Echo语音设备,并很习惯地和语音助手Alexa时不时聊个天。

与其焦虑,不如“Just Do It”

未来就像一盒巧克力,不尝试怎么知道?如果你是有胆识的CEO:

1. 转变心态,勇于“承认自己的未知”

Celia Pronto是Casual Dining Group的CDO。他表示:“真正接受技术的人往往会问很多问题。他们知道‘承认自己无知’,并不可耻。”

硅谷著名数字营销公司SparkToro的CEO Rand Fishkin,在他的博客中也坦承:

我至今仍在为缺乏工作中的某些知识而极度的难为情。在做决策时,会问一些很傻丢面子的问题。但关键是,至少是对我,要承认自己是个无知,正确的看待这种批评,不再恐惧,敢于说“我不知道,但我会弄清楚。”

2. 以初学者心态,持续跟踪技术动态,发展对技术的良好直觉

对于精通技术的人来说,最大的好处就是在一个特定的商业环境中,围绕什么是战略性的,什么是非战略性的,有敏锐、良好的直觉。这需要强烈的好奇心,并养成通过技术雷达去了解技术趋势,持续跟踪技术动态的习惯,长期积累。了解大的技术板块,关键技术的现状、所处烟斗曲线的位置、商业场景、对自己组织的影响、自身需要什么样的人才和构建什么样能力等。即使不能真正动手实现技术,也能保证在需要决策时,可以提出正确的问题。

3. 深入了解技术,通过动手去体验建立“未来”思维

了解一个技术是如何从默默无闻发展到全民热炒,只有理清发展脉络,知道它目前所处的状态、技术成熟度以及市场支持度,才能不被泡沫所迷惑。

千闻不如一试,如小扎所说,抱着好奇心,不妨和身边的技术Geek一起,6月2日,来深圳技术雷达峰会,动手写写代码亲自体验下区块链、机器学习解决问题的过程,重构“学习”思维,获得最新技术洞察,增强对未来的信心。

Share

聚焦测试,驱动卓越

在经历了“七年之痒”后,蓝鲸项目进入第八个年头,项目的一切趋于稳定。团队倡导持续改进,这时大家的感觉是已经尽力做到最好,似乎没有什么可以改进的了。为了突破这个局面,项目重新聚焦测试,从质量和测试的角度对现状进行了一次评估。

评估采用的是基于软件测试原则的模型,本文就是跟大家分享一下这个模型。

测试原则

在2012年澳大利亚敏捷大会(Agile Australia)上,ThoughtWorks非常资深的测试实践带头人Kristan Vingrys分享了如上测试原则,这些原则是ThoughtWorkers在多年软件测试实践基础上总结出来的。

1. 质量内建(Build quality in)

You cannot inspect quality into the product; it is already there. — W.Edwards Deming

著名的质量管理专家戴明指出:产品质量不是检测出来的,从产品生产出来后质量就已经在那了。这同样适用于软件产品。

缺陷发现的越晚,修复的成本就越高。质量内建要求我们做好软件开发每个环节,尽早预防,以降低缺陷出现后的修复成本,要减少对创可贴式的补丁(hotfix)的依赖。

推荐实践: TDD、ATDD等。

2. 快速反馈(Fast feedback)

每个环节的任何变化都能最快的反馈给需要的人,从而能够基于当下最新信息做出明智的决定,降低风险。这要求我们对系统进行频繁的测试,缩短回归测试的周期。

推荐实践:

  • 符合测试金字塔结构的自动化测试,让每一层的测试都能发挥尽可能大的价值,给出最快速的反馈;
  • 持续集成,尽早排查集成引起的问题,降低集成所带来的风险。

3. 全员参与(Involve everyone)

这次上线好多bug,QA是怎么测的?!

那个xxx组在上线前发现了很多的bug,他们的QA真给力!

成也QA,败也QA…如果还是这样的认识,那是极为片面的。测试不仅仅是QA的事情,团队成员要一起为质量负责,软件开发生命周期的测试相关活动需要全员的参与。

全员参与的好处是利用不同角色的不同领域知识和不同的思维模式,不仅可以使得测试的质量更高,同时还能最优化利用测试资源,做到价值最大化。

推荐实践:

  • 自动化测试:QA和BA结对用DSL编写测试用例,QA和Dev结对编码实现测试,生成业务人员可读的测试报告;
  • Bug bash(bug大扫除):团队不同角色一起参与的一个找bug的测试活动。

4. 测试作为资产(Tests as asset)

自动化测试帮助我们验证系统功能的正确性,好的自动化测试还有文档的功能,是宝贵的资产。如果每个项目都构建自己独立的自动化测试,没有跨项目共享,其浪费显而易见。

这个原则要求把自动化测试的代码跟产品开发的代码一起,当做资产管理起来,在不同项目间做到尽可能的复用。这笔宝贵的资产能帮助我们更好的统计跨项目的测试覆盖率,更好的优化测试。

推荐实践:利用版本控制管理工具把测试代码和产品构建代码一起管理,都作为产品的一部分。

5. 更快的交付(Faster delivery into production)

任何一个idea越快做成软件产品交付给用户,给企业带来的价值越大。

该原则要求我们把测试活动融入软件开发生命周期的每个环节,不要在后期进行长时间的集中测试;同时测试人员的关注点不再是发现更多的bug以阻止不符合质量要求的产品上线,而是把目标放在如何能够帮助团队尽快的让产品上线,让企业投资回报更早,也就是更快的赚钱。

推荐实践:自动化构建流水线、关注平均恢复时间、发布与部署解耦等。

6. 清晰一致的测试视图(Clear and consistent view of testing)

用可视化的报告给客户和内部团队展示测试的状态和产品内外部的质量,对项目的质量和风险把控是非常有帮助的。不同项目各自采用五花八门的图表样式,将不利于项目间的信息共享和比较,无端增加复杂性,带来浪费。

因此,我们需要把状态报告做的尽可能简单、清晰,并且保持跨项目的指标一致性;同时,我们不应该为了让某个指标变得好看而改变我们的行为,整个报告要诚实开放,这样才能真实反映出项目的状况。

7. 优化业务价值(Optimize business value)

开发软件无疑是要给客户的业务带来价值,软件测试也需要为这个目标服务,测试要跟业务价值保持一致,帮助客户优化业务价值。要求做到:

  • 测试不仅是保险,不仅是保证软件质量的;
  • 要有目的的关注变化的特性,不要盲目的散弹枪式的对任何特性进行测试,要有优先级;
  • 要能帮助企业驱动新的特性和功能;
  • 帮助客户创造安全的尝试新点子的环境,提供快速的反馈。

推荐实践:

  • 基于风险的测试,根据业务优先级需要调整测试策略,在测试过程中尽可能规避给业务带来的风险;
  • 生产环境下的QA,通过收集生产环境的真实用户行为和应用使用数据,对业务的优化做出贡献。

评估模型以及在项目中的应用

评估模型就是将上述七条原则的每一条细化,列出该原则对应的实践和行为,并给每个实践或行为设定0-5分的不同评分标准,最后统计各个原则的总分,形成类似下图的结果报告:

在项目中的应用

以Cristan分享的模型为基础,由Tech Lead和几个DEV、QA成立一个评估小组。

第一步:分别根据各自的理解给项目打分,结果是很有意思的,请看下图:

根据这些结果,可以看出大家的认识是不太一致的。

第二步:评估小组对模型中的每条细节进行review,做适当修改以更符合项目情况,并且在评估小组内达成共识。其中,所做的修改包括修改原有的实践评分指标、增加新的更适合项目和当前技术趋势的实践、删除过时的或者不符合项目特点的实践。

第三步:根据更新过后的模型指标对项目上的一个team做评估试点,详细分析该team对应到测试原则各个维度的well和less well部分,由评估小组成员一起打分,得到该team的评估结果图。

第四步:根据评估结果并结合项目目标排定需要改进的优先级,制定出改进action,并更新给试点team执行。

后续:试点一个周期后再次评估,并重新review评估模型,再推行到整个项目。同时,周期性的进行新的评估和制定新的action,以做到持续的改进和优化。

总结

应用程序的质量、测试的快速性、以及上线后轻松自信的更新服务的能力,是帮助企业实现业务价值最大化的关键因素之一,一直是我们所追求的。

基于测试原则的评估模型,可以帮助我们在追求这个目标的道路上少走弯路,帮助我们持续的改进,以驱动出更加卓越的软件。


更多精彩洞见,请关注微信公众号:思特沃克

Share

2018年5月期技术雷达正式发布!

ThoughtWorks每年都会出品两期技术雷达,这是一份关于技术趋势的报告,由 ThoughtWorks 技术战略委员会(TAB)经由多番正式讨论给出,它以独特的雷达形式对各类最新技术的成熟度进行评估并给出建议,为从程序员到CTO的利益相关者提供参考。

它比那些我们能在市面上见到的其他技术行情和预测报告更加具体、更具可操作性,因为它不仅涉及到新技术大趋势,更有细致到类库和工具的推荐和评论,因此更容易落地。经过半年的追踪与沉淀,ThoughtWorks TAB(ThoughtWorks技术咨询委员会)根据我们在多个行业中的实践案例,为技术者产出了第十八期技术雷达,对百余个技术条目进行分析,阐述它们目前的成熟度,并提供了相应的技术选型建议。

本期四大主题

浏览器增强,服务端式微

为了实现应用逻辑,浏览器在持续扩展成为部署目标的能力。当平台能照顾好横切关注点和非功能性需求的同时,我们注意到后端逻辑的复杂性有逐步降低的趋势。 WebAssembly 的引入为web应用创建逻辑提供了新的语言选择,同时把处理过程更加推向金属侧(以及GPU)。 Web Bluetooth让浏览器能够处理那些原本是本地应用才能处理的功能,而且我们看到越来越多像 CSS Grid Layout和 CSS Modules这样的开发标准正在替换掉自定义的库。对更好用户体验的追求,正在持续地把功能装进浏览器里,许多后端服务因此变得越来越薄,复杂性也因而降低。

不断蔓延的云环境复杂性

虽然AWS继续凭借令人眼花缭乱的新服务保持领先,但我们逐渐看到 Google Cloud Platform (GCP)和 Microsoft Azure 已经成为可行的替代方案。像 Kubernetes 这样的抽象层以及持续交付和基础设施即代码这样的实践,能支持更容易的演进式变化,从而促进云环境之间的过渡。但随着 PolyCloud (这允许组织根据差异化的功能在多个供应商之间进行挑选)以及越来越多的监管和隐私问题的出现,云策略必然会变得更加复杂。例如,许多欧盟国家现在依法对数据所在地做出要求。这使得数据存储的管辖权和其主机的管理策略成为评估云计算环境的新维度。云计算环境的可选范围也在扩大,比如在“函数即服务”和“管理更长寿命集群”这两者之间,就可以选择提供了“容器即服务”(CaaS) 的 AWS Fargate 这个有趣的选项。虽然各个组织对云技术的应用日臻成熟,但伴随使用这些新技术构建真实解决方案的,是逐渐蔓延又无法避免的复杂性。

信任但要验证

对于几乎所有的软件开发来说,安全问题仍然是至关重要的。当前我们观察到传统的“全局权限管理”的安全策略正在转变为更为细致的本地化方法。现在许多系统会在更小的领域内管理信任,并在不同系统之间使用一些新的机制创建可传递的信任。其理念正在由“永远不信任领域外所有东西”以及“从不验证领域内任何东西”转变为“信任但是需要验证领域内外任何东西”——也就是说可以假设和系统其它部分有本意良好的互动,但一定要在本地验证这份信任。这使得团队可以对自己的基础设施、设备和应用程序栈有高度的权限控制,从而实现高度可视化,并可以在必要时候提供高级访问护栏。类似 Scout2的工具以及 BeyondCorp 这样的技术反映了关于信任更成熟的视角。我们欢迎这种向本地化管理的转变,特别是当工具和自动化策略可以确保同等或更好的合规性时。

物联网的发展

物联网(IoT)生态系统持续稳步发展,关键成功因素包括安全和成熟的工程实践。我们看到了整个物联网生态系统的增长,从设备上的操作系统到连接标准,尤其是基于云服务的设备管理和数据处理。我们看到了一些成熟的工具和框架,支持良好的工程实践,比如持续交付、部署以及为实现最终广泛使用的大量其他必要实践。除了主要的云服务提供商——包括 Google IoT Core ,AWS IoT 和 Microsoft Azure IoT Hub ——像阿里巴巴和阿里云这样的公司也在大力投资物联网 PaaS 解决方案。可以从我们的 EMQ 和Mongoose OS 条目一瞥当今物联网生态系统的主流功能,它们也例证了 物联网 的良好的发展状态。

象限亮点抢先看

要记住,就像适用于其他软件领域一样,封装也同样适应于事件和事件驱动的体系结构。特别是,我们需要考虑一个事件的范围,以及我们是否期望它在同一个应用程序、同一个领域或整个组织中被消费。DOMAIN-SCOPED EVENT将在其发布的同一个领域内被消费,因此我们期望消费者能够访问特定的上下文、资料或引用,进而对事件进行处理。如果这个事件的消费在组织内更广泛地发生,且事件的内容需要有所不同,我们就要注意不要“泄漏”其他依赖领域的实现细节。

身份管理是平台的关键组件之一。外部用户在使用移动应用的时候,需要对其身份进行验证,开发人员需要被授权才能访问基础设施组件,而微服务也需要向彼此证明自己的身份。你应该考虑的是,身份管理是否真的有必要自己来搭建和维护。根据我们的经验,HOSTED IDENTITY MANAGEMENT AS A SERVICE( SaaS)这种解决方案更为可取。我们相信,像Auth0和Okta这样的顶级托管商可以在“正常运行时间”和“安全”两方面提供更好的SLA。也就是说,虽然有时候自行搭建和维护身份管理解决方案是一个现实的选择,特别是对于那些有操作规范和资源的企业来说,这个选择更为安全。但大型企业的身份解决方案通常包含更广泛的功能,例如集中授权、治理报告和职责分离管理等等。不过,这些担忧通常与员工身份更相关,特别是那些受遗留系统限制的企业,尤其如此。

在实践微服务的过程中,为了将后端资源进行聚合,我们实践了一个又一个的模式。之前,我们经常使用类似于Netflix Falcor这样的工具帮助我们实现BFF(Backend for Frontend ),现在很多项目已经开始使用GRAPHQL FOR SERVER-SIDE RESOURCE AGGREGATION。GraphQL可以让客户端直接使用特定的查询语句去访问BFF以获取数据。使用这项技术时,后端服务可以继续暴露 RESTful API,而GraphQL可以轻易的将这些服务所提供的资源聚合在一起,并且对客户端十分友好。我们推荐GraphQL是因为其简化了BFF和其他聚合服务的实现。

在高度分布式的微服务架构中,其可观察性有一个两难问题 —— 要么记录一切,代价是巨量的存储空间;要么随机抽样记录,代价是有可能丢失某些重要事件。最近我们注意到一项技术,它在这两种方案之间提供了一个折衷方案。通过跟踪请求头中传入的某个参数来LOG LEVEL PER REQUEST。使用跟踪框架(可能基于OpenTracing标准),你可以在一次事务中的多个服务之间传递一个相关的ID。还可以在开始事务时注入其它数据(比如期望的日志级别),并且与跟踪信息一起传递它。这样可以确保这些额外数据在系统中总是和相应的单个用户事务一起流动。这在调试时也是个很有用的技巧,因为服务可能会暂停或以逐个事务的方式进行修改。

Headless CMS( Content Management Systems, 内容管理系统) 正在成为数字化平台的常见组件。CONTENTFUL是一个现代化的 headless CMS。我们的团队已经成功把它集成到开发工作流中。我们特别喜欢其“API 优先”的特点,及其CMS as Code的实现。它支持强大的内容建模原语代码和内容模型演化脚本,并允许将其视为其他数据存储的schema,并将演进式数据库设计实践应用到 CMS 开发中。我们所喜欢的其他特性包括:默认包含两个 CDN以提供多媒体资源和 JSON文档,本地化的良好支持和与Auth0集成的能力(尽管需要做出一些努力)。

EMQ是一个可伸缩的开源多平台 MQTT代理。为了追求高性能,它使用Erlang/OTP语言编写,能处理数百万的并行连接。它能支持多种协议,包括MQTT、MQTT传感器网络、CoAP以及WebSockets,使其适用于物联网和移动设备。我们已经开始在项目中使用 EMQ,很享受其安装以及使用的便捷性,以及它能将消息路由到不同目的地(包括Kafka和PostgreSQL)的能力,还有它在监控和配置上所采用API驱动的策略。

TICK STACK是一个由开源组件组成的平台。使用它就可以轻松地收集、存储、绘制基于时间序列的数据(如度量和事件)来触发告警。TICK Stack 的组件包括:收集和报告各种指标的服务器代理telegraf、高性能时间序列数据库InfluxDB、平台的用户界面 Chronnograf,以及可以处理来自 InfluxDB 数据库的流式数据和批量数据的数据处理引擎Kapacitor。不像基于“拉”模型的Prometheus,TICK Stack是基于“推”模型来收集数据的。InfluxDB 组件是该系统的核心,同时也是目前最好的时间序列数据库。虽然这套组件栈基于 InfluxData ,而且需要使用诸如数据库集群这样的 InfluxData 企业版的功能,但在监控方面它仍然是一个不错的选择。我们正在一些生产环境上使用该平台,并且获得了一些很好的体验。

WEB BLUETOOTH能够直接从浏览器控制任意低功耗蓝牙设备。这样以前只能通过原生手机应用来处理的场景,现在也可以适用了。该规范由 Web Bluetooth Community Group 发布,并且定义了一个 API,通过蓝牙 4.0 无线标准发现设备并在设备间通信。 当前,Chrome 是唯一支持这个规范的主流浏览器。借助Physical Web和 Web Bluetooth,现在有了其他途径来让用户与设备进行交互, 且无需让他们在手机上安装另一个应用。这是一个令人兴奋的领域, 值得密切关注。

我们很开心使用 BACKSTOPJS 来做 web 应用的可视化回归测试。作为可视化比较工具,它的可配置视窗和可调节容错能力可以很容易定位到细微差别。它有很优秀的脚本功能,并且可以选择在无界面Chrome、PhantomJS 和SlimerJS 中运行。我们还发现,它在实时组件样式规范的基础上运行时尤其有帮助。

世界上有数不清的问题都可以用数学优化问题来表达,而其中可以用凸问题来描述的那部分常常能够得到有效解决。CVXPY便是一种针对凸优化问题所开发的开源Python嵌入式建模语言。它由斯坦福大学的学者维护,已经为数个开源和商业解决方案提供了功能齐备的安装套件。它的文档中也包含了许多能够引起开发者使用兴趣的例子。尽管有些时候,我们仍然需要类似Gurobi和IBM CPLEX这类商业解决方案,但CVXPY在原型设计阶段可以说所向披靡。在多数情况下,有CVXPY就足够了。同时,基于最近的优化进展,其开发者一直在为我们提供更多的扩展包(例如DCCP)和相关软件(例如CVXOPT)。

HELM是Kubernetes的包管理器。共同定义某个应用的Kubernetes资源集合被打包成图表。这些图表可以描述单个资源,例如Redis pod,或者全栈的Web应用程序:HTTP服务器、数据库和缓存。Helm 默认带有一些精选的 Kubernetes应用,维护在官方的图表仓库里。想要为内部用途搭建私有的图表仓库也很容易。Helm有两个组件:一个是称为Helm的命令行工具,另一个是称为Tiller的集群组件。保护Kubernetes集群是一个宽泛而微妙的话题,但我们强烈建议在基于角色的访问控制(RBAC)环境中搭建Tiller。我们在很多客户的项目中使用了Helm,它的依赖管理、模板和钩子机制极大地简化了Kubernetes中应用程序的生命周期管理。

ARCHUNIT是用来检查架构特征的Java测试库,比如包与类的依赖关系、注解验证、甚至层级一致性。它可以在你现有的测试方案中,以单元测试的方式运行,但目前只能用于Java架构。ArchUnit测试套件可以合并到C(I 持续集成)环境或部署流水线,使我们很容易地以演进式架构的方式实现适应度函数。

Hyperledger项目现在已经发展成包含一系列子项目的大工程。针对不同业务需求,可以支持不同的区块链实现方式。例如,Burrow专门用来实现带权限控制的Ethereum,而Indy更专注于数字身份。在这些子项目中,Fabric是最成熟的一个。当开发者们谈到使用 Hyperledger 技术时,实际上大多数时候是在考虑 Hyperledger Fabric。然而,chaincode的编程抽象相对底层,因为它直接处理账本的状态数据。此外,在编写第一行区块链代码之前,搭建基础设施也经常耗去很多时间。HYPERLEDGER COMPOSER 构建于Fabric基础之上,加速了将想法实现为软件的过程。Composer 提供 DSLs 来建立业务资源模型、定义访问控制和构建业务网络。使用 Composer,可以在不搭建任何基础设施的情况下,仅通过浏览器来验证我们的想法。需要明确的是,Composer 本身并不是区块链,仍然需要把它部署在 Fabric 上。

RASA是聊天机器人领域的新成员。 它并非使用简单的决策树,而是通过神经网络将用户意图和内部状态映射到回应上。Rasa 集成了自然语言处理解决方案(spaCy)。与技术雷达中的其他同类工具不同,Rasa是开源软件,可以自行托管,对于担心数据所有权的使用者来说 Rasa 是一个可行的方案。我们在内部应用中使用了Rasa Stack,效果良好。

RIBs即路由器(Router)、交互器(Interactor)和构建器(Builder)的缩写, 是来自 Uber 的跨平台移动架构框架。RIBs的核心思想是将业务逻辑从视图树中分离出来,从而确保应用程序由业务逻辑驱动。 可以将其看作是Clean Architecture模式在移动应用程序开发领域的一次应用。通过在原生 Android 和 iOS 应用上使用一致的架构模式,RIBs为应用提供了清晰的状态管理模式和良好的可测试性。尽管我们一直建议尽量将业务逻辑放在后端服务,不要将其泄漏到前端视图中,但移动应用程序非常复杂,RIBs可以帮助管理这种复杂性。

REACTOR是一个基于Reactive Streams规范的、用于开发非阻塞式应用程序的 JVM 库,支持 JVM 8 及以上版本。响应式编程强调将命令式逻辑转换成异步、非阻塞和函数式风格的代码,特别是在处理外部资源时。Reactor 实现了 Reactive Streams 规范,并且提供了两个不同的发布者API:Flux (0 到 N 个元素) 和 Mono( 0 或 1 个元素),可以高效地对基于推送的流处理进行建模。Reactor 项目非常适合微服务架构,并且为HTTP、WebSockets、TCP和UDP等提供了支持背压(backpressure)的网络引擎。

以上是我们在最新一卷技术雷达中随机摘取的几个Blips,欲获取整版技术雷达,请点击这里

Share