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

安吉・弗格森:IT曾是女性主导的行业

本文首发于微信公众号:哈佛商业评论,已获授权,转载请联系哈佛商业评论。

不可否认,女性程序员在全球IT领域仍处于劣势地位。2015年调查数据显示,Facebook的IT人员中仅16%为女性,谷歌为18%。而2014年夏,谷歌、雅虎、领英和Facebook公布本公司女性员工雇用比率时,就承认这一水平过低。事实数据说明,这些大型技术公司在提高女性程序员数量上仍需更多努力。

让我们再聚焦于中国IT从业人员。互联网求职平台100offer在2016年公布的中国互联网女性工程师工作报告表明,过去一年,男性程序员的注册人数是女性程序员的近4倍。此外,同一职位上的男性程序员薪资普遍高于女性程序员。实际上,女性在IT行业,甚至包括整个STEM(科学、技术、工程、数学)领域,都面临严峻挑战和多重偏见,导致这些行业的女性比例和待遇迟迟得不到提高。长达40年的社会科学研究表明,如果不对女性员工的偏见加以制止,这将继续渗透到人们观念中,而且人们会认为自己就在奉行贤能主义,所以更加不会采取行动,破除偏见。

加州大学哈斯汀法学院法学杰出教授琼・威廉姆斯(Joan C. Williams)发表于2014年《哈佛商业评论》的《攻克科技领域多样性问题》一文指出,技术行业女性员工面临的偏见和挑战主要可以分为四类:

  1. 再证明一次!女性要用更多成绩证明自己和男性有同等工作能力;
  2. 如履薄冰。普遍观点认为,高级职位需要在职者拥有传统意义上的男性特质,而女性应做到谦逊矜持。因此,女性职员不能过于女性化,这会显得能力不足,也不能过于男性化,会不讨人喜欢。
  3. 母亲壁垒。女性员工当了母亲后,其敬业度和工作能力会因其母亲身份而频频受到质疑。尽管很多从事技术行业的女性对本行工作时间灵活和远程工作条件称赞有加,但成为母亲后,一旦她们有失职情况,即便是迟到,也会再次印证女性不适合当CEO的传统观念。
  4. 内战。威廉姆斯的研究中,45%的受访女性称曾遭遇这种状况,即如果女性在其事业起步阶段受到歧视,会倾向于避免与其他女性接触,拒绝帮助她们,甚至不惜以损害其他女性利益为代价与男性协作。她们回避对性别歧视的控诉,并以此表明自己的忠心。

那么面对技术领域中普遍存在的四种性别偏见,女性应如何应对,公司又该采取哪些措施提升女性技术人员数量,保障女性员工权益,加强人才多样性呢?带着这些问题,《哈佛商业评论》中文版采访了全球技术咨询公司ThoughtWorks亚太地区集团执行总监安吉・弗格森(Ange Ferguson)。弗格森来自澳大利亚,拥有在澳洲、英国、荷兰、印度、新加坡和中国等国的跨国工作和管理背景,从事技术工作时间近20年。基于在该领域的深厚经验和对女性程序员的深刻洞察,她谈到了女性在技术领域遇到的阻碍以及解决之道

HBR中文版:从全球范围看,女性在技术领域所占比例都比较低。作为女性,你如何接触到计算技术并最终进入该行业?

弗格森:我的父亲是科学老师,所以我小时候可以借父亲工作之便,在放假时使用学校的计算机。1995年我考上大学,第一次接触到互联网,惊讶于这项科技巨大的连接性,决定从哲学系(50/50男女比例)转到计算机技术系(20/80男女比例)。计算机专业是个男性占绝对主导地位的学科,但当时我还没有意识到,这是个需要探讨的问题。

毕业后我去了一家小型专业服务公司。因为公司规模小,所以我得到很多大公司都不能给予新人的机会。虽然工作量很大,但我成长得非常快,还遇到了人生中一位重要导师丹尼斯。2001年互联网泡沫破灭时,我所在公司不幸倒闭了,于是我像很多澳洲人一样,去了欧洲旅行,并先后在伦敦、阿姆斯特丹工作。几年后我回到澳洲墨尔本工作,在丹尼斯引荐下,到了ThoughtWorks工作,到现在已经11年了。

HBR中文版:外界对IT行业的看法是竞争激烈,而且工作强度和难度都很大。作为资深从业者,你认为吸引你留在这一行的因素是什么?

弗格森:IT行业的工作机会很好,我有幸去世界不同国家和地区工作,也尝试了不同的职责,比如我曾在悉尼、布里斯班、香港、新加坡等地担任项目经理。我在ThoughtWorks工作几年后进入管理团队,一年后去印度担任管理工作,还为当地大学毕业生授课。我喜欢这种IT公司的商业模型——我们以项目为单位,结果为导向,工作时间和地点都不确定。你可能每半年或几年就要换新项目,面临全然不同的工作内容、合作伙伴和文化。我喜欢这种多样性带来的冲击。

此外,技术公司往往采取扁平化管理架构。比如在ThoughtWorks,我的另一位导师兼上司就在我隔壁。他像我的朋友,对我极其信任,同时又有很高期望,不断激励和鼓励我。导师对个人,尤其是女性的职业发展来说极其重要;他们的经验和洞见是年轻人最需要积累的财富。(但研究表明,女性虽然擅长建立关系网,可在职场中这种能力并未得到充分发挥。)当然除了导师以外,你可以向公司中每一个人求教,他们都会像朋友一样认真回答你的问题,而且相比进入管理团队,我们更愿意留在一线,学习应用最先进的技术,毕竟编程才是程序员真正热爱的工作。

HBR中文版:时间灵活、重视多样化,这些似乎都是对女性员工友好的工作条件。但为何现在IT行业女性人数依然过少?在打破技术公司性别偏见方面,ThoughtWorks有什么可供借鉴的解决方案吗?

弗格森:某名为《当女性停止编程》的研究指出,个人计算机最初进入市场时,其营销方向是男孩的玩具,所以美国、欧洲、澳洲的大多数家庭都会把电脑放在男孩子的房间。我们准备考大学时,卧室里有电脑的男孩对计算机更熟悉,技能更熟练,所以选择计算机专业的学生往往是男生,而最终从事这一行业的人也多为男性。我认为,市场营销,包括整个社会从一开始就建立了“计算机属于男性领域”的刻板印象,但这一假设并不成立。在计算机早期应用阶段,程序员往往是女性,而计算机主要用于行政工作——传统女性主导的领域。这样看,男女工作的选择更多受社会思维观念影响,而非男性真的做不好行政工作,或女性不能胜任IT岗位。

为创建多元化且有包容性的文化,ThoughtWorks一直以来都注重培养(cultivating)和发展(developing)员工,为他们提供开放、时间灵活、鼓励学习的工作环境。现在我们在中国的女性技术员工占员工总数的34%,所有女性员工占比40%,女性领导者在管理团队占比40%,在全球基本也是以上数据,这在IT公司中算是比较平衡的男女比例。我们是怎样做到这一点的呢?首先,我们会改变思维模式,不去规定你不能做什么,而是专注于你能做什么。我们赋权给员工,尽量给他们更多选择,让他们不论性别、种族、国籍、教育背景如何,都能发挥出其最大潜能。此外,IT行业变迁太快,这要求你在整个事业生涯中都不能停止学习。我们了解,每个人的学习方式都不同,所以我们提供不同的培训项目,并鼓励大家在网络平台上展开积极讨论,为所有员工创造了解彼此、互相学习、共同进步的良好氛围。值得一提的是,我们还在西安邮电大学建立的实验室,为上千名学生,特别是年轻女性提供线上和线下编程课程,希望更多学生,尤其是女性学到实用的IT知识,帮助他们缩小学校所学理论与行业实践的距离。我们认为,如果女性从学习编程初期就接触到聪明、有能力的IT女性,同时获得足够支持与鼓励,她们对编程会更有自信,并相信自己也会成长为杰出的IT女性。 我们还希望给她们跨越整个职业生涯的帮助,因为IT女性出于家庭、生育等因素选择性退出的比例远高于男性,所以每当她们遇到职业瓶颈期时,都可以咨询我们并寻求意见。

HBR中文版:也就是说,只要IT公司对内对外都构建起互帮互助、多元包容的文化,在行业中处于劣势的群体比如女性,会是最终受益者?

弗格森:的确如此。此外,你帮助的女性越多,她们就会形成越来越强大的组织和关系网,产生累积效应,IT女性的力量也就越来越强大。如今我们成为对女性友好的标志性公司,至少在澳洲如此,这其实也告诉外界:如果你的员工发展方式是正确的,女性程序员的潜能就能被激发。我们也倾向招募没有经验的毕业生,帮助他们建立自己的事业,让他们了解我们的价值观,而一旦他们认同并适应多元、包容的环境,他们就会成为这一文化最坚定的倡导者。

HBR中文版:但多数IT公司都未能在提高女性程序员比例上有所作为,女性仍面临同工不同酬、“母亲壁垒”、“再证明一次”等偏见。你如何看到这一现象?

弗格森:这些情况的确存在,我们听到很多这类故事,包括我们的中国员工也提到,在她之前的工作环境中,“作为女性,她必须比男性同级更优秀,才能获得升职加薪机会”。我想女性首先要了解偏见,然后有与上级谈判,要求同等待遇的意识和技巧。比如我曾经为一位女性管理者提供咨询,鼓励她与上级沟通,大胆提出自己的加薪要求,结果她与上级谈完后,提议立刻就被通过了——这说明,她一直都没有得到自己应得的工资,而如果她不提出要求,老板就不会主动给她晋升加薪机会。所以女性要做的不仅是做好自己的工作,更要有谈判、争取自身权益的意识和勇气。一旦你“向前一步”,不公就会“退后一步”。

另外,如果你的组织限定了女性的竞争领域,迫使女性展开内部竞争,争取仅有的几个对女性开放的升职或加薪机会,我觉得你应该离开这家公司。事实上,如果女性愿意联合起来帮助彼此,与已经获得优势地位的男性沟通,效果要好得多。比如在一个10人会议中,只有两位女性参加,那么她们可以彼此呼应,重复彼此的论点,避免自己的声音在男性主导的会议中淹没——事实上,我也用过这个策略。

我依然是对IT界女性力量的壮大,持乐观态度。回想我们的前一代女性,很少人当了母亲后仍在职场工作,但现在随着职场妈妈人数的增多,这一群体也在开始发出自己的声音,要求改变人们对“女性必须承担更多家庭责任”的偏见。更重要的是,如果你知道偏见的存在,就能做出更好的应对。比如女性面临的“如履薄冰”偏见,出现这一问题的原因在于组织多样化程度不高。如果你所在公司以男性为主导,整个思维模式都偏男性化,女性很少能找到同性榜样,这种巨大的权力落差就会造成极端化的刻板印象,让女性不知道如何在男性为主导的文化中表现领袖气质。但若你吸收了大量女性,保证性别的均衡,女性的形象和气质就会更丰富——你不必是“女汉子”或“傻白甜”,你更多是一个糅合多种气质、刚柔并济的员工。每个组织都需要更多领导者“画像”,让员工看到领导力的多种可能性。

HBR中文版:我们所谈的问题,现在依然没有得到公众的普遍认知和认同,有效的解决方案也并未得到广泛实施。对此,我们还需要做哪些努力?

弗格森:我认为,我们需要更多公众讨论,加强人们对偏见的认知和改变的决心。同时,这不仅是女性的战争,我们同样需要男性的支持。比如在澳大利亚,我们有一个名为“Male Champions of Change”的组织,参与者都是澳洲最有影响力的CEO和高层领导者。他们为女性发声,并致力于推动男女同工同酬,促进女性就业和晋升等。这样的项目和组织会在不同国家出现,以不同速度推进,因为这是对的方向,也是我们应该做的工作。


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

Share

2017年11月期技术雷达正式发布!

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

技术雷达的内容来自于 ThoughtWorks 的观察、对话以及在应对最令客户棘手的业务挑战时所沉淀下的一线经验,其中既包含现有技术,也包含新兴技术。技术雷达报告使用可视化的方式将技术趋势分为四组,分别涵盖技术、平台、工具和语言与框架,每个领域又进一步细分为暂缓、评估、试验或采用。


本期四大主题

崛起的中国开源软件市场

星星之火,已成燎原之势!在态度和政策发生转变之后,包括阿里巴巴和百度在内的众多大型中国企业正在积极发布开源框架、工具和平台。中国软件生态正伴随着经济扩张而加速成长。从这个巨大而繁荣的软件市场向 GitHub 等开源网站发布的开源项目的数量必将持续增多,质量也将持续提高。中国企业为何热衷于将他们的众多资产开源出来?与硅谷等其他活跃的软件市场一样,各个企业对开发人员的争夺十分激烈。紧紧提升薪酬水平是不够的,让聪明的开发者一起在最前沿的开源软件上共事才能够持续激励他们,这是一个放之四海而皆准的通则。我们预期主要的开源创意会继续保持 README 文件中先有中文版后有英文版的趋势。

容器编排首选Kubernetes

Kubernetes 及其在许多项目中逐渐增强的主导性推动了大量雷达条目的更新,以及更多的讨论。似乎软件开发生态系统正在 Kubernetes 及其相关工具的周边稳定发展,以解决有关部署、规模化和容器操作这些常见问题。诸如 GKE,Kops 和 Sonobuoy 这些雷达条目提供了托管平台服务和工具,以改善采用和运行 Kubernetes 的整体体验。事实上,它具备用一个调度单元来运行多个容器的能力,可以让服务网格(service mesh)和能够实现端点安全的 sidecar 得以实现。 Kubernetes已经成为容器的默认操作系统——许多云提供商已经利用其开放的模块化架构来采用和运行Kubernetes,而它的工具则可以利用其自身开放的API来访问诸如负载、集群、配置和存储等功能。我们看到更多的产品正在把Kubernetes作为一个生态系统来使用,使其成为继微服务和容器之后的下一个抽象层次。更多迹象表明,尽管面临分布式系统固有的复杂性,开发人员仍然可以成功地驾驭现代的架构风格。

成为新常态的云技术

本期技术雷达讨论中的另一个普遍性话题,无疑是近期的“多云”天气。 随着云提供商的技术能力越来越强大,且可以提供同样好用的功能,公有云正在成为许多组织中新的默认选择。当启动新项目时,许多公司已经不再问“为什么放在云端?”,而是问“为什么不放在云端?”。 诚然,某些类型的软件仍然要在公司内部私有地部署,但随着价格的下降和功能的扩展,云原生(cloud-native)开发的可行性越来越高。尽管主要的云解决方案提供商提供的基本功能都很相似,但它们也都提供了一些独特的产品特性,以针对特定类型的解决方案来实现差异化。因此,我们看到一些公司通过“多云”(Polycloud)策略来同时使用几个不同的云提供商,从中分别挑选最能满足其客户需求的平台专业能力。

各方对区块链的信任稳步增强

尽管加密货币市场仍然处于混沌状态,我们的许多客户已经开始尝试利用基于区块链的解决方案来处理分布式账本和智能合约的需求。雷达中的一些条目展示了区块链相关技术运用的成熟度,它们使用各种新技术和编程语言并以一些有趣的方式来实现智能合约。区块链解决了“分布式信任”与“共享且不可篡改的账本”这些老大难问题。如今,许多公司正致力于增强其用户对将区块链作为系统的底层实现机制的信心。许多行业存在着明显的“分布式信任”问题,我们期待区块链技术能持续找出解决这些问题的方法。


部分亮点预览

技术篇:

DesignOps:受DevOps运动的启发,包含一系列实践和文化转变的DesignOps横空出世。它可以帮助组织不断重新设计产品,而不在质量、服务一致性和团队的自主性上妥协。 DesignOps提倡创建并不断演进设计的基础,最大限度降低创造新的UI概念及其变体的工作量,并与最终用户建立快速可靠的反馈机制。使用DesignOps,设计正在从一种具体的实践演变成每个人工作内容的一部分。

Chaos Engineering:在早期的技术雷达中,我们讨论了Netflix的Chaos Monkey。Chaos Monkey可以随机终止生产系统中的运行实例,并对结果进行度量,从而帮助验证系统在运行时对生产中断的应对能力。今天,人们有了一个新兴术语来描述这一技术的广泛应用:混沌工程。在生产环境的分布式系统中运行这些实验,可以帮助我们建立系统在动荡环境下依旧能够按预期工作的信心。如果想要更好地理解这个技术方向,请参阅混沌工程原理。

Service Mesh:现在越来越多的大型组织在向更加自组织的团队结构转型,这些团队拥有并运营自己的微服务,但他们如何在不依赖集中式托管的基础架构下,确保服务之间必要的一致性与兼容性呢?为了确保服务之间的有效协作,即使是自组织的微服务也需要与一些组织标准对齐。服务啮合在服务发现、安全、跟踪、监控与故障处理方面提供了一致性,且不需要像API网关或ESB这样的共享资产。服务啮合的一个典型实现包含轻量级反向代理进程,这些进程可能伴随每个服务进程一起被部署在单独的容器中。反向代理会和服务注册表、身份提供者和日志聚合器等进行通信。通过该代理的共享实现(而非共享的运行时实例),我们可以获得服务的互操作性和可观测性。一段时间以来,我们一直主张去中心化的微服务管理方法,也很高兴看到服务啮合这种一致性模式的出现。随着 linkerd 和 Istio 等开源项目的成熟,服务啮合的实现将更加容易。

平台篇:

TensorFlow Serving:机器学习模型已经开始渗入到日常的商业应用中。 当有足够的训练数据可用时,这些算法可以解决那些以前可能需要复杂的统计模型或试探法的问题。 随着机器学习从试验性使用转向生产环境,需要一种可靠的方式来托管和部署这些可远程访问的模型,并能随着消费者数量的增加而进行扩展。TensorFlow Serving 通过将远程gRPC接口暴露给一个被导出来的模型,解决了上述部分问题。这允许以多种方式部署训练完成的模型。TensorFlow Serving 也接受一系列的模型来整合持续的训练更新。其作者维护了一个Dockerfile来简化部署过程。 据推测,gRPC 的选择应与 TensorFlow 执行模型保持一致。 但是,我们通常都会对需要代码生成和本地绑定的协议保持警惕。

LoRaWAN:LoRaWAN是一种低功耗广域网,专为低功耗、远距离和低比特率的通信场景而设计。它提供了边缘设备与网关设备之间的通信能力,能够通过后者将数据转发至应用程序或者后台服务。LoRaWAN通常用于分布式传感器组或物联网这些必须具备长电池寿命和远距离通信能力特点的设备上。它解决了在使用一般的WiFi进行低功耗广域网通信时的两个关键问题:通信距离和功耗。LoRaWAN已有若干实现,其中值得注意的是一个免费的开源实现——The Things Network。

Language Server Protocol:那些大型 IDE 的威力很大程度上源于利用源代码分析出的抽象语法树(AST)来进一步分析和操作源代码的能力,比如代码补全,调用分析和重构。语言服务器将这种能力提取到单独的进程中,从而让任意文本编辑器都可以通过 API 来使用 AST。微软从他们的 OmniSharp 和 TypeScript 服务器项目中,提炼并引领了”语言服务器协议”(Language Server Protocol, LSP)的拟定。编辑器只要使用 LSP 协议就可用于任何具备 LSP 兼容服务器的编程语言。这意味着我们可以继续使用自己喜爱的编辑器,同时也不必放弃各种编程语言的高级编辑功能——这对于很多 Emacs 瘾君子来说尤其利好。

工具篇:

Gopass:gopass是一个基于GPG和Git的团队密码管理解决方案。它的前身是pass,并在此基础上增加了诸如多用户密码管理、层级式密码存储、交互式查找、基于时间的一次性密码(TOTP),以及二进制存储格式等功能。由于它的存储格式与pass基本兼容,因此可以直接从pass迁移过来。这意味着只需调用一次存储密钥就能将其集成到迁移的整备工作流中。

Jupyter:过去几年间,我们注意到分析笔记本应用(analytics notebooks)的流行度在持续上升。这些应用都是从 Mathematica 应用中获得灵感,能够将文本、数据可视化和代码活灵活现地融入到一个具备计算能力的文档中。在上个版本的技术雷达中我们所提到的基于Clojure 的GorillaREPL,就属于此类工具。但随着人们对机器学习的兴趣不断增加,以及该领域中的从业者们逐渐将Python作为首选编程语言,大家开始集中关注Python分析笔记本了。其中 Jupyter 看起来在ThougthWorks团队中格外引入注目。

Rendertron:JavaScript Web 富应用的一个老问题是如何使这些页面的动态渲染部分可供搜索引擎检索。为此开发人员采用了各种各样的技巧,包括使用 React.js 的服务端渲染,外部服务或预渲染内容。现在谷歌 Chrome 新的 headless 模式又贡献了一个新的技巧—— Rendertron,即 Chrome的headless 渲染解决方案。它在一个 Docker 容器中封装了一个 headless 的 Chrome 实例,可以作为独立的HTTP服务器来部署。无法渲染JavaScript的爬虫机器人可以被路由到此服务器来进行渲染。 虽然开发人员也可以部署自己的 headless Chrome代理并配置相关的路由机制,但 Rendertron 简化了配置和部署过程,并提供了令爬虫机器人进行检测和路由的中间件示例代码。

语言&框架:

Gobot:Go语言能够被编译为裸片上运行的目标程序,这使得嵌入式系统开发领域对它的兴趣与日俱增 。GoBot是一个用于机器人、物理计算和物联网(IoT)的框架,它基于Go语言编写,并且支持多个平台。我们在一个对实时性响应没有要求的实验性机器人项目中使用了GoBot,并且用GoBot创建了开源的软件驱动。GoBot的HTTP API使其与移动设备的集成十分容易,从而能创建更丰富的应用。

Solidity:智能合约编程需要一种比交易处理脚本更具表现力的语言。在众多为智能合约设计的新编程语言中,Solidity是最受欢迎的。这是一种面向合约的静态类型语言,其语法类似于JavaScript。 它抽象了智能合约中自我实现的业务逻辑。围绕Solidity的工具链也在快速成长。如今,Solidity是Ethereum平台的首选编程语言。

CSS-in-JS:CSS-in-JS是一种用JavaScript编写CSS样式的技术,通过鼓励采用一种通用模式,编写样式以及应用样式的JavaScript组件,使样式和逻辑的关注点得到统一。该领域中的新秀——诸如JSS,emotion和styled-components,依靠工具来将CSS-in-JS代码转化成独立的CSS样式表,从而适合在浏览器里运行。这是在JavaScript中编写CSS的第二代方法,与以前的方法不同,它不依赖于内联样式,这意味着它能支持所有CSS特性,使用npm生态共享CSS以及跨平台使用组件。我们的团队发现styled-components很适合像React.js这样基于组件的框架,并且可以使用jest-styled-components做CSS的单元测试。这是个新兴的领域且变化迅速。用该方法时,在浏览器里人工调试生成的class名称会需要费些功夫,并且可能不适用于那些前端架构不支持重用组件并需要全局样式的项目。

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

Share

技术雷达是如何创建的?

ThoughtWorks一年发布两次技术雷达,在每次雷达的准备期,TAB(ThoughtWorks技术顾问委员会)成员都会全力以赴的投入其中,以至连睡觉都会变成一件奢侈的事情。

言归正传,到目前为止我已经参与了几次技术雷达的构建。在这之前我曾疑惑于一个问题——“技术雷达是如何建立的?”这也是如今我常常被他人询问的问题,在本篇文章中,我将从内部人员的视角就技术雷达的产生机制、准备方式和决策方式给予一些介绍。文章从一次为期四天的会议开始。

第一天

为了制定下一期技术雷达,来自全球的ThoughtWorks TAB成员一大早就汇集在了一起。每次我们都会从四个办事处中选择一处碰面——这次我们定在了去年刚成立的巴塞罗那办事处。如果你觉得初来乍到和时差问题会拖慢进程,那就错了。团队一旦聚在一起,稍作提神后,立马就投入战斗了。

首先给大家介绍一下我们的技术顾问委员会,它是由来自全球的ThoughtWorks资深技术人员组成的,其中包括首席科学家Martin Fowler。此次线下会议由我们的全球CTO Rebecca Parsons主持。

开始的第一天,技术顾问委员会的每一位成员都准备了不少他们认为可以纳入下一期雷达的想法——也就是我们在技术雷达中看到的具体条目。

这次在巴塞罗那,团队要对180个备选条目进行投票表决。这就意味着要达成共识,大家需要进行审慎的考虑和热烈的讨论。

候选条目按雷达象限(技术、工具、平台、语言与框架)归类,再分为几个环(暂缓、评估、试验和采用)。这便于提醒我们每个环所表示的意思,有助于决定条目的归属范畴。

  • 暂缓。这一环包含我们认为客户应当放弃或者需要等待时机成熟的条目。
  • 评估。我们认为有希望且值得研究一番的事物。
  • 试验。强烈推荐的技术,仅当我们预见能成功部署于生产时,才会将条目归于这一环——非常罕见的情况除外。
  • 采用。对于特定应用情形,我们认为这是唯一最好的方案。

为了确定最终能够登上本期雷达的100个条目,我们每次分析一个象限,每个象限从采用到暂缓由内而外地进行。条目的推荐人负责向团队进行介绍,然后展开讨论和表决。每个人有三张不同颜色的牌子:绿色表示“是,我希望将其纳入雷达”;红色表示“不,不可能将其纳入雷达”;黄色则表示他们有疑问或意见。这四天会议上将大量用到这些牌子。

红牌用完后,用橙牌表示新的红牌。

这次我们从技术象限开始——不仅因为这是我最喜欢的方式,也因为这样讨论将更加细致。如此一来,下一期技术雷达就有了起点。

第二天

直到第二天凌晨,雷达墙才略微显露出一些秩序——但区别也不是很大。一名团队成员负责逐一检查雷达墙,而我则负责确保跟踪所有决定——到后来几乎不可能记住所有的东西。检查雷达墙时,他们明确我们下一步即将探讨的提议,并将便利贴移到团队表决的位置。有些情况下,要将便利贴置于指定的环内——但后来可能移到其他环或象限,或者完全遭到拒绝。

偶尔我们会遇到一些条目,迸发激烈的争论,甚至会由于一些细微差别而陷入僵局。这些问题我们视为“太过复杂而无法成为条目”——这并不表示它们会被抛诸脑后;这些问题仍然很重要而且值得注意。只是不适合在技术雷达上探讨。

有这么多条目需要讨论和表决,让讨论继续进行才是关键。Rebecca负责监督程序的进展。介绍条目时,她会留意黄牌的出现,并告诉团队下一个发表意见或提问的人是谁。期间没有人会插嘴。每个人必须在轮到自己的时候才能发言。

第一轮表决进度很快。先介绍条目,再快速讨论,最后表决。这里有一个棘手的问题。已经有一些人发表了一些意见,但团队里仍有不少人举黄牌。为了保持程序正常进行,Rebecca拟制了发表意见的名单并提示我们:“乔尼发言后开始表决。”

表决票数经常比较接近,所以要一直举着牌直至统计完所有绿/红牌。当有黄牌出现时,讨论继续。达成决定后,进入下一步。这里不掺杂任何个人因素,我们进行地很快。

第三天

到了第三天,我们基本已经完成了新条目最主要的部分。但离完成还相差甚远。从许多方面而言,艰难的工作才刚开始。

之前,每一次表决都将决定是否将某个新条目纳入雷达。现在,我们得回顾上一期雷达的条目,加起来通常会有100个左右。他们是否仍然关系重大?哪些应当去掉?哪些条目需要重写?如果我们对一个条目的看法连续两期雷达都没有发生改变,就让其“淡出”。因为还有很多有趣的事情值得探讨!有些时候,为了腾出雷达空间,我们必须强制淡出一些条目——即提前删除这些条目。

即便如此,我们还有大量的条目。现在的讨论就变得激烈了。技术雷达诞生于全球充满热情的技术人员所组成的ThoughtsWorks社区。它基于我们的客户工作经验。我们认为这是我们的优势之一。但只要大家对技术怀抱热情,难免会存在异议。我们的雷达讨论也不例外。

接下来,我们检查所有人一致同意理应纳入雷达但不如其他条目价值高的条目。这种剔除过程非常艰难,好几次我们不得不停下来问自己:团队有没有什么建议?如果团队对某个条目没有明确的建议或一致的意见,那这个条目便不会被纳入雷达。

第四天

连续三天的讨论——除了雷达,偶尔下班消遣时也会与同事互动,挑起技术谈话——大伤元气。现在会议室里几乎每个人都很疲惫了,但仍需进行最后调整,落实到位。

为了确保在计划时间内结束,我们采用了许多方式。例如,Rebecca确保不让讨论无休止地继续。我们也明白有时候个别人会不同意团队的决定。这时候,有一个可以改变团队的决定机会——我们称之为救生艇。一旦雷达基本落实到位,各技术顾问委员会成员可选择一个条目恢复——但他们必须说服团队该条目值得纳入雷达。或者说服大部分人即可,无需所有人一致同意。

最后,只有所有人尊重其他人的意见时,会议才能顺利开展。Rebecca协调会议时确保所有人都具有发言权,能表达自己的想法、经验和关注点。看到一群热情的人以相互尊重的方式表达有力的观点,展开高质量的讨论,这是令人高兴的事。所以即使团队出现分裂,表决票数相当,我们也能进入下一轮讨论。

到第四天结束时,我们对雷达的内容做出了最终决定。每次参加技术雷达会议,现场的讨论都令我折服——有幸参加会议让我深感荣耀,我一直惊叹于大家的技术意见、意见产生的过程、意见的评估方式以及团队谈论的各种背景。

这仅仅是雷达建立过程的起点。随后我们必须详细编写每一个条目、讨论产生的主题及主要报告。敬请期待——新一期雷达将于11.30日与你见面!点击这里提前订阅。

Share

IoT时代,一起来探索社会化创新

[摘要]

IoT时代,社会化创新面临更多的挑战:如何在各种不确定下做决策?探索的方案涉及到智能传感器、云端平台、移动设备、工业设计、体验设计等多种复杂技术,如何做技术选型决策?硬件设备、集成接口昂贵,无法测试验证想法怎么办?Guide Dogs Victoria的智能手杖创新故事(文中有视频),将分享我们如何应对这些挑战,做精益式产品创新的过程和收获。

Guide Dogs Victoria的创新旅程

图片来自:https://www.guidedogsvictoria.com.au/

Guide Dogs Victoria(以下简称GDV)是澳洲一家活跃的慈善组织,成立于19世纪50年代。他们致力于帮助盲人和弱势群体,最大化提升其生活自主性、社会活动参与度,改善生活质量。

虽然使用导盲犬可以帮助盲人显著地提升外出活动的自主性,但是GDV也发现导盲犬存在诸多限制。首先是训练导盲犬的资金成本和时间成本都很高。一只拉布拉多从出生到通过培训及考试需要1年半的时间,而通过最终测试成为合格导盲犬的概率只有37%。同时,由于一些盲人独居或者缺乏照顾动物的勇气,也不愿意领养导盲犬。因此,GDV也在不断思考如何用导盲犬之外的手段帮助更多视力障碍群体独立出行。

在科技改变生活的今天,GDV想去探索如何利用新的技术,来扩展服务能力,进一步改善视力障碍人群的生活体验。他们希望能够研发一款设备,借助物联网的技术,让盲人可以更加安心地出行。

“我们的目标是不断寻找新的方式,来改善视力障碍人群的生活体验。导盲犬服务只能代表其中的30%。所以数字化服务同样作为另一种我们可以尝试的方式,就显得尤其重要。”

——Alastair Stott, GDV Victoria首席执行官

对GDV来说,这是一个创新的旅程。

一个成功的创新,需要同时满足“用户有需求”、“技术上可行”、“业务可持续”这三个条件。当我们审视这个创新项目时,我们发现有太多的未知摆在面前。我们应该用哪些技术?帮助视障群体具体解决哪些问题?新的业务应该如何运作?

用户需求的探索

找到有价值的用户需求是走向成功的第一步。在最初我们对“用户究竟需要什么”并不了解,所以我们希望通过深入现场的用户研究来挖掘真实的需求。在这个过程中,我们发现了很多超出预期的事实。我们原以为,帮助视障群体出行应该做一些类似于GPS、语音导航的东西来帮助他们找路,但是事实上,盲人在外出时最大的痛点其实是“过马路”。如果不是做用户研究,我们很可能在一开始就走错方向。

“盲人之所以觉得过马路挑战很大,是因为他们必须要在几十秒的时间里穿行马路,在无法看到正确前进方向的情况下,很容易偏离正确的方向。一旦偏离,很可能被汽车撞倒。”这极大地限制了他们单独外出的可能性。这一点是我们在第一站用户访谈中发现的。我们调研了几位视障工程师,请他们向我们讲述他们的经历,观察他们在不同生活场景下的行为。

技术方案的探索和验证

为了帮助GDV解决这个问题,我们构想了十几种解决方案,最终从中选择了四种技术可行性最高的方案,分别是:

  • 使用机器学习训练可以识别人行道正确方向的AI
  • 用手机配合安装在马路两侧的蓝牙信标iBeacon导航
  • 在手杖前侧加装红外亮度感应器,寻找地上的白线
  • 用计算机视觉来识别地上的白线

但是这四种方案是否真的能够为用户解决问题呢?在真正的产品摆在我们面前之前,谁都没有100%的把握。所以我们的决定是,用尽量少的投资做出原型,实地测验对比这几个技术方案。

“我完全被这些原型震惊了。其简单而直接地处理用户痛点的方式,真是让人惊叹。”

——Alastair Stott,GDV Victoria首席执行官

真理永远来源于实践。在3周之后,我们拿出了3款可工作的功能原型,请真实的视障用户使用。经过测试发现,在盲杖顶端加装红外传感器的方案是最有效的。在这个方案中,传感器可以感受地面的亮度,并将信息以震动和声音的方式传递给用户。这样视障者就可以分别出地上的白线。虽然iBeacon的方案也起到了完美的引导效果,但是它依赖于大量基础设施建设,所以留作未来考虑。

下一步规划

我们在几周的时间里,帮助GDV找到了最有价值的用户痛点,同时也找到了最适合的技术方案。基于实验中收集的数据,我们也和客户一起制定了下一阶段的投资方案,并且估算了未来投资的投入产出。这些尽早进行的实验帮助GDV有效控制了在创新项目上做投资决策时的风险。

接下来,GDV希望与中国深圳的硬件合作商一起,将这个原型开发到工程样品阶段,以将该产品尽快投放到市场。

点击此处观看GUIDE DOGS VICTORIA视频

IoT时代的创新挑战

挑战一:创新存在高风险,如何选择适合的投资策略

当我们感慨于创新的炫目时,也需要知道潜伏于其背后的高风险:我们应该用哪些技术?帮助用户具体解决哪些问题?应该以什么样的产品、服务模式出现?新的业务应该如何运作?其实在任何一个创新性项目中,都需要回答这些问题。对于像GDV这样的社会组织来说,一是资源受限,二是缺乏技术能力和洞见,挑战更大,风险也更大。他们必须选用适合创新项目的投资策略,才能避免浪费大量资源、做出失败的产品。

挑战二:技术选型的复杂度

在过去,交互主要是基于网页界面的,消费者无非是点击样式不同的按钮而已。就产品设计而言,上述限制虽然减少了发挥空间,但也节约了设计、实施乃至培训的成本。然而在IoT时代,消费者与产品交互的方式呈现出了爆炸式的增长,触摸、体感、体温乃至脑电波都可以成为与产品交互的途径,随之而来的是大量复杂的硬件模块和软件技术选型。

GDV产品设计目的是帮助盲人能够独立安全的通过马路。由于斑马线上没有导盲设置,盲人的手杖无法像在盲道上一样发挥作用,这导致盲人在通过马路时经常走偏而遭遇风险。设计团队一开始想到几种方案,如:

  • 使用手机摄像头配合人工智能,把摄像头捕捉的信号送到云端由人工智能判断是否有斑马线?盲人是否沿着斑马线在行进?有没有危险?目前智能汽车所采取的都是类似的方案。
  • 蓝牙定位技术,即在街道两边安装蓝牙基站,通过手机就能提示消费者是否沿着直线行进,大多数室内定位都是采取类似的方案。
  • 升级现有的盲人手杖,通过在盲人手杖的前端安装光学传感器,然后通过程序判断是否发现了斑马线。

这几个方案的跨度非常大,覆盖了人工智能、室内定位和智能传感器技术,每套方案又有完全不同的优缺点,比如蓝牙基站需要与政府沟通进行基础设施投入和维护;摄像头方案需要解决数据流量与电池问题;光学传感器的难点在于解决精度问题,比如雨天会影响传感器的接收;在这种条件下,技术团队如何帮助业务部门了解优缺点并一道做出决策呢?

挑战三:缺少设备、集成接口进行持续验证

过去几年来,持续交付实践快速演进,其中一个重要因素是云计算,它为开发人员提供了更充沛的计算条件,从而让软件开发、测试和上线的周期大大缩短。

在IoT时代,当我们创新的产品涉及到硬件设备时,由于很多大型设备的价格很昂贵,缺少设备依然是非常普遍的情况。比如在我们的另一个超市创新项目中,团队只有一组闸机可以使用,而且缺乏模拟器和易于理解的接口,开发团队往往需要硬件专家来破解其协议才能进行集成开发。缺少设备,缺少集成接口是实现持续交付的重大障碍。不能持续交付,就不能支持“构建 – 测试 – 学习”反馈循环。

GDV创新旅程中,我们收获的经验

精益式产品是应对创新风险的最佳实践

精益思想非常适用于打造创新产品。在充满不确定性的探索期,它强调应该把精力放在验证风险,低成本快速试错。在度过探索期之后,我们就可以找到正确的投资方向,开始持续的产品迭代,继续打磨产品的细节。GDV的创新旅程正是应用了精益式产品创新,才得以在5周时间里快速找到要解决的具体问题和技术方案,以极低的成本验证了关于用户问题、方案、产品形态的假设。

建立“完整团队”来应对技术复杂性

一个典型项目往往会包括智能传感器、云端平台和移动设备,所以建立一支理解业务、硬件、云计算、设计和现代工程实践的团队是项目成功的关键,我们的经验是典型的“IoT”团队需要包括以下角色:硬件专家、数据和算法专家、用户体验设计专家和业务专家。 另外,在过去的网页时代,设计师往往可以通过纸质原型完成最早期的测试,在IoT时代团队则需要升级工作包。比如乐高玩具是很好的工具,因为其灵活组装的特性使其可以与3D打印以及黏土配合,以设计早期用户测试所需要的部件。

当建立起这样一个全面的、跨职能的“完整团队”时,我们就能有效地面对技术复杂性,在关键的技术原型构建、用户测试过程中得到更充分的信息,进而做出技术决策。

开源硬件模拟和硬件在线更新设计

目前而言,我们的经验是通过开源硬件迭代模拟一个产品环境。通过不断地探查产品环境,利用手边的可用硬件不断“逼近”产品硬件环境,捕获“尽可能多”的问题;同时,开发团队也可以利用这套知识,构造多套环境来满足测试验证的需要。

第二个经验是在线更新需要成为硬件选型的标配。由于硬件规格、能耗、预算的限制,大量现有的硬件产品缺乏OTA能力,然而这是持续验证的必要基础。在避免大幅度超过预算的情况下,硬件设备设计足够的内存进行升级和回滚操作。这样,就可以在较少的硬件投入成本下,验证不同方案的测试效果,进而满足创新实验过程中所必须的快速“构建-测试-学习”的节奏。

一起来,探索社会化创新,让未来更美好

层出不穷的商业创新使整个社会的财富持续增加。尽管如此,一直困扰着人类的那些基本问题——贫困、疾病、劣质甚至根本没有的教育等等——并没有随财富的增加而相应地减少或减轻。相对于商业领域,社会领域更需要关注和创新。

我们感叹于AlphaGo Zero的强大,但我们仍然相信,更美好的未来还是掌握在人类自己手中。即使是我们的商业企业,在社会创新中,也扮演着越来越重要的角色。一方面,企业可以在商业创新中植入社会担当的因素;另一方面,企业将商业活动中积累的资源、项目运作和管理能力注入到社会创新项目中。GDV是我们众多创新旅程的一个故事,还有更多真实广泛的社会领域问题,有待关注和解决。一起来,加入我们的社会创新体验之旅吧!


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

Share