Bloody Sunshine

Just too damn hot

2017 ++

又是一年末了时,有好几年没写过自己的年终总结了。。

在日本生活了完整的一年,不过只上了8个月班,因为嘛,夏天生了个娃,小胖丫头一枚,网名三喵,简称喵喵喵,现在每天都会瞅着我傻笑,希望她能健康长大。PS:日本没有落地国籍,这孩子是中国人。
小手已经明确要求叫三喵了

到日本生活一段时间,是我们两口子的一个愿望,实现了之后的感觉更多的是想念北京,还有长春。今年只回了一次长春参加婚礼,路线颇为拧巴,东京-大连-长春-北京-东京,算上这一次,总共也只回了两次北京而已。

来之前还有个愿望是以东京为基地好好玩一玩日本,这个部分实施得不算很好,2017年没出去野几次,算下来只去了足利、江ノ島、仙台、沖縄,有一半原因是老婆怀孕不方便野了,更主要的还是内心真的喜欢宅。。。不过电影,展览和演出真是看了不少。日本电影地方保护比国内厉害的多,多数好莱坞电影都会晚三个月甚至半年多以后才会上映(是的蓝光都出了),我们金牛座当然不会吃这个亏,所以去电影院看的多是日本电影或者国内没上映的文艺片。
内田英治的新片《獣道》

说到文艺片,是要感慨一下日本的艺术院线,至少在东京还是挺发达的,新宿周边就发现了七八家艺术影院, 渋谷附近也是不少。这样的资源自然不能浪费,特意去看了几场R15+的电影,接近年底的时候更是跑到上野的成人电影院去看了一场R18+。R15+的电影有一些文艺片,也有被称作ピンク映画(粉红电影)的擦边球情色片。R18+就是赤裸裸的色情电影了。虽然不是什么了不起的事情,总归是见过真正的色情电影院,心情还是有一些小激动的。
正宗的成人电影院,里面放的都是赤裸裸的黄片

演出真是看了个爽,最满意的一场,可能也是我截至目前看过最满意的演出シン・ゴジラ対エヴァンゲリオン交響楽,演出素质极高,远超出预期,而且鷺巣詩郎亲自演奏,天野正道指挥,高橋洋子唱了那首歌,庵野秀明还人模狗样的出来露了个脸。不能再完美了。
シン・ゴジラ対エヴァンゲリオン交響楽音乐会散场

孩子出生之后嘛,受益于资本主义的福利,我开始了为期一年的陪产假,可以每天看孩子长大的感觉真的很好。为了保持自己的工作状态,在馒头商学院上开了个产品经理的入门课程,借这个机会对之前产品经理的工作做了个总结。

2017个人年度最佳

  • 电影:《Trainspotting T2》- Danny Boyle
  • 音乐:《T字路s》-T字路s,《三碗不过岗》-厨子和戏子
  • 电子产品:iPhone X - Apple
  • 书:没看新书,《海伯利安》值得一看。

2018年也很快就会过去,希望会发生一些有趣的事,希望喵喵喵健康成长。

PS:生了孩子之后,两只猫在家里的地位急剧下滑,也许只有回北京能拯救它们了?
相依为命的大喵和二喵(大雾

Beats Studio 3 Wireless上手

没有图,懒得拍以及反正网上到处都是,不差我这几张。

入手了一个2b耳机(因为左右耳罩上各有一个b。。。)
Beats是一个普遍被黑的耳机品牌,说实话如果不是W1芯片,我可能也不会考虑买它。但是这个耳机是目前唯一满足我所有需求的:

  • 主动降噪:我有几乎不隔音的AirPods了,需要一个火车飞机上用的主动降噪耳机
  • 无线:考虑到下一个手机肯定没有耳机孔了,无线是一定的
  • W1芯片:用了AirPods之后,无法接受没有W1芯片的耳机了
  • 能够链接音频线使用:最近觉得飞机上的娱乐系统片儿还挺新的,比自己拿iPad方便也舒适

Beats Studio 3 Wireless(太特么长了后面简称BS3W)是目前唯一用了W1芯片的主动降噪耳机,于是就它了,以下是一些感受:

关于我

不是发烧友,不信玄学,认为1000块钱以上的有线耳机声音表现能力都差不多,用过一些便宜耳机,森海塞尔HD448,舒尔215,Bose QC15/QC20,Klipsch Image One/X10。

音质

2013年的时候有段时间我挺想要个Beats的,有个朋友知道了,送了我一条Beats Tour。平心而论,音质不错,但是线材不太结实。。。
BS3W音质比我预期的好,首先完全没有传说中的低音轰头,反而是感觉低音的量比我之前用的Klipsch Image One还轻一点。解析力也没什么问题,声音颇舒适。缺点是稍微有一点闷。

降噪

降噪能力超出预期,但是没达到Bose QC15那种四大皆空的感觉,主要是因为有一些底噪,类似白噪音。尝试了东京的电车和商场,足够提供一个安静听歌的环境了。
开启和关闭降噪的情况,音质没有区别,这个挺好的。

佩带

相当舒适:耳罩足够大,不会压耳朵;头梁设计合理,不会压头也不会夹,作为一个大头我表示很欣慰。缺点也有,一个是稍重,不过配重很均衡,所以虽然觉得有点重但是不会失去平衡滑落,另一个是Over ear的通病,戴久了会有点热?

操作

操作是按键式的,左边是音量+/音量-/播放键,逻辑和EarPods的三个钮一样,右侧是开关,这个开关键功能比较多,开关机,开启关闭降噪,重新配对。
说实话,不是太好用,主要是这样几点:

  • 操作分布在两侧,关闭降噪并暂停音乐,这个出门买菜比较常用的行为需要两只手,不方便
  • 开关键是按一秒开关机,双击开启关闭降噪,按五秒重新搜索设备,这个按一秒开关机的「一秒」相当微妙,不是按一下开,而是要按住一小下才会开。。。

连接

连接很方便,托W1芯片的福,和AirPods一样自动同步到其他登陆了同个iCloud账户的设备,这个的好处是iPhone/iPad/Mac/Apple Watch都可以方便的切换,而传统的蓝牙耳机一般只能支持记住最后两个连接的设备。
而且BS3W采用了Class 1的蓝牙方案,也就是说理论上有效距离是100米,办公室里起来去弄个咖啡什么的都可以不用担心断开。

其他

开箱体验有硬伤,比如外封套的阻尼过大,不好拿;箱子里第一层的纸板质感不太好。但是也有惊喜,方正的盒子和蛋形的收纳盒的对比感觉很可爱。
AirPods的方便,除了W1之外,更多的是多个传感器的功劳,所以没有光学传感器/运动加速感应器的BS3W也没法实现摘下暂停之类的方便功能。

总结

  • 优点:W1芯片连接方便,佩带舒适,音质和降噪能力对得起价格
  • 缺点:操作不是很方便,国行价格太贵(但是这个牌子仿品很多不建议淘宝买水货)

濑户内海

2016年十月的时候去了一趟瀬戸内海(セトナイカイ)。
濑户内海

契机其实是《燕尾蝶》上映二十周年,小林武史张罗了一场演出「円都空間 in 犬島」,主要是Yentown Band和莉莉周,简直是梦幻组合,无论如何也不能错过。于是早早的买了票,并期待着。

这场演出是瀬戸内国際芸術祭的一部分,官网在这里 。这个艺术节每三年开一次,一次开一整年,2016年正好有这个艺术节,于是我们俩顺势逛了逛艺术节。

濑户内海这个地在日本的本州和四国中间,本来是个渔业发达的地方,近些年由于种种原因衰落了,于是转向了旅游观光和农业,现在最有名的土产貌似是柠檬。濑户内海有很多个岛,艺术节就分布在这些个岛上,有的岛上能提供民宿,不过我和媳妇还是选择了住城里的酒店,然后每天坐船去岛上看展。需要注意的是岛际交通都是靠船,末班其实都不是很晚,所以需要合理安排时间,尤其是如果深入岛内,一定要预留会港口排队买票的时间,不然晚上被困在岛上就悲剧了。

我们这次去了三个岛,具体的展出内容官网有详情

  • 犬島,目的:看演出
  • 直島,目的:地中美術館,李禹煥美術館等安藤忠雄作品
  • 豊島,目的:豊島美術館

结合航线信息和酒店情况,最后决定住在高松市,顺便丹下健三设计的香川県厅和県立体育館。
交通是东京飞到高松,然后新干线回来的,新干线回的原因,主要是,我,恐高,经不起,连续,飞行。不过新干线的价格其实和飞机没差,第一次在日本飞国内线,主要感受是安检登机流程简单得不要不要的,真心方便。

然后就上图吧?

高松市

白天高松的商店街

高松貌似是四国地区最大的城市了,是香川県首府,只有四十万常驻人口,和日本其他不太知名的地方一样,你会发现安静整洁,但是有一丝挥之不去的破败气息,总能看到年久失修的老屋。
白天高松的商店街

香川県厅

県厅就相当于省政府了,这个香川県厅是著名设计师丹下健三最有名的作品之一,日式风格和钢筋混凝土结合在一起,感觉非常特别。
香川県厅

香川県立体育館

也是丹下健三的作品,如今已经停用了,颇为破败,造型挺。。。。蛋疼的?。后来看他做的代々木第一体育館,大哥可能那几年喜欢用混凝土做曲线。。。
香川県立体育館

琴電

作为一个省会级城市,当地的电车竟然不支持PASMO卡,还让我俩挺意外的。不过琴電的小车挺萌的。
高松琴平電気鉄道

岛上

因为多数展览都不让拍照,所以并没有什么详细内容 Orz

直島:李禹煥美術館

主要是来看安藤忠雄做的建筑设计,各种混凝土,李禹煥自己的作品太禅了,现代艺术真难懂。
李禹煥美術館

豊島:豊島美術館

丰岛美术馆叫美术馆,其实没啥展品,展品就是建筑本身,不仅不允许拍照,还有好多工作人员盯梢,偷拍也很难,可以心平气和的坐在里面的水泥地上,发一会儿呆。尺度很大,但是有一些有趣的细节,在里面尝试从不同的角度去看,会有不同的发现。
和豊島美術館合个影

犬島

这是一个叫做「隐形眼镜」的作品,一面由大量不同尺寸凸透镜拼成的墙。同个作者还有另一个作品也很有意思。
コンタクトレンズ

岛民的日常生活
岛民的日常生活

演出场地,犬島精錬所美術館,这里的体验式展览也相当有趣。
犬島精錬所美術館

其他

喵星人

每个岛上都有很多猫,走着走着就能看到,不过有的猫在流鼻涕,根据我媳妇的经验,可能患有「猫鼻支」,虽然不传染人,但是撸完务必注意洗手消毒。

散养的两只,很好看,可惜不是很健康
散养的两只
一只臭不要脸的小流氓,蹭着上桌要吃的
喵星人的事儿怎么能叫流氓呢

防波堤和灯塔

因为有很多岛,于是就有很多防波堤,和很多灯塔,对于内陆长大的我来说还是有些新奇的,觉得很好看
好看的红灯塔

灯塔和濑户内海

二十周年纪念演出特别棒,发行了蓝光,我还在人群找到了自己。这里可以看预告片(需翻墙)。

还有挑了一些照片,传到相册里了,有兴趣可以看 :)

产品经理和产品管理

产品经理(PM)可能是人们对互联网行业了解最多的职位了,广大人民群众通过段子形成了对PM群体的印象:

  • 屁都不懂也能做
  • 没啥经验指点江山
  • 最爱的事儿是改需求

产品经理们通常自嘲的姿势是产品狗:

  • 没有人事权但要对结果负责
  • 求设计师
  • 求工程师
  • 求市场资源

黑归黑,很多人连PM是做什么的,以及存在的价值都没搞清就入了行也是事实。大体上,PM不是一个新的岗位,但是互联网行业对这个职位的需求量变得空前的大,而且也具有了更加可见的价值。

为什么需要产品经理

在传统行业中,产品迭代周期相对较长,一款产品的生命周期可能达到数年,通常老板可以协调各部门资源完成调研 - 研发 - 销售 - 反馈的迭代。一款产品的研发过程甚至不需要太多的产品决策,可以由销售驱动完成。举例来说,一家做马桶的公司,核心技术可能是陶瓷釉面和流体力学方面的研究,研发一款全新的马桶可能需要数月(换个外观)到数年(重大创新),较长研发过程中可能有相对明确的目标和产品定义,比如设计一个老年人蹲久了不会腿麻的马桶(等等为什么让老年人久蹲)。一旦研发完成可能销售数年甚至十几年。然后研发团队去继续研发下一款儿童不会掉进去的马桶。

不过一旦产品线太长,老板有限的精力会成为瓶颈,这时就需要授权下属对不同的产品进行管理,以保证公司顺利运转,如果组织结构按照产品进行整合,这个对产品进行管理的人就是产品经理了。

互联网行业有一个特点:产品是持续迭代/持续发布的。无论做一个网站或者一个App,消费者每次使用都会用到最新的版本。在这个过程中,每周甚至每一天都需要进行产品决策,如此高频率的决策需要高强度的精力投入,稍具规模的公司,老板都不会有足够的精力参与多数产品决策。于是就凸现了产品经理这个角色的价值。

产品经理的目标

如上所述,产品经理是为了解决老板精力不足以跟进产品持续迭代决策的问题。那么这个角色的目标是什么呢?

  • KPI?
  • 创造优秀的体验?
  • 为用户创造价值?
  • 改变世界?

都是瞎扯,产品经理的唯一目标是利用任何资源让产品价值最大化(此处先把长期价值和短期价值的争论放一放)。

很多产品经理患有「下一个乔布斯」妄想症,动不动就把用户体验挂在嘴边。但是你要知道,用户体验是工具而不是目的,产品经理追求用户体验的唯一愿意是:提升这个产品的用户体验,可以有效的提高价值。

换言之,如果一个提升一个产品的所谓「用户体验」,不会带来相应的价值提升,比如投入几个前端工程师去把一个内部管理系统的界面做得十分fancy,那么这个投入就是浪费的。产品经理就是失败的。

之前知乎有个问题 同样是节省时间,铁路为何花巨资提速,却不愿提升用户体验改造流程? ,这是对用户体验的典型误解,用户体验的基础是满足用户的需求,而不是提供奢华的服务。一个豪华但是没有火车通过的火车站,对于需要旅行的人用户体验好么?显然不好。在运力不足的时候,提速(提升运力的必要手段)就对用户体验最重要的提升。

很多只做用户端的产品经理,误以为用体验就是交互,设计就是UI或者外观,这是非常业余的。(此处绝非黑锤子)

产品管理

产品经理(Product Manager),顾名思义理论上做的工作应该是产品管理(Product Management)。但是在实际操作中,多数产品经理在做产品设计的工作,对于产品管理基本上处于下意识或者被动管理中。产品管理有如下关键点:

  • 产品的愿景和线路图:主要是哲学问题,这个产品是什么,为什么存在,要到哪里去?不断和团队传递产品愿景有助于提高协作效率,保证大家往正确的方向前进。
  • 需求Backlog:所有已确定和未确定的需求,再进一步讨论和整理前应该进入Backlog,之后基于Backlog中需求的优先级确定未来的研发计划。
  • 团队资源:团队资源决定了每个迭代周期能做多少事情。产品经理必须非常清楚,才能有效的安排研发计划。
  • 优先级:优先级管理是多数产品经理日常工作的核心任务,大量需求飞过来,团队需要明确的知道接下来要处理哪一些,而且要随时同步。基本上可以用急迫性/重要性的矩阵来判断。(需要注意的是,紧急但是不重要的事情多数时候不是真的紧急,在快速迭代的产品中,很多你以为的紧急,两个版本后都不是个事儿了)

在我入行的最初几年,也是过分关注产品设计而忽略了产品管理,好在跟对了老板,虽然是无意识的,还是在老板的驱动下对于优先级和Roadmap进行了管理。在实践中掌握了基本的方法,命好 :P

组织结构与敏捷开发的一点随笔

在日本呆了几个月之后,对于一些我们原本习以为常的架构,有了更深的理解。可以说是看到了落后与传统之后,更能明白先进的价值。
对于国内的互联网公司,敏捷开发是默认选项,而且实用主义的中国人并不拘泥于传统敏捷(Agile/Scrum)那一套,在软件工程管理上走得更远,更灵活。

传统的软件开发模式

传统的软件开发模式是长周期,里程碑式发布的,典型的是类似微软Office早年没几年发布一个大版本。这个开发模式的流程通常是市场研究/反馈 - 确认功能需求 - 设计(工程/视觉) - Coding - 内部QA - 小规模外部测试 - 交付/上架。这里面每一个环节都是以月甚至季度为单位计算的。
这个流程的目标是按时高质量的交付需求产品。但是现实是非常骨感的,在一年甚至数年的项目周期中,外部环境千变万化,如果在进入Coding之后的阶段有需求有变更,可能会对之前的设计架构有所冲击,开发团队将会面临三个选择

  1. 一旦需求确定,拒绝变更:会导致无法快速响应市场变化
  2. 在之前的方案上打补丁:如果架构设计出色可能问题不大,不过没有万能的架构,总会有一天补丁打得太多导致积劳成疾。
  3. 推翻重来:市场变化这么快,这次推翻重来了,谁知道俩月之后是不是要再推一次?

显而易见的:交付周期,交付质量和灵活度无法同时获得。因为有这些个问题,也就有了签字画押确认需求确认设计确认确认确认的超长流程。

敏捷开发模式

为了改善软件开发流程中遇到的问题,九十年代中期(是的1990年代),敏捷开发模式初步成型,并广为软件/互联网行业所接受。敏捷开发理念如今看来也并不过时,但是和所有理念一样,在生产实践中仍然需要具体的方法论,目前最流行的敏捷开发方法论应该是Scrum,核心方法是以周为单位开发/每日站立会/定期回顾,这些方法也被国内很多团队所采用。

大体上敏捷开发的目标是即使需求不断变化,也可以高效高质量的交付产品。
但是,如果读过敏捷开发的书籍或者文档,你就会发现,有一个词被反复提及:客户(Customers),这和国内互联网公司关注的用户(User/Customer)是不同的概念。这里的客户通常是需求方,这也引出了下面这个话题。

传统行业实际操作中的软件开发团队管理方式

在互联网行业,我们非常习惯高度集成的团队:一个产品团队中有相对独立的产品/设计/工程/商务/销售等角色,这个团队对产品结果负责。但是对于传统行业来说完全不是这样,传统行业(和这个世界上很多人)对软件工程的理解是:外包。很多行业认为软件开发并不是自己业务的一部分,所以并不会建立一支团队开发和维护自己需要的软件产品,而是通过购买或者外包开发实现目的。这种情况在发达国家非常普遍,所以各种关于敏捷开发的文档里才会如此强调交付(Delivery)。

时至今日,很多行业需要的软件仍然是行业工具,通常通过购买(比如制图软件)或者定制开发(比如ERP系统)来获得,但是随着人们生活的信息化,越来越多的行业开始通过软件或者网站为消费者提供服务,比如房地产或者服装品牌。于是需求方寻求定制开发用户产品,简单的比如官网,复杂的也许会有在线销售或者定制业务。
传统企业的组织结构示意图

相对应的,既然有这样的运作方式,组织结构自然也是如此,通常一个公司会有供应链/产品开发/市场/销售等部门,以官网为开端的互联网产品通常是市场部门寻求外包解决方案,随着需求越来越多,能带来的价值越来越高,外包成本越来越大,该市场部就会考虑自建一个团队进行用户产品开发。于是变成了供应链/产品开发/市场(包括互联网产品开发)/销售等部门。这个互联网产品开发部门其实和公司主营业务关系不大,存在的原因一般都是成本考量,这解释了为什么传统企业的互联网相关部门没有什么话语权(甚至有的时候在IT部门下),这也可以理解为一种历史包袱。
传统企业在新时代的组织结构示意图

在日本发现的有趣的事情是,某些公司虽然本身是互联网公司,在组织结构的设计上却是非常传统的横向大部门方式,业务部门/设计/工程开发部门这样,因为业务部门是最终赚钱的部门,所以有最高的话语权和最终决策权,其视设计部门为内部外包公司,把需求提给设计部门之后,设计部门整理确认,然后二度“外包”给开发部门。这样的组织结构会导致不同角色各自为政,缺少产品团队内部沟通,难以产生优秀的产品。

国内的情况

按照我的了解,国内的互联网公司基本上倾向于高集成度的小团队作战,通过减少组织层级保证信息传达的有效性。因为是一个相对稳定的团队长期经营一个产品,多数团队都对Scrum进行了简化,以对应更高节奏的开发。

从产品管理的角度看,无论网站还是App基本上都可以做到以周为单位快速迭代;工程管理角度上看,有追求的团队基本上能做到:

  • 持续集成(CI)
  • 持续测试(CT)
  • 持续交付(CD)

国内社交媒体上的产品狗们经常会黑自己经常改需求,之所以敢于自黑,通常是因为真的自信:今天改的需求明天就特么上线了,这是多么强大的效率啊。
总的来说,我觉得优秀的人才,灵活和高效的组织结构和项目管理方式,是中国互联网近十年弯道超车的重要原因。

优秀的人才

提到优秀的人才,还想补充两句就好像设计方法论无法保证作出牛逼的设计一样,项目管理方法论也无法保证项目的结果牛逼。关于敏捷开发有太多的最佳实践了,但是无论Pair programming, Code review还是TDD都无法保证你的代码是牛逼了,只有牛逼的团队能帮你接近牛逼的结果。