CSS-in-JS,向Web组件化再迈一大步

简介

CSS-in-JS是什么,看到这个词就能大概猜到是在JavaScript里写CSS,那为什么要在JavaScript里写CSS呢,像之前一样写在css文件里哪里不好么?

在介绍这个概念之前,先来回顾一下在日常编写CSS代码时都有哪些痛点:

  • 全局污染 – CSS的选择器是全局生效的,所以在class名称比较简单时,容易引起全局选择器冲突,导致样式互相影响。
  • 命名混乱 – 因为怕全局污染,所以日常起class名称时会尽量加长,这样不容易重复,但当项目由多人维护时,很容易导致命名风格不统一。
  • 样式重用困难 – 有时虽然知道项目上已有一些相似的样式,但因为怕互相影响,不敢重用。
  • 代码冗余 – 由于样式重用的困难性等问题,导致代码冗余。

进化史介绍

在CSS的进化历史上,出现过各种各样的框架致力于解决以上的问题:

  • SASS, LESS – 提供了变量、简单函数、运算、继承等,扩展性、重用性都有了很大的提升,解决了一些样式重用冗余的问题,但是对于命名混乱问题的效果不大。
  • BEM (.block__element–modifier) – 比较流行的class命名规则,部分解决了命名混乱和全局污染的问题,但class定义起来还是不太方便,比较冗长,而且和第三方库的命名还是有可能冲突。
  • CSS Modules – 模块化CSS,将CSS文件以模块的形式引入到JavaScript里,基本上解决了全局污染、命名混乱、样式重用和冗余的问题,但CSS有嵌套结构的限制(只能一层),也无法方便的在CSS和JavaScript之间共享变量。

可以看一个简单的CSS Modules例子了解一下:

生成的dom结构如下图,基于css文件中的class名称生成了唯一的class名称,样式会定义到生成的class上。

styles打印出来如下图,定义了css中的class名字和生成的唯一class名字的对应关系。

可以看出,以上框架都解决了不少痛点,但也还是各有一些不足,当然CSS-in-JS也并不是完美的解决了所有问题,我们先来详细介绍一下。

流行框架介绍

现在随着组件化概念的流行,对从组件层面维护CSS样式的需求日益增大,CSS-in-JS就是在组件内部使用JavaScript对CSS进行了抽象,可以对其声明和加以维护。这样不仅降低了编写CSS样式带来的风险,也让开发变得更加轻松。它和CSS Modules的区别是不再需要CSS样式文件。

来看一下几个流行的CSS-in-JS框架六个月内的下载趋势

我们来看看几个下载量靠前的框架的风格是什么样的:

styled-components

先来看看下载量最高的styled-component的代码风格:

从上图可以看出,Title和Wrapper都是框架包装好的component,可以直接在react的jsx语法中使用,在包装component的时候还定义了标签分别是h1和section。此段代码产生的html dom如下图所示:

可以看到section和h1上分别生成了唯一的class名称,样式也对应的定义在生成的class上了。

这样就可以解决命名混乱和全局污染的问题。组件相关的代码都在一起,可以统一查看,也可以方便的重用样式。

glamorous

再来看看glamorous,这个框架是PayPal开发的。(前两个logo看下来,恍惚间感觉进了化妆品专柜)。

和styled-component不同的是,glamorous的样式直接以attribute的形式定义在了dom上,之后虽然也为其生成了class名称及样式,但这种以attribute定义的方式对伪类选择符(如 :hover)支持的不好,会带来一些不方便,而且需要再记住一套attributes名称和值与真正的css样式代码的对应关系。

JSS

和上面两个框架类似,jss也是会定义styles对象,并附到component上,最后生成的dom也是会有生成的唯一class名称,并有对应的样式,但样式并不是真正的css语法,而是对象的属性和值,这样也是对伪类选择符支持的不好,而且也需要记住属性和css样式代码之间的对应关系。

Radium

Radium在定义样式对象上看似和其他相似,但在生成dom结构的时候并没有生成唯一的class名称,而是直接把样式放到了style属性上,这样会带来诸如可读性差、CSS权重过大、不支持伪类选择符等问题。

测试

下面再来看一个styled-component提供的基于jest的测试框架:

jest-styled-components

这个框架主要是通过生成Snapshot并比较的方式来保证component样式的每次更改都会被检测到,并且样式是期望的样式。这样就又降低了重构CSS样式带来的风险。

优劣势总结

看了这些框架后,可以发现CSS-in-JS的优势还是挺多的:

  • 因为有了生成的唯一class名称,避免了全局污染的问题
  • 唯一的class名称也解决了命名规则混乱的问题
  • JavaScript和CSS之间可以变量共享,比如一些基础的颜色和尺寸,这样再当需要在JavaScript里计算一些高度的时候,可以取到和dom相关的一些padding,margin数值,统一管理
  • 只生成页面需要用到的代码,缩减了最终包的大小,提升了性能
  • CSS的单元测试增加了样式重构的安全性

但是CSS-in-JS也存在着一些不足和争议:

  • 有些观点觉得JS和CSS的关系没这么近,把CSS写进JS里引入了新的一套依赖,增加了复杂度,新人加入项目后需要学习的东西就更多了,也让学习曲线更加陡了
  • 对前端框架确实有些依赖性,更适合于组件化的框架,如React等
  • Debug的时候需要花更多的功夫才能找到对应的样式代码
  • 覆盖第三方插件样式时会有权重不够的问题
  • Lint工具对于JavaScript内部的CSS代码样式支持的还不够

最后

在ThoughtWorks最新一期的技术雷达(CSS-in-JS | Technology Radar | ThoughtWorks)里,它的等级是Assess,表示的是:“值得追求。重要的是理解如何建立这种能力。企业应该在风险可控的项目中尝试此技术。” 所以最后想说的是,虽然它还是有些不足和争议,在应用之前需要多角度衡量一下对项目的适合度。但它的优点也很多,确确实实解决了很多痛点,而且与web组件化的方向高度一致,希望大家在条件合适的情况下多多尝试,多多反馈,这样也能促进整个CSS编码体验的继续进化~


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

Share

是什么在扼杀你的创新文化?

[摘要]

数字化创新不仅仅需要技术和人才,也需要创新文化。创新文化是组织持续创新、规模化创新的必需土壤。从组织中常见的扼杀创新文化的“七宗罪”,来一起反思构建组织创新文化的正确姿势。


在快速变化的不确定时代,每个行业都在经受着技术所带来的指数级变革的影响。无论处于哪个行业,企业都需要重新审视过往的经验,快速、灵活地采取行动,以跟上变革的速度。这就需要各个企业具备持续创新、把创新的点子孵化为新业务、进行规模化创新的能力。但,数字化创新绝不仅仅是技术和人才。如果把技术和人才比喻创新的禾苗,那创新文化就如同土壤和空气。没有创新文化,持续性创新、规模化创新就无从谈起。

如何建立和培育创新文化,一千个组织可能有一千个不同的做法,无法一概而论。但在很多组织里,却存在着很多反模式,这些做法不但没有培育创新文化,反而是在扼杀创新文化。

扼杀创新文化的“七宗罪”

1. “不见兔子不撒鹰”

“这种投入能多大程度上提升我们的交付效率?”

“这个新产品三个月后能带给我们多少营收?”

“能现在就告诉我们转型的结果吗?”

“同行转型的数据是什么样的?”

……

这些声音听起来是不是很耳熟?对于成熟业务,投资产生的影响有一定可预测性;对于探索或尝试业务,因为不确定性很高,在短期内给出量化营收会很困难。如果把“成功”完全等同于立竿见影看到营收数字、强调必须“成功”才能投入的策略,可能也会让组织失去创新力。

“只有当商业社会对创新持以支持和包容的态度,而不是只看胜败输赢的心态,这才是我们走向‘中国创造’的开始”,《聚变式创新》的作者程然这样说。创新不是一定要“成功”,而是通过尝试快速学习,最终为客户和组织带来价值。

2. “憋大招”

“我有个很好的想法,但是现在不能公布。”

“我们既要解决大型企业定制化,也要做到通用化。”

“我们要做一个类似于XX的平台,现在还没到时候演示。”

……

觉得自己的创新想法非常独特,生怕别人偷了去。不看外部反馈、只顾埋头苦干,可能导致过度投资。过度的投资本身就是创新的敌人

ARM芯片如今已经成为几乎所有移动设备的心脏,当其老板Herman Hauser在被问及是如何做到的时候,说:“回过头来看,当时在我们决定做一款微处理器的时候,我认为我做了两个重要的决定。我信任我的团队,并且给了团队两件英特尔和摩托罗拉永远不会提供给他们员工的东西:第一是缺钱,第二是缺人。他们不得不保持简单。

3. “惩罚错误”

“一次性把事情做对”

“同一个团队不犯相同的错误”

“同一个组织,两个团队不犯同样的错误”

……

很多创新投资失败后,事后很容易看清楚产生错误的归因,但回到当时其实很难判断。如果组织对待错误的方式就是惩罚,那么,人们会避免做出任何有风险的决策,这是创新文化巨大的障碍。

不去惩罚错误,不是鼓励人不考虑后果,而是确保人们能够获得必要的信息来做出有效的决策,找到办法来限制决策可能带来的负面结果,并且训练有素地从错误中学习经验教训。我们要改变对待错误的方式,甚至要人为制造一些困难,让团队从错误中吸取经验。Netflix公司以一套被戏称为“类人猿大军”(Simian Army)的服务将这一理念发挥到了极致:这套服务中,“混世魔猴”(Chaos Monkey)会每隔一段时间将生产环境服务器关闭,以此来测试生产环境的快速恢复能力。

4. “当包工头”

“员工能力不够”

“项目紧,培训放周末或晚上”

“这样的薪资水平找不到合适的人才”

“外包员工流动性很大”

……

尽管把“尊重每一位员工”挂在嘴边,但到执行时依然会把组织中的每个人看成是机械化时代流水线的工人,忽略了每个人内在的创造性。

组织中最宝贵的,唯一可以增值的是人。张瑞敏在哈佛大学“物联网时代的商业模式”的主题分享称海尔通过人单合一模式,充分调动了员工的积极性,并购多家企业,在没有进行人员调整下,一年内扭亏为盈。如果只是把员工当成流水线工人,不去激活他们,创新力无从谈起。我们曾经在一个组织做过类似的事情,原来外包人员分散在各个团队,完全没有积极性。在组织结构调整时,把外包员工放到了同一个团队,由两名资深员工把握质量,制定明确的目标,赋予他们明确的职责。不到一个月,团队整个氛围发生了很大的变化,大家更加主动,积极性变化很大。

5. “刻板印象”

“电信产品都是遵从协议的,需求变化很少”

“银行产品安全性要求很高,没办法快速迭代”

“API接口已经定义好了”

“年轻人做事毛糙不靠谱”

……

虽然,实践经验是我们的宝贵财富,但一味因循守旧只会固步自封。人们对变化天生具有恐惧心理,“刻板印象”——选择性地记忆实践经验,并利用其做决策,很可能是我们抵抗新想法、新方式的借口。

6. “重用一切”

“杜绝代码浪费,尽可能重用组件,等组件团队改好了我们再开始”

“杜绝重复投资,B团队也在做这个点子,我们就不要尝试了”

……

当面临的是确定性的问题,已经有成熟方案、已被验证是最佳实践时,“重用”模式是对的,可以避免浪费;但如果面对的是新问题,还需要探索验证最佳方案时,“重用一切”的思维可能就是在做局部优化,阻碍持续创新。

微信是在腾讯3个类似的产品竞争中胜出的;手机音乐应用软件在腾讯内部有四款;有三个从事虚拟现实技术研发的业务部门;进入视频直播时,有六个部门都在做视频直播。马化腾说,内部竞争是必要的创新动力。内部PK可能暂时看起来是浪费资源,但却在不断打磨增值核心竞争力

7. “归罪于外”

“IT部门做事太慢”

“业务部门需求变化太快”

“开发的质量太差”

“环境不够且不稳定”

“我的事情很多”

“别人总打扰我”

……

这是我们在很多组织进行敏捷转型时,特别耳熟的话。不只是组织中的个人,小到团队中的不同职能,大到组织间的各个部门,都经常会有这种典型的思维模式——“归罪于外”,而不是从自身去找原因。自我限制是走向成功创新思维的最大障碍。

(图1:扼杀创新文化的“七宗罪”,图by王伟)

导致“七宗罪”的核心归因

如果反思前面七种错误思维的出现,会发现核心原因是:

  1. “不见兔子不撒鹰”,“憋大招”,“惩罚错误”:这主要和组织的创新流程和管理机制有关。具体来说,就是组织对创新的投入没有“聚焦”,缺乏明确投资标准;针对探索性投资,没有看到“验证假设”、学习也是成功的定义之一;欠缺一个短迭代的PDCA机制来促使创新团队获取反馈。
  2. “当包工头”:这主要是领导者思维的问题,管控思维over授权思维,没有真正授权团队,并为团队真正“赋能”——通过建立正确的组织能力来加速创新流水线中的验证和学习活动。
  3. “刻板印象”和“重用一切”:这是在组织层面“连接”的问题——即在组织的各个节点之间没有真正互连互通,缺少建立信任、倾听、收集反馈、共享数据、连接想法的机制,因而也缺少了规模化创新所需要的网络效应。
  4. “归罪于外”:本质是创新文化“培育”不足的问题,没有建立起“成长性思维”的组织“精神底层”。

(图2:组织的创新引擎

培育组织创新文化的10个有效实践

(图3:构建创新文化的有效实践)

1. 在全组织内培育“成长性思维”

如果“归罪于外”这种思维普遍存在,那么在组织内全员做“成长性思维”培育非常有必要。“成长性思维”强调用乐观积极的态度去面对各种问题、困难和挑战,从内在找问题、并正向思考解决方案的心智模式。而且,已经有实验证明,这是可以被培养的。通过新人入职培训、全员覆盖的在职培训等,改变大家的思维模式,这对于建立创新文化的氛围很有裨益。

2. 组织在各个层面的战略工作坊,帮助团队“聚焦价值”并上下对齐

战略工作坊使用设计思维作为理论模型,通过大家协同工作,在战略、目标、短期计划构建精益价值树上达成共识。组织、部门、团队各个层面组织这样的工作坊,让大家真正理解上层的战略和目标、核心价值,保证短期计划预制对齐。

3. 建立很多小的、自主的产品团队,“轻”投资

小团队更容易激发自主性和灵活性。对于以探索性的新业务,成立具有跨职能角色的、恰好满足端到端完成产品探索和验证的小团队,更容易验证创新文化和创新管理机制,成为创新榜样。

4. 建立领导者准则:教团队“算法”,而不是“答案”

对于领导者,要真正授权团队,教团队做决策的原则和方法,而不是告诉团队做什么样的决策。比较有效的实践是,把此作为领导者行为准则,并定期匿名向团队收集领导者执行该准则的反馈。

5. 为创新业务开创独立的技术平台和配套资源

对于承担创新业务的团队,提供独立的技术平台和配套资源支持,开辟“绿色通道”。

6. 广播创新案例故事,把创新工作透明化

及时把创新案例做成视频等,通过各种渠道,展示给组织内的其他部门或外部受众:要验证的想法是什么?为什么要验证? 学到了什么?从这些维度进行分享,或者更进一步,分享客户评价的原文,这样的机制才能充分展示“创新想法”的价值。

7. 创新论坛,撬动大众去创造更多的想法

组织内部建立一个开放、透明的点子平台。例如“我的星巴克点子”, 共有四大功能:分享、投票、讨论、状态。只要注册会员,就可以上去分享自己的点子。想法可以是产品、服务、店内装潢,甚至是企业责任提出方案和改进建议。同时所有人可以针对点子投赞成票和反对票,并且留言回复进行讨论。最后,平台由50位经验丰富的“点子伙伴”随时更新点子执行情况和采纳点子的最新产品和服务的来龙去脉。

(图4:我的星巴克点子网站

8. 组织黑客马拉松和设计马拉松

创新想法落地可以通过非常轻量的机制来实现——如将开发人员,设计人员和产品团队聚集在一起,围绕一个问题进行创想、构建和修改,更简单的,还可以去接触不同职能部门的员工群体,当他们刚好有空时,临时找一个会议室, 大家围绕特定的客户或业务问题进行快速的头脑风暴,即“黑客马拉松”和“设计马拉松”。

(图5:2016武汉黑客马拉松现场)

9. 定期调整工位、灵活的轮岗机制

调整工位、灵活的轮岗机制都是“连接”的有效机制,可以有效地激活组织个体能量。

卡内基梅隆大学教授李顺基,在一家韩国电商企业以前后对比的方式,分析了工位变化对员工个体创新和销售业绩的影响,他发现,那些换了工位、与不熟悉的同事坐在一起的员工,平均每天创造的收入比搬之前的平均水平高出40%。“当你对具体工作领域足够了解后,认识新人会让你更有创造力。对于新认识的同事,空间上的接近能提升信任度,促进有价值的知识和新信息的分享。这能让你将新知识与原本掌握的知识结合起来,从而进行创新。”

10. 广泛建立外部网络连接

“Think Out of Box”,创新的想法来自于各种新鲜想法之间的碰撞和连接。有效建立外部网络连接、通过社区活动、主题会议等形成内外互动的创新网络,才能发挥出创新所需要的网络效应。

以制药公司礼来(Eli Lilly)为例,这家公司在2000年就创办了一个创新中心,通过网络把组织内部遇到的问题分享出去,征求外部人才的协助。其中,85%的问题都得到了有效解答,答题者中40%的人并没有常规药学领域所要求的硕士、博士学位。

写在最后

如果说企业进行规模化创新,也需要元能力的话,那么这个元能力就是“构建创新文化”的能力。这是项极具挑战而有意义的工作。你的组织中有哪些扼杀创新文化的思维模式?又有哪些经过实战总结出来的好实践?希望我们一起来分享并持续探讨。


推荐阅读:

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

Share

翻译这件小事

加入ThoughtWorks一年半,在前辈们的牵线搭桥之下,非常机缘巧合的参与了两本书的翻译,虽然加起来10多万字,远远未到“足以谈翻译这件事”的地步,还是希望在本文中从经验的角度分享出一些真实简单的感受,给想要入坑的伙伴们一些参考。

翻译的目的和价值是什么?

答案肯定因人而异。就我本人来说,一开始是误打误撞纯粹图个名,后来发现翻译几乎就是比精读更精读的阅读一本书,你需要了解作者提到的各种术语,知道举证案例背后的事实,有的时候为了一句话,查资料越跑越远像是发现新大陆。在这个过程中,且不论最终翻译的质量如何,一定会对原作的每一句话形成深刻的理解,因为你需要不断去思考作者为什么这么说,才能保证译文的准确性。至于花上这么长的时间精读一本书是否值当,那就取决于这本书本身了,所以这里首先建议有尝试意向的人,一定要选择自己感兴趣的领域内容,这对于克服懒惰这个天敌意义重大。

“有了Google Translate,还需要人工翻译么?”在机器学习技术红起来之后,很多人对翻译这件事情的价值理解就打了个更大的折扣,如果从前人们还相信书籍的翻译出版有“信达雅”的标准,现在大多数人估计认为翻译无非就是把Google Translate的译文随便调整下,能通畅地表达就行了。其实没错,还真就是这样的。

从某种意义上来说,Google翻译确实大大拉低了翻译的门槛,这倒不是因为翻译的要求降低了,而是因为机器翻译大大提升了翻译的效率。翻译一直以来都是一门对技术敏感度非常高的学科,计算机辅助翻译(Computer Aided Translate,简称CAT)的技术发展已经超过三十年,翻译实践很早就从纯人工行为转向了人工和信息技术相结合的策略。随着机器学习技术的兴起和语料库的不断扩充和完善,机器翻译已经成为译者倚赖的工具,这没有什么不好意思承认的,发明和改善工具,原本就是为了提高生产效率。当然,这里不打算讨论机器翻译是否会完全替代人工翻译这个话题,感兴趣的可以回复交流,写这篇博客的目的还是为了说回翻译这件事情本身。

翻译是什么?

通常我们所讨论的翻译就是将某一语言的言语产物转换到另一语言当中。更广义来说,它还可以包括语言和非语言符号之间的转换,比如转换为手语,以及一种语言中不同变体之间的切换,例如从文言文到白话文的翻译。但是究其根本,翻译的核心终归是在译文中完整准确地表达原文的意思。如果将人工翻译的过程拆解开,那就是阅读原文,理解原文,输出译文。

理解原文

关于翻译的理论研究成果非常丰富,关于翻译实践的技巧也很多,但是这些无一都是聚焦在“输出”这个环节上的。而实际上,对原文的理解才是翻译的源头。这一点有多重要以及有多难,从事文学翻译的译者最有发言权。

我们通常接触的原著作一般是非文学领域的,例如技术书籍或是商业分析等等。这类比较偏标准化文本的著作,出于其本身的写作目的,通常都是为了说清楚某个问题、介绍某种方法,或是表达某个观点,大体都是表意清晰客观,语言规范且较少存在歧义的。在上下文和逻辑的帮衬下,要准确理解原文并不会太难。如果碰上句式结构复杂,拿不准断句和原意的时候,Google Translate 就可以派上用场了。以英译中来看,谷歌翻译的译文虽然无法直接拿来用,但是不得不承认,机器学习输出的译文对原文的理解准确度是非常值得肯定的。并且,谷歌翻译对专业术语或是一些惯用表达的译语,很大程度上可以帮助提升效率。

也千万切记,Google Translate的释义并不是完全make sense的,所以一定要不断联系上下文来看整体表达是否切意,对不通之处要寻求各种帮助来弄懂。如果译者自己都没有弄明白作者在说什么,只是语焉不详地照搬原表达,不知何以然,那么读者的混乱程度只会更高。

输出译文

准确理解原文之后,接下来就是译语的转化了。如果说上一个阶段要求的是对原语言的理解力,那么这一阶段需要的就是目标语言的写作能力了。写作能力越高,对目标语言的掌控力越高,在理解准确的前提下,当然也就可以更为精准地还原原文的意思。是的,道理大家都懂,可是写作能力这件事儿不是看几本书就能立刻得到提升的,这是一个需要不断练习和打磨的技能。大家可以参加一些写作工坊,尝试“21天持续写作”等方式,来持续提升自己的写作能力。

直译还是意译?

进行译文创作(如果翻译这件事情真的存在“创”作的话),永恒的问题就来了,到底是选择意译还是直译?

一般来说,比较遵照原文语言结构的译法就是直译,脱离原文语言结构的束缚,只翻译意思的译法就是意译。逐字翻译、直译、意译和解释翻译之间并没有非常清楚的界限,但是四者的顺序反映出了一个自由度提升的过程。直译好还是意译好,其实并没有一个高下之分。不同的人就有不同的翻译风格,直译能保留更多原作的味道和比喻,但是经常被人吐槽“翻译腔”,其实就是表达方式过于西化;而意译就像滤镜,对于目标语言的融合度更高,更符合读者的阅读习惯,但是也会丢失更多原作的风格,读者离原作也就更远一些。

直译和意译的选择并非绝对,对于非文学翻译来说,尤金奈达的“功能对等”的理论非常适合。我们的目的是将原作的知识和信息准确、清晰地传达给目标语言的读者(以读者为中心),首先是重现意义,然后是风格。那么我们能得到这样的优先级排序:准确、易读/易懂、尽可能还原作者的风格(例如幽默)。如果直译的结构十分不符合中文的表达习惯,那么我们应该在保证意思准确的前提下,选择意译。

一些实用的小Tips

这里有些简单的技巧,可以为我们在处理特定结构的表达时提供参考:

1.不要受困于词性

对词性的敏感(名词、动词、形容词等)在翻译过程中很容易束缚住表达。因为词性的概念建立在语言的表层结构上,而英汉两种语言的表层结构恰好差别很大。执着于词性的对应会严重影响意义的表达,例如:

  • It took a long Presidential drive to get them talk again. (在总统不顾路途遥远,驱车前往调停后,双方才恢复了对话。)这句话的上下文是叙利亚外长和以色列总理访美期间谈判陷入僵局,美国总统前往调停,译语里改变了long, Presidential, drive, talk等词的词性。为了确保可读性,一定要跳出词性在英语学习过程中建立起的牢固概念。特别是使用Google Translate辅助时,机器翻译大体还是遵从了词性的对应,译者必须有意识地进行调整。

2.拆解句子结构,分合移位

切分、合并、移位是翻译中很常用的方法。目的是将原语言更自然地用目标语言表达出来,可以对原文进行切分、合并或是调整词组/从句的顺序。

  • My father was not wrong in judging me too young to manage business of importance. (我父亲认定我太年轻,办不了大事。他算是没说错。)原本很简单的一句话,译成中文后成了两句,但是表达的层次更清晰也更自然。再比如 Thank you for your advice and counsel 译为“谢谢你的忠告”,因为两个词实际是一个意思,重复只是一种语言手段,翻译可以考虑合并。

如果想要表达更通俗易懂,可以尽量使用短句。短句是否一定就是好,这点尚存争议,也取决于译者风格。句子越短,意味着对原文的拆解越彻底,译者发挥的自由度越高,也更有利于读者的理解与阅读,比如本段的表达。但与此同时,这种译法表达错误的几率也偏高,且更容易损失原文的味道。

3.被动语态的处理

被动语态是英语的惯用表达,例如 I was told that…中文里虽也有被动结构,比如上面这句话就可以翻作“我曾被告知……”,但是实际应用场景中,除非特意强调,例如“他被捕了“,通常并不会颠倒主谓宾。我们需要意识到,大多数情况下,被动结构本身并没有什么意义。特别是在技术类书籍中,因为没有特定的主语,所以被动结构成了常规表达方式,翻译时什么时候应该转为主动,什么时候应该沿用被动取决于译者当下的判断,并没有直接的判断标准。可以注意以下两点:

  • 被动转主动时,汉语中可以不需要主语;
  • 即便使用被动语态,被字有时也是可以省略的,例如“广告随处可见”;就算无法省略,汉语中还有其他助词可以表示被动,例如:受、遭、让、叫,等等,尽量避免“被”字连篇。

4.增词不增意,删词不减意

增词通常出于两种目的:一是用更多的词解释清楚原意,例如前面提到过的long Presidential drive;二是增加上下文之间的衔接词,比如“而且”、“所以”、“于是”等等,使表意更通畅。

减词的目的是改善汉语行文,例如 He shakes his head 就没有必要翻译为“他摇着他的头”,“他的”两个字就可以去掉。英文中因为严格的语法结构,其实很多代词、连词和介词都不需要逐词翻译出来,减掉不影响表达的词是保证汉语简洁的常用手段。

所以不论增词还是减词,目的都是使表达更符合汉语的表达习惯,而不是对原文的意思进行增减,在保证含义准确的前提下,译者自己可以把控这个度。

5.校对

翻译完成后一定要自己校对一遍!这点很重要!很多在翻译时觉得挺正常的表达,在最后校对时会觉得完全不通。校对一般脱离原稿,这时的目的除了修改错别字以外,最重要的就是调整表达。把自己当作一个陌生的读者,看译文是否达意。

写在最后

总结来说,对于偏标准化的专业类书籍,翻译没有所谓的门槛,是一种人人都可以尝试的学习方式。最大的障碍只有懒惰和不求甚解(其实是一回事)。马上又要到大量书籍等待认领的时候了,分享一些个人建议:

  1. 正如前面提到过的,选择的原著最好是自己感兴趣的领域;
  2. 翻译的效率高低与专注度正相关,因此翻译的时间尽量不要打得太碎;
  3. 针对专业书籍,最好创建并维护一个术语表,保证译语统一,特别是多人合作的情况下;
  4. 如果原作的格式较多,推荐使用markdown编辑器,Ulysses或者MacDown都不错;
  5. 魔鬼都在细节里,翻译过程中这点尤甚。格式、注释、术语等等细节问题尽量不要积压到最后一起处理,每一次的任务结束都尽量保证完整性和准确性,因为最后校对阶段极有可能不会再逐句对照原文检查。

最后,引用张玳老师在引荐《精益扩张》这本书的翻译工作时说过的话:“翻译是比较累的活,经济收入也不成正比,但是能带来名誉,锻炼语言,也可以磨练心志。”希望所有正在这条路上受苦受累的人,最终都能有所收获并乐在其中。


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

Share

数字化平台之微信平台策略

当下,互联网技术正在深刻地重构我们的社会,各大企事业单位——大到万人集团公司,小到图文复印店——都在争先恐后地从所谓的“传统行业”中脱胎换骨一番以完成数字化转型。

在这个过程中,“企业即IT”、“科技即商业”等口号被屡屡提及,企业开始重新审视已有的CRM系统、供应链体系等诸多IT资产,发现割裂的信息化并不能给企业带来多少价值,于是CIO们逐渐意识到他们所需要的其实是一个IT生态系统。简单的讲,这里的IT生态系统即可以理解为数字化平台,这个平台不单单是个技术平台,同时也是一个业务平台。

微信平台策略

在中国,我们似乎有天然的优势,因为我们有微信呀!是的,就是那个连咱们的二大爷三大姑都能够用之在朋友圈分享点养生常识,以及那些成天被城管追着跑的路边烧烤小哥都能用之完成无现金收款的微信。

微信本身便是一个数字化平台。这个平台为个人或组织提供了一种新的展示空间——市场营销、自媒体、移动支付、业务办理等等等等。事实上,“平台”一词有两种含义:一种是上文提到的微信平台本身,另一种是对于某个组织来说,利用微信(包含微信公众号和企业微信)做为其自身的业务平台,本文讨论的是后者。

通常来说,企业在构建微信生态的过程中,可以采用三种微信平台策略。前两种是比较基本的策略,这里只做简要介绍。本文重点将讲解第三种:结合了微信公众号和企业微信的“行业解决方案平台”。

微信公众号

第一种,也是最简单的一种,即大家在平时生活中都能够接触到的微信公众号。微信公众号已经在悄然地取代官网成为企业新的门户,诸如寄快递、订机票这些先前只能在Web网站中完成的业务,现在只需关注某个公司的微信公众号便可完成。

请注意,微信公众号分为订阅号和服务号,订阅号主要用于宣传营销,并不能有效用于那些需要在微信中开展业务的场景;而服务号则主要用于开展业务,因此本文在说到公众号时,主要指的是微信的服务号。

事实上,这种方式还算不上“平台”可言,但是它的确是一种行之有效并得到广泛采纳的触达终端用户的手段。通常来说,微信公众号并不完全独立运作,它依然需要与企业其他业务系统集成起来以形成完整的业务闭环,这里的“其他系统”有可能为了配合公众号而进行全新开发,也有可能是企业已有的IT系统,而微信公众号充当的只是另一种业务接口而已。

在技术上,公众号开发可以有多种形式,包括微信自身提供的“消息应答机制”、HTML5网页应用以及小程序等。

微信公众号平台

公众号+企业微信联合平台

微信公众号主要面向终端用户,同时,腾讯公司还提供了使用对象为企业员工的企业微信。对于多数企业(特别是中小型企业)来说,一个微信公众号已经足够,甚至连腾讯官方的解决方案库中也主要只针对公众号而缺少对企业微信的提及。当然,当前已经有越来越多的企业开始使用企业微信,但是其中多数企业使用企业微信的目的主要集中在诸如通讯录、考勤等人员管理上,而不是本企业的核心业务。本文讨论的主要是将企业微信用于完成企业的业务环节,比如快递公司的快递员通过企业微信完成包裹的录入登记、售后人员通过企业微信完成服务工单的追踪等。

微信公众号和企业微信联合平台可以完成各大企业移动化办公的梦想。在企业微信中,我们可以开发多个业务应用,比如一个汽车生产商的企业微信中可以包含ERP、CRM、供应链以及4S店管理等应用。另外,在企业微信中开展业务流程时,我们可以直接享受到企业微信现有的支撑功能,包括通讯录、企业邮箱、企业支付以及公费电话等。可见,企业微信本身便是一个不折不扣的平台化工具,再加上面向终端用户的微信公众号,该联合平台有助于形成一个完整的客户服务以及业务运作体系。

微信公众号+企业微信联合平台

有了这个联合平台,你会发现微信不再是发个宣传图文或者购物收款这么简单,而是摇身一变成为能够满足用户自服务的核心业务工具;企业微信也不再只是管理一下通讯录或者让员工请个假打个卡,而是一款能够完成业务运作以及提升办公体验的员工伴侣。

行业解决方案平台

行业解决方案平台主要用于解决某个行业中的通用业务问题,可以是单独针对公众号的,也可以是单独针对企业微信的,还可以是同时包含了公众号和企业微信的“终极”平台形式。

腾讯官方在公众号和企业微信两端均提供了平台化支持。对于公众号,可以通过微信开放平台的第三方平台完成公众号的业务授权和代理;对于企业微信,可以通过服务商平台完成企业微信的业务授权和代理。当前,市面上已经存在大量单独的第三方平台应用或者服务商平台应用,但是将此二者结合以形成完整的业务闭环还鲜有出现。

为了便于读者理解,这里列举两个典型的应用场景:

客户投诉:

每个致力于长远发展的企业都需要一个完善并且能够实际运转的客户投诉机制。对于客户投诉的处理流程在各个行业中其实大同小异——都是基于类似于工单的处理流程。因此,某个专门做微信开发的公司做了一套关于投诉的行业微信方案。在该方案中,客户通过某企业的微信公众号完成投诉,企业员工通过企业微信完成对投诉的处理,整个过程完全移动化。企业并不需要自行研发投诉管理系统,只需将自身的公众号和企业微信授权给这个基于微信的投诉平台即可。可以看出,这里的投诉平台事实上是一个类似于具有多租户特点的云平台,而很多基于微信的行业解决方案系统的确也正是部署在云平台之上的。

汽车销售:

汽车生产商通常并不负责汽车零售,而是将其代理给多个4S店,这些4S店并不隶属于汽车生产商,他们也有自己的企业,有自己的品牌,有自己的企业微信和公众号。但是,4S店需要遵循汽车生产商的某些规范或者服务标准,从这点来讲,后者与前者又存在管理与被管理关系。汽车生产商为了规范化对客户的服务,开发了一套针对该品牌汽车销售的行业级微信平台,所有经销商均在该平台上完成汽车销售相关的业务。该平台同时包含了公众号和企业微信,终端买家可以通过经销商的公众号完成车型查看、试驾预约等业务,而经销商的员工可以在经销商自己的企业微信中完成对客户的服务业务,比如安排试驾、客户关系管理等。需要注意的是,所有销售过程都发生在经销商自己的公众号和企业微信中,而不是汽车生产商的,这有利于经销商建设其自身的品牌形象。经销商自身并不需要做任何开发,而是将公众号和企业微信授权代理给汽车生产商开发的微信行业平台即可。可以看到,在企业微信端,这是一个B2B的系统,在公众号端,这又是一个B2C系统。

以汽车销售为例,经销商的微信公众号与企业微信是两个相对独立的主体,要使他们服务于同一个业务流程,我们需要将此二者关联起来。此时,我们创建一个“经销商管理平台”系统,在经销商在管理平台上注册之后,系统将关联它的微信公众号与企业微信。由此,终端用户在公众号端发起的请求可以直达企业微信中的员工。

微信行业级解决方案平台(以汽车销售为例)

这种平台落地之后类似于:汽车制造商为了促进销售额以及规范对客户的服务,开发了一套同时兼顾B2B和B2C的微信平台,不同的经销商带着各自的微信服务号和企业微信入驻该平台。所有的经销商都通过由汽车生产商提供的同一套业务流程和标准向终端客户服务。

如果我们把“汽车销售”的例子抽象一下,便会发现各行各业均存在这种分级式的商业关系:商品的生产方并不直接将商品或服务提供给终端客户,而是通过代理的方式将这些业务交给中间的经销商或代理商,不同的经销商或代理商除了宣传生产方的商品或服务之外,也会建设属于自己的品牌。

总结

互联网时代的企业都需要一个属于自己的数字化平台,具有“中国特色”的微信能够为企业提供现成的平台基础。在整个数字化平台的生态体系中,企业可以选择微信平台以触达终端用户和完成核心业务。在该平台中,微信公众号与企业微信紧密结合,形成了一套完整的、行业级别的业务运作和客户服务体系。


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

Share

什么是数字平台战略

传统企业正在面临IT新技术的挑战——单从“传统企业”这个居高临下的称谓,你就能读出“非传统企业”(也就是IT企业、互联网企业)满满的优越感。每天在各种新媒体平台上看着BAT们又掌握了什么黑科技、又颠覆了哪个行业,“云大物移”已经成了高频出现的热词,传统企业们愈发清晰地感受到IT的重要性与挑战。数字化浪潮躲不过,和BAT拼技术又拼不过,传统企业的出路在哪里?

目光投向大洋彼岸,最传统的传统企业、年收入数千亿美元的沃尔玛在过去几年中的数字化历程颇有可玩味之处。直到2011年,沃尔玛还不是出色的数字化玩家,只能算一个有电商网站的线下零售商而已。正因为如此,当沃尔玛的电商收入在2011年至2014年的三年间增长150%、从年销量49亿美元增长到122亿美元、超过史泰博(Staples)成为亚马逊和苹果之后的美国第三大在线零售商时,这一变化才更令人惊叹。像沃尔玛一样的数字化转型先行者,能给我们带来哪些启示?

数字化企业的三个关键字

首先,传统企业们需要清楚一件事:“传统”不应该是贬义词,它同时意味着数十年积累的宝贵资产,包括客户关系、数据、品牌形象、供应链、渠道等等。传统企业要在互联网时代的竞争环境中占得一席之地,靠的不是突破最高精尖的技术领域,而是以数字化的形式激活自己多年累积的核心资产,将核心资产转变为可以在互联网上使用的服务,使其焕发新的价值。

对众多成功的数字化企业进行的调研显示,这些企业有着一些引人注目的共性。在“激活核心资产”的过程中,他们对三个关键字的重视特别值得我们关注:IT效能、生态系统、创新实验。

首先,这些成功的数字化企业重视提升IT团队的效能。正如ThoughtWorks在第16期技术雷达中所指出的,技术人员的工作体验正在成为科技企业的差异化竞争优势。这里所说的“体验”不止是给程序员舒适的座椅和人体工学键盘,更重要的是消除IT团队在工作中遇到的阻力和摩擦,尤其是充分利用云计算的弹性能力大量简化和自动化与实现业务功能无关的基础设施性工作,让IT团队将注意力集中在真正与业务相关的工作上。这里涉及的一些技术和实践(例如技术栈管理)乍听起来可能困难重重,但为提升IT团队效能付出的成本终将物有所值。

随后,这些成功的数字化企业把他们的核心商业能力与资产以服务的形式在互联网上提供出来,构建本行业的数字化生态系统,使新的服务和产品能够在这些服务的基础上被创造出来。同样是在技术雷达中,我们看到了“平台的崛起”:几年前只有亚马逊这样的巨头企业能在互联网上提供各种云服务;而现在有更多原本不太有“互联网基因”的企业围绕自己的核心资产建立起了数字化平台,不仅对内、而且对外提供服务。在国内,我们看到华为把软件开发能力变成了云服务、海航建立了自己的云生态。我们相信,更多的企业也能从核心资产的服务化中受益良多。

最后但绝非最不重要的,这些成功的数字化企业养成了创新实验的习惯。在互联网中弄潮的经验让他们承认,自己不能预先掌握所有需求、做好所有设计。因此他们转而打造组织的响应力,致力于缩短精益创业的“构建-度量-学习”周期。他们知道成千上万的用户不会明明白白地说自己想要什么功能,于是他们监控用户行为、用A/B测试等方法进行受控实验,用“假说-实验”代替了“需求-实现”,在不断的反馈中完善自己的产品和服务。

数字平台战略的五大支柱

以提升IT效能、构建行业生态、促进业务创新为目标,有志于迈出数字化步伐的企业应该立即开始制订自己的数字平台战略蓝图。不要被“平台”和“战略”这样的大词欺骗:这个以增强企业响应力为目标的平台战略不应该是在漫长的规划之后建设出一个庞然大物,而应该是迭代的、精益的、价值驱动的。更多的时候,我们谈论的“数字平台”更像是一系列IT技术与实践的落地结合。这些技术与实践有机构成的五个支柱,让数字化的企业能快速交付IT系统、围绕核心资产构建云上生态系统、从线上系统和用户行为中获得洞察、开展受控实验、并为顾客创造全渠道统一的用户体验。在成功的数字化转型案例(例如沃尔玛的案例)中,我们就能看到这五个支柱的投影。

第一个支柱:支持云和敏捷的交付基础设施

为了让IT团队快速交付,他们使用的基础设施应该具有弹性,开发、测试、运维等不同角色应该可以随需动态获得完整的应用环境,从而统一环境、标准化研发实践、规范化研发能力。他们开发的应用程序应该用持续交付实践打通开发、构建、验证和部署流程,使软件随时处于可发布状态。他们的交付流程中应该内建对安全的考量,而不是依赖最后的整体安全检查。生产系统所使用的运行时环境应该前向拉通到验证和研发环节,保障运行时环境的一致性。需要对系统的IT运维和业务运营进行全面的监控,聚合起来了解系统整体状况。

第二个支柱:以微服务为核心的API和架构治理

为了鼓励不仅企业内、还包括企业外的开发者在平台上发挥创造力,平台架构和API的设计应该注重开发者体验。在API的背后,应该从业务功能的角度出发划分合理的限界上下文和服务边界,对外提供高内聚低耦合的服务。在服务边界之间,应该考虑使用异步的事件机制实现服务之间的通信,来客观地描述运行时间比较长、甚至本质上不可能立即完成的操作(例如涉及人工操作)。为了方便使用者,应该提供API网关作为所有服务使用者的单一入口点,在API网关背后去处理众多内部IT系统的复杂性。整个API架构应该以微服务的风格呈现,避免典型SOA架构中普遍存在的、过于复杂的ESB编排逻辑。

第三个支柱:允许开发团队数据自服务

为了让业务和研发团队获得关于生产环境、关于线上业务、关于顾客的洞见,他们需要首先定义数据流水线,使数据能够顺畅地流过收集、转换、存储、探索/预测、可视化等阶段,产生业务价值。他们需要用实时的架构和API在短时间内处理大量、非结构化的数据,从中获得洞见,并“实时”影响决策。为了提高应变能力,系统中的数据不做ETL预处理,而是以“生数据”的形式首先存入数据湖,等有了具体的问题要回答时,再去组织和筛选数据,从中找出答案。IT团队会更进一步把数据包装成能供外人使用的产品,让第三方从数据中获得新的洞见与价值。为了支持数据产品的运营,他们需要实现细粒度的身份认证,针对不同的用户身份,授权访问不同范围的数据。

第四个支柱:创新实验基础设施和监控体系

为了让创新真正基于数据(而非拍脑袋)来开展,IT团队需要从多种来源采集关于系统、关于顾客的数据。需要根据业务目标在系统中埋设监控点,并及时把监控结果可视化呈现给业务用户。为了降低实验试错的风险,在把新版本发布给全部用户之前,应该以“金丝雀发布”的形式首先发布给一小部分用户,确保新版本不造成重大损害。系统需要支持功能切换开关(toggle),允许团队在不修改代码的前提下改变系统的行为,再加上用路由技术支持蓝-绿部署和A/B测试,方可高效地开展受控实验。

第五个支柱:支持全渠道的用户触点技术

为了通过多样化的触点技术向顾客提供随时随地、连贯一致的用户体验,整个企业需要建立对其顾客和目标顾客的唯一、连贯、准确、整体的视图,从而更好地了解和服务顾客。他们需要结合顾客的特征和不同数字渠道的特征建立连贯的内容策略,在多种渠道(例如电脑、智能手机、门店等)之间引导顾客的消费旅程,与顾客产生正确时间、正确地点、正确方式的交互。基于从各种渠道获得的顾客本人及其行为的数据分析,他们可以向顾客提供定制化的内容、服务和产品推荐。作为必要的技术保障,所有数字渠道的软件应用(尤其是原生的Android和iOS应用)都应该实践持续交付,这样才能实现全渠道的快速响应。

小结

在数字化的浪潮面前,传统企业不必恐惧于互联网企业的技术优势。只要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱,逐步建设自己的数字平台,不断提升IT效能、构建本行业的数字化生态系统、养成创新实验的习惯,传统企业同样可以用数字技术激活自己多年积累的核心资产,在新的竞争环境中找到自己的一席之地。

了解更多关于数字平台战略的信息,可下载《数字平台战略》白皮书。


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

Share