Author: twinsights

在ThoughtWorks，我们如何做招聘

评论

引子

知乎上有很多关于ThoughtWorks面试的讨论，主要集中在这样两个方面：

  • 该如何准备ThoughtWorks的面试？其面试流程是怎样的？
  • ThoughtWorks选择员工的标准是什么？

做OP（办公室负责人）一年了，我发现自己几乎30%以上的时间都在面试——招聘成为了我最重要的工作。于是想写一篇文章，讲讲我对面试的理解。

网上盛传ThoughtWorks面试严格，为什么会有这样的说法？说简单一些，与其说ThoughtWorks在选择员工，不如说ThoughtWorker在寻找同事。人与人之间是互相效仿的，很多人加入ThoughtWorks，就是为了和更多优秀的人共事。我们的中国区总经理曾经写过一篇名为《ThoughtWorks的同侪压力》的文章，文中提到：

对应到ThoughtWorks的上下文，这里汇集了一群追求卓越的人，于是这群人形成了一个追求卓越的环境，让每一个新进来的伙伴都压力山大，努力提升自己，寻求用正确的方法，做正确的事情。当对大家留在ThoughtWorks的原因进行调查时，很多人的回答是，因为有出色而努力的伙伴逼着我必须进步。

如何持续寻找我们的同事？

  • 将胜任力模型作为统一的面试框架，寻找有“学习型思维模式”的人才。
  • 多轮测评，以提高人才命中率。
  • 鼓励所有人为招聘出力，打造全员参与的招聘文化。

尽管组织的极速发展带来了巨大的人才需求压力，我们仍然不想在这方面有所妥协。为此，我们在内部建立了由同事进行评估的招聘体制，并成立招聘委员会——伯乐，招聘结果需要通过同事评估、由伯乐来定夺，以尽可能保证结果的合理性。

我们甄选人才的标准基于以下四个方面：

  • 知识：目标职位所需的技术和专业知识——候选人知道什么
  • 经验：目标职位所需的教育背景和工作成就——候选人做过什么
  • 能力：目标职位所需要的一系列行为表现——候选人能做什么
  • 个性特征/工作动力目标：与目标岗位的工作满足感和成败相关的特质——候选人是怎样的人

我们希望面试官在招聘时不要过于重视应聘者掌握了多少知识，而更应看重他们尚未开发出的潜力，也就是他们学习新知识的能力。亨利.福特说过：“不管你是20岁还是80岁，只要停止学习，就说明你老了。坚持学习的人则永远年轻。人生中最大的乐事，莫过于保持头脑青春永驻。” 拥有“学习型思维模式”的人是我们理想的应聘者，这些人不仅有处变不惊的智慧，也有乐于享受变化的心态。

以胜任力模型作为统一的面试框架

专业能力的发展一方面是知识、技能的持续更新；另一方面是通过刻意的锻炼和实践，持续提升专业所需的素养，在ThoughtWorks我们称之为胜任力。Competency Model (胜任力模型)是一个在HR领域非常成熟的、基于行为模式描述的人才管理模型。ThoughtWorks选取和我们的文化特点以及业务模型相匹配、重点强调员工发展的模型而不是单纯“考评”的工具，我们在自己的胜任力模型里定义了Craft Skill(使用某种特定工具解决某类特定问题的能力)和Amplifier(经过一段时间的学习和训练具备达到更高层次的能力)，分别探寻个人在其方向上的发展方式。

举个例子，我们的“企业文化”也可以用胜任力模型来解释：

  • 360度反馈 => 自信
  • 培养型文化 => 发展他人
  • Tech@Core => 技术专长
  • Business Relevance => 客户成果交付

我们以“胜任力模型”作为统一的面试框架。对应胜任力模型，我认为有“学习型思维模式”的人具备这样的特点：

  • 自信：他们敢于挑战更高目标，迎着困难不停前进，而不是总想给自己留条后路。
  • 灵活机动：心态开放，对新事物有好奇心和主动钻研的热情，愿意对自己习惯的做事方式做出改变。对自己的强项和需要改善的地方有清晰的认知，而且能不断调整和突破固有思路和做法，适应新的岗位和要求。
  • 分析性思考：有逻辑、有条理地将问题逐条解决，能比其他人更快学习和领会新事物的特点。
  • 技术专长：在不断地实践中摸索最佳的答案，并持续不断地提高对技术的掌握水平，寻找更好的方法来解决问题。

设计这样的面试流程

很多公司在人才甄选方面非常粗放，随便看看简历，问几个问题就了事，这是非常不妥的。为了提高人才命中率，我们会采取多轮面试方式进行测评。

工作样本测试：针对候选人未来可能面临的实际工作场景、工作内容进行抽样和模拟，观察和评估候选人的表现。比如我们的Homework Review、Pair Interview和Role Play都属于工作样本测试。

行为事件面谈：这是结构化面谈的方式之一。它通过一系列对真实事件而不是假想事件的询问，了解应聘者是否具备职位所要求的能力。在准备面试前（Technical & Culture)，面试官首先根据职位要求的关键能力准备相关的问题，并通过导入性问题和探索性问题开展面谈。

导入性问题：用于导入我们关心的一项能力，通常以“请举一个例子”开头。比如，当我们想评估求职者处理复杂问题的能力时，就可以问：“请举一个例子，当你遇到棘手的问题、或是需要作出一个重大决策的时候，你是怎么应对的？”

探索性问题：我们需要用STAR模型来还原当时的真实场景。

  • 情景：这件事情发生的时间、地点、人物等背景介绍。
  • 任务：这件事发生在什么样的场景下，你要完成什么任务？面对什么决策或者两难？
  • 行动：你扮演什么角色？你具体做了哪些事情？如何想到要那么做的？
  • 结果：事情结果如何？你收到了什么反馈？如何进一步改善？

情景问题面试成功的秘诀是对细节的深挖，像放电影一样还原当时最真实的场景。这样面试官就可以判断候选人提供的信息是否属实，是否具备需要考察的能力。

打造全员参与的招聘文化

在面试中，我们的职责是在有限的时间以及人为设置的环境中辩识出应聘者的优势。我们对招聘的要求越高，面试的过程就越重要，也就越富有挑战性。一个人的简历也许会告诉我们：他不仅成绩优异，还有很强的社交能力。但是通过面试我们可能会发现，这个人其实是一个几年都没有什么进步的平庸之辈。

同时，应聘者并不是唯一接受面试的人。一个能力过人的应聘者在接受我们评估的同时，也在对我们进行审视。我们不仅需要斟酌我们提出的问题，也要留意那些提出深刻问题的应聘者。在这个双向评估的过程中，我们需要不断地锻炼自己的分析力、洞察力、感知力和沟通能力。练习这样的面试技巧，不是很有意思的事情吗?

物色人才不只是招聘团队的事，招聘团队管理招聘流程，但人人都应该参与到招聘工作中来。招聘与整个组织的发展息息相关，这一理念需要渗透到组织深层。

对于小型企业而言，全员参与招聘非常自然。记得我在2014年刚加入ThoughtWorks武汉办公室的时候，无论是校招还是社招，几乎都是人人参与。然而，当组织扩大到一定规模的时候，我们经常谈论的是“人员如何分配”，而不是“如何寻找精英之才”。 而寻找TWer范的优秀人才应该是我们最重要的工作之一。

人才济济的组织很容易在人员规模上翻倍，每位员工只需引荐一位俊才，这个目标就可以实现了。这就是为什么在很多卓有成效的组织中内推很有效的原因——招聘周期短、且推荐的人才适配度更高。

写在最后

我们将胜任力模型作为面试的框架，帮助我们客观地收集信息、评定并识别候选人“冰山”以下的能力。

在武汉，招聘团队在持续推进面试官培养计划，挑选擅长面试的面试官给新人作培训。我们正在统计每位同事举荐的人数和来参加面试的应聘者人数，我们还会评估面试官填写面试反馈的效率，并可视化参与招聘活动的频率。我们鼓励所有人为招聘出力，以此来打造全员参与的招聘文化。

《变革的基因》这本书提到了“谨慎招聘”（Hire Slow)。文中提到：

“优秀的人才通常没耐心等待，为什么还要谨慎招聘？这是因为招聘决策非常重要，如果仓促做了招聘决策，就很可能要在低效的培训、无休止的反馈和痛苦的提升计划中耗费时间。为什么不尽力一次做对呢？”

我们设计相应的招聘流程，就是为了更好的提高人才命中率。我们也建立了招聘反馈机制，在持续关注每一位入职新人成长的同时，验证招聘的有效性，并持续改善我们的招聘流程。这或许能回答我们在文章开头提出的问题。

谢谢阅读！

PS：如果你也想成为一名ThoughtWorker，请查看这里：https://www.lagou.com/gongsi/j67300.html

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

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