開發往事:深度講述2010到2015,微信一路風雨的背後
http://www.52im.net/thread-290-1-1.html
研發的擔當、格局、視野
前言
微信作為當前國內移動端最成功的明星應用,一直被各界高度關注,作為即時通訊開發者同行,微信的成功,同樣無時無刻不在被解讀、研究,以期從中獲得相應的啟發和收穫。
作為當初微信iOS客戶端3名開發之一,本文作者將從技術人員的角度分享2010年到2015年這段時期內微信背後的故事。
第一章 創世紀
微信的成功,讓我相信:沒有什麼是不可能的。
2010年後,廣研的發展到了一個瓶頸期,郵箱的佈局已經相當完善,閱讀空間也已到了強弩之末,那年最大的興奮莫過於郵箱漂流瓶,一個簡單的功能,卻讓郵箱的活躍使用者翻了一番。
團隊要發展,但巧婦難為無米之炊,一時之間不知道可以做什麼了。於是那段時間發生了一個不可思議的事情,團隊第一次對未來的發展方向做了大的規劃,規劃很巨集大,計劃做一個產品矩陣,包括郵箱、閱讀、儲存、記事本等,基本上把團隊幾年之間嘗試過的產品重新做了梳理,每一個都將是一個獨立的門戶,從一個產品內的四個功能變成四個產品。
而10年的移動網際網路正處在爆發的前夜,團隊當然對這個發展趨勢早有佈局,郵箱早在08年就開始佈局移動端產品,從最初的wapmail到後來的塞班版客戶端,手機開發團隊在10年也逐漸成熟起來。
當時確定的四大產品方向,除了郵箱外,其餘三個都沒有移動端,但都做了規劃。由於手機開發團隊規模的限制,如果我沒記錯的話,當時只啟動了一個新產品的開發--記事本,而且只是在ios平臺試錯。當時手機開發團隊大部分人都是做塞班系統的開發,而ios和android作為新生的智慧手機平臺,它的重要性不言而喻。但那個時候ios和android平臺作為新平臺開發者相當少,開發團隊只能臨時拼湊,ios團隊是從公司其他部門轉崗過來的兩個做windows客戶端的同事,android是從塞班團隊抽出來一個同事招了兩個實習生開始幹起來的。
2010年10月,一個產品的釋出在網際網路行業一石激起千層浪:kik messenger,這個應用有多火?它直接導致2011年成千上萬的類kik應用被研發出來,這其中就包括後來大紅大紫的微信、米聊、line和kacao。
kik messenger的火爆源於它的極致簡單跨平臺,它是為移動而生的應用,幾乎不花任何力氣就在很短的時間基於手機通訊錄建立起自己的關係鏈,這對於很多web2.0時代的sns應用來說,是不可能做到的。很短時間內,它就以席捲一切的氣勢開始革命,首當其衝的是各國的運營商們,這個跨平臺跨國界的手機通訊工具,它可以在不同的手機終端實現文字圖片的訊息溝通,秒殺簡訊和彩信體驗,它的體驗之極致,甚至讓當時的手機巨頭--黑莓--在自己的手機平臺封殺它。
在kik甫一出現之際,小龍就預見它的火爆之勢。小龍當時給pony發了一封郵件談這個事情,並申請廣研團隊做一個類似的應用出來。而pony也極為讚許,併為這個應用起了一個名字--微信。
當時做了一個多月的記事本立即停止,開始投入微信的開發中,很多程式碼直接複用過來,目標只有一個:快。
就這樣,十個人的微信團隊又一次在沒有任何經驗的情況啟動了一個試錯的專案,這次是三個平臺(ios、android、塞班)同時進行。
而據說當時公司還有其他團隊也在同時做類似的事情,且團隊要強大的多,人力豐富有經驗。但是,廣研的小團隊文化,為了取悅自己的巨大信念,使得廣研微信團隊能夠在幾個團隊中脫穎而出,第一個完成了產品開發,只用了不到四個月時間,在2011年1月21號於ios平臺首先發布了它的1.0版本。
在11年初的春節期間,當pony第一次使用微信並給出“體驗很贊”的評價時,微信團隊的信心達到了前所未有的高度。
但,此時,廣研的其他同事卻並不看好這個體驗簡單到有些簡陋的手機應用。
第二章 衝出重圍
微信的成功,除了團隊的努力,時機的把握也很重要。
11年2月,新年伊始。上一年年底的興奮似乎已經逝去,微信在經過一個春節的討論之後,嚐鮮的人開始散去,只有很少的同事還在用著這個應用,因為那個時候有ios和android智慧手機的同事還很少。微信並沒有像kik那樣在很短的時間積聚大量的使用者。
當時大家普遍不看好這個簡單的應用。理由大致是:功能太簡單了;qq會殺死所有的類kik應用--它只要做一個手機客戶端。公司當時正在忙活著微博大戰,雖然有幾個團隊同時在做類kik應用,但公司內對這些應用的關注並不高。
但是公司的高層對這個應用還是寄予重望的,開年第二天,tony親自過來南方通訊大廈給微信團隊打氣。而且,我們也能明顯感覺到小龍已經把注意力完全轉移到這款手機應用上面。
2月底,harvey突然找到我,直接了當的問我:要不要過去微信做客戶端?然後又解釋說:過去微信團隊只是暫時的,如果產品做不成,還是要回到閱讀空間團隊繼續做下去。
當時我很糾結,在機器學習和資料探勘上剛剛找到感覺,放棄它很是不捨。harvey讓我考慮後再答覆他。
我沒有想太久,那天下午就答覆了harvey:我去。
2011年3月1號,正式加入微信團隊,成為ios客戶端的第三個開發工程師,進小黑屋。
當時ios開發團隊的andy給了我兩本書,《objc基礎教程》和《ios3.0開發技術大全》,讓我在一週內看完第二週參加開發。
雖然從來沒做過客戶端開發,但是我一直覺得客戶端開發沒什麼難度,況且我鑽研計算機學科最難的課題--機器學習和資料探勘--有一段時間了,普通的開發工作對我來說真是小菜一碟的事情,harvey當時也對我說:客戶端開發只要上網找找資料學習一下,和同事討論一下就可以解決大部分問題了。
確實沒錯。
我兩天就把兩本書翻了一遍,接下來的幾天開始閱讀程式碼,andy的程式碼還是比較容易讀懂的,我在一個本子上畫了兩天流程圖基本搞清楚了底層的大部分邏輯。在第一週的最後一天,我寫了一個ios的“hello,world”。
第二週開始,從一個小需求開始,一點點堆積objc程式碼。一週下來,也是相當的純熟了。於是接下來就參與了一個後來頗為重要的功能的開發--群功能。
在3月份,接連發了兩個版本,但是使用者資料依然不見起色。
很快,我們在4月初又發了第四個版本,這個版本微信的四個tab位置被確定下來,最初的四個tab分別是:微信、通訊錄、找朋友和設定。其中,找朋友這個tab可以看出當時微信的急迫,在這裡,系統通過通訊錄聯絡人、qq好友、qq郵箱聯絡人甚至企業域名郵箱聯絡人等多種關係鏈給你推薦好友,以期在很短的時間內能夠積聚到使用者。
但,使用者資料依然不見起色。
另外一款應用的火爆引起了我們的注意:talkbox。這個發語音短訊息的應用有著與kik類似的邏輯,但語音無疑是最大的亮點。類似的功能qq很早就做過,但一直不溫不火,但是當它被放到手機上之後,瞬間捕獲了大量的使用者。
另外一方面,智慧手機在這個時候開始高速普及,尤其是iphone4的釋出,以革命之勢席捲了整個手機市場。
小龍判斷:智慧手機和pc是完全不同的,基於智慧手機平臺的功能和pc上也是完全不同的。
也是從那個時候開始,團隊就一直在挖掘手機平臺的各種可能,不斷嘗試利用手機天然的能力做出極致簡單且自然的功能。
很快,我們決定要做語音。問題來了,團隊沒有做過多媒體的經驗,語音需要的編解碼能力如果等著公司相關部門支援,怕是一個月也未必搞得定。當時我自告奮勇要求去搞語音引擎,雖然有信心,但內心很虛,一方面從來沒有接觸過語音編解碼,另一方面,小龍和harvey判斷使用者對流量很敏感,我們要做到比talkbox更小的流量(三分之一的流量)但卻要一樣的品質。
兩天後,我發郵件給小龍:搞定了。那是我在廣研做過的最有成就感的事情,估計那個時候小龍內心一定默唸:吶尼!但這絕不是最後一次。類似的事情很快又一次發生在2.5版本的視訊功能上,同樣的要求(whatsapp四分之一的流量)編解碼只用了四天時間,那次我通宵了兩晚,並且在旅遊的時候還在寫程式碼,一時之間成為團隊笑談。
其實我只是把開源專案做了適配,在ios上跑了起來,內裡邏輯並沒有太花時間去理解,我知道,專案的速度很重要,先完成再理解。後來很多的專案都是在這樣的情況下完成的。
經過一個月的努力,微信2.0語音版終於在5月初發布了(這是正式第一版本,之前的版本都加了beta)。當我們看到使用者資料一柱擎天的時候,很久以來壓抑在團隊頭上的石頭開始粉碎。
接下來的發展,我們一直在追趕當時另外一個很火爆的類kik應用--米聊。我們當時從米聊的賬號分配演算法可以估計到他們的使用者量,然後與自己的使用者量做對比。但其實,我感覺大家並不擔心米聊,以我們的產品研發速度和公司的使用者基數,超越米聊是時間問題,大家真正擔心的,是同門的另一個應用--QQ。
但,作為一個處在生存期的應用,必須一個假想敵來超越(這也算是廣研做產品的一個潛規則吧),那就米聊吧。
當時使用者對微信、米聊甚至talkbox,感覺是差不多的,大家都在談論著這三個應用誰抄襲誰,後來米聊做了塗鴉功能,他們的同事在知乎發表文章,說靜等微信抄襲。
微信給的答覆是8月初的2.5版本,除了那個我通宵兩夜的視訊功能外,那個版本最大的驚喜莫過於附近的人。可以這麼說,語音版奠定了微信的基礎,但真正讓外界感受到微信強大的,是附近這個功能。
當附近的人釋出的時候,相信很多人有這樣的驚歎:微信原來有這麼多人在用啊!
是的,我們很快甩開了所有競爭對手。
當國慶節那天我們釋出搖一搖的時候,微信的地位已經是似乎無法撼動了。
但是,我們的擔心還在,那個內心的幽靈一直揮之不去,團隊依然崩的很緊不敢鬆懈。
本章結束。
另外多說一句:微信的“彈性工作制”也是從那個時候開始的,以前廣研的作息最晚不過10點,從微信2.0之後,通宵會經常出現。
第三章 平臺化
朋友圈和公眾號是偉大的發明。
文字、圖片、語音和群是微信作為通訊工具的基礎,附近的人和搖一搖則進一步擴充了通訊的範圍,向社交演進。到這個時候,微信已經是一個相當完備的移動通訊應用。
朋友圈是必然的。
QQ郵箱作為pc端僅次於QQ即時通訊工具的第二大通訊工具,它向社交的演進是受限的,因為使用者上網交流的主場景不在郵箱,所以QQ郵箱選擇從閱讀切入社交,它遇到的困難遠大於qzone。
而微信是移動端上網聊天的主場景,使用者在移動端的主要活動聚集地,它天然的適合做社交,所以,微信有朋友圈是必然的。
朋友圈的成功有兩個基礎。
其一是閱讀空間在社交領域三年的浸淫,讓團隊對社交有了比較深入的理解。
其二是超強的團隊執行力。
第一點在前面閱讀空間的文章中已經說的比較多了。主要談談第二點,朋友圈的整個研發過程耗時4個月,投入的人力不超過十個,但卻在這短短的4個月時間內,團隊完成了完整的30多個版本的開發迭代,我們形象的把這個開發過程叫做迴轉開發流程,每天上午,開發團隊通過郵件接收產品經理整理出的下一個版本功能點啟動開發,傍晚的時候把功能交付給小龍和產品經理,他們在晚上就當前版本討論分析,然後在下半夜給出新的想法甚至方向,產品經理在天剛亮的時候把想法細化為一個個功能點發郵件給開發。周而復始。
當團隊決定要釋出朋友圈的時候,我想大家已經到了極限了,因為那時候還有bug沒有解決,小龍說:bug也是一種文化,就發了。
朋友圈釋出前,小龍和harvey打了一個賭,他們賭三個月之後的朋友圈日發圖量的規模,小龍認為可以達到1000萬,harvey覺得是200萬。這個問題的答案我就不說了,各位可以自己去猜。
朋友圈的體驗,相信很多人已經再熟悉不過了。咋一看他和facebook沒什麼區別,都是一個訊息timeline的體驗,但是用過一段時間後,你會發現本質的不同。朋友圈延續了微信的雙向好友關係,沒有向二度關係擴散,把使用者隱私保護作為設計的基礎,你在微信中無論是聊天還是曬命,都是沒有任何壓力的。
當然,朋友圈的體驗還有很多體現產品情懷的細節。但保護隱私我覺得是最key的設計點。之後,微信內其他的任何功能,雙向好友關係是設計的底線,不能逾越。
那麼,在微信內看到的都是好友的資訊,怎樣看到更多豐富的內容呢?這就回到了閱讀這個命題。
這次給出的解決方案是--公眾號。
關於公眾號的話題,我打算在之後談及微信商業化的時候再詳細展開,我覺得它是一個潘多拉盒子。
2012-2014年的移動網際網路,朋友圈和公眾號的影響力相信大家都看到了。在它們出現之前,微信是一個成功的產品,在它們出現之後,微信成為了一個平臺,在公司的戰略中,它真正成為了一個與qq並駕齊驅(甚至領先)的雙引擎之一。
2011年,微信有語音、附近的人、搖一搖;2012年,微信有朋友圈和公眾號;接下來呢?
商業化和國際化。
有幸參與了微信從一個成功的產品演進為一個平臺的過程,更慶幸接下來的兩年裡全程參與了微信的商業化程式,這又是一次學習與探索的歷程,這段時間接觸的人和事,各種感受給了我極大的衝擊。
這段時間比較忙,更新無法保證及時,也沒有時間雕琢,寫的比較粗糙。最後奉送一個小故事作為收尾吧。
朋友圈本來是打算在2012年春節前釋出的,團隊一直繃的很緊堅持到春節前兩天,在那天發生了兩件事情,第一件事情是兩位核心開發同事因為一點小事吵了起來,整層樓都聽到了他們的怒恐。第二件事情是當天晚上我們團隊去給一個同事送行(請假回家過年),全部人吃飯到10點還沒回來,老大們急壞了,以為我們罷工了。這兩件事情,最後給我們帶來兩個好訊息,其一是年前不用釋出了。其二是年後經過更加密集的迭代,有了一個更完美的朋友圈。
就這樣吧。
第四章 商業化
微信的商業化佈局在2012年底就已經付諸行動了。當時的討論範圍非常廣泛,支付、卡券、微生活、微電商、遊戲等等都經過很多的討論,這個大討論牽涉了公司內幾乎所有的bg和部門。
討論是發散的,但執行是聚焦的。
微信商業化是三層架構:最底層是微信的社交平臺,它聚集了海量的使用者,這是商業化的養分;第二層是開放公眾平臺,它連線所有的主體(服務和內容提供方),這是商業化的土壤;第三層是業務,包括遊戲、支付業務、廣告、O2O、電商、企業、硬體等,這是商業化的收成。
微信商業化從啟動以來的這兩年,在這個框架下逐步展開。
這個框架是非常清晰明瞭的,邏輯也比較簡單,並無特別。但是與其他大的平臺相比,執行起來卻差別很大,我覺得百度強於技術、阿里強於商業、QQ強於運營,而微信強於產品,這就必然導致幾大平臺走出不同的商業化道路。
在微信的商業化決策中,一直還是以產品需求為導向的。小龍和團隊討論任何的商業化專案,主題一直是圍繞著使用者的需求展開的,戰略、戰術、競爭等等不會成為焦點。
問題來了。
商業是喧囂的,不去吆喝怎麼做生意呢?但是微信是使用者的家園,是不能容忍喧囂,尤其是,微信一直堅守為使用者構建一個舒適的環境,沒有干擾、沒有隱私暴露、輕鬆可信賴。要在維護這個環境的前提下做商業化,難度是很高的。在C與B的博弈中,微信是傾斜於C的。
小龍在設計微信的過程中,提煉了很多的準則。除了上篇文章提到的不可逾越雙向好友關係之外,有另外一個準則最能解釋微信的各種商業化設計。
微信內的資訊是和使用者相關的,不是系統推送的。
這個準則延伸出去,有很多的結論。比如,不要做過度的活動推廣,不要誘導分享,不要誘導關注,資訊流要清晰,資訊流突出好友等等。
這條準備保證了:微信是使用者的,微信不是商家的,微信也不是微信團隊的。使用者開啟微信,期待看到的是自己關注的資訊,自己好友的訊息,而不是系統推薦的不痛不癢的資訊。
當然,這條準則不是強制性的,它是強制建議性。商業化是一個複雜的課題,有很多意想不到的事情。有一些重要的合作伙伴,他們提供關鍵的資訊給微信使用者,但需要微信給他們提供入口作為條件。微信在可控的前提下,提供了一些這樣的入口,不過這些入口的收效卻甚微。這就從另外一方面佐證了這個準則的正確,系統推薦的資訊使用者不待見。
但是,遵守這條準則執行起來很難很難。
其一,執行團隊很難找到合適的B端一起參與專案開發。使用者接收的資訊流往往是需要B端角色一起參與,微信要求他們提供優質的內容,但是能夠提供優質內容的B端很少,所以微信的B端運營規則顯得很嚴,打壓很厲害。
其二,微信商業化專案的設計很難。一般都會引入好友關係,會通過加強使用者參與互動把功能做起來,但是這些功能無論怎樣設計,都會太接近朋友圈,朋友圈在這裡成了一個過不去的坎。團隊在幾個領域的專案中進行了幾十次的迭代嘗試,最終沒有一個能夠通過驗收。
2014年,團隊在電商、O2O、服務等領域做了很多的嘗試,但是很少有專案能夠達到滿意的效果,真的是舉步維艱。這一年,團隊是在挫折中學習與探索。
不過,還是有一些成功的專案的。
遊戲是第一個商業化專案,也是目前最成功的一個商業化專案。2013年的飛機大戰打響了微信商業化的第一槍。
飛機大戰這個小遊戲多說一下,它和我的關係忒大了。
最初小龍只打算做一個坦克大戰的動畫作為5.0的啟動頁,不過那會我開小差在玩遊戲引擎,順便就做了一個飛機大戰的demo。小龍看了之後覺得不錯,讓我們嘗試把它做的更完整更有意思一些,於是我拉了一個小團隊開始做這個事情,我們奮戰了一個多星期,幾乎每天都通宵的節奏做了四個不同的版本,美術、音效、玩法經過激烈的pk迅速換了一遍又一遍。我們甚至做了商業化的策劃。
飛機大戰的穩定性是很關鍵的,因為每一個使用者啟動微信都會先玩這個小遊戲,如果出問題,所有使用者就進不了微信了,當時我的領導甚至對我說,如果穩定性有問題,你可以捲鋪蓋走人了。
經過小夥伴們一個月的努力,最終飛機大戰獲得了不錯的效果。那年回家,一路上聽著不斷的“求求求”的槍聲,還是挺過癮的。
上篇文章我提到過,公眾號是一個潘多拉盒子。最初我覺得公眾號是為了解決在微信上閱讀的需求而設計的,它的訂閱-推送模式說明了這一點。(我想,是不是小龍覺得團隊太久沒有閱讀都變low了:)但是,公眾號設計成一套訊息系統,使得它擁有了無限的可能性,我又想到小龍很早之前提的統一通訊的理想,公眾號的設計我覺得是在完成這個理想。
從最初解決閱讀的媒體訂閱號,到後來連線一切的服務號,公眾號給微信開了一個好大的口子。整個中國為這個小小的號沸騰了。但是團隊一直以做優質平臺為目標,兩年多以來一直在非常謹慎的探索中為平臺增加能力,節奏顯得很慢,內外的質疑聲越來越大,大家都不看好公眾平臺的商業化價值。
直到,團隊在公眾號的最下面開了一個口子,嘗試做效果廣告。這是一次成功的試驗,效果超乎團隊預期。優質的內容充分展示了它的商業價值,也更加堅定了團隊做好優質的決心。微信廣告團隊一直沒有以提升收入作為目標,團隊通過不懈的學習與探索,堅實基礎,努力把自己打造為最優質的效果廣告平臺,為使用者提供有價值的資訊。
微信商業化的故事一篇文章是寫不完的。面向未來,各種挑戰層出不窮,單純的試錯法也面臨複雜問題的挑戰,底層社交平臺也面臨發展的挑戰,公眾平臺面臨很多競爭對手對規則的挑戰。後面的壓力會越來越大。
但是,有兩樣東西還在:正確的方向和團隊的激情。我相信,我們還是可以做的更好的。
-- 全文完 --
相關文章
- 微信後臺開發作業講解
- 從MySQL到POLARDB, 三位CTO講述遷移背後的故事!MySql
- 我們的20年 | 講述雲安全背後的故事
- 微信小程式開發精講微信小程式
- 《一念逍遙》團隊成員講述遊戲開發、上線背後故事遊戲開發
- 微信支付大規模前端開發背後,如何用外包解決困境前端
- android仿微信表情雨下落!Android
- 天貓精靈、小度背後的智慧音響江湖,同樣腥風血雨
- xjbz京東電器攜肖戰獻上賀歲大片《後背》,講述冠軍背後的守護故事
- 微信後臺開發實戰教程
- 微信小程式開發風口下,微信小程式該如何運營?微信小程式
- 騰訊首部帕金森病紀錄片,講述醫學AI背後的故事AI
- 網易·世嘉·CA 為您講述《全面戰爭:三國》代理背後的故事
- 蘋果軟體工程師講述“安全碼自動填充”功能背後的故事蘋果軟體工程工程師
- 天刀手游上線,團隊講述背後的武俠江湖故事創作
- 微信支付商戶系統架構背後的故事架構
- TDengine Contributor 鍾宇講述 TSZ 壓縮演算法最佳化背後的故事演算法
- 風雨過後見彩虹:救園成功
- 蘋果和微信大搞創意精品的背後,是什麼發生了變化?蘋果
- 一句話講明白 WebAssembly、微前端等技術背後的核心Web前端
- "Hello World"背後的風險分析
- 基於後端雲微信小程式開發後端微信小程式
- Spring Boot 開發微信公眾號後臺Spring Boot
- 149、風雨
- 微信開發系列之一 - 微信公眾號開發的開發環境搭建開發環境
- 微信小程式開發之https從無到有微信小程式HTTP
- 執行uni-app到微信開發者工具APP
- 《聖女戰旗》發售一週年,製作組講述遊戲開發的幕後故事遊戲開發
- Python開發微信公眾號後臺(系列二)Python
- 微信公眾號開發-後端demo(隨錄)後端
- 微信開發-微信網頁開發-授權多次回撥網頁
- 微信開發之微信域名防封介面
- 微信開發1 (接入微信)
- 微信小程式開發系列六:微信框架API的呼叫微信小程式框架API
- 微信小程式開發框架從入門到放棄微信小程式框架
- 開發微信小程式的作用微信小程式
- 西安微信開發方案
- PHP微信支付開發PHP