那些年小步快跑的日子 (EP1)

離開大陸互聯網公司一段時間後，最近重新開始接觸台灣軟體公司的產品開發模式，對於步調的落差有些感觸。趁著還有記憶，簡單記錄一下記憶中『快速迭代』，『小步快跑』的產品開發模式，以及對於『試錯』的感想。

快速迭代 —  一週一版本

與「專注、極致、口碑、快」七字產品心法其中的快相呼應，小步快跑的關鍵在於能執行『快』。

體現到團隊的執行上，『快』考驗的是研發 / 測試團隊的執行能力。為了快，執行時間壓縮的極短，對應的就是高強度工作環境，在高強度的工作狀態下首先付出的代價必然是高工時，另外，考驗的還有團隊在高強度執行下能撐多久。

一週一版本的產品時程節奏大概是這樣設計的：

週一是需求評審會議，由 PM 提出產品需求，研發及測試團隊評估可行性以及時程估算。

週三前 PM 輸出需求文件，UX 團隊輸出 UI Design，週四研發團隊開始實作。一週後的週三下班前提測，週五下班前概率發佈初版。按照這個節奏每週疊加在一起後，就演變成每週五發佈一版本。表面上看起來美好，實務上一個比較明顯的問題在於最新提測版本與新版本的需求實作時程是重疊的。還有一個變因是用戶運營會帶進用戶回報的問題，以用戶為中心的思維下，此類問題通常需要額外發 bugfix 版本修正。在這些條件下，除了要求研發與測試能力足夠強大外心理素質也必須高於一般人。

試錯也要有方法

小步快跑與試錯是並行的，在互聯網產品的世界裡，應該有一個假設是沒有完美的產品，每一個版本都是一個 beta 版本，所以我們需要根據數據以及用戶反饋持續更新迭代產品。因此在互聯網產品中試錯是必須也是合理的，但重點是必須快速試錯改正，但不能反覆試同樣的錯去浪費團隊能量。

PM 通常有需要持續產出需求的壓力，因此斷續會出現一些荒謬的邏輯，提出一個薄弱需求時無法完整論述動機與背景也無法 defend 需求，最後只能說出『就試試看啊。』這樣不負責任的陳述。

PM 的一個很大的能力是要能抓準需求，一個是能夠提出用戶真正剛需的，次者能提出一個改善用戶使用體驗的，或者能提出讓用戶感到爽的需求。 一般能提出這三種需求都相對容易 defend，這類需求通常有足夠用戶反饋當支持立論或是有產品數據為基礎。否則在這種高壓的開發模式下，研發與測試團隊願意為你試錯的機率極低。

產品數據為迭代依據

2014 年第一次接觸到大陸互聯網產品時，給我帶來最大的衝擊的是當時大陸同事對於產品數據的深刻解讀理解以及對於產品細項數據的思考模式。對比過去在 PC 時代開發的 Windows Application，根本完全是矇著眼睛在做事，甚至當年在台灣某知名手機廠也從未根據數據去發想需求以及改進產品(其實根本連數據都沒埋)。

以產品留存率以及 DAU 這兩個基本數據來說，每一個明顯的數據變化必定能推測出原因背後的意義。而就留存與 DAU 這兩點來說還可以再細分子功能留存率以及子功能 DAU，再往下是功能點擊來源，功能離開出口，功能持續使用時長等。要能推測出數據變化原因，PM 必須有能力預先將相關數據埋點一並在產品需求中提出。

小步快跑與試錯的基礎就是產品埋點數據，如果 PM 無法在需求規劃階段就思考好埋點數據的意義，最後通常都是小步快跑然後跌倒。

順帶一提，過去曾經有大陸主管跟我說：每個人個體都是一個產品，也需要不斷迭代，根據數據不斷更新自我。包含執行的過程本身也是一個需要不斷迭代改進。

結論

坦白說，台灣的開發模式步調確實是較慢的。原因也許是大陸互聯網產業競爭激烈，不快就被取代，也可能是我們就喜歡追求安定與小確幸。也許沒有對錯，可以說是選擇問題，能夠平靜的工作又能存活與賺錢當然是最好。

每種開發模式或方法有其衍生動機與設計目的，但總會有臨時不按原訂規則的時候，重要的是這些突來的變化必須是根據足夠強烈的數據基礎而更動或是完整的調研論述，否則一旦規則變形，後面的團隊框架就很有可能逐漸分崩離析。尤其最可怕的是演變成隕石式開發模式。當年在大陸互聯網產業時就曾經因為商業收入原因而不斷有直接來自高層的需求把什麼小步快跑，試錯拋在腦後。

另外一個重點是，上述開發模式的維持還必須在產品整體數據是在持續向上或持平的條件下，否則無法維持團隊長期高強度的工作狀態。

記得最近讀過一篇文章提到，當團隊有接近的目標感與相似價值觀時，不需要太多規範，也不需要太多會議 Sync，更不需要什麼專案開發方法。每個人都會自動自發超乎預期產出。但這種團隊可遇不可求。