四月在北京参加了一个 VR 相关的技术会,期间有分享也有互动讨论,也有很多 VR 领域厂家的产品展示。最直接的感受是 VR 很热,投资人和创业者都很想抓住这次机会,把它应用于各个领域创造价值。甚至有创业者认为这是人类自发明互联网以来最伟大的发明,并且是人类最后一个伟大的发明。我虽然对未来人类的发明能力持续乐观,但丰富的想象力也确实让我对 VR 的未来或者说对即将进入 VR 时代的未来世界充满期待。

想象归想象,从各厂商的展示和专家的演讲中来看,当下该领域却还很「骨感」。从厂商展示来看,大部分厂商展示的是头盔设备和拍摄的内容,头盔设备品质差不多,拍摄内容的展示则来自于一些传统影视公司。其中只有一家公司的现场 VR 直播技术让我感觉是在做一些解决该领域内通用问题的尝试。当然,游戏和影视是 VR 两个非常好的应用场景,传统影视公司的重视说明有其应用价值,只可惜现在拍摄的 VR 影片都只是一些短片。

而演讲的嘉宾中,大部分都是在展示自家产品,或者是和自家产品的结合,或者展望该领域美好的未来,或者探讨商业模式。忏愧的是,我作为七牛云的代表,在云方面目前只能通过 VR 内容的存储和 VR 直播角度去分享,只可惜目前 4K 分辨率以上的视频通过公网传输还不太理想,更别说通过公网直播了。从云的角度说,我的分享只供参考,当下还没有实际价值,我只提出了问题,也即,要更快更实时的传输 VR 视频,当前基础网络还达不到标准,我们怎么样让这个传输更快更高效?

遗憾的是,所有大会上我们都只是在尽情分享自家的成果,推销自家产品(或者内容)。而我希望看到的是,在一个新领域的大会上,我们聚在一起探讨当前存在的问题和可能的解决方案,这样才不至于大家分享的时候都很空洞。比如,有厂商朋友反馈说,据他观察,他的大部分用户带上头盔之后虽然知道自己看到的是全景图,却不知道脑袋是可以上下前后左右转动来体会真实世界中的感觉的。对于这个现象我一开始很吃惊,后来想想也好理解,原来是因为我们习惯了传统观看视频的方式。在 VR 以前,无论是去电影院看电影还是在电脑上看视频,我们都只能盯着前方,因为播放视频的设备是不会动的。但这种习惯和长在我们脑袋里的眼睛看世界的习惯不太一样,眼睛可以随着我们脑袋的转动看到上下前后左右真实的世界,它有宽度厚度深度浅度。如果把眼睛看真实世界的习惯当成是正常的,那么长久以来我们盯着前方看视频的习惯就是不正常的。而在虚拟真实世界的 VR 世界到来之后,我们虽然带上了头盔这双「眼睛」,却还是会用不正常的方式习惯性把看 VR 视频当成在看普通视频,会一直盯着前方而忘记上下前后左右晃动以寻找更精彩的虚拟世界。

无论怎么样,我现在看到了 VR 的雏形,并从它的雏形中看到了未来世界更加精彩的样子,要么在游戏、影视领域让你感觉更加虚幻,要么在教育等领域让你感觉更加接近现实。在 VR 这条新的赛道上赛跑,值得从黎明前出发。

最近在朋友圈发了两个引发我思考的内容,第一个是:

统计表明,Facebook 上有 85% 以上的视频都是在没开启声音的情况下播放的,这至少意味着两件事情:1. 点播下视频和音频可以分开加载。2. GIF 动画还有很大的生存空间。

这是一个专业性非常强的内容,其中 85% 的数据来自于 DigiDay 的这篇文章:85 percent of Facebook video is watched without sound. 回复或者点赞的人大都是视频或者社交领域的技术人或者创业者,有朋友直接指出了我的错误,认为「在 HTML5 的完善下,GIF 被替代是必然,已经在被替换了,现在各大社交平台都在替换。低画质显然不符合人们对美好的期待」,同时也给了我一个更为系统的知乎链接:为什么 GIF 格式迟迟没有被取代?

也有朋友认为这样的推理是不对的,Facebook 本身从产品上就设置了默认不开启声音,而好多人只采用默认设置,况且 Facebook 的视频是现实在屏幕上就会自动播放。同时,从 Facebook 采用无声视频格式而非 GIF 来看,这正说明 GIF 正在失去市场。

第二个引发我思考的内容是,我在朋友圈里面问:

有没有人分享一下 Google 这些大公司怎么做到这么多产品界面高度统一?

同样的,点赞和回复的要么是非常关注产品和设计的设计师,要么是在 Google/Amazon 这种大公司工作过的程序员或者设计师。我得到了很多很好的回复,很多回复的字数超过了我提问字数的好几倍,比如:

设计规范和设计语言提炼的比较好。 首先有个集团层面的设计语言作为公共规范,然后每个BU基于设计语言衍生出自己的设计规范。每个具体产品线的guideline又遵循于BU的设计规范。

和:

苹果的guideline太宽泛了,所以样式比较多。但是material design的规范很细致,做出来的app比较统一。公司的产品变多之后一般都会定制自己的guideline,然后照着guideline同意就可以了。会有一些常见的部分,比如色彩、文字、架构、模块、动效等等。照着Material Design的框架可以简单搭一个。

以及:

谷歌众多产品设计统一性的问题在几年前也没有得到解决。但自从 Material Design 这个设计语言出来后,得到了设计界的高度评价,进而谷歌开始全力推进这套设计语言。到今天谷歌的全线产品基本都适配了这套语言。可以上 Material Design 的官网了解下这套设计语言的细致规范,也给业界做出了最好的设计规范典范(如何从大的设计哲学到具体的细节至一个 dp)。另外在 Medium 上谷歌设计团队也分享了一些实操案例,各个产品如何调整设计风格到 Material Design 。当然 Guideline 本身要具有可执行性,可迭代性。毕竟 Guideline 是确定设计的下限(让水平差的设计师也能按规范做出统一的产品),设计的上线还是要靠优秀的设计师来去突破,进而迭代 Guideline 。

也有人给了我一个 Airbnb 的设计参考:Building a Visual Language — Behind the scenes of our new design system1.

这两个真是非常有价值的讨论,回复中基本上没有纯粹的赞或者不相干的内容,它们让我学到很多东西,同时能够以相似兴趣点的方式来识别哪些人的能力和兴趣点在哪里。

这样,每个人都在朋友圈里构建了一个以他自己为中心的社区,社区的质量取决于他所发内容引发的思考和讨论。但是很遗憾,这样的社区是封闭的,它的开放性仅限于「朋友圈」,要通过零碎的讨论去认识新的志同道合之人只有通过建群,而在群里加人则是另一种带有很强目的性的行为,而非仅仅是为了一次有意义的讨论,因此有时会让人「望而生畏」。

但是知乎这种非常开放的社区在后期大众化之后却只能变得鱼龙混杂,广告主永远是它上面的第一大寄生虫 — — 无论是以何种形式存在的广告主。为了构建一个「理想和理性的社区」,最后的手段可能还是得求助于足够开放的产品背后的算法,它不限制你也不强迫你,但是会在背后默默观察你、评估你。

当我们说某个领域(比如社交)被大公司垄断了不再值得做的时候,实际上是被想象力限制了。就像程序和算法永远无法达到完美,永远确保它们有没有 Bug 一样,构建在程序和算法之上的产品永远有革新的机会。就拿社交来说,它一直都存在,只是每个不同的时期都有不同的领导者去垄断。因为想象力和技术的先进性,Twitter 之后有 Medium,以社交为中心的 Facebook 也会做好大量的基础工作帮助更多的人接入,即便是 Feed 流也很多可玩的地方。

有人认为博客是一种过去时,中国确实很少有人去写博客了,但实际上只是换了一种形式,他们在写公众号。这样的转变并不是因为公众号有多好,而是因为他能让人更快的满足一种被认同和触及更广泛更密切目标受众的需求,或者直白点说他能更快的在朋友圈传播,能够被打赏。很遗憾的是,这是一个建立在「为了逃避孤独的心理诉求」之上的产品,它在技术上却是一种倒退。实际上即便是满足「帮助人们拜托需求」这样愿景的表现形式也不应该只有一种,更别说这种表现形式牺牲了很多技术的先进性,它只是将城围了起来。

因此,从目前的产品来看,并没有一个「理想和理性的社区」,所有这些已知的产品都存在或多或少的问题。庆幸的是,「理想」和「理性」是两个很好的驱动力,让我们不断的迭代自身,突破已有的系统。从这个收益角度讲,追求完美的过程本身就是一个完美的收益。只有这样,社会才能不断的进步,我们才能不会停留在因为一点点成绩就将其归结为「懂人性」这样不客观也无法量化的评价中。由于信息不对称而造成的神秘感不是社会进步的推动力,神一样的存在让万人敬仰不是社会价值所在,迷恋其中只会让人误入歧途白白浪费生命。

有一次我和测试同事沟通,尝试找到一种可度量性能的测试方法。他们告诉我,这是很难做到的,所有我提的方案他们之前都尝试过了,最终都以失败告终。因为这个系统本身非常复杂,影响用户感受的指标有很多又太主观,很难说是某个特定的指标产生了影响。这我是完全理解的,我也承认我自己对这些的复杂性认识不及他们的一半。但是,对于一个几乎所有内容都只和技术有关的产品,我的直觉告诉我它的所有东西都是可以度量的,只是暂时没有找到方法。我们很容易先入为主,以为尝试过而没有找到方法就代表没有解决方案。这是我们所有人都很容易进入的误区,时不时不自觉的进入这个误区也可以理解。

这种沟通方式可怕的地方在于,当你先入为主的进入这样的误区,认为没有办法的时候,你会自大的以为别人所有的努力和尝试都只是幻想和徒劳。对于任何一个问题,我们应该努力去寻找行得通的方法,而不仅仅是告诉别人什么方法行不通。对于一个很复杂的问题,如果影响用户体验的因素很多,你不应该仅仅告诉向你咨询的人「所有这些都是不确定的,因为影响它的因素太多,需要综合考虑」。当知道需要综合考虑之后,我们需要知道的是「这个指标影响了 XXX,那个指标影响了 XXX,他们结合在一起会怎么样,需要寻找一个什么样的平衡」。对于问题解决者,我们不能看到一团乱麻就告诉观看者这是一团乱麻,即便是说明了产生一团乱麻的原因也还不够,我们不仅希望看到它的解释,更希望看到直面乱码抽丝解乱的方案。在这里,我的信念是,如果一个系统的一切都是由技术构成的,那么一切都是可(模拟)量化可(模拟)测量的。

上周在沟通能力工作坊上我们做了一个游戏,一组 15 人左右,每人手上 2 张牌,里面布满了各种图案,所有这些牌中的图案都可以按一定的顺序连接在一起,游戏要求在一定的时间内按这个顺序摆放好所有的牌,但是必须「落子无悔」,牌放在某个地方之后不能移动,其它的牌只能放在它左右两边有空的地方。除了这个对结果的要求之外,排列过程中所有人的交流仅限于语言,不能给别人看自己手中牌的图案,但是语言没有限制。我们小组差几秒钟就能完美的完成游戏,这时候困惑我的是为什么游戏时间设置在 10 分钟,而不是更长或者更短,有何科学依据?

游戏结束后大家发表讨论,我发现游戏成功的关键在于一开始能找到规律告诉大家,让大家按这个规律一致行动完成游戏。幸好有个同事之前玩过这样的游戏,所有一开始大家就有头绪,基本上没有任何怀疑就跟着走了。如果不考虑几秒钟的相差,把这游戏定义为成功,那么成功的关键之处在于一开始找到了规律,要不然所有人肯定都是无头苍蝇一样不知所措,即便语言沟通没有限制也不一定能很好的表达,即便表达准确到位了别人也不一定能够理解。所以它是一个非常考验语言、沟通和理解能力的游戏。

我在这个游戏结束之后做了另外一个假设,假设一开始的规律是错误的,假设那个你意识到的所谓规律只是一个带你进入误区的假象,那么如果所有人都没有任何质疑,我们都将失败。这是另外一个先入为主的例子,一开始出现在你脑海中的规律占据了你大脑,它让你不会再有任何其它的 mindset hack,而其它所有人则在一边庆幸安全一边让自己的大脑进入放松状态,不再寻找其它可能的解决方案。这让我想起了电影《潜行者》,潜行者带领另外两人进入「The Zone」的时候需要遵循严格的规律,任何闪失都有可能将所有人葬送。

前面这个游戏和工作坊上的另外一个游戏类似,它给每个人一个数字,要求所有人蒙上眼睛后无声的按顺序排列起来,数字可能是从 0 开始,也可能从 1 开始。闭上眼睛没多久,我就感觉自己进入了一个黑暗的太空,在那里你看不见任何东西,没法发出任何声音,只能靠触摸来交流来尽快找到出路。这让我感到害怕,让我瞬间打消了以「老了以后被抛入太空自生自灭」这种死法为终极目标的年头。我老了以后是会更有力量坦然面对一切不再恐惧呢,还是会更加害怕?

这两个游戏和《潜行者》教会我另外一个道理:我们应该始终怀有强烈的信念,相信最终能够找到出路;但是不能执念于一开始的假设,让这种先入为主的判断主宰整个过程,而应该在整个过程中快速切换策略。如果结局和运气无关,信念的强弱以及如何坚持这样的信念将起着决定性的作用。在找到最终答案之前,没有哪种策略是不可怀疑天生就是正确的。

每次市场部的妹子找我出去分享的时候我都要准备好久,我会在写 PPT 之前先写一篇零碎的文章整理思路。小时候写话题作文,长大了写话题 PPT。这次我把分享之前整理思路的时候写的零碎内容整理一下写成文章记录下来。

技术人员是懒惰的,他们宁愿花费业余时间来创造提升效率的工具也不愿一直重复劳动,当然也更愿意使用现成的提升效率的工具,前提是你这产品做的足够好,也就是有其价值。这也是出现越来越多服务开发者的细分产品的原因之一。我们的云存储产品虽然以 API 这种无界面的形式提供,但用户的体验也非常重要,其中有两点体会非常深刻:

1. 体验的要素:Don’t make me think

在我们七牛的云存储产品一开始面市的时候好多人问我,你们和竞争对手相比有什么优势?那时候市场上面向开发者可用的云存储产品没有几个,很多存储领域的创业者还是在做网盘,API 对他们来说是可有可无的。因此,光从这点来看,我们就有足够的优势。存储之上,我们有一个受到几乎所有客户好评的重要功能,也就是后来被所有友商当作标配的镜像存储功能,这个功能几乎可以让大多数客户毫无成本的从任何别的地方迁移过来。

不久以后,图片社交类的产品越来越多,对图片缩放裁剪等各种处理的需求也越来越多,我们推出了一个几乎囊括了所有图片缩放裁剪需求的功能,一直用到现在(也一直在优化),后来也被友商们作为标准功能。

镜像存储和图片的灵活缩放裁剪两项功能,真正做到了“不让用户思考”,开箱即用。但是对于一家以提供 API 为产品的公司来说,Don’t make me think 的边界还是很难衡量。并不是说我提供了某项体验非常好的功能就可以让客户一直爽到底了,因为我们所提供的产品是以 API 的形式呈现的,其连续性相对没有网站或者 App 产品那么好(这点可以拿 API 的“交互”对比网站或者 App 产品的交互体验)。那么到底做到多好才算足够好呢?比如,文件的 MD5 值到底该不该我们来生成?我们到底该不该帮用户自动生成可以保证唯一性的文件名?终端用户上传完成后,回调成功的可靠性到底该由谁来保证?

对于基础架构没那么好的系统来说,你可能觉得我这里提到的几个问题都可以由用户自己来完成。比如 MD5 值可以在上传之前就算好,唯一的文件名也可以在上传之前就生成好写入数据库,而对于回调成功的可靠性保证那就更不好做到,因为每个终端用户的网络环境都是不一样的。对于图片的缩放裁剪来说,你也可以让用户在上传之前进行缩放裁剪,或者上传之后需要用的时候下载下来再缩放裁剪。但是,我们认为当客户有需要的时候进行这样操作不是一个完整甚至完美的体验,比如图片文件的缩放裁剪放在本地处理会花费终端用户或者我们客户巨大的代价。为此,我们在存储周边做了很多看似存储之外的事情,而保证基础架构良好的扩展性是应对多变需求的基石。

当然,作为技术人员,我们并不是不知道所有事情由服务提供商做了的好处,但作为实现方,我们也要考虑实现该功能的便利性和实际价值。这时候 MVP 原则就派上了用场。如果我们无法预测某项功能是否有必要开发,是否能够对体验带来提升价值,那就暂时先不实现它。客户不是上帝,他只是上帝的派生类对象。而派生类的对象具有唯一性,其“父类”上帝的共性需要我们自己去归纳和总结。

打造极致的产品和保证体验的完整性,是保证良好用户体验的两个非常重要的要素。

2. 服务即体验:Don’t make me cry

对于上文的阐述,或许你有一个疑问,同样作为服务技术人员的技术人员,为什么我们会遇到无法预测某项功能是否有必要开发的情况?其实,作为互联网最基础的服务,构建在我们之上的上层服务和业务非常多,而其中大部分场景都我们都没有经历过。例如对于一款视频类的社交产品,没有类似客户之前我们都没有过类似的研发经验,不知道这里的研发会遇到什么坑。如果把我们的产品当成是由几个上传下载 API 组成的“界面”,那么我们自己对存储之外的事情就知之甚少,甚至毫无必要知道。

我们可以从客户需求中抽象出共性,然后通过满足共性需求来满足大部分客户的需求。但是对于一款产品来说,如果脱离了客户的使用场景,再好也没有意义。因此,对于一款视频社交类的 App,我们有必要去了解我们客户的用户是如何使用产品的?而他们在使用过程 App 的过程中,又是怎么样使用我们的服务的?比如在视频播放之前,是否有必要提供一些视频内的截图让用户预览?很多有版权的视频是否需要水印来保护?这些问题都涉及到对整个视频的处理。对于已经上传到七牛的视频,我们是否有必要让客户下载下去处理好之后再上传?如果这样让用户自己去折腾,那就不是一个完整的体验。我们的做法是,还是以 API 的形式提供一系列的视频处理操作,这样客户只需理解我们 API 的用法,然后根据他的业务需求做相应的操作就可以,完全不需要我们的干预。

那么,在我们对视频领域毫不熟悉的情况下,我们是如何做到准确感知客户需求的呢?答案是客户服务。

如果按已知和未知来划分我们所认识的世界,那么我们已知的部分其实很少很少,未知的部分比它多很多,而还有另一部分比例相当大的“暗物质”是我们不知道知不知道的。我们对自身产品的了解得非常的熟透,但那只是已知的很少很少一部分,而对于很大一部分在使用我们产品的客户,我们所知甚少。因此,如果闭门造车,只完成我们认为已经完成的那部分,这样打造出来的产品对客户来说可能价值有限。很多人都说乔布斯是创造需求的,实际上不是,这样的神话只会出现在不知道如何收集客户需求如何根据需求来改进产品的创业者眼中。即便是有,也是风貌菱角,非常不具有可复制性。

对于一款服务于技术人员的产品来说,研发产品或者功能的技术人员直接与客户接触有一个很大的好处,他能够理解自己的努力对于同行的价值。如果有个问题困扰了客户,造成客户方价值的损失,他可以去直接修复,这是显而易见的价值体现。对于服务方来说更重要的是,这个与客户互动的过程,是一个很好的建立认同感(或者不认同感,如果自身很糟糕的话)的过程,用好的方案解决实际问题比任何虚的关系维护都更有效。而对于服务方产品的一线研发人员来说,接触足够多的案例或者使用场景,是抽象和创新的基础。从具体场景到抽象再到具体场景,是一个螺旋式的正向循环上升过程。

说到客户服务,不得不提一下最近几年非常流行的“布道”。布道一词在过去是指对宗教的传播,以扩大受众范围,福泽天下。对于互联网公司来讲,带有客户服务性质的布道会有更广泛的含义,这个过程不止是一个把我的产品传递给你的过程,甚至也不止收集需求改进产品。和用户交流多了之后你会发现,原来你的产品有很多很多不同的使用方法(姿势),不同的用户在使用你的产品过程中也会遇到各自不同的问题。举个例子,我们有一个功能,在用户往我们这边上传完文件后回调我们客户的服务器,通过网络请求的形式通知客户方我们已经上传完文件了。这个功能在生产环境使用起来很方便,因为生成环境都有比较好的网络环境。但是客户在自己本地机器调试的时候会有一定的不方便性,我们回调的时候没法访问到他的本地机器(127.0.0.1),这时候就需要客户部署一个可被公网访问到的 API 服务来接受我们的回调请求,然而这样的操作在大多数情况下很不方便。有一次在和客户接触的过程中发现他用了一个叫做 localtunnel 的工具来给自己的机器做代理,用一种很取巧的方式让外部服务可以访问本地机器,于是我将它推荐给了后来接触到的所有需要的客户。再后来,我发现了一个以此服务为产品的公司 Runscope,这项服务可以用来监控、测试以及调试你的 API,分析你 API 的进出流量。所以可以说,布道不仅是一个将你的产品或者理念单向传递给对方的过程,对方的反馈对你和你的其它客户都非常有帮助,甚至可以在这个过程中发现更多有趣的商业机会。

服务是体验的一部分,我们可以从两个维度来理解:好的服务态度和提能力是一种好的服务体验,与客户的积极接触能够帮助改进产品进而带来更好的体验。

远程协作是一个听起来很酷的词,就像谈恋爱一样,听起来总是觉得它和浪漫一词相关,但实际进行起来却由于各种原因感觉不是那么浪漫。那么,我们这次就来分享一下远程协作过程中的浪漫和苦闷,以及我们在两者之间的取舍。

远程协作,我们也把它叫做“云办公”,好处是自然可以想象:

  1. 节省办公室租金( HR 曾好几次跟我说公司办公室位置不够了,把我从这个地方赶到那个地方。)
  2. 工作环境自由/高效/免打扰(云办公的含义是,你可以选择任何地点进行办公,不一定是要在家里,可以在办公室,也可以是咖啡厅甚至酒吧,去此时此刻任何让你感觉到舒服的地方,只是无论你去哪里,你的同伴都很可能还和你保持“远程协作”。)
  3. 节省路途时间,可以拿来工作,也可以拿来陪家人(我们组有一个同事就是因为家里太远了,每天可以节省 3 小时来回时间,在家办公更适合他)
  4. 更有可能招到更好的人才(有不少人才因为地域的限制而被放弃,这是非常可惜的。我们的设计师就是因为在杭州,不需要到上海来才加入。)

那么,在这些“诱惑”之下,我们是如何在工作中保持持续的跟踪和反馈的呢?我们使用了一些很酷的在线工具!

我们团队麻雀虽小但五脏俱全,全端工程师、设计师和产品经理全部齐全。因此,在做一款基于 Web 的产品方面是一个比较齐全的组合,不需要借助多少外界,四个人凑合在一起,除了干活就是沟通。各自隔离开来,是为了干活更高效,沟通也是为了干活更高效,只是殊途同归。沟通和隔离,本来是相互矛盾的,只是借助在线工具之后,两者的矛盾程度降低了,在某些方面反而相互促进了(比如在需要用文字表达的时候,相互隔离又保持一起在线可能会更高效,更容易让大家专心思考并无障碍的表达自己的观点)。

首先,前期需求的沟通。我们花了大量的时间(大概两三天)来寻找一款好的远程语音或者视频通话工具,最好是兼具屏幕共享的。体验过太多类似产品,以至于我们发现很多该领域的创业公司。网络带宽条件越来越好,移动端的兴起,以及浏览器技术越来越先进,导致该领域涌现大量的创业公司,比如最近被 Slack 收购的 Screenhero,远程视频会议领域之王 WebEx 出的新产品 Cisco Spark 等等。最后,我们选择了 Skype,它在语音通信质量方面胜过其它国外的同类创业公司。我们另一个远程团队使用的是 QQ 语音,效果也不错,只是我们一开始没有尝试。该领域的其它产品包括 sqwiggleRoomMoxtraTalkyKato

其次,需求文档的撰写和矫正讨论。文档共享方面我们有很多方式,因此也有很多选择。比如,你可以以文件的形式共享在 Dropbox 上,也可以提交到 Github 上,当然 Google Docs 的形式最好,可以共享编辑和添加注释,只可惜被墙了。最后我们选择了没有被墙,在产品体验上也更好的 Quip,这是 Facebook 前 CTO 创业做的一款产品。这款产品一改古老的 Docs 风格,不以分页的形式展示文档内容,在编辑和在线沟通等体验上都好过其它产品,是我们的最佳选择。国内的同类产品叫石墨。

再次,设计稿的共享。设计稿的共享也有很多形式,最简单的就是使用 Dropbox 这种工具来同步,也可以发到 Slack 上去。我们使用了在线白板系统 Frontify,可以在线对共享稿的细节进行勾画和讨论。

然后,项目管理。Trello 无疑是整个项目管理的中心,产品的规划、任务的分配,都在 Trello 中记录。只可惜我们团队的开发不是很规范,产生的内容没有多到任何细节都覆盖,因此在 Trello 上只是零散的记录一些关键功能的开发,以及视觉走查和功能走查的 Bug。为了保持 Trello 的整洁而不会杂乱无章,我们把设计稿和需求文档的讨论放在别的更专业的工具上(Quip 和 Frontify),只在 Trello 上贴这些相应资源的链接。使用 Trello 管理的重点不在于添加内容并消灭,而在于分解工作、约定规则和常规工作流程,并严格执行。在这方面 UserVoice 有一篇文章值得参考 How We Use Trello & Google Docs to Make UserVoice Better Every Day: http://community.uservoice.com/blog/trello-google-docs-product-management/

最后,琐碎沟通。就像七牛早期只使用 Gtalk 进行沟通一样,Slack 取代了 QQ 成为我们最常用的沟通工具。我们作为小团队,在工具选择方面达成一致的代价非常小,并且 Slack 相比 QQ 具有非常明显的优势,比如我们记录了从项目开始到现在为止完整的沟通过程,所有的吵架记录都在。我们使用远程协作,大家在物理上都相互隔离了,它最大的优势在于不轻易去打扰别人。Slack 作为通知中心在跟踪队友进度方面起到了非常大的作用,这种跟踪是以跟踪者选择性的收取相关信息来进行的,而不是一问一答的形式。我们用 Slack 来收取 Github 的提及记录信息,使用 Slack 来收取 Frontify 上设计稿的更新记录,收集 Trello 上的项目进度信息。

以上,是我们在远程沟通过程中使用的工具,看起来很酷,但如果一个产品的打造过程只由这些冷冰冰的工具组成,那团队不一定能够走到现在,或许早已经解散。

远程工作的终极理想是解放每个人的生产力,让每个人可以在适合自己的情感和现实状态下尽可能发挥自己的才能完成极其专业性的工作,不必困于一处。但这毕竟只是理想。团队之所以称为团队,是因为大家习惯了在一起。我们之所以使用这么多协作工具,是因为大家希望保持沟通。对于聚集在办公室的团队来说,这是天然的优势,他们可以在不满的时候朝对方一笑继续接受之前不满的事实继续干活,而不是不断的沉默让你问一句答一句,抽一鞭走一步。事实上,我们在前期需求沟通的时候遇到过巨大的困难。

我们遇到的第一个问题是,前期沟通频次控制不够好。前期我们以为有 Skype 持续在线语音沟通就够了,但是后来发现这样更浪费时间,如果大家都只在自己电脑面前干坐着而没有更多想法,只会浪费时间。我们的改进方案是,各自先做相应的思考,然后每天不定期进行简短的沟通,达成意见的统一。再后来需求沟通完成后,各自进入具体的工作,每天不定期的沟通就会对大家造成更多不良影响。于是,我们就开始定规矩,每天早上 10 点准时开早会,时间不定,每天尽量只需要实时沟通一次(其它琐碎的事情在 Slack 上沟通)。除了早会之外,每周一 10 点准时到公司开周会。项目进行到后期,工作上的内容大多可以通过在线沟通解决,但周会的意义在于保持组员见面联络,让大家在情感上感觉到这个团队的存在和使命。

其次,文字的沟通容易吵架。Slack 虽然有丰富的表情,但跟 QQ 和微信不一样,不太符合中国人的习惯,作为技术人员,我们在讨论工作事情时候也更习惯于用纯文字进行沟通。有时候如果多方意见不统一,就很容易造成至少两方在玩文字或者逻辑游戏,打口水仗,情况恶劣的可能会影响大家的心情。这在专业性极强的工作内容中是没有必要存在的,我们无非是为了做一个工程做一款产品,不是为了显示自己的智商有多高逻辑有多强。为了坚持自己的主观看法而去吵架不叫有情怀,以为对方伤了自己的自尊再去伤对方的自尊不叫出息。假如真的在文字聊天的时候吵起来了,最有效的挽留办法不是继续为自己“辩护”,而是打开 Skype 或者电话沟通,甚至直接让大家跑到办公室统一意见。当然,这些都只是具体的操作,每个人应该在心里记住的是,我们之所以讨论不是为了吵架,不是为了秀智商的上限或者下限,而是为了做一款更好的产品。不忘初衷,方得始终。

最后,主动和自觉非常重要。我们说过远程协作可以不受办公室其他同事的打扰,但却免不了你自己所在环境的打扰,特别是独处的时候免不了自己内心的打扰。比如,有些人特别是 leader 可能会无形中感觉压力大,会感觉恐慌。如果是创业,可能会有意无意关注一些竞争对手,他们可能是真实的,更多情况下是假想的敌人。这时候,主动而自觉的和队友沟通就显得非常重要。沟通形式多种多样,比如按时完成符合对方预期的工作就是一种很好的沟通,结果即为互动。再比如,工作内容之外生活内容的沟通,很容易在远程协作团队中忽略,特别是同性之间,物理上的隔离很大情况下就意味着生活内容的隔离。我们需要背靠背的力量,来排除一切干扰,缓解各种有意无意情况下产生的压力。

Ikbear

Be nice. Or else.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store