别着急提方案,先想好问题在哪

作为ThoughtWorks的一名用户体验设计师,我做过很多不同的产品。我常常发现项目组早已列出了一系列他们想要实现的功能,而在工作中,他们只是在寻找一个新办法去改进设计流程,让其变得更有效。通常我会从他们列出的功能中找出一个,然后问他们一个简单的问题:“这个功能为用户解决了什么问题?”,这个问题往往就能把他们难住。

接下来,我能看出他们脸上的疑惑。 为什么在已经有解决方案的情况下我还要去了解问题?我们不是在走回头路么?这感觉是在浪费时间,让我们这样做的家伙是谁啊?

然而,我一次又一次的发现,由于不了解问题,项目组迷失了方向。而当我尝试让大家简单地去了解问题时,我又一次次的感受到了巨大的阻力。为什么人们会对了解问题如此抗拒?了解问题真的这么重要吗?要怎么样做才能让他们茅塞顿开?

为什么我们不重视理解问题

问题都是抽象的。所有的问题都会引发各种疑惑、假设,以及理解上的缺失;它们会让我们感到不安。而解决方案把这些抽象的事物变得具体,同时也明确解答了一些疑惑,即便有些回答只不过是猜测。无论如何,解决方案让我们感到开心和愉快。

我们的大脑非常擅长于直接给出解决方案。为了更有效率的沟通, 我们常常需要直接给出解决方案。我们常常潜意识的按照需求将不同的细节组合起来形成一个可能的解决方案。具体的东西往往比抽象的更容易让人理解。比如,你不会说,“我的身体告诉我,我想吃点好吃的。”你只会说:“去吃pizza吧。”

因此,直接给出解决方案是可行的,在很多情况下也是必要的。然而,在开发软件产品的过程中却不能这样。

理解问题的好处

在产品开发过程中,如果直接把解决方案作为讨论内容,带来的问题是讨论没有包含问题本身。当人们第一次听到某个解决方案或某个功能的时候,会试着逆向还原用户的问题。接着,他们会根据自己的理解解释这个问题的重要性及成功的标准。然而,每个人逆向还原的过程可能都是不同的,因此从一开始,大家就没有一个明确而统一的目标。随着项目的进行,人们就不得不在细节上互相妥协,并且在MVP的功能构成上争论不休,因为大家推测出的问题和优先级都不一样。这种情形就像你们在用不同的语言交流一样。

在和组织其他人沟通的时候,真正理解用户的问题也是一个非常有用的工具。如果你考虑的只是解决方案,就会拘泥于功能上的对错。而如果你关注的是有衡量标准的问题本身,就可以根据市场反馈来修正策略。只要你们在朝着这个重要的目标前进,用什么具体的功能实现这个目标的其实并不重要。

定义问题的过程

描述一个问题并不会花太多的时间,重要的是要和设计师、开发人员、产品相关人员以及市场需求人员一起合作。这样才能让大家对这个问题有共同的理解,同时也能在验收条件上达成一致。

在描述问题之前,我建议先给大家展示一些相关的调查,并且审视一下当前的市场竞争。不用太关注细节,能够提供市场的大致情况就好,这能够让你知道目前市场的机遇在哪里。如果你是在改进一款现有的产品,请把带有截屏的流程图贴在墙上,也把竞争对手的也贴上,然后和大家一起研究一下。

然后就可以和大家一起来描述问题了。我喜欢用下面的形式,这是我从 Jeff Gothelf 的 《Lean UX》一书中得到的一些灵感,他在书中写到:

产品为用户提供了实现目标的途径。我们发现有些产品并不是为了解决问题而设计的,这往往对产品产生了不良的影响。让用户真正满意的产品是针对问题而设计的,这体现在产品的可度量的验收条件中。

在描述问题时,可以不拘泥于某种形式,但应该含有下面的要素:

  • 目标用户
  • 目标用户的目标
  • 目标用户现在是怎么解决问题的?该解决方案的缺点是什么?
  • 如何给用户提供一个更好的解决方案?
  • 用于评估结果的可度量的验收条件

现在大家终于有了共同的起点,可以开始评估解决方案和讨论用户意图了。把之前描述的用户问题贴在团队周围的墙上,并经常参考。同时,也让项目之外的人看看这些问题,听听他们的意见。在回顾解决方案的时候,鼓励每一个人对这个解决方案提出反馈。

Share

明信片上的互联网

 当从安全角度来审视计算机之间的通信时,你会发现现在的互联网在这一方面并没有什么太多的东西。在安全通信领域传播最为最广泛的技术叫作“传输层安全”协议(TLS,之前也曾被称作“安全套接字层”协议——SSL)。然而,这项技术并没有像预期那样广泛地部署使用,因为其配置过于复杂。但是,即使能够正确地配置,TLS还是存在着很多问题,以至于从长远角度来看也并不是十分合适的。而另一个在传输安全中需要提及的,就是怎样用一种安全的方式去查找名字。DNS(“域名服务”)是进行名字查找的协议,但是它也同样存在着许多的问题。
最终,我们将需要一套新的协议来保证传输安全,这套协议应当真正地为互联网上的每一个人提供安全、身份验证以及数据完整性。但是,在讨论这个最终目标之前,我们还是需要先谈论一下TLS和DNS现有的问题,这样接下来才能够真正地针对这些问题进行修复。

TLS的问题

TLS是英文中“传输层安全”的缩写,这种协议尽为许多其它网络协议提供数据保密性和真实性。这些协议中最有名的就是HTTPS了,当我们想要连接到安全的Web站点(比如银行和电商)时,就会使用它。TLS会做几件不同的事情:确保没有人能够读取在客户端和服务器之间的通信流量,保证你正在通信的服务器确确实实就是你认为的那一个。这些都是非常重要的,否则你的网络连接就有可能遭受到中间人攻击。

网络协议

TLS是一个复杂的协议,因为它确确实实地包含了一些其它协议,也支持在多种算法间进行选择。在TLS设计初期,安全社区就在主张“算法灵活性”方面达成了共识。算法灵活性是指一个协议应当设计得足够通用,并且包含很多不同种类的加密算法,这样就可以在使用中轻松地切换到其它算法。TLS就是以这种方式实现的,因此服务器和客户端就可以在各自支持的范围之中对将要使用的算法组合进行协商确定。然而,这就使得TLS现在包含了大量的算法和支持选择不同安全等级的加密技术。另外,许多加密技术已经完全损坏并且被弃用了。这样来看,一个典型的TLS实现包含了巨量的不会被使用的代码,这些代码在很多情况下还存在着一定的风险。TLS还经常遭受到所谓的降级攻击,在这种情况下攻击者会强迫连接使用尽可能弱的加密算法。

最后,在使用了密码技术的协议中,还存在一些我们现在认为是坏主意的设计选择。其中两个最大的问题就是“likely compression”和“MAC-then-Encrypt”。假如TLS在今天重新设计,这两方面将会用不同的方式来完成。但是,由于这些方案已经集成到了协议的设计之中,除非我们对所有的TLS实现进行重大修改,否则这些情况无法改善;而另一方面,TLS必须要在长时间内保持向前兼容性,这就意味着这些问题也无法完全地得到解决。

X.509和认证中心

TLS实现使用一种叫做X.509的协议,来验证正与你通信的服务器。这个协议的基础是公钥加密技术,以及由叫做认证中心(CA)的实体所签发的证书。基本上,如果想要拥有一个使用HTTPS的Web站点,你就要去找到一个CA,付给他们一些钱并且证明你拥有那个想要申请证书的域。之后,认证中心会在你的证书上制作一个电子签名,认可证书确实是这个Web站点应当使用的正确证书。再之后,当一个TLS连接到来的时候,服务器就会把这个证书以及它的签名发送给客户端。客户端会检查签名并验证它,然后它要确定这个签名是由一个受信方制作的。但是,客户端如何才能得知这一点呢?其实,已经有数百个受信的CA随着你的浏览器和操作系统被分发到客户端了,它们全都会自动地被信任。其中包括像Verisign这样的公司以及中国政府等不同的机构。

这个系统存在着若干问题:第一,你必须要信任整个层级结构中的所有证书,也就是说如果有人控制了层级结构上层的任何一个实体,他们就可以假冒任何人来使用TLS;第二,对于哪些CA能够认可哪些站点或者服务器来说,不存在任何限制。这也就是说,在这个星球上的任何一个CA都可以为thoughtworks.com、olabini.se或者nsa.gov签发证书。那么,当不同的CA有着不同的目标或需要时,这就成为一个问题了。

成为一个CA也是笔大生意。获取证书是需要花钱的,这就意味着大多数人都不想费这个事。但是,这样就使得整个互联网的安全变得更糟了。所以,获取证书这件事情必须要变得非常便宜以至于任何人都能去做。

这个系统还存在着其它的问题。对于服务提供商来说,它设置起来相当复杂。当证书过期或者遭到泄露时,想要更换或是更新它们也是个大麻烦。而在Heartbleed漏洞被发现之后,一些服务花费了很长一段时间去更换它们的证书,而其它很多服务仍然还没有这样做。这其中的原因实际上包括了更换证书的难度以及花费的成本。如果你必须要在工作量、金钱以及安全之间做出选择的话,通常会牺牲安全。而这,对于每一个人来说都是件坏事。

在理想情况下,你应该拥有一个可以每过几天就能切换证书的系统,这个操作应该是半自动化的并且相当容易,这样每个人就都能去做。

X.509的定义实际上使用了另一个称作ASN.1的协议。这是一个以规模大、复杂并且很难被正确使用而闻名的数据描述语言。许多年以来,很多TLS实现都在它们的ASN.1解析器中存在着严重的缺陷。

最后,CA系统是基于中心化的想法进行设计的。信任中心化和功能中心化,这些对于我们所需的安全可靠的互联网来说恰恰是对立的。另外,非常遗憾,中心化有着促进垄断控制的倾向,这也使它们难以被替代。我们之所以仍然处在这种不利的境地,其中一个原因就是有太多的资金投入用来维持现状。

TLS实现

由于我们之前提到的情况,TLS实现变得极端复杂。大部分都包含用于完成相同工作的多种代码路径,不过也会出现并没有完成相同工作的情况发生。因为有太多的功能和扩展需要支持,这些实现的代码质量也并不是很好。在2014年,我们看到了极端严重的缺陷 和针对每一个主流TLS实现的攻击。从Heartbleed到Goto fail,很多类似的事件发生了。也有许多的权威人士针对这些问题的原因进行了谈论。但我想,答案其实很简单:TLS太大也太复杂了。长久以来,软件工程师们就知道缺陷的数量会随着代码库的大小以及复杂度而增加,安全工程师们也知道想要把一个东西在合理条件下变得安全的唯一方法就是把它变得小,只保留最低限度并且让易于理解。而TLS协议和TLS实现并没有遵循这些实践。

DNS的问题

当我们想要连接另一台机器的时候,你的计算机通常要做的第一步就是要发出一个DNS请求,它的目的是要把一个像thoughtworks.com这样人类能够读懂的名字翻译成一个IP地址(比如像198.61.151.86),这个IP地址可以实际被用来在互联网上按照合适的路由传递消息。但是,DNS协议在工作时存在着一些问题。

这个协议会泄露一些关于正在访问的网站的信息,所以如果有人在监听你和DNS服务器之间的通信流量,他就能很容易地得到与你浏览器中的历史记录相同的信息。在一些情况下,这并不是问题,但在其它情况下,这也许是个很严重的问题——特别是当你身处在一个对访问内容实行审查和检举制度的国家之中,尽管这些内容应当是公开并且所有人都可以访问的。

标准的DNS协议也不包括任何证明信息正确和时效的方法。事实上,一个DNS服务器可以返回任何它们喜欢的信息,并且你的计算机会认为这些信息是真实的。这是互联网审查机制工作的主流方式。这种方法也可以用来注入恶意软件。只需要让DNS请求返回一个你所控制的IP地址,然后你可以把所有请求通过代理的方式再发送到真实的IP地址,在这个过程中就可以更改或者增加任何信息。而这就正是我们需要像TLS这类技术的主要原因之一。从根本上来讲,TLS认证中心系统允许证书针对DNS处理的名字进行声明,而我们需要这么做的原因就在于DNS实在是太容易被操纵和被劫持了。

DNS协议完全是层级化的。这意味着当thoughtworks.com域名由ThoughtWorks拥有时,我们可以在这个域的范围内改变任何东西,比如studio.thoughtworks.com。但是这也同样可以用于另一种场景,比如.com域由Verisign所有,所以理论上他们可以任意地修改thoughtworks.com的信息。所有顶级域(比如.com,.org,.se)实际上都被组织在一个单一的由空字符串表示的顶级域中。它是由国家电信和信息管理局(NTIA)所拥有和运营的,所以理论上他们可以修改世界上任何一个DNS名字的信息。

这个层级化的弱点并不仅仅是理论上的。事实上,美国执法机构曾在没有任何应有法律程序的情况下,用这种方法搞垮了上百个域。

所以,让我们重述一下要点:DNS可以被任何人读取,也很容易被任何人修改,而且它还是层级化的,这增强了现有的互联网权力结构。

DANE和DNSSec

也许有些人在读过之前的内容后会问这个问题:难道“域名系统安全扩展”协议(DNSSec)不能解决所有这些问题吗?至于之前提到过的TLS的问题,难道“基于DNS的命名实体身份验证”协议(DANE)不能解决吗?DANE是一个允许在DNS系统中加入加密密钥信息的协议,这样的话可以不去信任一个CA,转而到一个DNS系统的服务器中去查找密钥。这个方法非常棒,它完全取代了CA系统。但是,这仅仅意味着把信任挪到了其它地方。特别提一句,DANE要求使用DNSSec协议。

那么DNSSec是个好主意吗?DNSSec是一个可对DNS记录进行签名的协议。理论上这解决了之前列举的一些问题,特别是伪造DNS记录这一方面。但是它并没有解决信息泄漏的问题。更为关键的是,DNSSec同DNS系统自身一样也是层级化的,因此它实际上加剧了层级化带来的问题。除此之外,还有一些关于DNSSec的问题导致它无法被采用。其中之一就是DNSSec实际上比DNS泄露了更多关于服务器上有哪些DNS名字的信息,另一个则是协议本身比较复杂并且还没有太多的提供商支持它。

像DANE那样的技术是非常棒的,但是它对DNSSec的依赖让人们望而生畏。而结合DANE与基本DNS也不是一个可行方案,因为这样的系统也是没有安全性可言的。

现在怎么办呢?

我们需要一个基于密码技术的、安全的、去中心化的、可以提供消息路由基础的和用来保护互联网上大部分流量传输的的命名系统。现有的解决方案(主要是DNS和TLS)是层级化和中心化的,十分复杂。而且由于TLS对DNS中的一些东西进行了断言,来自于这两个系统的数据之间存在着根本性的隔离。TLS中的身份保证机制是脆弱、层级化的,并且现有系统使得对证书的变更和更新变得非常困难。

所以,是时候来设计一些新的协议去解决这些问题了。在我看来,关键在于不要把TLS和DNS分割开来,它们从内在上是连结在一起的,并且任何一个试图去解决这个问题的协议都应当同时去解决在这两个协议中存在的问题。

在下一篇文章里,我会谈到一些现有的针对这些问题的解决方案以及它们的优缺点。

注1: 压缩和完整性检查

就像在这篇文章中提到的那样,在整个TLS协议中存在着一些严重的问题。在我的想法中在我看来,有两个主要问题,即压缩和何时进行完整性检查。压缩的问题是指,当一些被传输的明文在加密之前就被压缩时,我们可以通过检查被加密内容的大小来找出与明文相关的信息。该方法的唯一前提是你能够在响应消息中加入一些文字,而这可以很简单地实现(例如使用cookie)。有些时候,这被称作压缩甲骨文(compression oracle),即2012年的CRIME攻击和2013年的BREACH攻击所利用的主要漏洞。唯一的解决方案就是不压缩数据,而这样一来在TLS之中就又存在一部分我们再也无法放心使用的功能了。

TLS中的完整性检查是使用消息验证码(MAC)机制实现的,使用AEAD密码(比如AES-GCM)的场合是个例外,但这种情况现在不是很常见。对于TLS这样的协议讲,完整性检查是很有必要的,但是TLS实现它的方法却是有问题的:这种方法叫作“MAC-then-encrypt”,它是指先基于明文生成MAC之后再把所有数据进行加密。这里的问题是,攻击者可以使用某些方法去修改密文,而这在消息解密的时候也不会被察觉。这也意味着,你可以让服务器去对很多潜在的已经损坏的密文进行解密,一些有弱点的实现可能因此泄漏加密密钥和明文等信息。最好的方式是使用“encrypt-then-MAC”方法,即在解密之前先校验信息的完整性。

Share

提升女性在技术会议中影响力的三个想法

在上一篇文章里,我谈及了在IT领域获得更多的女性领导者的挑战。另外一个经常被忽略的问题是,技术会议如何能保证更多的女性讲师和参会者。与男性相反,很少有人跟我讨论在这个男性为主导的技术行业中,女性的上升瓶颈是什么。而我经常参加各种座谈会和讨论,内容则是关于领域特定语言、技术架构的进化和数据的角色以及数据科学在社会部门的应用等。抛开所有的先入之见,我一直在和我的技术同行平等交流。但为什么在技术大会中还是缺少强大的女性讲师阵容呢?

这要从会议的计划流程说起。有些技术大会是邀请制的。一旦你作为女性讲师进入了这个会议的圈子,常常被各种会议组织者邀请就不足为奇了,因为他们都想获得性别平衡。

遗憾的是,我们经常发现只有很少的女性会去提交演讲题目。其实大会的策划者已经趋向于对参会者和讲师进行完全匿名的审核,这样理论上摒弃了所有对讲师的偏见。实质性的反馈也会帮助所有的提交者改进他们的内容。但是,这些只是积极的步骤,调整审核的流程并不能解决提交者短缺的问题。更要解决的问题是如何扩大提交演讲的女性的数量。以下是一些关于提高这个数量的实际建议。

跳出舒适区

一个解决方案是,确保对文章和报名的征集能够广泛的发布到整个技术社区。会议组织者可以寻找一些不同的影响圈(不要局限于常见的那些),这样就可以找到更多样化的目标群体,然后鼓励他们报名。研究表明,通常女性不愿意毛遂自荐,而这令人不安的趋势也影响了会议讨论的话题提交。

帮助和激励

会议方很难确保女性讲师的数量,因为资源池就是有限的。一种主动提升女性讲师数量的方式是,让她们第一次先和有经验的讲师结对,以获得支持和鼓励。这样的合作方式可以让女性分享这个舞台,减少压力并为其提供精神上的支持。公开演讲(特别是当听众大部分都是男性时)并不是件容易的事,但是提供一个有经验的肩膀去依靠,会极大地促进女性走向演讲台前的麦克风。我们的职责就是多去鼓励女性,促使她们迈出提交想法和专业知识的第一步。很多会议用的方法(开放对于议题的报名,然后等着大家报名)并不会产生一个多样化的候选人资源池。与其等待着报名,不如先去找到她们。

多样化的方法

例如,我即将参加的位于湾区的技术大会FlowCon,在他们的演讲者花名册里,女性演讲者达到了40%。组织者通过将特定邀请和公开提交两种方式有效的组合在一起实现了这份令人印象深刻的花名册。所以,最终的责任还是在会议组织者身上,要扩大搜索范围而不能只关注常见的地方。

解决方案就在我们面前,虽然需要更多的努力来实现。如果会议组织者关注且在乎多样性,那它就是可以实现的。如果我们共同激励和支持下一代女性讲师,将会拓展我们的领导力。新的解决方案、新的视角、新的思路以及新的思想者的声音等待着被我们听到。让我们一起伸出援助之手吧。

Share

打造你自己的技术雷达

20世纪90年代的大部分时间以及21世纪初,我一直都在一家小型培训咨询公司担任CTO。在这份工作开始之初,主流平台是Clipper——一个基于dBase文件构建DOS程序的应用程序快速开发工具。Clipper是基于对象的,我们给它补充了一个扩展库Class(y),来让它变得完全面向对象,正是由于创建了这个广泛的面向对象的框架来辅助程序开发,我们迅速地击溃了竞争对手。蓬勃的培训和咨询业务让我们非常开心。

直到有一天一切都变了。我们注意到了Windows的兴起,我们中的大多数都用过它,甚至用它的原生工具来构建过一些小程序。但是产业市场依然还是DOS的天下……直到它突然被替换掉。几乎就在一夜之间,所有业务都没了。我们只好争先恐后地在Windows的世界里寻找对应的工具和平台。这次教训给我留下了深刻的印象:不能忽略日新月异的技术发展。

这件事也给了我一个关于技术泡沫的教训。当在一项技术上投入太多时,你就进入了模因(memetic)泡沫(也叫回音室)。由卖方制造的泡沫尤其危险,因为在泡沫里面你永远听不到坦诚的评价。而最大的危机是当泡沫开始破灭的时候,在泡沫里的你不会注意到破灭的来临;等你注意到的时候,一切都晚了。我们在Clipper上遭遇过这种情况,你也有可能会遇到。

我们缺少的是一个技术雷达:一份评估既有技术与新生技术的风险和利益的动态文档。我相信你会需要两个雷达:一个自己的雷达,用来帮助指导你的事业决策;另一个是公司的雷达,帮助你们在做购买决定和选择技术方向时保持理智。我会讨论如何创建这两种雷达,但是首先,我想先谈谈为什么我会产生这样的想法。

ThoughtWorks技术雷达

ThoughtWorks TAB(技术顾问委员会,Technology Advisory Board)由ThoughtWorks一群资深技术领导者组成,他们的使命是协助CTO Rebecca Parsons,一起为我们以及我们的客户制定技术方向和战略。ThoughtWorks尽力保持在技术选择上先发制人,就我们实际遇到的问题来客观地评估技术的用途。例如,我们是企业级Ruby on Rails的早期提倡者,因为我们了解Rails的技术优点以及它适用的场景。我是TAB的一员,我们两周进行一次严格把控时间的国际电话会议,此外,一年中还会有几次面对面谈话。

面对面会议的其中一项产出就是最新的技术雷达。刚开始,它是面对面会议中大多数人觉得最有趣的环节——酷炫技术讨论——的产出物。ThoughtWorks是一个复杂的实体,TAB成员会面时的日程安排十分紧张。但是本质上,我们都是些极客。刚开始,我们在日程中留出了一小段时间来讨论当前热衷的事情。随着时间的推移,它逐渐发展成了一年两次的技术雷达大会。技术雷达的最新情况请参考:www.thoughtworks.com/radar

扩展阅读:《2015年11月期技术雷达正式发布》

技术雷达的流行程度已经极大地超出了我们的想象。确切的原因并不清楚,或许是因为我们是罕见的愿意诚实地给出技术意见的咨询公司。我们酷爱钻研技术,并且不惧怕说出自己的想法。技术雷达流行起来的另一个原因是因为它用了一个实用的类比来评估技术。虽然这个类比并不完美,但却十分形象。而且有时只需要一个可以展示想法的框架就可以让文化基因(memes)蓬勃发展。

TAB渐渐地习惯了以一年两次的节奏推出技术雷达。然后,就像通常那样,意外的副作用发生了。在一些我参与演讲的会议上,与会者们找到我并且感谢我帮助推出技术雷达,并说他们的公司已经开始在创建他们自己的技术雷达了。我们还没有考虑过将这种实践推广出去,但是回首时这却是显而易见的事实。自此之后,我们与几个客户开展了这项实践,都取得了巨大的成功。

我还发现,这可以回答那个在所有会议中演讲者提问部分常常出现的问题:“你(演讲者)是如何紧跟技术的发展的?你怎么知道下一步应该追求的技术是什么呢?”答案当然是我们都有某种形式的内部雷达。使用这里介绍的工具,你可以自己规范这一流程,帮助你决定在哪些方面投入宝贵的研究和开发时间,这也许会引导你进入一个全新的事业,但同时也会占用你的家庭时间。

你需要两个雷达:一个给自己,一个给公司。我会谈到如何以及为何创建它们,但首先我需要谈谈技术雷达本身。

技术细则

技术雷达是由一些同心圆组成的:

techradar-sample

它被分割成4个象限(作为一家咨询公司,我们习惯于把东西按象限划分,这是种奇怪的强迫症):技术、工具、平台,和语言和框架。

技术雷达中有4个环,从外到内:暂缓、评估、试验、采用。

暂缓

暂缓环的本意是“目前暂缓使用”,用来表现那些新推出,还无法进行合理评估的技术。我们考虑的是那些有大量动态更新,但是尚未得到验证的技术。暂缓环逐渐演化成了“别用这项技术启动任何新项目”。在已有项目上使用它没有坏处,但是想在新开发的项目上使用这个技术的话需要三思而行。暂缓是最靠近避免范畴的,但Rebecca不同意我们加入避免环。这个决定十分明智:使用雷达这种形式真正的目的在于,雷达应该是侦测你的期望,而不是责怪过去。

评估

评估环里出现的条目表示的是值得研究一番的技术,以确认它将对你产生何种影响。你应该投入一些精力(例如开发调查、科研项目、参加会议讲座等等)来确定它是否会对你所在的组织产生影响。例如,许多大型企业在制定移动战略的时候都明显经历过这段时期。

试验

试验环列出的技术是你(和同事)认为值得去追求的。理解如何建立这种能力十分重要。现在是时候在一个低风险的项目上试点,实践这项技术,这样你就可以真正的了解它。我们希望在将某个技术从评估环移动到试验环时ThoughtWorks能有一个客观的标准,我们必须在实验项目上认真地使用这项技术。我们坚信只有当真正使用了一项技术来解决真实问题之后,你才能全面地评估这项技术,理解它的缺点和优势。通常情况下,评估阶段你会看到好处,却很难看出限制,而解决实际问题则让你对这项技术有了一个全面的了解。毕竟,每个技术都在试图吸引人们的使用,它们鼓吹自己的优势,同时会掩藏不足。这就需要你自己去发现新技术中的缺点。

采用

对于采用环里的技术,我们强烈主张业界采用它们。如果适合我们的项目,我们就尽量毫不犹豫地使用。

我们尝试找到一个好的标准,来衡量什么时候一项技术明显地应该被移入采用环,我的同事Mike Mason找到了一个标准,我们叫它Mason的剃刀:如果你没有使用采用圈里的技术,我一定会嘲笑你。最新的一条附加条件是Mason的第二法则:当你想要把某个技术移到采用环里时先质疑一下——你是不是真的足够了解它了?

图标

我们采用一套简单的图标。三角形代表新出现或位置发生过变化的技术,而圆形表示没有变化的项。我们也会用向量来说明各个点在每个象限中的移动。

如果一个图标在一年内的两期技术雷达上都没有移动,我们就把它略去,以减少混乱。如果对某项技术又有了一些有趣的话题,我们会让它在雷达上复活(或者让它又“昙花一现”)。

如何创建雷达

对于每个象限:

  • 在白板上画出4个维度来代表4个环(暂缓、评估、试用、采用),所有人在便利贴上写下自己提名的技术,并把它们贴到白板上相应的维度中。
  • 主持人(TAB的某个成员)把相似的便利贴归类(我们认为酷的技术必然会出现重合)
  • 作为一个团队,我们就每一个技术进行讨论,决定它是否应该留在雷达上,以及应该在哪个环内。
  • 选择一个充满激情的人,写几句话描述做此决定的背景(有些看起来像是白皮书上的心得体会)

对现有雷达上的条目我们也会这样做,以决定它们是应该移动、移除,还是被“复活”。

我的同事Erik Doernenburg,TAB成员之一,也提供了有益的推动力量,他总是施加压力,鼓励我们提名某种技术。例如,使用具体的技术名称,而不是采用广泛的一类技术(比如:日志聚合工具)。我们最近在这个新领域内选出了两个典型的工具,logstash和Greylog2,希望大家可以采用它们。明确的技术名称使技术雷达更加具体了。

达成共识

我们在事后才注意到的一件难能可贵的事情是,TAB能快速的达成一致。资深技术人员往往都充满了激情,但是我们很快就能达成一致,很少需要Rebecca来投出决胜票。而其他类似的团队,无论是在ThoughtWorks内部还是外部,似乎都会花费一段长得令人沮丧的时间,才能最后达成一致。有一种理论说,作为技术人员,我们习惯于说明理由,然后等待认可;就算获得的结果是否定的,也会尊重这个结果而不会耿耿于怀。一旦在大型组织的软件项目上工作过,你就会磨练出接受的技巧。我们意外地从这项来之不易的实践中获益,决定我们的雷达上会有什么样的技术,是我们之间最意气相投的事。

开源可视化工具

我的一位前同事Brett Dargan开发(并开源)了基于JSON和Javascript的雷达可视化工具:https://github.com/bdargan/techradar。

要使用这个工具,你必须把技术及其在雷达中所处的位置填入一个JSON数据结构中。我们为雷达布局的时候并不操心在一个环内的细微区别。因此不要因为一个点更靠近中心几毫米而去解读编辑的想法,我们只是努力让每个标签不要重合,使它们可以清楚地被看到。由于使用了极坐标,Brett的雷达工具会在显示雷达之前做位置信息的转化,从而可以精确地控制每个点在环内出现的位置。

ThoughtWorks雷达

许多人错误的解读了ThoughtWorks技术雷达的目的。我们的首席科学家Martin Fowler建了一个FAQ页面来回答一些常见的问题。对我们来说,雷达是当前我们这群固执己见的技术人员共同认为很酷的技术的缩影。它不是一个用来评估某个技术生命周期的工具——许多我们十分喜爱的技术,例如GitHub已经在我们“不费脑子”的采用类中消失很久了。关于雷达的比喻十分恰当:雷达跟踪的是将要到来的事物。

我们从未期望技术雷达会流行起来,不过依然有许多人在自己的个人事业发展中开始使用雷达,并且用它来支撑很多企业所缺少的完整反馈环。

个人雷达

当你踏入软件开发行业时,你跟自己签订了一个契约:承诺会跟上这个世界的变化。这一开始很有趣,因为总是有新的东西可以去探索和尝试。但是随着时间推移,学到的东西变成了事业,这时技术就有了更多的价值,而不单单只是本身的酷炫了。投入精力去透彻地研究当前正在使用的技术栈是明智的(并且好的方面是,如果你发现这个技术还很酷,你依然可以称之为“工作”)。

但我们永远不可能在成就面前停止脚步。技术世界飞快地变化着。我的一个前同事曾是世界闻名的Clipper专家,他哀叹自己不能将现已无用的大量Clipper知识替换为其他的东西。他还推测:历史上有没有其他一群人会像软件开发者一样,一生中学了很多详细的知识,然后又把它们抛到一边?(这个问题依然没有答案)

以放任自由的态度对待技术事业是非常危险的。大多数技术人员在选择技术的时候都或多或少地基于某种特定的基础:什么技术比较酷,或是你的雇主正在推行什么技术。创建自己的技术雷达可以帮助你确定想法,并且平衡各种技术(炫酷却小众,还是乏味但好找工作)。应该像对待你的金融投资组合一样对待技术组合:在许多方面,它们是相同的。你的理财规划师是怎么跟你说的?分散投资!

选择一些有广泛需求的技术和技能,并持续跟踪这类需求。同时你或许也想尝试一些高风险/高回报的技术策略,例如,开源或移动开发。我认识几个开发者通过开源项目成功地把自己从格子间劳役中解救了出来:他们在开源项目上辛勤工作到深夜,这项开源项目开始受到大家的欢迎,有人愿意购买,并且最后成为了事业的目标。移动开发目前被闪亮的光环围绕,这很合理,但是也非常困难。

抽点时间,开发一些实验性项目来帮助你选择技术,并且创建一个雷达。你可以用我们的象限,也可以创造属于自己的象限。请注意,练习过程和结果一样重要,所以请安排时间在一年内多次回顾你的技术雷达。我在每年年底都会自然而然地重新审视自己的雷达,因为年底正是我萌发新想法的时间;夏天我也会重温雷达,因为这个时候我会开始考虑明年的新话题。创建一个物理雷达(一个粗略的雷达图表+心得体会)可以帮助你规范想法、理性决定,、温故而知新。

企业雷达

个人雷达的价值显而易见,而企业雷达看上去似乎没那么重要,但实际上它要有价值得多。

原因

你的公司为什么需要技术雷达?原因有5条:

1. 风险 vs 采用

对于任何一项特定的技术,它一定在你公司里处于如下曲线中的某个位置

创新者、早期采用者、早期众多跟进者、后期众多跟进者、滞后者

DiffusionOfInnovation

创新采纳周期

但是你面对的不只是一项技术,而是很多技术:开源框架、商业产品、自制工具等等。对于其中的每一个,你都可以在曲线上画出它现在的以及希望达到的位置,并在风险和收益之间进行权衡。虽然这是个很有用的实践,但是对每一个技术都这么做实在是过于复杂和缓慢。尝试构建一个可以综合评估技术所有维度的矩阵注定是要失败的。相反,你需要一个粗粒度的分类系统,像是广口的桶,而不是精细的小孔,例如我们雷达上的环。

对于特定的技术,它在你组织的创新曲线上都有一个理想的位置,让风险和收益相平衡。我的同事Darren Smith想出最初的雷达比喻,就是通过将使用的技术和理想的采用时期可视化出来,然后又将它们放入二维雷达环中。雷达是一幅个个时间点的快照,展示每项技术在你的采用曲线上的位置。正如许多的隐喻一样,“雷达”在很多层面都是有效的。

2. 持续分析的平台

在有了框架之后,这项实践就变得更容易重复了。所以,你需要创建一个平台来让你可以持续地估算对技术的反应能力和喜好。技术永远不会一成不变,你必须不断地重新评价它们,否则就有可能大大落后于竞争对手。一个标准的框架可以帮助你建立一个有关本实践的历史记录,随着时间推移,可以帮你提高洞察力。

3.从技术人员向感兴趣的非技术人员传递统一信息

你的CTO或CIO或”制定软件购买决策的人”可能会时常四处走动,和大家聊技术,或许还会询问每个人的看法。但是CTO很少会召集会议,让他手下的人对他们每天要使用的工具进行评级。许多C级别的领导者会更多地从销售人员,而不是他们自己的员工那听取意见。为什么呢?首先,没有人想要负面的反馈,特别是当这些反馈并非必须时。第二,当出现提供反馈的机会时,大部分反馈都是负面的,并以抱怨的形式呈现出来。你有没有对你的CTO说“X技术选得非常好!”或是“你知道吗,换成Y之后我们的生产力提高了很多。”有效的技术是无形的,但是有缺陷的技术对于使用它的人来说就非常扎眼。大部分组织并没有从技术使用者到技术选择者的反馈闭环。技术雷达是一个免责工具,可以让所有的技术使用者向技术决策者提出他们的建议。在一些我们帮助其创建雷达的公司里,有许多基础设施的变化都是开发人员倡导了一年多的时间,但是直到掌权者意识到了普遍需求的时候才会立即开始执行。

4.借此激发热烈的技术讨论

曾经有一个项目经理对我抱怨,说他项目上的技术人员经常争吵。我纠正他说他们只是在热烈的讨论,这种讨论是因为激动而不是气愤。对技术充满热情的技术人员们多久能聚在一起一次,热烈地讨论大家每天都要打交道的技术?创建一个雷达就能成为很好的理由,让大家在一个(希望是)没有敌意的环境中。这些技术人员应该来自不同的项目,并且涵盖所有的技术栈。通常情况下,编程语言壁垒和自然语言一样,具有相同的社会影响,不同的语言会把大家隔离成不同的小团体。雷达给了所有人一个聚集到一起的机会,谈论他们之间的相似之处,而不是不同点,这样的讨论常常会得到意想不到的结果。

我们发现这是雷达实践中最美好的部分,因为你可以针对某项随时可能用到的技术进行深刻的讨论,而且这也是唯一的办法。例如,大部分程序员大概都认为他们知道运营负责人对Puppet的看法,但是正式的交谈往往能够产生意想不到的效果。

5.帮助协调业务人员和技术人员对技术的看法

雷达可以帮助你决定什么时候可以更激进(或较柔和)地推进一项新技术,并且提供了一个可读的、精简的技术图景,即便是非技术人员也可以理解它。如果公司对于当前和未来的技术形势有共同的认识,你们就能做出更加明智的决定,以及更好的事业规划。

通常来说,你希望业务人员和技术人员对技术的看法能够吻合,但却时常事与愿违。例如,你的公司和另一家公司合并了,这能带来非常理想的业务成效,然而技术上却不尽人意。有一个明确的发展规划图能够帮助所有人(技术人员及非技术人员)来评估战略思想并制定计划。

机制

每个公司都会以不同的方式来做这件事,并且也应该有自己的风格。用以下建议来帮助你们开始,并适当修改细节。

象限

你或许想要为公司的雷达更改象限。当我为公司做这件事的时候,我有时会把语言象限移到工具里(因为在大多数大型公司中,语言的选择已经不幸被提前决定了),增加一个软件包象限来取代语言。这对许多用一个巨大的鲁布·戈德堡装置与COTS(商业现货供应)软件集成的公司来说是一件大事。你也可以创建其他的象限,比如合伙公司、顾问,或其他特定领域。

何人?何物?何时?

何人可以分成生产者(制作雷达的人)以及消费者。生产者应该是一群资深技术人员代表(同事推荐或提名),以及公司中任何一个对技术选择有兴趣的人。如果超过了30个人或者在不同的地方,那就需要做多次谈话,然后将结果汇总起来。消费者可以是任何一个感兴趣的人,因此产出物(文档、演讲、视屏广播)必须假设消费者为非技术人员。雷达的目的之一是让利益相关方了解技术决策,所以应该让他们看得懂雷达。虽然首席级别的领导参加这样的会议没有什么问题,但是整个流程应该由技术人员主导。

你生产的是何物?有可能是10页纸长的文档,像ThoughtWorks的技术雷达;也可能是雷达小组的作者们向大家做的一次演讲。它可以像一个wiki页面一样只需要你定期更新。过程远比产出物要重要,所以输出可以是极小的。我们由一个白板开始,在上面画上用来表示象限的线条,以及贴上代表当前雷达项的便签。

收集结果的方法很简单,当我们为公司执行这一实践的时候,通常会用一个电子表格来统计结果。写心得体会是其中最麻烦的部分,但是也是雷达创建之后最有价值的部分,因为这些体会让雷达上的各个点有了更具体的意义。我们的雷达因受印刷的限制,只能为每项技术写几句话的介绍,但是当你在创建公司雷达的时候,应该鼓励更加详细的介绍,来总结团队是如何讨论并达成共识的。

何时制作雷达也取决于你的公司以及它与技术之间的相互影响。我的推荐是至少每年做一次,最好是一年两次。因为技术发展相当迅速,一年的时间就可能发生翻天覆地的变化。

总结

当选择技术事业的时候,你其实也默认了会管理你的技术事务。用技术雷达这样的形式来管理这个过程,能帮助你做出更好的决定。类似的,为你的公司创建一个雷达还能提供丢失已久的反馈闭环。有些人每天都在接触你的软件, 为什么不利用他们丰富的知识和经验呢?

有这两个雷达在手也是一件非常有用的事业发展工具。正如在上面的文章中看到的,当你是CTO的时候,做技术选择的过程就完全不一样了。记住,雷达是一个防御工具……但它也可以成为进攻武器。研究一下你的雷达和公司雷达的区别,然后看看这个工具能不能帮你更好的地统一协调你的职业目标。

我有一个疯狂的幻想,如果将交换技术雷达(个人和公司的)作为面试中的一个环节,并以此作为互相评估和选择的基础,会不会很棒呢?

Share

从自我驱动到带领10人团队

新的机会

有一天,你的老板找到你,他说你这段时间的表现都非常不错,我很欣赏你,正好呢,另外一个团队需要一个头,于是他决定把你提拔为那个团队的项目经理。这时的你可能会这么想,我将屌丝逆袭迎娶白富美。

如果你,正在经历这种转变,从自我驱动到带领团队这么一个过渡阶段,那么恭喜你已经成功的,走过了《领导梯队》的第一个层次,并且迈向了更高的层次,这也是职业生涯的第一次晋级。 不过咱们也别高兴的太早,因为,也有不少人没有成功转型,没有屌丝逆袭,也没有迎娶白富美。

想想以下几个问题:

  1. 为什么老板看上我?而不是其他人?
  2. 新的职位需要什么技能?工作内容是什么?
  3. 我要胜任新角色需要做出那些努力?那些我能搞定,那些需要别人帮助?

这些问题不是打击你的信心,而是帮助你更好,更快的适应新角色。不过转头一想这些问题的答案好像也简单。

  1. 我的技术过硬,踏实,肯干,能解决别人搞不定的事情
  2. 没吃过猪肉,还没见过猪跑。我看我们的项目经理,比我清闲,也就是,催催我们的进度,跟客户开会,管理项目进度,控制风险,制定应对措施,向上汇报。至于技能嘛,差不多就是,协调沟通,资源整合,计划能力,识别风险。
  3. 看样子大部分我都是知道的,如果再找找其他项目经理学习学习经验,应该是错不了了。

以上的答案还是不错的,已经说明你有很不错的观察能力和总结能力,不过团队负责人的职责可不仅仅是这些。我们先来看一下这个阶段的团队负责人,是什么样子了。一般来说,他将负责以下四个部分。

01

  • 交付管理。说白了就是要保证项目的按时交付,为了达到这样的目的,作为项目负责人需要关注交付范围,预算,人员计划,发布计划,并且需要实时监控项目进展,评估是否有潜在风险以及应对措施。
  • 客户管理。有些团队可能没有我们平常意义上的客户,但是每一个客户都有一个广义上的客户。你可以认为你是boss,就是你的客户,或者是说甲方就是一个客户。作为团队的管理者,客户的所有沟通,合作,都是你的职责。
  • 人员管理。重点是人员成长,如何帮助组员快速成长,并且在项目中承担更重要的角色。这是一个双向活动,就团队本身而言,需要组员成长一边提升交付能力;另一方面,作为组员提升自己的能力当仁不让。
  • 过程管理。主要是日常项目活动的章程,比如说新人如何更快的上项目,软件开发过程中的各种实践:站会,迭代计划会议,结对编程,代码检视,持续集成,当然也包括一些开发之外的活动,比如请假,Team Building等。

看到这儿是不是突然觉得,其实白富美,还真不容易取,屌丝的逆袭,也不是说说而已的。其实事实也是如此,这是一个非常关键的过渡时期,之所以重要,因为工作内容的转变是一方面,但更重要的是你的思维方式工作方式都发生了巨大的变化,同时,你也需要为此对领导力的成长付出巨大的努力。

思维方式的转变

事必躬亲到委派任务。

你不可能完成所有的工作,帮助团队成员成长,并使其承担职责更加重要。比如,你手头上有两件事情。一件事是为下一个90天计划做准备。另外一件事情是,和客户的,技术带头人,讨论某一个系统的未来架构。作为从技术出身的人,并且现在还在做着技术相关类工作的你,对于后者,是,更有把握的。以当前的团队领导阶梯储备情况,你必须亲力亲为这两件事情。渐渐的你会发现这样的事情越来越多,你从开始的逐渐适应变成了陀螺,忙得不可开交。其中一个非常明显的信号时,你的会变的很多,一些会在刚开始的时候对你来说是有价值的,有挑战的,但到了后面,就是失去的原来的价值。因此你要做的是讲自己的工作或者职责一一列举,进而考虑那些事情必须自己来完成,哪些事情可以委派给别人完成。这样做的好处显而易见,集中精力做应该做的事情,给别人以成长的机会。

我有一个同事,他是某一个项目的负责人。有一次我们在聊天的过程中,他向我吐了一肚子苦水,主要是他多么多么的忙,甚至很多时候都不敢请假,即便生病也得扛着去上班。我请他列举了一下他所忙的一部分事情:

  • 所有跟客户的沟通都由他进行
  • 每周跟客户开一次项目状态更新会,他需要找多人收集信息
  • 主持没填的各种实践:站会,代码检视
  • 每人每月的谈心
  • 考虑如何做人员培养
  • 组织Team Building
  • 督促大家按时填写Time Sheet(简化版的工作日志)

看到这样的工作列表,的确是没法请假。但是稍加分析一下,我们很快就能得出“不必事必躬亲”的结论,假如把其中划线的部分去掉,他的工作量将大大减少。《专业服务公司的管理》一书中专门就提供专业服务的公司的共性问题——授权不足展开了论述,它的危害主要有:降低项目的利润,影响职业发展,降低士气,缺乏对未来的投入等,如果有兴趣也可以看看这本书。

培养自己的领导梯队。

说白了就是培养自己的得意助手。在某一方面可以成为的你备份,可以让你委以重任的人。如果我们拿交付管理举例子的话,你的成长轨迹应该是这样的:积累知识,从实践中学习;总结,形成理论观点;培养,构建自己的接班人。之后你的接班人再做同样的事情,生生不息。如果这样的事情持续进行的话,我们将会看到一个领导梯队不断的团队,就像是一个梯子一样,而你再梯子的中间,既为整个梯队培养人才,有成为别人的培养对象,这是一个健康的团队的表现。在ThoughtWorks我们有一条不成名的规定,如果你想从某一个项目roll off,请找到你的接班人。大多数的情况是,这样的接班人需要你自己来培养,这也是作为高级咨询师的职责和技能的一部分。

工作方式的转变

从关注局部的关注整体

这个阶段对可能出现的问题就是只见树木不见森林。你必须从只关注一些开发细节转变为能够关注项目的宏观层面,比如项目的交付进度,日期,潜在的风险以及相应的处理。举个例子,原来的你有可能只关注特性的开发,但是现在的你需要关注开发的整个生命周期=需求分析+开发+测试+部署+上线,每一个阶段无需深入细节,但必须在你的视野之内。从另外一个角度出发,也只有当你成功的培养了组员,并适当分配任务,才能在不陷入所有细节的情况下,对全局有所把握。反之,则需要你自己来发现所有细节,以便对整体有所把握。

我和客户会定期的开会,来更新项目的整体情况,由于同时管理了多个小项目,但我仅仅工作在其中一个,所以无法得到所有详细信息,当然我也无需了解所有。每次开会之前我的准备工作就是,找到其他小项目负责人,了解一下信息:

  • 项目的整体进度
  • 是不是按计划进行,如果不是,是由那些因素导致的?
  • 有没有风险,如果有是什么?相应的对策是什么?
  • 有没有人员变动?
  • 。。。

从追随者到领导者

所谓屁股决定脑袋,作为一个普通组员,我所关心的事情无非是写好代码,配合项目负责人,其他一概不管。很多情况下,我的工作内容是别人指定,更多的是扮演追随者的角色,但是作为团队负责人,则大大不同,你需要完成一个被决定者到做决定者的转变。这种角色的转变是不容易的,因为它所涉及决定的方方面面,不仅如此你还需要为结果负责。所谓事不关己高高挂起,当事关己时,则纠结不已。

小气鬼

在对外时,如资源的协调,一定要有鲜明的立场——团队的利益是首要的。如果你的观察够仔细,你身边的项目负责人也够优秀,你就不难看到这样的场景——一个为了找到最佳人员的项目负责人和另外一个项目负责人争的面红耳赤,争执结束后他们又继续是好朋友。

总结

虽然仅仅是10人团队的管理,但是其中所蕴含的基本道理却是与管理100人1000人有共通之处。而从自我管理到管理他人的转变却是质的飞越,这个过渡中的思维和工作方式转换对该阶段的人来说,至关重要,希望各位能够好好把握个中关键成功转型。

Share