关于年终

其实,年终总结本来早就想写了。但是各种原因,不知道从何下笔。而且,有时候写一些牢骚又会让别人感到不舒服,我也就只能重新思考下该如何去写一写年终总结。

其实说起来,过去的一年,我个人认为对我来说还是很沮丧的。当然,也像一些朋友说的那样,我太负能量了。很多时候我都很难从正面去看待一些事情。就像最近流行的x付宝集福的活动,我就觉得这纯粹是一个愚蠢而无聊的闹剧。并且还不给人选择“我不要玩,别来加我,我没有敬业福,滚蛋”这样的选项。

我的另一位朋友和我说:“大叔,人各有所好,很多人还是很喜欢的。”

我对他说:“可也有人不喜欢,如果不喜欢的人不说,那就没人会知道这事儿还有人不喜欢。就是因为有不一样的声音,我们才能期待还有好事发生。”

我是个很喜欢吐槽的人,有时候确实也给人带来许多面子上过不去的时刻。而且,许多人不喜欢大声说出来的这样解决问题的方案,尤其是我们这个环境是一个内敛而讲感情的环境。但我一厢情愿的觉得,其实很多时候,in your face 的交流方式反而更高效快捷的能解决问题。

其实某种程度上来说,我是个不太在意所谓面子啊传统啊之类的人。很多时候效率高就好了。不过确实,有时候也有一些纯发泄的吐槽,倒确实是不应该,毕竟也没带来什么利益,以后确实需要减少。或许,人成长就是不断去妥协一些事情,然后最后变成自己不喜爱的那种人罢。

今年换了个环境,从绿茶团队离开了,主要是想去不一样的环境锻炼锻炼。确实锻炼了许多,不仅仅是前端,甚至是本来都想放弃的 android 方面的开发都提高了很多。其实每次量的积累最后导致质变,都会明白很多事情,这种感觉很好,但是也是这种感觉才会推动我继续学更多的知识。

关于一些拙见

其实,常常和圈子内朋友们讨论,产品和研发之间的一些东西。我有几位很厉害的产品朋友,和他(她)们互喷的过程中,总能学到很多知识。在我们的交流圈里面,一般都是直接甩脸上的那种方式交流,简单明快一击毙命。很多时候真的能让你一下子明白自己的问题在哪里。

说起产品和研发,我之前很多次都说到过,一个研发的产品修养。当然我这里特指的是应用的研发,毕竟其他方面的我也不甚了解,不可胡言乱语。

其实初级的研发和中高级的研发,一方面是技术上的提升,另一方面就是对于产品的感觉。很多研发同学并不会在意产品所做的事情背后的意义。觉得产品么,就是瞎头脑风暴一拍脑子做点想发出来就好,要么就是抄一下竞品,抄一抄微信,抄一抄 uber 什么的。其实有这种感觉也难免,毕竟现今环境中,初级的产品和初级的研发都非常之多。甚至许多地方根本不重视产品的存在,随便找一个有经验的就行。所以不靠谱的产品经理就带来了不靠谱的产品原型,然后就被各种吐槽。

作为一个应用研发,如果要继续前进,除了技术上提升以外,对于产品设计的一些基础也是需要了然于胸的。没错,不是了解,而是了然于胸。其实现在的环境中,很多时候,你不能要求产品也如同技术人员一样,去对每一个平台的细节都了解的一清二楚。对于不同的平台,其实有一些产品设计上面的妥协或者说特点,都是技术人先能够知道,很多时候产品需要等到市面上有人做了那么一个东西,才会了解到,我擦,原来还可以这样。

举个简单的例子,iOS 有个 Network Extension 的 API ,这个东西你让普通的产品去看,肯定是云里雾里,但是如果你告诉他,这个东西可以去接管用户每一个访问网络的请求,那么我想产品的想象空间就会大很多。

又比如 material design 说实话,很多产品是不会认认真真的去看这个东西的。为什么,因为国内市面上很少有人用全套 MD 设计的去做 App。 当然造成这样的情况的原因很多,这里不讨论是非对错,不过,如果仔细阅读过之后,思考一下为何作为平台提供方的 Google 会如此去设计规范,为何要如此去处理信息流,是不是又可以打开一些思路呢?

偷偷插播一句,我特别反感一听到 MD 就觉得:阳春白雪/不适合国内环境/微信曾经那么做后来还是取消了,所以这个不好 balabalabala 的说法。我觉得,一个官方的规范出来,多多少少应该研究一下,国内确实缺少这样的生态环境,但是不影响我们去取用里面适合当下环境的优秀细节。最简单的一点,一些交互其实都是为了加强上下文而产生的,即使不照抄也可以借鉴这样的思路去设计产品,而不是每次都先看一看竞品怎么做,然后再模仿一把。

所以,作为一个研发,去了解所在平台的特性,特质然后反馈给产品,告诉产品什么新东西可以做,什么东西用在这里不符合生态和使用习惯,这是一个值得花时间提高的点。

那么反过来说,作为产品人员。专业方面我就不好妄加评判了,就像我上面说的那样,产品绝不是头脑风暴出一个 idea 随便画个原型就完事的工作。里面还是有很多的道道要去深入研究才能有所成就的。但是,我综合观察下来,初级的产品和高级的产品对于技术方面的感觉是完全不一样的。

这里说的感觉,并不是说,高级产品必须会撸起袖子写代码,也不是说产品必须技术出身像张小龙那样才能牛逼。并非如此,而是觉得产品不能去惧怕技术方面的东西。不能一直抱有,我就是一个画原型的,我干嘛要去了解这个技术实现的态度去处理事情。

一个简单的点,产品写 PRD。我见过太多产品(包括大公司)写 PRD 还停留在很古老的阶段,要么是一个 word/wps 文档,要么是 word 转 pdf 的发过来,pdf 的还好,也就是大一点,word 文档换个电脑一打开排版说不定哗啦一下乱七八糟。最重要的一点,没有任何版本管理,改了需求,只能再给你发一个文档,一来一去这次少发了设计人员,那次少发了某个研发,然后最后乱七八糟。或者就是上传一个网盘或者协作软件,稍微好一点,有一定的版本管理,但是下载体验,阅读体验还是非常的糟糕。

其实,这些事情明明可以很简单的优化好。这个世界上有种语言叫做 markdown 。相信很多圈内人都知道,这并不是什么很高深的技术,一个初中小孩都可以很快学会的一种标记语言。但是不知为何,一些人一听是一种“语言”就排斥起来,不愿意去学习,不愿意去尝试。

我为什么推荐 markdown 呢,很多人会说,markdown 有些功能实现不了啊…… 没错,但是 markdown 可以完成大部分的功能,而且这是纯文本,你可以通过 svn/git 甚至 dropbox 去很好的管理。并且,大部分的团队都会有自己的版本服务器,这些服务多多少少会支持在线 markdown 渲染,这样和研发的工作紧密了许多,我相信,任何研发对于 git 上面的变动肯定比某个网盘里面文件变动来的敏感得多。何况这个世界上还有一种东西叫 githook ,你可以把你每一次修改都变成一个提醒推送到每一个关注的人那边。

当然,会有人反驳,为什么需要产品去学用技术的版本管理服务?这不是额外成本么?是的,这是额外成本。但是这样的额外成本解决的问题减少的成本值得去付出的话,那就是值得的。况且,git 基本的使用也不是特别复杂,不喜欢命令行各个平台也有还不错的图形化客户端。而且这一下就能无缝衔接了产品和研发的工作流,何乐而不为。

当然,很多厂商比如 Trello / Tower / Teambition / Worktile 都在试图做好文档和各种通知管理。但是相信我,任何一个技术人员在专心投入工作的时候,绝对不会去看这种系统的。这类系统更适合复盘和记录,作为一个 Todo list 的存在,而不适合作为团队内部工作衔接的存在。

不过,这一些说法,也就是我这一年对于自己效率上的思考带来的一些拙劣的想法。很多东西还有待于推敲,但我觉得写下来让自己看看,也是不错的想法,或许半年一年后又会在此想出更多的想法,那也是不错的结果。

希望我在新的一年里,技术做的更加精湛一些,自己的效率也能再有所提高。大概就是如此。另外希望明年公司的游戏都大卖,然后多分点奖金给我,哈哈哈哈哈。