2015/09/12 第335期

Scaling Startups

Quip 的 COO Molly Graham 根据她在 Goolge / Facebook 的经验,总结了一套管理高速扩张的 startup 的办法。发展到50个员工会遇到什么情况、发展到200人、750人等会怎样。

2年前我们公司用 quip 的时候,这个COO亲自做客服的,基本上每天她都要来问我们要反馈、我们有什么 feature request 也直接发信给她。当时 quip 刚刚支持了gif,于是被我们玩疯了;我们上传了很多搞笑 gif 帮他们做测试:)“很多” 是真的很多的意思。。。

公司扩张意味着要大量招人。新员工进来会“抢”老员工的工作。很多人或许因为一直做一个岗位很舒服了、或许真的因为责任感很强,不愿意让出自己的工作职责、也不愿意去尝试其他新的东西。就像小孩玩乐高积木,把积木抓得牢牢地,不想分给其他的小朋友。

"If you personally want to grow as fast as your company, you have to give away your job every couple months."

startup 高速扩张到几十人后,突然有一天,你发现你无法认识公司里的每个人了,全公司没法挤在一张桌上吃午饭了;你意识到,这真的是一个公司了,不再是小打小闹了。

Uber 代码的进化

老生常谈,从 monolithic 架构进化到 microservice 架构。Uber 内部有 500 多个大大小小的 service,用 thrift 定义数据结构。

人生

帮助 Facebook 取得10亿用户、帮 ICQ 取得 2.5 亿用户、帮 Winamp 取得 1 亿用户的 Chamath Palihapitiya 在生日之际,对人生的思考。

他把剩下的人生换成天数,13383天(36.6年);为自己余生定下4个目标;每星期结束前问自己4个问题,比如“这一周里,有多少天是快乐的?快乐,指的是真的“快乐”,不是假的“快乐”;没必要骗自己。

一个客服对付1千6百个付费用户

statuspage.io的经验。其实是一个全职客服加上全公司其他人轮岗做客服。这个观点挺好:做产品得 design for the novice, configure for the pro

SoundCloud 进化到 Microservice 的历程

他们从 Monolithic 架构进化到 Microservice 的主要目的,不是为提高性能、提高系统稳定性、更不是为了赶时髦,而是为了提高团队的开发效率。

他们做的一切,高度实践了 Conway's Law:软件系统的架构反映了公司内部的组织结构、团队间通讯的结构。"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"

任何高速发展、并且最后存活下来的startup,一开始都是实用主义者,不搞花俏的东西。都是实践所谓 monolithic 架构,具有“快糙猛”的属性,一份凌乱的代码快速迭代;所有东西都跑在同一台机器(或极少数几台)上。SoundCloud 早期的 monolithic 架构的昵称是 mothership;Linkedin 的叫 Leo,Twitter 的叫 mono-rail,Yelp 的叫 yelp-main。也有比较没创意的,比如用 django 的公司,直接叫 django app;用 Ruby on Rails 的,直接叫 rails app。