@Lenciel

Work Life Balance的神话

Don't touch me

最近有几个事情让我在这方面想了很多。

首先是那篇在业界掀起轩然大波的关于Amazon高压管理制度的《纽约时报》封面文章。由 Jodi Kantor 和 David Streitfeld 耗时 6 个月调查了 100 名 Amazon 离职和在职员工的这篇文章,细数了 Amazon 企业文化里面充满达尔文主义味道的部分:

  1. 末位淘汰,并且建立通道让员工将身边同事的表现秘报给共同的主管
  2. 对流产或者患癌员工不但不给予关心,还进行低绩效考评或者工作上边缘化
  3. 每周超长的工作时间,经常有凌晨的邮件,并且要求及时处理

其中一个叫 Molly Jay 的前 Kindle 项目组成员讲述的故事我印象最深:她说因为要照顾患癌的父亲,一周不能达到80个小时以上的工作时间,绩效考评就迅速下滑。甚至在父亲临终前希望晚上和周末少一些加班,不但被主管拒绝,甚至当着她的面说她”是个麻烦”,最后她选择了离开。

然后是周三凌晨看曼联队的欧冠球赛,解说聊起范加尔对续约还在犹豫时说:64 岁的范加尔对媒体坦言希望仔细考虑一下是否继续执教球队,因为自己陪家人的时间太少了。而就在之前,65 岁的温格因为类似的原因,和自己59岁的太太离婚了

最后是柳青患癌的消息刷爆了创业圈之后终于又刷爆了朋友圈。含着金钥匙出生,哈佛毕业,投行背景,拼到滴滴总裁,却年纪轻轻遭此恶疾,比之前李开复患癌的消息更让人觉得唏嘘。

说好的Work Life Balance

在包括四大、投行、建筑、广告、传媒等等需要打鸡血的职业里面,程序员大概算蛮幸运的:因为我们这行大多数公司还是比较推崇Work Life Balance的。

一方面是因为在这个行业,顶尖人才永远是卖方市场,供不应求。为了留住人才,公司纷纷开出更人性化的福利和政策。

上班与休假方面的规定就是一面镜子。这些年本座眼看着无限制的年休假从少量公司的福利慢慢成为硅谷创业公司的标配,更有 Netflix 豪迈的新生儿父母一年带薪产假。这些政策都是有数据支撑的:Google 的女员工带薪产假延长至 22 周后离职率下降了 50%。

另一方面是一些广为人知的道理又被大家抬出来温习。

包括这次 Amazon 的新闻一出,先后参与了 Facebook 和 Asana 的创建,31 岁就已经攒下 79 亿美刀身家的达斯汀·莫斯科维茨就发了一篇雄文表达自己的态度:如果能够再来一次,他希望自己在创建 Facebook 的过程中能够过得轻松一些。

文章里面提到的那个一周不能工作超过 40 个小时的理论,我之前也唠叨过。实际上这个结论福特在 1926 年就调查得出了,并且开始实施在自己的汽车厂

说好的Work Life Balance呢?

然而别人家的公司与你的公司总是有差别的。

如果没有这篇 Amazon 内幕以及之后引发的世界范围内的大吐槽,广大的天朝码农经常都沉浸在「为什么受伤的总是我」的悲伤气氛中。

没错,移动互联网火热之前,国内 IT 企业标杆多是华为。大家都狼得没边儿,猛打猛拼。现在 BAT 火了,也不忘贡献996为代表的各种疯狂制度。

过去我要安慰大家,只好说其实不仅仅天朝这样:从我经历过的项目来看,东亚和美国的 IT 人士们都非常非常苦逼。闲到十八摸这种程度,很多美帝的工程师只要我在线他就在线;之前 M 记的韩国大老板说在三星工作的时候,公司在办公室边上修了很多公寓以便员工不回家直接进去续命;日本台湾的就更不用说了…

现在好了,发现其实全世界大多数从业者的日子都没什么大的区别(注意我这里说的从业者不包括各路水货混子嘴炮流选手),真是给了本座莫大的安慰。

还在 M 记的时候,我就挺关注burnout的,因为自己确实有过经历,所以很怕带的团队里有小伙伴中招。

出来创业为了大家不搞出内伤,我们不打卡不搞绩效不规定上下班时间不限制休假长度。

但即便如此,圣杯般的 Work Life Balance 并没有发生:至少本座没有体验到。

事到如今我终于可以认定它是不可能做到的:从事实上看如此,从道理上讲也应该如此。

工作和生活是两件需要同一个主体,你,投入身心的事情。你可以把两件都做得马马虎虎,你可以把其中一件做得不错另一件做得挺糟,你也可以把其中一件做得出类拔萃另一件完全不做。但你没法两头都做好,因为没有平行世界。

觉得自己都能做好的人,一定是参考的样本太过于局限:很多时候你需要和自己差不多资质的选手比较,才能发现更多的专注意味着什么。而实际上大多数真正做好了的人,资质比你更好并且比你专注多了。

所以呢?

好的引导流程胜过10个新功能

SNS 的有趣之处就在于,经常你会看到一些话,让你对着屏幕点头不已。比如下面这句:

Don't touch me

Joshua Porter 的这段话看起来是吐槽,但又实实在在的发生在参与创业大潮的你我身边。在 2000 年互联网泡沫破灭之前,那些最终幻灭的高科技公司的发展轨迹无非是:

  1. 用一个美好的想法或者概念融资
  2. 花 9-12 个月的时间推出一个产品
  3. 花大把的 PR 费用去做推广和宣传
  4. 发展无法满足预期
  5. 花 6-9 个月推出产品 2.0 版本
  6. 重复#1-#5,直到烧完所有的融资

在 2000 年之后,经过这十来年的发展,业界总结了很多的经验教训。我们在团队里面推行了敏捷、TDD 等各种各样的方法论,我们在架构上进行了从 monolithic 到 microservice 的演进,我们的部署开始容器化并且都是 Devops 来完成了。

所有的人都充满信心的宣布,我们现在通过迭代,能够以较低的成本快速推出新版本了。然后,当你观察身边那些高科技公司的时候你发现:

  1. 用一个美好的想法或者概念融资
  2. 花 3-6 个月推出一个应用(web app、手机 app 或者干脆是基于微信开发的 app)
  3. 提交到各种应用市场然后发动 PR 攻势
  4. 发展无法满足预期
  5. 买关键字、买量、买推广
  6. 发展无法满足预期
  7. 花 3-6 个月推出应用 2.0 版本
  8. 重复#1-#7,直到烧光融资

Hmmm…所以也难免有人会说这其实没有什么不同嘛:

Don't touch me

然而无论预警者的声音再大声,作为创业者这种”启动-失败-再启动”的反复试错的精神都已经成为了我们的信条。的确,就跟你打开一张刮刮乐发现没奖时一样,如果我们做出来的项目没有人用,那么再来一次无疑是最轻松最诱人的选择。

然而如果你仔细看数据的话,会发现下一次失败是那样的必然。

数据:冷启动后的留存

下面这个曲线是从业者们最不愿意面对的曲线,展示了从流量导入到一个月后可怜的留存数据:

Don't touch me

  • 1000 个 UV 访问
  • 200 个用户注册(20%)
  • 160 个用户完成注册(80%)
  • 次日上线 40%
  • 次周上线 20%
  • 次月上线 10%

也就是说 30 天后,日活用户大概是 2%左右:而且你还不要觉得这数据很惨。如果去搜集真实产品的数据来看,除开 IM 类产品,大多数的产品甚至完不成这样的数据。

所以,做互联网产品首先要接受一个现实:你多半比拿破仑派去入侵俄罗斯的大军要崩得更快

加新功能?

当悲观的数据被端到面前的时候,决策层首先要明白,大多数时候加入任何新功能都不能把曲线扳回来。最容易出现的错误就是:

  1. 加入的功能不是服务于大多数人:特别是如果加入的功能仅仅服务于已经注册或者已经使用过产品的用户,而不是目前还不是用户的或者刚刚注册为用户的人群
  2. 加入的功能没有体现在大多数人能感知的地方:特别是如果加入了新功能,但是在用户进行注册或者使用的流程里面没有提示他们,让他们根本感知不到

这些错误之所以很容易犯,是因为我们作为产品设计和开发的人,很愿意把时间花在”很高级”或者”很酷”的功能上。而这些所谓的增加用户”粘性”的高级功能,如果你看看上面那条曲线,你会发现大多数是没有任何意义的:一个在用户使用产品第七天才会用到的功能,对于在第四天之后就不再出现的用户来说,等于没有。

其实在产品设计里面有一个概念是所谓的”engagement wall”。那些需要用户关联支付渠道或者累积经验值才能解锁的功能,或者是深度使用才能挖掘出来的功能,被认为是藏在墙后面的。比如微信上面的拍摄分享视频,发送红包等等。那些可以通过简单的投入就能让用户体验到价值的功能则被认为是在这堵墙外面的。比如微信上浏览好友的朋友圈,点个赞等等。把什么样的功能作为吸引用户的糖果放在面上,把什么样的功能放在墙里面藏着并激励用户来解锁它们,是需要经过精心设计的,但有一个规则不会变:那些放在墙里面的功能,是没法改变曲线的走势的。

如何选择下一个新加的功能?

首先想好要不要挑。

如果产品还在初期,你可能需要做的是精细打磨现有的功能,而不是加入新功能。新功能,特别是我们自认为可以”扭转乾坤”的新功能,往往意味着巨大的风险,巨大的投入,巨大的预期,以及极大的失败可能性。你需要掂量自己和团队是否能够承受得住。

决定好要挑?那就先去全面深入地了解你面对的问题域和你的用户的所思所想,搜集那些真正能够带来转化率的功能,然后:

  1. 做那些能够影响最多人的功能:成功的产品会把最多的时间花在那些非用户或者是随便来玩玩的用户使用的功能上,比如Slack的引导流程,比如Medium的访客评论
  2. 做那些能够带来转化的功能:特别是在精力和人力有限的时候,做影响曲线前半段走势的功能:注册、登录、引导等等,特别是首次登录后的引导。不同的产品类型,需要引导的方向是不一样的。测试平台上,你要引导用户顺畅的完成一次测试;SNS 你要引导用户添加好友,完成第一次对话或者分享;云服务,你要引导用户完成机器创建、带宽选择、域名解析等等动作,让他可以使用你的服务。根据你的业务,给用户一个舒适度极高的引导流程,带来的转化率的提升是非常高的。

然后?

Let’s keep our fingers crossed and God bless us…