Wang Pin's 2018 总结 - thinking more,doing the best

跳出程序员的思维

做“出格”的事

很多人都曲解了【不在其位,不谋其政】的含义,包括曾经的我,觉得自己工作范畴之外的事情,都应该不闻不问,不理不睬。作为程序员,就应该专注于实现功能,提高效率,修复漏洞,至于客户需求,界面设计,等等,和技术无关的部分,就应该事不关己高高挂起。
但很多时候,事情并不是看上去那么简单。也许未经仔细确认的需求,会演化成无限膨胀不可制约的毒瘤;互相矛盾的设计语言,会将原本简单明了自解释的页面逻辑搅得乱七八糟。此时,迷茫的程序员们会痛恨产品经理,设计师,会怪罪公司。然而于事无补。
所以,我现在偏好做“出格”的事情

要掌握一件东西,必须先了解它。

要将需求的前前后后边边角角都捋清楚,才能在此之上构建足够明了的架构,函数,接口。同样的,要首先了解 UI 设计是怎么回事,才能据此来推导整个客户端界面所应该具备的风格,小到一个按钮应该如何反馈点击,大到复杂的界面如何响应不同尺寸的设备。
然后,必须去沟通
得用产品经理的语言去和产品经理沟通,去阅读客户需求,去分析需求的含义,直到能彻底的掌握需求的本质。
得用设计师的语言去和设计师们沟通,去理解设计风格,去分析设计要素,直到看一眼他们的设计稿就能理解他们的设计诉求。
最后,还得学会关键对话
当对方持有不同的观点时,努力平复情绪,理解,学习,持续沟通,直到双方达成共识。

当做的更多,往往就能看到更多,理解和包容更多。我看到产品经理在会议上面对即挑剔又无知的老板和客户时,无奈又疲惫;我看到设计师们面对繁重的设计任务和反复无常的经理时,一腔热血无法施展的辛酸。在往上,又能看到 vp 们的焦虑和无力。我一边看见,一边读书,尝试去分析,去感悟,然后静待成长。

看书

做出格的事情,除了准备好自己的大脑,随时从coding模式切换到日常模式以外,还得逐步构建自己的知识架构。看书是个好办法,当然前提是看好书,用心看。下面是我的(部分)书单。

  • 《品牌的起源》
  • 《淘宝十年产品事》
  • 《产品经理入门攻略》
  • 《腾讯产品法》
  • 《产品经理方法论》
  • 《产品的视角:从热闹到门道》
  • 《人人都是产品经理》
  • 《破茧成蝶-用户体验设计师的成长之路》
  • 《关键对话》

作为业余放松,我也看小说。目前已读完的:

  • 《三体》
  • 《大明1566》
  • 《天龙八部》
  • 《射雕英雄传》
  • 《神雕侠侣》
  • 《倚天屠龙记》
  • 《碧血剑》
  • 《鹿鼎记》
  • 《连城诀》
  • 《七种武器》

在读和计划的:

  • 《冰与火之歌》
  • 《哈利波特》
  • 《书剑恩仇录》
  • 《雪山飞狐》
  • 《李自成》

关于工程师和QA的思考

当工程师的任务太繁重时,产品质量必然降低。那为了保证质量,应该招聘更多的工程师,这是很直接的思维。或者,招聘更多的QA来发现问题,然后请求工程师修复。后一种,好像也能解决问题,但是,他同时也将工程师和QA放在了对立的位置上。

在这样的管理方式下,整个项目组的人员演变,将变成:

  • 工程师任务太重,所以减少编写单元测试的时间
  • 招聘QA来编写测试代码
  • 工程师发现单元测试可有可无,于是不再写单元测试
  • 招聘更多QA

以上过程会无限循环,最终,会稳定为这种开发模式:工程师只写业务代码,基本不测试(自动或者手动),大量的QA辅助测试。随着业务代码的不断累计,问题也会越来越多并且难以简单重现,必须招聘越来越多的QA。同时,由于工程师数量少且任务重,随着项目越来越庞大, 产品迭代速度会越来越慢。

很不幸,我所在的项目组已经沦入这样的陷阱中。2018年我们招聘了 1 个开发,与之对应的,QA 为 3 个。

技术和创意

server render 和 pwa

spa(single page application)首屏渲染太慢,原因是它必须等待关键 js 文件下载完成并执行,而在执行的过程中,可能又会下载其他 css,图片,或者调用后台 api 获取构造页面的数据。这整个过程可能会耗时数秒。
server render 做这样的事情,在用户第一次访问时,在后台就准备好尽可能多的必须资源,一次返回给客户端,以加速首屏渲染效率。

pwa(progress web application)通过 server-worker 和 cache,将静态文件存储在本地,当再次启动 app 时,直接加载本地文件。由于本地文件加载0耗时,所以 pwa 能提供媲美原生应用的启动速度。

结合 spa 和 pwa,app 的启动速度将得到质的飞跃。

web component

web component 提供了一组原生 api 以定制组件。目前,有一些领域已经开始在实践 web components,譬如微前端:用 web component 来业务模板,利用 shadow dom 天生的安全性来隔离数据和封装逻辑。

material design

我的所有关于设计的初印象几乎都来自于 material design,由 google 某团队领导并推广的设计语言。从设计的门外汉,到现在可以对某些设计要素,如颜色,布局,动画,层次,等等,能够侃侃而谈,material design 功不可没。同时,它打开了一扇窗,通过丰富的站内索引,和不计其数的新鲜名词(对我而言),我得以了解以前完全陌生的领域,开始懂得鉴别美和丑。这一切,都是在不经意间,缓缓形成的。可能当时啃文档的时候,还有些觉得晦涩难懂,甚至痛苦,但现在想起来,却只有收获知识的喜悦。

创意

没实现的创意,那只是脑洞
饭桌上,走廊里,或者办公室一角,我经常听到各种各样的奇思妙想,但100%不了了之。或因为本身的不切实际,或因为实现起来难于上天,或,更多的是,只是因为不愿意脏了手。

世界上最轻松美妙的事,不过于高谈阔论,与之相对应的,最苦难的事,无非是身体力行。还好,我懂的不算太晚。我对一些创意,做了初步的规划。如下:

  1. hexo 主题 - remind
    remind 是一个魔兽争霸3选手的id,又名小凤凰,风格朴实的暗夜精灵选手。当时要给自己一个英文名,我不假思索,就选了 remind,即是向偶像致敬,也是来鞭策自己,永远勤恳踏实。我希望这个主题也能像它的名字一样,朴实,而又精致。
  2. boli - local 资源文件编辑器
    从入职 hp 的第一个项目起,就被国际化反复折腾 - 频繁的文件修改,低效的邮件沟通。翻译人员用 excel 保存修改意见,而我们用 json 文件保存最终结果。这中间的差别,再加上双方的沟通不畅,催生出来的质疑和职责,我至今记忆尤深。
    但其实,问题十分简单 - 我们的思维方式和知识背景不一样。而解决问题的办法无非两种:统一思想,或者统一工具。私以为统一工具的难度较低。boli 就是这样的工具。我第一版的计划是做一个 editor。如果后续有需要,可以做云端。
  3. 更简单的私人博客
    很多人从公共博客,比如cnblogs,转到私人博客,比如用 hexo 搭建,我觉得原因无非有下面几个:
  4. 想玩,比如我
    2.想要自己的独立地址

对于 2,如果让他们也经历 1 所不能避免的折腾:购买域名,备案,配置 ssl 证书,设置 dns,手动发布博文。那无疑是残忍的。那么,有什么办法能够即享受 2 的美好,又能避免 1 的折腾呢?这其中是不是隐含着一种商业模式呢?

(全文结束)