SteveY對Amazon和Google平臺的長篇大論
Steve Yegge, Amazon 的前員工,現任 Google 員工,其本來想在 Google+ 上和 Google 的員工討論一些關于平臺的東西,結果不小心把圈子設成了 Public,結果這篇文章就公開給了全世界,引起了劇烈的反應。發布后很快他就馬上把這篇文章刪了,不過,互聯網上早備份了下來——SteveY’s Google Platforms Rant。后來,Steve 在其 Google+ 上作了一些解釋,大體是說他喝多了,而且又是在凌晨,所以大腦不清,文章中的觀點很主觀,極端且不完整,還有 Google 的 PR 對他很好,等等,等等 。
幾個星期前看到時就一直都想翻譯一下這篇文章,不過因為最近事情太多,文章又很長,所以現在才翻譯完成,翻譯的不好,還請大家指正。
導讀
在你閱讀正文以前,我想說明幾點,希望你注意一下:
- Steve 這個人非常喜歡寫長篇大論的東西。而且比較喜歡辛辣調侃和惡搞的文風,這點大家要注意!
- 文中先“罵”Amazon 公司,再通過“罵”Amazon 的創始人貝索斯 Bezos 并烘托出他的的悟性和雄心,最后教育了一下 Google。
- 我把文章分成了三個部分,這樣方便大家閱讀和討論。第一部分只是個人情緒化的抱怨,第二部分是說 Amazon 的成長,第三部分是教育 Google,我覺得第二部和第三部分是重點。
- 對于我們來說,我們應該獲取 Steve 那些關于平臺(Platform)相關的那些有價值的觀點。尤其是他說的 Amazon 如何進化成一個平臺性的公司,以及闡述 Google 應該怎么做的那些觀點。
- 關于對 Amazon 的那些指責,我想說,6年,對于一個世界級的互聯網公司,已經很不一樣了。
正文
第一部分
我曾在 Amazon 工作了六年半,現在,我在 Google 的日子也這么長了。對于這兩家公司,有一件事總是縈繞關我——這種感覺一天比一天強烈──那就是,Amazon 每件事都做錯了,而 Google 每件事都做對了。當然啦,這是很籠統的話,但卻是驚人的準確,相當的瘋狂吧。大概有一百甚至兩百種不同的地方可以讓我們去比較這兩個公司,而 Google 可能在每一項都能勝出,如果我記的沒錯,除了其中3項以外。因為,我曾用電子表格把這些項都列出來了,只是法務部門不會讓我給任何人看,即使人事招募部門很喜歡這個報表。
這里,讓我先給你個例子讓你稍微體會一下:Amazon 的人事雇用流程有根本上的缺陷,因國各個團隊各招各的人,以至于,各團隊之間的招聘標準相當的不一致性,即使他們通過各種努力來統一標準,但是實際操作上卻是一團糟;他們沒有真正的 SRE(陳皓注:Site Reliability Engineer ),工程師們什么事都要做(陳皓注:SDE – Someone Do Everything)、幾乎沒時間編碼。當然,不同的總門有不同的情形,不過,這取決于你的運氣。他們不搞慈善,也不幫扶貧困人群,也不搞社區貢獻,或是其它相似的活動。在那里,他們從來不談這些,或許只有在說笑話的時候才會提到。他們的辦公環境是個灰塵及污跡四處的像農場一樣的隔間,他們在公共區域連一分錢裝修的都不會花,而且,他們的薪水和福利相當差,只是近來與 Google 和 非死book 競爭人才,這個差距才變得非常地小。不過,他們沒有我們有的津貼或額外獎金——他們只是給你錄用信上的那個數字,就這么多。他們的程序代碼完全就是災難,無論什么都沒有任何的工程標準,除了各別團隊有一些。
公平起見,他們的確有套非常非常不錯的版本控管系統,而這是我們(Google)需要盡力趕上他們的地方,他們還有一個漂亮的發布/訂閱系統,我們也沒有相對應的東西。不過,就大體而言,他們有的不過是一堆蹩腳的工具,用關系數據庫來讀取或寫入狀態機里的信息中罷了。我們不應該這么搞就算這樣做是可以。
這就是我所所說的那3件事中的兩件事 Amazon 比 Google 強的,那就是的他們的發布/訂閱系統以及版本控制系統。
我猜你也許會為他們爭辯到——他們要更快更早地推出服務并通過狂熱地迭代來不斷地改進和完善。他們把服務發布的優先級看得比任何事都重,包括工程紀律或是其它一堆可能會讓其花時間的事務。所以,即使這么做讓他們在市場上有了某種程度的競爭優勢,但也造成其他足夠多的問題,總之,這樣的做法算不上是個漂亮的扣籃。
但是,他們有一件事做的非常非常好,其好到可以把其他政治,理念,技術上的消耗和混亂和完全彌補回來。
第二部分
Jeff Bezos 是個臭名昭彰的微管理經理人,他的微管理都管理到了 Amazon 零售網站上的每一個顯示像素。他雇傭了 Larry Tesler——Apple 的首席科學家,他可能是全世界最有名也最受尊敬的人機接口專家,然而,Bezos 忽略了 Larry 三年來提出的每一個建議,直到 Larry 最后——明智地——終于離開了公司。Larry 本應做一些大型可用性(Usability)研究,并可以系統地了解那個根本就沒有人能夠搞懂、使用那該死的網站,可是,Bezos 對于那些像素不放手,這些頁面上的那幾百萬個顯示像素就像是他的孩子一樣。所以,他的這些孩子還留著,而 Larry 沒有。
當然,微管理不是第3項 Amazon 做的比我們好的事。我的意思是,沒錯,他們微控管理做地非常地好,但我不會把這項列在他們的強項清單上。我這樣說只不過是為了我下文做鋪墊,幫助你了解我后面要說的事兒。我們現在要說的這個人,是在多個嚴肅的公開場合說要來 Amazon 工作就應該付他錢才對的人。當有人跟他意見不同時,他會遞出寫有他名字的黃色即時貼以提醒那個人“誰是公司的老大”。這家伙是……,Steve Jobs,我猜。除了沒有品味和設計能力。千萬別誤解我,Bezos 是個絕頂聰明的人,只不過他把那些正常的管控搞得像嗑了藥的嬉皮士一樣罷了。
所以,有一天,Jeff Bezos 下了一份命令。當然,他總是這么干,這些命令對人們來說就像用橡皮槌敲擊螞蟻一樣。這個命令大概是2002年,我想誤差應該是在正負1年內 —— 這個命令發布的范圍非常地廣,設想很大,讓人眼珠子鼓出來的那種,這種驚訝程度和其他的命令相比,就好像突然收到獎金一樣。
這份大命令大概有如下幾個要點:(陳皓注:這里是本篇文章的要點!如果這真是 Bezos 發出來的,那么太贊了,Bezos 完全就是一個系統架構大師啊,那可是2002年左右啊。作者調侃 Bezos 完全是正話反說啊)
- 1) 所有團隊的程序模塊都要以透過 Service Interface 方式將其數據與功能開放出來。(陳皓注:Service Interface 也就是 Web Service)
- 2) 團隊間的程序模塊的信息通信,都要透過這些接口。
- 3) 除此之外沒有其它的通信方式。其他形式一概不允許:不能使用直接鏈結程序、不能直接讀取其他團隊的數據庫、不能使用共享內存模式、不能使用別人模塊的后門、等等,等等,唯一允許的通信方式只能是能過 call Service Interface。
- 4) 任何技術都可以使用。比如:HTTP、Corba、Pubsub、自定義的網絡協議、等等,都可以,Bezos 不管這些。(陳皓注:Bezos 不是微控經理嗎?呵呵。)
- 5) 所有的 Service Interface,毫無例外,都必須從骨子里到表面都要設計成能對外界開放的。也就是說,團隊必須做好規劃與設計,以便把接口開放給全世界的程序員,沒有例外。
- 6) 不這樣的做的人會被炒魷魚。
- 7) 謝謝,祝你有個愉快的一天!
哈哈!你們這群150位前 Amazon 員工,當然能馬上看出第7點是我開玩笑加上的,因為 Bezos 絕不會關心你的每一天。
不過第6點是很真實的,于是,所以人們都去工作。Bezos 并派出了幾位首席牛頭犬來監督并確保進度,領頭的是和熊一樣大的牛頭犬:Rick Dalzell,Rick 是以前是陸軍突擊隊隊員,西點軍校畢業生,拳擊手,和沃爾瑪的首席虐刑官 / CIO,而且他也是個高大、和藹、令人敬畏的人,還是經常使用”hardened interface”詞的人,Rick 本來的走路和說話都比較 hardened interface,所以不用多說,每個人都得干出有重大的進展,這樣 Rick 才能看得見。
在接下來的幾年,Amazon 內部轉變成面向服務架構 SOA (Service-Oriented Architecture),在這華麗轉身的過程中,他們學到了相當巨大的東西。我在的那個時候,世界上就有很多很多的關于 SOA 的學術文檔,但在 Amazon 的那種超大規模的面前,這些東西就好像告訴印第安納瓊斯(陳皓注:電影奇寶奇兵男主角)過馬路前要先看看兩旁有無來車一樣沒用,Amazon 的研發工程師們在這個過程中有了很多很多的發現。下面只是他們發現中的蒼海一粟:
- pager escalation(陳皓注:生產線上問題的尋呼系統)變得比較困難,因為 ticket 可能會轉過來轉過去(陳皓注:ticket 就是處理問題的工單),只到轉了20次,都找到真正能解決問題的團隊和人。如果每一個呼叫都花去團隊的15分鐘的響應時間,那在找到真正的團隊之前幾小時就過去了,除非,你建造出很多很多的腳手架,測量標準和報告。
- 每一個和你的相關團隊突然間都可能成為一個潛在性的 DOS 攻擊者。沒人可以讓事情有進展,直到在每一個 Service 里放上配額(quota)與節流閥(throttling)的機制。
- 監控與 QA 是被統一了。如果你不進行一個大規模的 SOA,你就不會這么去想。但是,等到你的 Service 說,“是的,我還好!”,情況可能是,服務器里唯一能正常運作的功能就就是一個快樂的機器聲音在呼叫你:“我很好,收到,收到”。為了要確認整個服務能正常運作,你需要對每一個部分都去 Call 一下。這個問題會以遞歸的形式地出現,直到你的監控系統能夠全面性地系統地檢查所有的 Services 和數據,此時,監控系統就跟自動化測試 QA 沒什么兩樣了,所以兩者完美的統一了。
- 如果你有上百個 Services,而且你的程序只能通過由這些 Services 來跟其他團隊的程序做溝通,那么,沒有一套 Service 發現機制的話,你就不能找到這些 Service。所以,你得先有一套 Service 的注冊機制,這也是一個 Service。所以,Amazon 有一套全體適用的 Service 注冊機制,以例可以通過反射機制來找到 Service,并知道 Service 的 API,以及是否可用,在哪兒。
- 調試其他人的代碼以調查問題變得非常的難,幾乎都不可能,除非有一套全面性的標準的方式,他可以在可被調試的沙盒里運行所有的 Services。
上面這些只是極少數幾個例子,在 Amazon 在進化的過程中,Amazon 遇到這樣的問題可能一打甚至數百個,Amazon 都一一學習和總結了。對于把 Service 外部化甚至還有很多幾乎沒有人會想的非常生僻的知識,當然,也不會有你想像的那么多。把業務組織成 Service 讓團隊學會了不能相信對方,就如同他們不能信任公司以外的程序員一樣。
當我在2005年中期離開 Amazon 加入 Google 時,這個努力進化的過程還在進行時中,但那時已經相當的先進了。從 Bezos 頒布法令的時間到我離開的時候,Amazon 已經把文化轉變成了“一切 Service 第一”為系統架構的公司,今天,這已經成為他們進行所有設計時的基礎,包括那些絕不會被外界所知的僅在內部使用的功能。
那時,如果沒有被解雇的的恐懼他們一定不會去做。我是說,他們仍然怕被解雇,這基本上是那兒每天的生活,為那恐怖的海盜頭子 Bezos 工作。不過,他們這么做的確是因為他們已經相信 Service 這就是正確的方向。他們對于 SOA 的優點和缺點沒有疑問,某些缺點還很大。但總的來說,這是正確的,因為,SOA 驅動出來的設計會產生出平臺(Platform)。
是的,這就是 Bezos 的法令要達成的目標。他以前(現在也是)一點不關心各團隊是否好,也不關心他們使用什么樣的技術,實際也不去管他們如果動作他們的業務,除非團隊開始把事搞砸。但是,Bezos 比絕大多數的亞馬遜人都很早很早就領悟到,Amazon 必須成為一個平臺。
如果是你,你會想到要把一個在線賣書的網站設計成為一個有擴展性,可程序化的平臺?你真的會這樣想嗎?
嗯,第一件 Bezos 領悟到的大事是,為了銷售書籍和各種商品需要的基礎架構,這個基礎架構可以被轉變成為絕佳計算平臺(Computing Platform)。所以,現在他們有了 Amazon Elastic Compute Cloud(亞馬遜彈性運算云平臺 EC2),Amazon Elastic MapReduce,Amazon Relational Database Service(亞馬遜關系數據庫服務),以及其他可到 AWS aws.amazon.com 查得到的一堆 Service。這些服務是某些相當成功的公司的后臺架構,比如我個人喜歡的 reddit 是這一堆成功公司的其中一個。
另一大領悟是,他知道他們不可能永遠都創造出對的東西。我認為,當 Larry Tesler 說他媽媽完全搞不懂怎么使用那個該死的網站時,Bezos 的某根筋被觸動了,當然,我也也不清楚到底是誰家母親,這無關緊要,因為沒有人的母親能夠會用那個該死的網站。事實上,連我這個在那那工作超過5年的人都覺得 Amazon 網站的接口令人膽戰驚心。
我并不是很確定 Bezos 是如何領悟到的——領悟到他不能創造出一個產品能適用于所有的人。不過,怎么來的這不重要,重要的是他的確領悟了。這種事有一個正式的術語,叫 Accessibility,這是計算機世界中最最重要的事情了。
最!重!要!的!事!
如果你在心里面在想“哼?你是說,像盲人和聾人那種 Accessibility 嗎?”,那么,你不是唯一這樣想的人,因為我已經知道有很多很多像你這樣的人:這種東西對你們這種人來說是不可能有正確的 Accessibility,所以這事你還不能理解。當然,不能理解也不是你的錯,就像眼盲,耳聾,或是其他行動不便的殘疾人,這些也不是他們的錯。當 Software——或 ideal-ware——如果因為某些原因不能被存取或使用,那么,這就是軟件或是那想法的錯了。這就是 Accessibility failure。
就如同生命中那些重大的事一樣, 有一個邪惡的雙胞胎姊妹,它在幼年都受到父母的溺愛,現在它已經成長為同等強大的復仇女神(是的,Accessibility 有不只一個復仇女神),這個復仇女神叫安全性(Security),他們在一些總是爭執不休,冤家一對。
不過,我會和你爭論 Accessibility 要比安全性來的重要多了,因為零 Accessibility 就意為著你根本沒有做出產品來,而如果安全性為零,你仍然還是可以有一個某個程度上成功的產品,譬如說 Playstation Network。
對了,也許你還沒注意到,我其實可以為這篇文章寫出一整本書,很厚的一本,其中填滿了那家我曾工作過的公司里關于螞蟻與橡皮槌的事。但是,我可能就永遠無法發表這短篇的夸夸其談了,而你也就無法讀到除非我現在開始結尾。
第三部分
那三件 Amazon 比 Google 強的中的最后一件事是,Google 很不會做平臺(Platform)。我們就不懂什么是平臺。我們就根本不知道平臺的內涵。你們其中一些人明白,但是你們是少數派。在 Google 過去這六年來,越清楚這一點就越讓我痛苦。我曾有一線希望,來自 Microsoft 和 Amazon,以及近來 非死book 的競爭壓力,會讓我們全體人都清醒過來,并開始打造我們公司的 Service。不是那種特制的或半生不熟的,而是多少和 Amazon 的類似的那種:一次到位,真正的,沒有作弊或是欺騙,并且把它放在最高優先級的位置。
但實際上卻不是,這個事被放在了好像是第10還是第11位,或是第15位,我不知道,反正是相當低。只有少數幾個團隊嚴肅地看待這個事,但大多數的團隊不是從沒有思考過這個事,就是只有一很少的人很鼠目寸光地在看待這個事。
對大多數的團隊來說,只要是讓他們以提供給別人那種可程序化的方式存取他們的數據與運算的方式來開發軟件,就算幾個小小的粗糙的 Service,對他們來說也是翻天覆地。他們大部分人都以為他們在做產品,但他們只是在提供那些凄慘粗糙的 Service。回去看看前面我所列的那些部分的 Amazon 學到的東西,然后告訴我,哪一個粗糙的 Service 能讓你有超凡脫俗。迄今為止,就我所知,一個也沒有。就算是這些粗糙的東西很不錯,不過這就好像要汽車的時候,你卻只有汽車的零件。
沒有平臺的產品是沒用的,再精確一點,去平臺化的產品總是被平臺化的產品所取代。
Google+ 是我們完全失敗的不懂 Platform 最明顯的例子,從最高層的管理層(嗨,Larry、Sergey、Eric、Vic,你們好)一直到最最底層的員工(嘿,你)都沒不懂。我們全部統統都不懂。平臺 Platform 的黃金守則是 Eat Your Own Dogfood(吃你自己的狗食——自己都要用自己的平臺)。Google+ 這個平臺是個懷具的馬后炮。我們在在發布它的時候完全沒有任何 API。我查了一下,目前也只有少得可憐的 API。Google+ 的一個團隊成員在發布 API 時告訴我這個事,我問:“這是 Stalker API(用來偷窺的 API)嗎?”,她郁悶地說“是啊”。我的意思是,我那是是個玩笑話,但是,不,我們提供的唯一的 API 就是取得某人的信息流,所以,我想我把玩笑開到自己頭上了。
Microsoft 知道“狗食守則”至少有20年了。這已經成為他們世世代代文化的一部分了。不能是你吃人類的食物而給你的開發人員們號狗食。那樣做只會是為了短期的成功而掠奪了平臺長期價值。平臺就是要你考慮得長遠。
Google+ 就像膝跳反射,一種短視的的東西,是基于以為 非死book 其偉大產品的成功作出的錯誤判斷。但那不是為什么他們能成功的東西。非死book 的成功是因為他們建立了一個可以讓外界在其上上面開發的產品群。所以對 非死book 對每個人來都不一樣。有些人把全部時間花在“Mafia Wars”上,有些人則是花在“Farmville”(開心農場)。那里還有成百上千個不同的高質量的時間消耗游戲,所以,人們總是可以在那里找到他們想要的。
我們的 Google+ 團隊看了看說:“哎呀,看來我們需要一些游戲,讓我們去找一些人來為我們寫些游戲吧”。你是否開始看到這樣的的思考有多么不靠譜了嗎?問題在于我們試圖預測人們想要什么,然后推出產品給他們。
你不能這么做。真的不能。也不可靠。在這個世上,甚至在整個計算機的歷史上,只有極少數幾個人能夠這么干,Steve Jobs 是其中一個。但是我們沒有 Steve Jobs。對不起,我們真的沒有。
Larry Tesler 有可能說服了 Bezos 相信他并不是 Steve Jobs,但 Bezos 意識到他不需要成為 Steve Jobs 也能提供給所有人好的產品:大家感容易使用的接口與工作流。Bezos 明白他只要有讓第三方開發人員來做的平臺,這些東西自然就會有的。
我要向一些人道歉,這些人會覺得我所說的是再明顯不過的了。是的,的確是巨明顯的。只是我們沒有去做。我們沒有領會平臺,我們也無法領會到 Accessibility。這兩者本來就是同一件事,因為平臺會解決 Accessibility。而平臺就是 Accessibility。
- 是的,Microsoft 領會到了。而且你們也像我一樣知道 Microsoft 他們對這些東西一知半解。那是因為他們能夠了解平臺完全是他們商業上意外性的副產品,是他們一開始的業務就是提供平臺。所以他們在這個領域有著三十多年的經驗。如果你去看看 msdn.com,并多花點時間瀏覽一下,假設你以前從沒去看過,你等著被嚇到吧,因為那里面的東西可是多得不能再多。他們擁有成千成千成千個 API。他們擁有一個超巨大的平臺。說實話,太巨大了,因為他們要霸占一切,但至少他們做了。
- Amazon 也領會了到了。Amazon 的 AWS (aws.amazon.com)相當的驚人。去看看吧,四處點一下。令人羞恥吧。我們今天什么都還沒有。
- 很明顯 Apple 也領會到了。他們做些在基礎上不開放的選擇,具體來說是移動平臺。但是他們明白什么是 Accessibility,并且他們知道如何燃起第三方開發團體的力量,而且他們吃自己的狗食。你知道嗎?他們的狗食做得很好吃啊。他們的 APIs 比 Microsoft 的要干凈不知道多少倍,而且是遠古的時候就這樣了。
- 非死book 也領會到了。這正是讓我所擔心的。這使得我不得我抬起懶惰屁股寫下這些東西。我恨寫 Blog。我恨……Plus(指 Google Plus)不管怎么稱呼它,反正在 Google+ 上發表長篇大論,就算這是個糟糕的地方,但是你還是希望 Google 能成功.我真希望!我的意思是,非死book 想挖我,而且很容易就去了。但 Google 是我的家,所以我堅持我這個小小的家庭干涉,就算你不舒服。
等到你為 Microsoft 與 Amazon 提供的平臺感到神奇后,當然,我想也你可能會被 非死book 嚇到(我不敢去看,因為我不想讓我太沮喪),讓我們回頭看看 developers.google.com 。是不是有很大的差別?我們的這個平臺看起來像是你家小學五年級的侄子搞出來的東西一樣——讓一個小學五年級的他,試著描述一個強大的的平臺公司,如果這家公司什么都有,會整出個什么東西來?
這里請不要誤解我——我知道一個事實,dev-rel 團隊為了發布這些 API 曾經不得不去“搏斗”。據我所知,這個團隊很不錯,因為他們知道什么是平臺,并且他們如英雄般努力掙扎地要做出來,然而遇到的卻是“平臺冷漠”的環境,難聽點是那種有敵意的環境。
我只是在直白地描述出一下 developers.google.com 在外人眼里是什么樣子。它看起來很幼稚。Maps APIs 在哪呢,老天爺啊?其中有有些東西還是實驗性的項目,我點進去看的 APIs……他們都毫無價值。他們很明顯都是些狗食。甚至都稱不上是好的有機食品。跟我們內部 APIs 比起來,他們全部簡直就是豬屎馬糞。
當然,也不要錯誤地理解我對 Google+ 的看法。他們還不算是最差的。這是文化氛圍的事。我們現在做做的簡單來說就是要進行一場戰爭,是一場失敗很多的少數的平臺派和那些強大的信心堅持的產品派的戰爭。
那些從頭到尾明白理解供外部可程序化的平臺概念的團隊都是受壓迫的人——Maps 跟 Docs 團隊浮現在我腦海中,而且我也知道 GMail 是這個方向的先頭部隊,但是他們很難得到資金注入,因為這不是我們文化的一部分。Maestro 的資金完全沒發和 Microsoft Office 開發平臺的資金相比:就像小毛兔和暴龍相比一樣。Docs 團隊知道自己永遠無法和 Office 競爭,除非他們能趕上 Office 的腳本能力,而且他們得不到他們相要的資源。我的意思是我假定他們沒有,現在應用的腳只在電子表格中有,而且沒有為 API 設置鍵盤快捷鍵。在我看來,這個團隊完全沒有被重視。
具有諷刺意的是,Wave 是個偉大的平臺,愿他能安靜地長眠。我們需要知道,做一個平臺并不會馬上給帶來成功。平臺需要殺手級應用。非死book——他們供應了的涂鴉墻和朋友等其他東西——則是 非死book 平臺的殺手級應用。但是,如果你說沒有 非死book 平臺,僅有 非死book 應用也能像今天這樣成功,那么,這會是個一個非常嚴重的錯誤。
你知道嗎?人們總是在說 Google 的傲慢自大。我是個 Google 人,所以我和你一樣當聽到那些話都會覺得很憤怒。但總體而言,我們并不傲慢。我們大約99%不自大。我在文章開頭時就寫到——如果你回去看看—— 我是這樣描述 Google 的“所有的事都做對了”。我們知道人們為什么要這么說我們自大,因為我們沒有雇用他們,或是因為他們對我們的政策不爽,或是那一類的事情。他們推斷出我們自大是因為這樣會讓他們心理平衡一些。(陳皓注:作者在這里的反話正說)
但是,當我們擺出那種我們知道怎么給用戶設計出完美的產品的姿態時,你最好相信我,我們就是笨蛋。你可以說是自大,天真,或是別的什么,無所謂,但最終的結果就是我們干的很愚蠢。因為,這世界不可能有一個產品對所有人都是完美的。
你看,我們的瀏覽器居然不能讓人設定默認的字號。這就是我們對 Accessibility 的公然冒犯。我的意思是,我總有一天會老的,我也會得老花眼,并會變瞎的。我的意思是我不會變瞎,但是如果你到了40歲,你的老花眼讓你看不清近的東西。那么,字號的選擇會成為生和死的問題:某用戶就會被完全排除在產品之外。但是 Chrome 團隊就是這么 NB 傲慢:他們想要開發出無需配置的產品,他們對此相當自豪,去你 TMD 是瞎子還聾子,管你是誰,在你剩下的日子每訪問一個頁面都按一下 Ctrl-+吧。
并不僅是他們。是第一個。問題是,我們是一家“產品”公司,一直一直都是。我們開發的最成功最有吸引力的產品——搜索引擎,那樣巨大的成功讓我們產生了很多定式和偏見。
Amazon 過去也是家產品公司,一道神秘的力量使得 Bezos 領悟到他們需要平臺。那道神秘力量來源于,他們被逐漸蒸發的市值逼到墻角了,不得不想方設法突圍出來。但他當時所擁有的只有一群工程師和他們的一堆計算機……除非他們能變成印鈔機……你可以看到他們是怎么搞出來 AWS 的,而不是像我們 Google+ 一樣事后諸葛亮。
Microsoft 從一開始就是個平臺,所以他們有很多很多的實踐。
非死book:我有些沒看透。我不是專家,不過我很肯定他們一開始也是一個產品,并且成功了很長時間。所以我不知道他們什么時候開始轉變成為平臺的。應該是很久以前的事了,因為他們要成為平臺后,Mafia Wars 這玩意才會出現(而 Mafia Wars 也很老了)。
也許,非死book 只是看一眼我們,就問到:“我們如何擊敗 Google?他們少了什么?”
我們面對的問題非常的龐大,因為我們需要經過劇烈的文化轉變后,我們才能迎頭趕上。我們沒有內部的 SOA 平臺,所以我們外部也沒有。這就是說,我們整個公司都“沒有領會到”:產品經理沒有,工程師沒有,產品團隊沒有,沒人領會到。就算是個別人有,比如你你有,那也相當于沒有,除非我們在生死存亡的時候。我們不能這樣不斷推出產品,并裝作我們以后會把這些產品轉變成迷人美麗的可擴展式的平臺。我們試過了,不行。
平臺的黃金守則,“Eat Your Own Dogfood 吃自己的狗食”,換句話說,“先打造出自己使用平臺,然后把它用在所有的地方”。你不能事后再做,那樣做就太困難了——你去問問那些把 MS Office 平臺化、把 Amazon 平臺化的人。如果你放在后面做,那么你比一開始要花十倍的精力才能做對。你不能作弊,你不能讓內部軟件走秘道去取得特定的優先權限,不為什么,你必需從一開始就要解決這個問題。
我不是說現在做已經太遲了,但我們等的越長,我們就會越接近——“太遲了”。
老實說,我不知道這篇文章怎么收尾。我今天在這里說得太多了。因為這篇文章花了我6年時間。請包涵我言語冒犯之處,包涵我可能誤解了一些產品,團隊,或某個人。也許我們真的在開始做了很多平臺方面的東西,只是我沒看到。我只想說聲對不起。
但是,我們必始在開始時把事做對!
來自: coolshell.cn