移動媒體研發(fā)的9條教訓

0 評論 2954 瀏覽 0 收藏 15 分鐘

編者按:本文作者方軍,跨界于內(nèi)容與技術, 移動互聯(lián)網(wǎng)從業(yè)者?,F(xiàn)任現(xiàn)代移動數(shù)碼 CTO ,公司旗下有 iBloomberg 彭博商業(yè)周刊、iWeekly 周末畫報、iArt 藝術新聞等知名移動媒體應用。

在技術團隊辦公區(qū)整面墻的白板上一直寫著三組詞:Breaking Things(打破事物)、Clarity(清晰)、Simple (簡單)。這是 2013 年年中寫下的,這是對整個產(chǎn)品技術團隊的期許,其中首要、也最重要的是,隨時準備“打破一切”。

從“打破一切”開始,記錄一下過去兩年多的在內(nèi)容與技術間跨界的 9 條體會與教訓,是的,多數(shù)都是教訓。

1. 樂于“打破事物”,永遠不要害怕“打破事物”

“Breaking Things” 的想法冒出來是現(xiàn)在的項目從零開始進行到差不多一年半之后。因為在之前,我們已經(jīng)拋棄了自己的那些需要被打破的東西,每天橫沖直撞就是在打破那些別人舍不得打破的。經(jīng)歷十多年互聯(lián)網(wǎng)的轉型,雖然不是數(shù)字原生代,我們已經(jīng)逐漸了解隔段時期就必須忘掉所有的“經(jīng)驗”。

但今年年中突然有一天,我們發(fā)現(xiàn)自己也不自覺地期望減少改變,擔心看似正常運轉的系統(tǒng)因為調整出現(xiàn)問題。當看到我們自己開始被害怕技術的正常調整帶來負面影響時,我們意識到害怕打破的雜草已經(jīng)在埋下種子,而選擇開始打破,打破我們自己所積累的過去:代碼模塊可以被拋棄和替代,沒有希望的產(chǎn)品可以被放棄,可以拋棄原來的常規(guī)建立新的系統(tǒng),在調整中容許犯下錯誤、犯下大錯。

“打破事物”是艱難的,放棄已有的東西,是和人的常規(guī)心理相違背的?!按蚱剖挛铩笔瞧D難的,當飛機還在地面上組裝時,出點問題也不怕,但是,某個階段之后的打破卻是“在飛行中換引擎”。

2. 結構比細節(jié)更重要

結構的選擇比細節(jié)的選擇更重要?;蛟S因為角色不同,我比較傾向于從結構的視角去考慮問題,而很多時候不得不用把眾人的注意力拉回結構選擇。

把注意力放在細節(jié)上是非常容易有安全感的,做選擇的人會覺得一切在他 / 她的可控范圍之內(nèi),從而形成一種虛假的安全感。而結構的選擇是不能給人安全感的,因為這時的選擇明顯受到大環(huán)境的影響、需要很多人達成共識,沒人能有掌控感。

這就是有趣的地方,結構的選擇實際上會給人更大的掌控感,但在此過程中卻人人都缺乏它。人不會相信想象的事物,直到真正地看到它;當我們看到它時,結構已經(jīng)被細節(jié)隱藏起來了。

“產(chǎn)品經(jīng)理”這個概念這幾年已經(jīng)遠遠超出了互聯(lián)網(wǎng)行業(yè),深入人心,但特別多的人把它想成” “交互細節(jié)”,這是對它極大的誤解。細節(jié)是可變的,結構才是穩(wěn)定不變的。比如,功能特性都是細節(jié),是隨著時間不斷變化的,而接口才是結構,它應該是相對穩(wěn)定的。

3. 簡單

我們常常無法選擇最簡單的,有各種各樣的原因阻攔我們做到這一點,其中最大的原因是懶惰。因為懶惰,我們不愿意多痛苦一步;因為懶惰,我們?nèi)淌芨鞣N讓系統(tǒng)變得復雜的雜亂事項;因為懶惰,我們用復雜的方式去達成目的。最終,由于懶惰,我們事后付出更多的氣力。

“簡單”被提起經(jīng)常是從設計的視角出發(fā),從產(chǎn)品與技術的角度出發(fā)還可以有新的認知。任何一個技術系統(tǒng),都是要持續(xù)運行與維護的,如果在開發(fā)階段想盡一切辦法達到簡單,那么就自然地減少了后續(xù)成本。簡單,才是可持續(xù)的。真正優(yōu)雅的方案,也都是簡單的。

要始終相信有簡單的選擇存在于某種,然后努力去找它。委員會式?jīng)Q策或相互妥協(xié),從來不能走向簡單;只有愿意放棄自己的看法、選擇能找到的最佳方案,才可能走向簡單。

4. 快速

快速就是對的。2012 年初,看到 Facebook 辦公室的幾條口號之一是,“Code Wins Argument”??焖倬褪牵灰褧r間浪費在爭論上,用具體的代碼、產(chǎn)品來驗證對錯。不是花時間在爭論,而是直接用實現(xiàn)來驗證對錯。

在互聯(lián)網(wǎng)業(yè),我的感受是一個季度等于其他領域的一年;而在移動互聯(lián)網(wǎng),一個月相當于其他行業(yè)的一年。在互聯(lián)網(wǎng)之初有本書叫“21 個狗年:我在亞馬遜的日子”,狗的一月相當人的一年。

移動互聯(lián)網(wǎng)時代,我們每個月過的都是“一年”。之前一年的很多具體的產(chǎn)業(yè)洞察、技術能力、技術實現(xiàn)、產(chǎn)品功能,現(xiàn)在都已經(jīng)變得毫無意義。用這樣的“一年”來理解,能最好地解決快速的問題:沒有人會花一年的時間來爭論,是吧?

5. 在自建與集成之間平衡

在技術領域里面,一項功能是自行開發(fā)、還是采用已有的通用技術產(chǎn)品,這是個問題。

我們在自建和集成之間來回轉,有些選擇了集成,但最后發(fā)現(xiàn)某一天幾乎把所有的集成過來的全部拋棄,有些選擇了自建,但后來發(fā)現(xiàn)采用通用服務更簡單快捷。這個選擇,可能是一個持續(xù)調整的過程,改變并不是說明之前選擇的錯了。

自建,則可以構建一體化的整體效果,集成,則可以快速達到目標。一般而言的原則是,核心的業(yè)務,應該盡量采取自建;而非核心的,則采用通用產(chǎn)品。 關于這一點的補充原則是,只自建那些有長期價值的、會長期開發(fā)和升級維護的特性。對那些一次性、日拋型(月拋型)的特性,可以考慮直接否定掉。

這種一方面這樣、另一方面怎樣的原則,往往聽起來沒什么價值,但在工程領域就是這樣,絕對的原則往往脫離工程領域的實際情況。

這一看似模糊的事項成為我們自認為需要記取的教訓,是由于對它的體會貫穿于每一天,它讓我們更好地理解工程原則。有這種工程方面的考慮,是因為我們從一開始就訂立了平臺化開發(fā)的路徑,因而具體產(chǎn)品和背后的工程化體系是并重的。

6. 持續(xù)地重建

重建,如果用開發(fā)的術語講,是“重構”。對于技術團隊來講,需要一段時間就重構代碼,也包括重構整個產(chǎn)品結構,以保證代碼不會在持續(xù)開發(fā)、增加功能過程中變得不可維護,從而由資產(chǎn)變成負債。 樸素地講,重構,就是通過梳理調整,始終保持代碼是資產(chǎn),因為,可維護的代碼才是資產(chǎn),可運行的代碼不一定是。

在移動互聯(lián)網(wǎng)方面,代碼的過時速度(特別是客戶端部分的),遠快于互聯(lián)網(wǎng),這使得重構必須縮短時間間隔。過去,我們常常會把代碼留給下一撥人去解決(多數(shù)時候他們會罵代碼很差,有時選擇自己從零開始重寫),在移動互聯(lián)網(wǎng)時代時間快到只能我們自己解決問題。

在產(chǎn)品特性方面,也需要不斷地重建。一個又一個新版本,可能是表面上沒什么變化,但實際上必須是根本性的變革。這種變革,需要放棄許多之前投入了資源的特性,可能需要做出更艱難的舍棄。重建是必須的,否則,產(chǎn)品在生長的過程中會逐漸失去活力。

7. 早集成、早測試、早把產(chǎn)品推向市場

早集成、早測試、早把產(chǎn)品推向市場,早比晚好。豐田式精益(lean)生產(chǎn)有一條核心原則就是,早把問題暴露出來,以便更早解決。比如,發(fā)現(xiàn)問題,“任何人”可以停下整個生產(chǎn)線的設計,就是把問題暴露出來??粗届o的水面,我們常會不自覺地估計水面下也是平的、很安全,降低水位把石頭露出來,就可以強迫我們面對問題、解決問題。

在開發(fā)的過程中,盡早把各個模塊集成,可以發(fā)現(xiàn)模塊之間的那些空隙;盡早把產(chǎn)品推向用戶,可以在實際試運行過程中發(fā)現(xiàn)產(chǎn)品設計問題;盡早正式運營產(chǎn)品,可以通過市場來實際檢驗對產(chǎn)品的諸多假設。

沒有“更早”,是過去幾年的最為慘痛的教訓。麻煩的是,等到發(fā)現(xiàn)沒有“更早”的教訓之時,這是為數(shù)不多難以彌補的教訓。

8. 關注核心數(shù)據(jù),永遠別自我欺騙

找到那些真正有價值的核心數(shù)據(jù),關注這些數(shù)據(jù)的變化,永遠不要自我欺騙。數(shù)據(jù)統(tǒng)計分析系統(tǒng),常常是最后一刻才想起來要做,實際上,它應該是整個項目規(guī)劃時就重點投入的功能特性。

數(shù)據(jù)沒那么復雜,沒什么大數(shù)據(jù),一個簡單的數(shù)據(jù)圖表就可以解決問題。如果用簡單的數(shù)據(jù)表不能理解,那么談什么大數(shù)據(jù)只是空談。

在《精益創(chuàng)業(yè)》中,作者提到一種“虛榮指標”式的自我欺騙,其中主要提到的是累計用戶量。移動應用上最大的虛假繁榮正是累計下載量,實際上我們都知道,沒有持續(xù)回來的用戶,不過是過客,再多的過客都不過是個數(shù)字而已。

9. 建立技術人主導的團隊

最后,或許也是最重要的,以移動互聯(lián)網(wǎng)為主要業(yè)務的公司,應該建立技術人主導的團隊。至少在產(chǎn)品開發(fā)方面,應該建立技術人員主導的團隊,而不要把工程師看成沉默的程序員。 只有技術人員主導的產(chǎn)品技術團隊,才是健康的、能長期發(fā)展的,因為技術是現(xiàn)在所有變化的核心源頭。

強調技術驅動很容易講,但真正做的公司與團隊,應該很稀少。有很多種說法,工程師不懂戰(zhàn)略也不理解戰(zhàn)略,出于中國教育原因工程師不懂產(chǎn)品,出于不再一線工程師不懂需求這些不過是他人用來試圖掌握主導權的說法而已。

和所有人一樣,技術人員也有長期養(yǎng)成的思維慣性,比如有的人喜歡考慮所有的可能情況,導致他設計的解決方案過于復雜;有的人比較容易妥協(xié),導致他接受并不正確的方案;有人常傾向性地選擇自己熟悉的技術方案,而不愿意嘗試新的。這是別的領域也存在的人性。

另一方面,技術人員有一種常見的慣性是有價值的,技術人會更傾向于建立 “ 能長期運行的系統(tǒng)”,“長期”意味著在設計時已經(jīng)考慮了它的長期價值,“系統(tǒng)”意味著會考慮它的方方面面、特別是那些縫隙;“運行”意味著最終的交付成果一定是運轉的“活”系統(tǒng)。

如果可以回到過去,這里教訓就是,給每一個工程師更大的技術產(chǎn)品主導權,并為產(chǎn)品技術團隊爭取更大的主導權。

最后的話

2011 年年中,重新打開編程工具持續(xù)地做開發(fā)。之前有很多年只是修修補補或者偶爾學學新的編程語言與技術。再之前,是作為媒體人與編輯做針對文字媒體的工作,以及帶領一支較大的互聯(lián)網(wǎng)內(nèi)容與產(chǎn)業(yè)團隊?;仡櫰饋?,過去兩年多時間,全部的注意力都在產(chǎn)品與技術,從產(chǎn)品戰(zhàn)略、到技術系統(tǒng)、到產(chǎn)品體驗、到代碼細節(jié),事無巨細,埋頭苦干。目標很簡單,就是希望借移動互聯(lián)網(wǎng)的機遇,用技術產(chǎn)品來發(fā)現(xiàn)移動互聯(lián)網(wǎng)究竟給內(nèi)容帶來什么。

這一過程還在繼續(xù),移動互聯(lián)網(wǎng)的機遇之窗才剛剛開了一個小縫。但如果復盤看,幾乎每件事都可以有更優(yōu)的選擇,反思是為了更好地抓住移動內(nèi)容機遇。

 

來源:36kr

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發(fā)揮!