跟随,学习,进步

CNCF年度报告解读(2018年)

2019-02-13 17:23:01 Jimmy Song

2019年2月初,CNCF 发布了2018年的年度报告,这是 CNCF 继2017年度报告之后,第二次发布年度报告,2017年度的报告只有区区14页,今


Elixir 从入门到放弃

2019-02-13 08:00:00 Draveness

过去将近一年的时间里,作者在日常工作中需要经常与 Elixir 这门编程语言打交道,包括使用 Phoenix 框架开发一些后端服务、实现定制的组件,读过之前 2018 年总结 一文的读者相信对此也有所了解。


npx 使用教程

2019-02-09 20:12:07 阮一峰

npm 从5.2版开始,增加了 npx 命令。它有很多用处,本文介绍该命令的主要使用场景。...


指令集架构、机器码与 Go 语言

2019-02-08 08:00:00 Draveness

Go 语言编译的最后一个阶段就是根据 SSA 中间代码生成机器码了,这里谈的机器码生成就是在目标 CPU 架构上能够运行的代码,中间代码生成 一节简单介绍的从抽象语法树到 SSA 中间代码的处理过程,处理 SSA 的将近 50 个步骤中有一些过程严格上来说其实是属于机器码生成阶段的。


找回密码的功能设计

2019-02-07 15:14:02 阮一峰

所有需要登录的网站,都会提供"找回密码"的功能,防止用户忘记密码。...


详解 Golang 中间代码生成

2019-02-04 08:00:00 Draveness

前两节介绍的 词法与语法分析 以及 类型检查 两个部分都属于编译器前端,它们负责对源代码进行分析并检查其中存在的词法和语法错误,经过这两个阶段生成的抽象语法树已经不存在任何的结构上的错误了,从这一节开始就进入了编译器后端的工作 — 中间代码生成 和 机器码生成 了,这里会介绍 Go 语言编译的中间代码生成阶段。


Golang 如何进行类型检查

2019-02-03 08:00:00 Draveness

我们在上一节中介绍了 Golang 的第一个编译阶段 — 通过 词法和语法分析器 的解析得到了抽象语法树,在这里就会继续介绍编译器执行的下一个过程 — 类型检查。


解析器眼中的 Go 语言

2019-02-02 08:00:00 Draveness

代码其实就是按照约定格式编写的一堆字符串,工程师可以在脑内对语言的源代码进行编译并运行目标程序,这是因为经过训练的软件工程师能够对本来无意义的字符串进行分组和分析,按照约定的语法来理解源代码。既然工程师能够按照一定的方式理解和编译 Go 语言的源代码,那么我们如何模拟人理解源代码的方式构建一个能够分析编程语言代码的程序呢。


《深入浅出Istio》读后感

2019-02-01 11:17:00 Yisaer

前言《深入浅出Istio》这本书这两天开始卖了,我也第一时间入手了以后到现在已经基本上全部翻完了。在这里记录一下看完这本书的读后感。总体来说,这本书是一本既适合Istio本身有一定了解程度的使用者,也适合对ServiceMesh初学者的去学习Istio的书籍。这本书比较全面的介绍并总结了Istio的各个组件及其使用方法,并给出了许多具体的场景。作为一名接触ServiceMesh领域和Istio快小半年的我来说,对于书中一些比较基础的章节和内容快速翻了一翻,同时也对部分对我帮助非常大的章节做了一些总结和心得。在这里用一篇读后感记录我读完以后的感受。关于书籍作者作者在ServiceMesher社区里面是一个非常活跃的人,对istio.io的中文化工作做了非常大的贡献。作为一个大部分时间在社区内处于一个围观群众,在这里对作者对国内ServiceMesh领域做出的贡献表示由衷的感谢。全书结构整本书分为十章,整本书我重点看了第1,2,3,5,8,10。第七章重点看了后半部分。服务网格历史服务网格的特性介绍istio安装istio详解Helm部署istioIstio插件服务Http流量管理Mixer应用Istio安全生产环境使用Istio的建议正文作者从微服务的诞生和发展谈起,简略谈了一下在微服务架构为我们解决了许多老问题时,它所给我们带来的一些新的问题。为了解决这些问题,Kubernetes为代表的容器云系统出现提供了部署、调度、伸缩等功能,,而ServiceMesh则应运而生去解决如何管理、控制、保障微服务之间的通信。随后,作者挑了几个重要的产品与事件来梳理了ServiceMesh的发展历史。从SpringCloud确定微服务治理的标准特性,到Linkerd发布后受人关注,再到Istio横空出世。ServiceMesh领域中目前发展的最好的毫无疑问是Istio。这不仅是因为Istio吸取了前面产品的经验,同样也背靠了Google,IBM和Lyft这三个公司共同组成的开发团队。由于我接触ServiceMesh领域时,Istio都已经发布到0.7版本了,所以这块的内容让我了解了整个ServiceMesh领域的发展历史。在第二章,作者着重聊了一下Istio官网首页所印着的四个特性:连接、安全、策略、观察,所分别代表的意义和场景。然后在第三章介绍了Istio整体架构和每个组件所承载的意义和功能以及一些Istio自定义的CRD。关于Istio的架构设计和功能组件Istio官网本身就有非常详细的介绍了,直接看官网介绍就行,对于部分CRD的介绍挺好的,可以帮助理解每个Istio组件对应了哪些Istio配置文件。第四章和第五章这块都是关于安装Istio的,这一块我比较熟悉就直接跳过了。同时对于个人开发者学习Istio而言,需要的是一个更快的本地搭建Istio环境的教程,这里推荐一个更简单的快速本地搭建istio教程第五章着重介绍了Istio安装文件种的Helm结构,以及每个参数所代表的意义。这一块我觉得对我的帮助非常大,由于之前我在生产环境安装istio都是通过我本地开发机helm template一个完整的安装文件,然后一并apply到生产环境上。这给我至少带来了两个大问题:我的本地开发机拥有一个具有读写权限的生产环境k8s账号修改各个部件相关参数变得十分麻烦目前在这上周我已经全部回收了我们开发组内所有人的生产环境权限,统一通过K8S DashBoard进行操作。当然,这也意味一旦需要更新istio就不能再走本地apply安装文件的方式。一个更加科学的方法则是通过CICD系统,用helm install/upgrade来管理生产环境的istio配置。所以,掌握istio的helm文件结构就显得非常重要,这块第五章给我的帮助很大。第六章作者介绍了Istio的一些官方推荐的插件服务如Prometheus,Grafana,Jaeger这些。我就直接跳了。第七第八章作者介绍了通过Istio进行网格的Http管理和Mixer应用。这两张是本书的两个大头,当然同样也是Istio应用的两个大头。对于第七章,作者介绍了VirtualService,HttpRoute,Gateway这些相关概念,以及通过这些组件进行负载,转发,灰度这些内容,基本上我就快速看了过去。我个人在istio的实践上,也已经在生产环境上通过istio进行灰度发布,所以对于这块内容我已经比较熟悉了。相关资料: coohom在生产环境上使用istio的实践与经验第七章的后半段提到了通过Istio在生产环境进行故障演练的方案,这一块挺让我耳目一新的.一方面是没想到还能这么玩,一方面是在生产环境的故障演练同样也是我今年上半年将要去做的一个目标之一,这块对于故障注入与故障演练的场景方案对我帮助很大。第八章作者着重介绍了通过Mixer来进行一些黑白名单、限流、自定义监控指标这些操作。在Istio官网上关于Mixer的大部分内容我也已经全部看完并实践过了,所以这块内容我看的比较快。一个比较遗憾的一点是没有看到关于如何自定义Adapter相关的介绍,这一块是Mixer有着非常大潜力与价值的一块内容,但同时也有着不小的门槛。这一块我前不久一直在花时间调研并通过自定义Istio Mixer Adapter完成了一个比较常见的需求,这次放假有空将会整理一下。第九章讲了Istio安全认证这块,我暂时直接跳过了,在我目前的场景中,生产环境集群内所有服务都将长期处于互相信任的状态,所以我暂且并不关心这方面内容。第十章作者给了一些在生产环境上使用Istio的建议,有大部分内容和我在生产环境上实践所的出来的结论相同,以及Istio目前的一些发展问题。关于生产环境使用Istio的建议,这里我摘录几条我深表赞同的:永远准备一套不用Istio的备用环境,( 目前我们服务的生产环境长期保留了主备服务,主服务使用Istio,备用业务则不使用Istio,每当进行istio升级或者是部分参数调整时都会提前进行主备切换,等升级调整验证完毕后才切换回来)确定使用Istio的功能范围 (在我们的场景中,只有真正的业务服务才被服务网格管理,其余不需要网格管理的服务绝对不强上网格)时刻考虑Istio功能的性价比 (不为了用功能而用功能,Istio Citadel安全功能对于我们来说目前收益接近于零,但风险极大,所以就坚决不用)同时对于Istio这个产品发展的现状,作者给出了一定的担心,即目前Istio团队,发布的产品API稳定性太不稳定,不向后兼容,很多API全部改写。另一方面在发布质量上也出现过比较大的问题,造成了版本回退,发布延期等问题。同时Istio组件目前本身也有着一些瓶颈与问题如Mixer的复杂性与高成本学习,Pilot的性能瓶颈,SideCar的性能消耗。以上这些都有待Istio团队去解决。最后整体来看,对于Istio,我个人认为Istio目前的发展状况在ServiceMesh领域中还并没有像K8S取得事实胜利,可能Istio也有可能步Linkerd的后路,为未来的产品开路和经验,但是ServiceMesh这条路无疑是正确的,我也会继续关注ServiceMesh和istio在2019年新的表现。


每周分享第 42 期

2019-02-01 10:08:23 阮一峰

这里记录过去一周,我看到的值得分享的东西,每周五发布。...


Go 语言编译过程概述

2019-02-01 08:00:00 Draveness

Golang 是一门需要编译才能运行的编程语言,也就说代码在运行之前需要通过编译器生成二进制机器码,随后二进制文件才能在目标机器上运行,如果我们想要了解 Go 语言的实现原理,理解它的编译过程就是一个没有办法绕过的事情。


2018 年总结 · 初窥门径

2019-01-31 08:00:00 Draveness

一转眼 2018 年就过去了,回想了一下今年确实做了非常多的事情,从零搭建交易所服务到负责基础架构以及微服务治理,整个 2018 年也是作者服务端技术逐渐成熟的一年,对于未来的职业规划和方向也变得越来越清晰,到了年末的时候也确实开始回忆和反思这一年个人到底有哪些提升和进步以及有哪些地方能够做得更好。


敏捷转型是根据具体问题的演进过程

2019-01-29 21:03:09 李强

敏捷转型是根据具体问题的演进过程,也是和各干系人真诚合作的结果。敏捷教练需要在战壕里。

tags: 敏捷


Kubernetes与云原生2018年终总结及2019年展望

2019-01-29 13:54:50 Jimmy Song

去年我写了Kubernetes与云原生2017年年终总结及2018年展望,按照惯例也应该推出2018年的总结和2019年的展望了,写这篇文章


吉薇艾儿

2019-01-28 06:41:22 Yisaer

这是一个考验,来自过去的考验,人的成长,就是战胜自己不成熟的过去。下落今天表弟来我家做客,和以往不同的是,家里人的脸色都沉沉的不怎么好看。原来这次表弟来我家,主要是因为他这次考试很不理想,他已经初三了,今年就要参加中考。表弟家里人非常着急,所以带着他来我家里,希望我作为一个哥哥,曾经的一个学习不错的学生,能指导指导他,让他好好读书。把表弟接进房间以后,看着他低着头坐着一言不发,我叹了一口气。“家里人希望我好好劝他,让他乖乖读书,生活回到正轨”,我心里想:”但是我又有什么资格去劝别人的生活呢,我自己的生活都一团糟。”从去年十二月份开始的时候,我的女朋友,或者说是曾经的女朋友就一直发信息向我抱怨说和我在一起一直不开心。虽然我一直劝她,也一直向她保证以后会花更多的心思在和她的相处上。但是在两个礼拜前,在我定好电影票和江边城外的座位准备和她一起享受周末时,她的一通电话告诉我,我们分手了。一段从大学时代开始一路走来的感情就这样结束了。逃避我一直以为我是一个非常坚强的人,以往碰到了大大小小的挫折都被我克服了过去。但是那个周末,我一直躺在床上想,想为什么会变成这样,一边想一边哭,一边哭一边想。最后哭累了睡了过去迎接了周一。“至少不能让同事看出来”,我用冷水尽力把眼睛消肿,平复着情绪上班去了。我尽力的让自己不去想感情生活上的事情,将自己心思一股脑的扑到工作上。比起所在业务组一开始的同事,现在的同事来了一批新同事也走了一批老同事,虽然我是这里面年龄最小的一个,但我目前成了生产环境上最细整个技术架构的人了。所以每天我除了自己需要完成的工作内容之外,还要帮助其他同事一起对接平台组,运维组,监控组,质效组这些其他支撑部门的需求。事情一件接着一件,虽然让我感到身体和内心都十分疲劳,但也是让我不去胡思乱想的好事。“你平时做作业么?”,我问他,表弟低着头轻声的说:”不怎么做。” “那你平时上课有听过么?” “也不怎么去上课。” “那你为什么不去上课呀?”,我问他,但表弟他只是在那沉默的低着头不说话。“他不想说,一定有他的原因。”,我想。 在我眼里,表弟家在学习上一直希望他能够好好读书成为一个好学生,而且经常拿我和我们家族里一位学霸姐姐给他做例子。“就知道玩,能不能用点心思在读书上?”“这么语文怎么考的这么差,能不能考考好?” “能不能像你哥哥姐姐学学?” 这些话经常从他家里人出来,成为一个个施加在他身上的要求。这些话在我还是一名初中生的时候也同样经常听到,虽然我已经不大记得当时自己的心情了,但是我非常了解当听到别人以抱怨的语气对你像机关枪一样射出一个个要求。“每次约会都是玩到晚上8点你就回去了,为什么不能玩的更晚点?”“喜欢我难道不应该风雨无阻来找我吗?”“你就不能过的更有仪式感一点吗?”当我听到电话那头的她对我说出这些话时,就像一颗颗子弹打在我心上。我想开口说点什么,但不知道说什么好。远眺“考不好其实也没关系”,我拍了拍表弟的背,“这只不过是中考前的某个模拟考。” “对了,”我问他:“你有想过读书的意义是什么。” 本来一直低垂着头的表弟,抬起头来看着我,没有说话,露出了疑惑的表情,也许他并不理解为什么我在这个时间突然抛出这个问题。“其实这个问题在我读完高中以后也一直没有明白”,我告诉他:“虽然那个时候我成绩整体上还行,但其实一直起起落落。” “我那个时候读书的,就是一开始凭借了一点小聪明,在刚开始的起步稍微比别人快了一点。让老师和家里人都觉得我是学习好的一个优等生。但其实我的心思都在打游戏上,完成作业,考个好成绩之类的都是从小学起往上带过来的惯性,没有别的想法了。”学生时代的我只是知道读书要保持一个好的成绩,如果不做作业的话会被老师骂然后通知家长,最后吃到苦头。读初中的时候,老师向我们强调中考的重要性,读高中的时候,老师向我们强调高考的重要性。“所以那段时间我,心思放在玩上面一段时间以后,成绩自然就下落了,被老师和家长一埋怨,我就又把心思放到学习上把成绩拉了上来。一直这样周而复始”,我告诉他:“一直到我读了大学以后,才慢慢理解读书的意义。” 到了大学里以后,发现了各色各样,有厉害的特长和有趣的性格的同学们以后,我逐渐想明白了自己想成为一个怎样的人,未来去做哪些事情与行业。“然而这些事情在我初中高中的时候,我都没机会,也没精力去想。每天晚上回家有很多作业要做,而且时不时还要面对我不喜欢的化学课,虽然我自己很喜欢写作,但我的写作分一直不高。”我跟他说,“后来在大学里有了自己的时间,见识了很多很多同学以后我才逐渐想明白自己要的是什么。你有想过自己未来想成为怎么样的人吗?” 表弟歪着脑袋想了一下,然后摇了摇头告诉我,“没想过,也不知道自己想成为什么。”“这很正常,”我告诉他:“其实现在读书,就是为了将来能在大学里面经历这些事情。你可以不喜欢语文或者不喜欢考试,但是我希望你一定要想清楚自己想要什么,想成为什么。而这个问题,不用那么急去想。等到以后读大学了你的身心智力都成熟了以后再慢慢去考虑也不迟,而你现在的读书的目的,都是为了你未来的做出人生选择时所慢慢做的准备。一次模拟考没考好真的没有关系,他对你的人生所造成的影响简直微乎其微。中考没考好还有高考,高考没考好还能在大学继续努力。但是这一切的前提下是你要想明白你真正想要的是什么,并为之努力。” 表弟点了点头。“但是遇到挫折,然后克服挫折才是人生常态。”,我叹了一口气,想到了自己感情处理上的失败。以前在大学里读书的时候,至少还会经常加一些班里女同学和学妹们的联系方式,还经常一起讲讲话聊聊天。自从有了女朋友以后和其他女生的联系都断了,也没再加过别的女生。现在想来自己这一年来就没有跟除了妈妈和女朋友以外的其他女性说过一句多余的话,现在分手了以后感觉自己未来离相亲不远了。“但你必须要去克服在读书的时候碰到的这些小挫折,等你毕业工作以后才能去克服工作、生活上的更大的挫折。”,我背靠在椅子上对我表弟说:“其实我觉得在你参考中考和高考前,考差几次也蛮好的。把你自己所有的问题都暴露出来,这样等你中考高考的时候就不会犯这些错误了。” “嗯。”表弟轻轻的点了点头。新生给了表弟一些学习上快速提分的建议后,和他一起玩了一会游戏吃了顿饭就送他走了,我打开了新标日继续开始学习。去年年末的时候答应前任我会开始自学日语然后争取今年年底我们俩能一起去日本旅游。虽然两个礼拜前和她分手了,但是这个每天背单词看网课的习惯却一直保持了下来。想到这里我心里又开始隐隐难受,我打开QQ,小心翼翼的翻开前女友的状态想看看她最近过的怎么样。发现她换了一个新的情侣头像的时候,我楞了一下,沉默住,内心不像是难过,也不是嫉妒或者愤怒之类的感情,倒更像是一种平静的释然,一个像过去的生活告别的撬动点。自从毕业了以后,我依旧凭着过去在学校生活的惯性,像完成考试内容一样完成工作内容,像争取让父母满意一样争取让女朋友满意。我为工作上的困难愁眉苦脸,也为未来两个人如何继续走下去而辗转反侧。这些问题都没有写在教科书上,也没有哪门课教,只留给我自己去独立面对。有失必有得,在我失去了女朋友以后同样也失去了感情上的烦恼。我开始有时间去思考自己下一步想如何发展,也可以单身一人想去哪个城市定居就去哪个城市定居。我可以有时间继续探索我的兴趣,而且目前学日语也逐渐对我来说变得有意思了起来。拥有这段感情时创造了许多美好的回忆,所以在失去这段感情时我也会感到如此难过。但我选择接受Both Good&Bad。 这个月Mentor和我One on One的时候告诉我,鉴于去年我在工作上的热情与成绩,所以绩效非常不错,他也为我争取了这次升职高级工程师的机会,让我好好准备,对我来说这算是2019年来的第一个好消息吧。我删光了前任女友所有的联系方式,然后向她妈妈发信息表示了感谢和道别。2019年,我希望自己在工作能力上能更进一步,同时继续着自己在技术专栏和个人博客的写作之路,今年能够有机会凭借着自己的力量能去日本游玩,然后多交一些朋友吧。当然同时也希望我的表弟能尽早走出这个低谷,在未来的人生路上不再迷茫吧。


8个常见的研究者认知偏误陷阱

2019-01-28 02:40:06 Sijia

作者:Sijia 前言: 认知偏误(Cognitive bias)是一种常见的现象,它是指当我们思考问题或做决策时,大脑会有一些固定的思维倾向。这个过程多是无意识的,有时也会带来正面作用,如帮助我们在纷繁复杂的环境中节省思考时间,更高效地做出决定但是在研究中,认知偏误易导致研究结果不准确,降低研究的价值。 我们都希望研究是客观、理性、反映真实情况的,了解常见的认知偏误可以帮助我们在工作中尽量规避它们,得出更准确的结论。 实际上每个人都会有认知偏误,包括用户研究者和用户。 今天我们就来说说研究者的常见认知偏误,下次有机会再谈谈用户的,敬请期待。 ——————————————————————————————————— 一、 确认偏误(Confirmation bias) 当人们本来就持有某种观点时,对这种观点的感知和注意度会被放大,会选择性地回忆或收集关于它的事例。人们对于自己原本就相信的观点会更容易接受,而把反面观点搁置在一旁。举个例子:有些人认为女司机不擅长开车,更容易造成事故,所以当新闻中的事故与女司机有关时,他们会觉得“果然如此”。而实际上男司机的事故率比女司机更高。 在用户研究中,当你的预设想法是用户对A设计的满意度比B设计更高时,在研究中你可能会更关注用户提到的A设计的优点、收集更多用户对于A设计的正面评价。当用户表示对A设计满意时,会觉得“果然是这样”。这种偏误会让你遗漏许多其它信息。 二、 虚假一致性偏差(False consensus effect) 虚假一致性偏差是指人们很容易认为其他人跟自己有相同的想法,从而高估这些观点的普遍适用性。举个例子:有一种冷叫做“你妈觉得你冷”。妈妈感觉到了冬天的寒冷,担心我们也会冷,于是催促我们穿秋裤,但可能年轻人并没觉得冷。此时妈妈的想法就带有虚假一致性偏差。当年轻人吐槽父母朋友圈转的鸡汤文、养生文无用时,也是一种虚假一致性偏差。 在用户研究中,我们也很容易陷入虚假一致性偏差。比如,当你认为产品的某个方面比较好或者你对产品的某个方面不满意,可能会倾向于认为这也是许多其他用户的感受,但也许事实并非如此。在对海外产品做研究时尤其要注意这一点,研究者与用户的巨大文化背景差异可能会导致研究结果的严重失真。 三、 聚类错觉(Clustering Illusion) 聚类错觉产生的原因是人们倾向于从随机事件中找出某种规律。举个例子:如果张三连着几次在群里抢红包都抢到最大份,他可能会觉得自己最近“手气特别旺”。这就是一种聚类错觉,人们试图将几次随机的结果联系起来,用某种规律进行解释。 在研究中,聚类错觉容易出现在小样本研究中,比如,我们在小样本中发现了被访者的某些共性,总结出某些规律,并期望它们在更大的群体中也适用,但这种共性可能只是源于随机,而非事实。我们应该谨慎对待在小样本研究中的发现,思考它们是否只是随机结果,最好用其它研究方法帮助验证或参考二手资料,避免出现聚类错觉。 四、 知识的诅咒(Curse of knowledge) 培根说过,“知识就是力量”,它怎么会带来诅咒呢?知道的更多难道不好吗?知识的诅咒是指,人一旦知道了某件事,就没办法想象不知道的样子,也很难体会到不知者的感受。举个例子: 在某次考试之后的课堂上, – 老师:“同学们,这是一道送分题啊,大家都做对了吧?只要先连一条辅助线,再……” – 学生:“这是啥?这又是啥?这些都是啥?” 在用户研究中,知识的诅咒也会给我们带来许多困扰。比如,我们对自己的产品很熟悉,就很难想象新手用户是如何使用它的,使用感受如何。我们可能会惊讶地发现,即使在我们看起来操作十分简单的功能,新手用户使用起来也很吃力。再比如在设计问卷或者访谈脚本时,我们可能会不小心加入一些专业术语而不自知,让用户看的一头雾水。   研究者的有些认知偏误还会直接影响到用户的行为和反应。 五、 选择性偏差(Selection bias) 选择性偏差是指过程或样本的非随机性导致结论的不准确。举个例子:假设张三想统计人们的工资水平,他拿着一份个税纳税名单开始了调查,结果发现,所有人的工资都在5000以上。这个结果当然是不准确的,因为5000是我国的个税起征点,工资超过5000的人才会出现在纳税名单上,张三的研究样本是有选择性偏差的,不能代表总体。 在用户研究中,选择性偏差不仅会出现在样本选择中,还可能会出现在研究设计中。比如在可用性测试中,我们设计了一系列的任务,研究结果自然就无法包含未选中的任务。而且这些任务也会让用户产生一种心理,既然它是设定好的任务,就一定是可以被完成的,他们也会耐心地多次尝试去完成任务,以期达成某种结果。当然我们也不会设置无法完成的任务。但在实际的使用情境中,用户并不知道哪些操作是有结果的,哪些没有,他们的行为和态度可能与可用性测试中不同。 六、 框架效应(Framing effect) 框架效应是指,对于同一个问题,当描述有所不同时,人们给出的选择也会有差异。举个例子:假如说“XX疾病的存活率达93%”,人们可能会觉得这种疾病没有很严重;但如果说“XX疾病的致死率达7%”,那么人们可能会觉得很严重。在用户研究中,我们也要避免框架效应带来的影响,不要设置引导性的问题,题目中不要用明显的正面或负面词汇,尽量用中立的语言描述。避免题目的描述干扰到用户的选择,而导致研究结果不准确。 七、 观察者期望效应(Observer-Expectancy Effect) 观察者期望效应是指,研究者有时可能会期望出现某种结果,他们无意识地操纵了试验过程,或者错误地解释实验结果,导致研究结果严重歪曲。一般来说,被观察者几乎无法不受观察行为的影响,当研究是针对人时,被试者会更容易感觉到研究者无意中透露的期望,从而做出相符的反应。 在用户研究中,研究者的表情、肢体语言等都可能会反映出自己所期待的结果,如果用户察觉到了这些,就可能做一些迎合研究者期望的反应。比如,如果研究者无意中透露出某个新功能是他们团队非常重视、投入巨大、报有很大期待的功能,用户可能会更倾向于对这个功能给出正向的评价,肯定该功能的市场前景。但这也许并非他真实的感觉。 如何避免这些认知偏误呢?这里有一些建议: 1. 研究方案:避免单一的研究方法和单一的样本渠道来源 多种研究方法的结果相互验证,多种样本渠道来源互做补充,帮助我们避免“聚类错觉”和“选择性偏差”,让我们的研究结果更准确。 […]

tags: 用户研究,认知偏误


整理Backlog的困惑

2019-01-24 21:23:37 李强

实现价值驱动交付,首先要有一个好的backlog。

tags: 敏捷


用户访谈——哪些原则简单却有效

2019-01-24 02:10:20 姜, 茜

最近,桥水基金创始人瑞·达利欧的《原则》一书风头无两,洛阳纸贵。这本书对我最大的启示是,工作中无论多小、多简单的事情,都可以将其沉淀为原则。对自己而言,可在实践中将这些原则反复打磨锤炼,迭代优化,逐渐成熟;对于行业新人而言,亦可为其提供快速有效进阶的参考。 在此,笔者针对用户研究最常用的方法之一——用户访谈,抽象出5条谈话技巧。这些技巧,我斗胆称之为“原则”,希望你可以选择适合自己的几条,逐一实践,并将实践的结果反馈给我,我们一起迭代优化。当然,知晓这些原则没有价值,知晓之后的思考,思考之后的实践,实践之后的收获,才有价值! — 01 — “最近一次”原则 访谈中,我们需要探知用户的行为或是态度。例如,我们希望了解用户在购买服装类商品时,是否会考虑搭配问题。如果直接询问,其实是让用户对他们的行为进行总结和提炼。首先,这样的提炼会因场景或先前条件的描述不充分而有失偏颇;其次,这样的提炼往往简短直接,研究人员因此损失了很多用户行为和体验的细节,不利于充分理解用户,挖掘其深层次需求。 事实上,总结和提炼是研究人员应该做的事情,用户只需要讲好他们的故事。针对这一问题,我们可利用“最近一次”原则,即请用户描述他们最近一次体验类似场景时的情绪体验和处理方式。 应用于本文中的案例,我们就可以请用户描述他们最近一次买衣服的详细过程,例如买了什么,如何搜索、如何挑选、如何决策,然后将搭配的问题,放置于这个购买场景中去询问。在此过程中,研究人员还可适时追问,既表现出对用户回答内容的兴趣,还可引导用户回忆和描述更多的体验细节。我们充分了解用户行为中的细节,才能彻底探知对方的需求和态度。 一句话总结:不要让用户干巴巴地描述观点和行为,请他们结合最近一次的场景体验去讲故事。把回忆交给用户,把提炼和总结,交给我们。     — 02 — “鹦鹉学舌”原则 访谈中,遇到关键性问题,或是用户表述模糊的地方,我们可以利用“鹦鹉学舌”原则去重复用户的话,从而确认自己的理解与用户的描述是否一致。在这个过程中,我会用对方的语言描述一遍,再用自己的语言总结一遍,然后与用户确认,自己的表达是否准确地描述了他的态度。 具体操作就是,“您刚才说了……,我的理解是,您认为……。我理解的对么?”除此之外,我还会特别真诚地补充一句,“如果我理解地不对,或是不全面,请您一定要纠正我。”这时,用户往往也会特别真诚地说,“你说的对”,或是帮助我再补充或强化一些观点。这样做既可有效地避免理解性偏差,更透彻全面地理解用户的态度,还便于记录者捕捉与整理访谈关键点。  一句话总结:对于访谈的关键性问题,或是用户描述不清之处,通过重复用户的描述,可有效避免理解性偏差,并适时总结提炼用户的观点。     — 03 — “沉默10秒”原则 访谈中,在研究人员提出问题之后,用户需要足够的时间思考和回忆,不要立即让用户给出他们的回答,给用户大概10秒的沉默时间。请用户评价方案时亦然,给用户充足的时间,以自己的方式细致浏览方案,然后给出评价。在最开始做用户访谈时,我会尽力避免沉默时间。一方面避免延长访谈时间,另一方面担心沉默的尴尬。但后来发现,“访谈留白”给了用户细致思考的时间,他们在回答时会更详尽而肯定。 在我们需要鼓励用户说出更多内容时,也可以使用“沉默10s”原则。当用户描述结束后,可以不要急于接话或是追问,认真地看着用户,并点头鼓励,用肢体语言告诉他,我对你的描述非常感兴趣,期待你说出更多。这时,用户往往会再补充一些描述。当然,当用户确实无法说出更多时,也不必给过于苛求。告诉他,他刚才讲出的内容已经很有价值了,如果有新的想法,可以在访谈过程中随时告诉我们。  一句话总结:在抛出问题,或是展示方案时,给用户充分思考和回忆的时间,沉默之后,用户会给予更多。 — 04 — “不答反问”原则 访谈中,经常会遇到用户针对设计方案主动提问的情况。在这种情况下,可不必急于回答用户的问题,而是反问用户,请他们聊聊对方案的预期。例如,如果用户提问,“这部分会展示什么内容?”,我们可以反问, “您认为这部分会展示什么内容呢?”甚至还可以进一步追问,“为什么您认为这里会展示这些内容呢”。聊到这里,我们就可以探知用户对方案的构想,以及对方案的关注重点。 接下来,可以告诉用户,我们目前的设计方案是怎样的。然后将现有方案与用户的预想进行对比,请用户评价下各自的优劣。最后,还可以进一步探究,为什么用户会问出这个问题,为什么他会对这部分展示什么内容感兴趣?抽丝剥茧,层层追问,可以帮助我们更好地探知用户的需求。 一句话总结:当用户主动提出问题时,不要急于给出答案。变被动回答为主动追问,才可刨根问底,层层探知用户本质需求。   — 05 — “转场衔接”原则 在访谈前,我们经常说明我们不是在测试用户,而是与对方交流探讨。这就需要我们把问题融入聊天过程中,让用户不觉得是在完成任务,而是与一个懂得耐心倾听的对象聊天。 要做到这一点,合理暖场对于拉近与用户的距离,消除陌生感非常重要,这一点大家都会实施,此处不再赘述。另一个技巧,我个人认为也非常有效,就是转场衔接。在访谈的过程中,我们不可避免的需要从一个模块跳转到另一个模块,从一个话题跳转到另一个话题。如果直接按部就班地照纲询问会让用户觉得突兀而生硬,这时候我们需要用一些承上启下的句子,恰当地转换话题。 例如,“刚才我们一起探讨了……,感谢您为我们提供了非常有借鉴价值的建议,下面我们希望请您体验一下……的操作流程。”再如,“刚才您体验了……的操作流程,让我们一起来回顾一下您的操作,然后就您的每一步操作,交流一下好吗?”这样衔接的句式,既做到了对上一模块的总结,也让用户知晓接下来的研究内容,访谈过程衔接自然,用户也会因心中有数更而更从容自在。 一句话总结:合理转场,用承上启下的句子衔接不同话题,让访谈生动而不生硬。   — 06 — Takeaway Message 综上所述,以下原则会帮助你在用户访谈过程中,深入理解用户,挖掘本质需求。   “最近一次”原则:不要让用户干巴巴地描述观点和行为,请他们结合最近一次的场景体验去讲故事。把回忆交  给用户,把提炼和总结,交给我们。 […]

tags: 用户研究,原则,用户访谈


理解 Golang 中函数调用的原理

2019-01-20 08:00:00 Draveness

函数是 Go 语言中的一等公民,理解和掌握函数的调用过程是深入学习 Golang 时无法跳过的步骤,这里会介绍 Go 语言中函数调用的过程和实现原理并与 C 语言中函数执行的过程进行对比,同时对参数传递的原理进行剖析,让读者能够清楚地知道 Go 在函数的执行过程中究竟都做了哪些工作。


理解 Golang 中函数调用的原理

2019-01-20 00:00:00 Draveness

函数是 Go 语言中的一等公民,理解和掌握函数的调用过程是深入学习 Golang 时无法跳过的步骤,这里会介绍 Go 语言中函数调用的过程和实现原理并与 C 语言中函数执行的过程进行对比,同时对参数传递的原理进行剖析,让读者能够清楚地知道 Go 在函数的执行过程中究竟都做了哪些工作。