加入到互聯網產品行業已經有3年半了，根據我的觀察經驗，凡是一拍系列的項目，成功率不足1%，死亡率平均是50%，成功和死亡之間則是“好死不如賴活著”這么一個不上不下的狀態。如此慘淡的結果，極大促進了流程管理的專業化，各種用研手段，各種競品分析，各種數據挖掘競相攀比，結果呢？成功率可能提升到了5%，死亡率平均降低到了35%……在管理層看來不過是五十步笑百步。

很早很早之前，網易游戲一位不知姓名的高人有句產品畫冊設計名言：無論是5個人的項目，還是500個人的項目，失敗原因多半都出自“沒抓住用戶需求”。這句話的真意是，再怎么專業的流程管理，對成功率的提升都是極有限的。否則那些牛逼哄哄的國際大公司，他們通常有著最精密，最謹慎的項目管理規范，豈不是常勝不敗？屁嘞——還不是一堆爛尾樓。

任何產品的成功都有三個必備要素：
1、產品處于上升期的市場（天時）
2、管理體制與資源支持能促進產品發展，而不是拖累它（地利）
3、產品領導者具備這款產品必備的基因（人和）

三者俱備，談何容易。流程管理最多只能驗證出“天時”，對于“地利”與“人和”均束手無策，對成功率的提升自然有限。但如果連流程管理都不做，恐怕更是一拍系列群魔亂舞。就算拍得不算太離譜，也有兩個后患：首先是初期版本沒抓準核心需求，一出膛就砸了口碑，Web產品的用戶不愿意再嘗試，APP用戶卸載或不再升級。其次是初期規劃的彈性太小，對后期拓展造成很大限制。當然，初期畫個大餅則死得更快……

所以到底是敏捷呢，還是保守呢，見仁見智，根本沒個確定的說法。說白了，這得看人。靠譜的人會根據項目背景，選擇輕盈或是穩重的流程管理，而不是抓住一根教條死不松手。但這個定律在輕應用時代又有轉折，變成一面倒的“敏捷發布為王”。原因很簡單——輕應用的開發時間平均也就6-8周，如果前期準備都要做3-4周，飯菜都涼了。當開發成本低到一定程度，敏捷發布反而是更好的風險控制手段。因為流程管理的保障效果僅僅是“聊勝于無”，卻要耗費大量的時間，開發成本又完全虧得起，不如信賴產品領導者的經驗與直覺。

這時，對PM的信賴感就是實行敏捷發布的關鍵。此外還有三個必要環節，對結果亦有決定性影響。

第一，輕應用比傳統產品更適合敏捷發布，其原因不完全是開發成本低。輕應用本身的定位就是“滿足特定用戶的特定需求”，對目標用戶群的劃分粒度比傳統產品更細，用戶更加典型化而非多元化，降低了用研的難度。

第二，必須有一半以上組員是這款產品的忠實用戶（尤其是PM本人），這比什么用戶模型都他媽的管用。只有強烈的感同身受，才能真正理解用戶，理解應用情景，與用產品畫冊設計戶有更多的共鳴與話題。雖然也可能以己推人過甚，但總比隔岸觀火有效太多。

第三，管理上必須精簡崗位，追求一人多能而不是精細分工（降低溝通成本）；必須以小項目組的方式組織人力，一腳踢飛該死的提單排期（提高產品歸屬）。組內成員最好經過了半年以上的磨合，協作默契，彼此友愛。

綜合以上三點，很容易發現敏捷發布其實與大公司全無緣分。因為大公司壓根就瞧不起“小打小鬧的輕應用”，立項都難；再說人員調度非常不靈活，第二點完全沒保障；第三點更加是鏡花水月。如果遇上授權不充分的部門，層層匯報層層審批，談什么敏捷發布，根本是閹人的春夢。可是越戴著八十斤的鐐銬走路，越容易幻想和鼓吹敏捷發布的美好，卻忘了“人靠譜”即王道——是啊，誰又愿意承認自己不靠譜呢？

所以再看到滿天下的大喇叭放著“敏捷再敏捷”的口號，我就很尷尬。道理誠然不錯，舉著這桿大旗胡作非為的人亦如過江之鯽。我每次一談敏捷，立刻有不少人大聲叫好，有時我好奇去看他們做的產品，額頭汗珠頓時有如泉涌。罷了，就算我不談敏捷，難道他們就不會歪歪扭扭地飛跑起來嗎？誰沒有傻逼的過去，誰不是在三番五次撞墻之后，或許有一天破墻而出。只要能承擔失敗的代價，你就去撞吧，而我自己又何嘗不是如此。

唯一的問題是，如果你選擇了敏捷發布（輕應用）這條路，那就最好不要在公司的項目上去嘗試，不要拿著老板的錢去冒自己的險。另外，絕大多數公司體制也壓根不支持敏捷發布，反而受其拖累。不如找一些志同道合的同伴，組一個小隊，用業余時間自由自在地做點帶感的項目吧——對某個構思真有愛的話就要舍得付出。鄙視那些成天喊著“為什么不敏捷”“為什么不創新”，然后8小時一到準點下班的人，讓公司為自己的魯莽和無知買單，卻不愿意為了公司（和自己聲稱“很投入”的項目）多干兩三小時活兒。