一、一人一個團隊時期

我加入大眾點評的時候，我所在的事業部剛剛分拆出App的業務線，剛好我是這個事業部的第一個iOS開發。所以當時的情況是一個人一個團隊，而且只在點評這一款App上開發，版本迭代的節奏基本上就是我自己的開發節奏，因為只有一個人，PM們對我充滿了無盡的respect和dependency。那時候很累，我基本上很少晚上9點之前下班，週末很少雙休，而所有的這一切都是自願的，儘管沒有調休沒有加班工資，所以，雖然累，但自己還是樂在其中，尤其那種被PM、QA包圍的感覺，滿滿的存在感。

二、第一次制定App開發流程規範

點評App的每個版本的計劃，什麼時候開始，什麼時候結束提交App Store，沒有規律可循。有時是個大版本，時間就長一點，我們業務就可以多做一些需求，趕上小版本時，沒辦法，砍需求吧。後來，隨著業務不斷的擴充套件，人數不斷的變化和增加，而iOS團隊和Android團隊，也慢慢變大（3～5人）。之前我一直覺得新興業務，業務變更很正常，要知道我在第一家公司時，有一半的需求做了就壓根沒上，所以我對PM大多持“放水”的態度。令人頭痛的是，隨著PM團隊的變化，不同的PM，不同的需求風格，需求變更變得更加頻繁與肆無忌憚。有時候需求評審時，PRD不再是我想要的樣子，草草的文字描述或者簡單的截圖就想讓RD幹活；而後端團隊對於APP的計劃時間點也並不是那麼敏感，介面進度常常會delay我們開發；因為這種環境下做出的產品，業務邏輯充滿了模糊和不確定，下游的QA團隊對我們的抱怨越來越強烈；在這種背景之下，我深深體會到，是時候需要將PM、RD、後端、QA、設計等團隊拉到一起聊一聊了。經過各方的一番“激烈”爭論，最終我們形成了一套針對我們業務的移動開發流程規範，明確了在什麼時間點，各方該做什麼事，具體如下：

 這個規範的最終形成，並不順利，經過一次改版最終形成。其中針對PM的需求變成，我們還另外製定了一套需求變更流程規範，為了讓這個需求變更規範發揮它的作用，特此讓團隊大老闆拍板同意，最終執行。

三、美團App和點評App雙平臺作戰

第一次制訂出流程規範後，App的需求開始步入正軌，我們經過幾個版本的迭代之後，生活的“幸福指數”不斷攀升。然而，好景並不長，美團點評合併之後，業務的不斷調整和變化，最終我們業務需要同時維護開發點評App和美團App，進行雙平臺作戰，而且此時PM也換了一撥。要知道，美團App的移動迭代大流程以及版本計劃，和點評完全獨立，我們試圖用之前點評的流程去同時開發雙平臺，發現不斷產生迭代混亂，暴露了問題也越來越多：

（1）PM想做一個需求，點評和美團雙平臺都要做，PM該何時提需求？該怎麼提？是點評提一次，美團再提一次？

（2）而且雙平臺同時迭代，開發一下子會開發很多需求，到QA介入環節，往往只有幾天，測試資源顯得十分緊缺；

（3）我們業務剛起步，PM收集需求時，需求本身也具有一定的模糊性和不確定性，有時是業務老大們拍板必須要儘快上線的，有時突然來自第三方必須跟最新的版本上線，而最新的版本需求評審已經過去了。意味著，我們需要給PM的需求留有一定的空間；

針對這個問題，我曾經嘗試過，PM有需求就提給我，我把每個需求的所需要的資源明確後，再分給團隊RD去開發，這樣既簡單，有高效，後來慢慢發現，我根本無法從眾多的需求之中脫身，對應的android團隊，QA團隊也不贊成。經過不斷的摸索，中間甚至還經歷過雙週迭代。後來，經過總結，我發現，眼下的問題到底在哪裡？

（1）PM拿到需求時，往往自己也無法完全明確所有的條條框框，只有有一點是明確的，這個需求必須要上。而RD要開始開發一個需求時，也必須是明確的；很多團隊RD常常對我抱怨，我們應該在需求評審時，不明確的需求統統斃掉到下個版本再評審。一線的RD是無法體會業務的壓力的（我曾經帶領團隊開發一個美團專案，放下所有的流程規範，無條件上最新的版本），要知道美團的版本一個版本差不多一個月就過去了，像我們這種面向大眾的業務，趕上暑假節假日，你這不是要PM命麼？PM不跟你拿生命去戰鬥才怪。

（2）下游的QA團隊他們，只希望留有足夠的緩衝時間，讓他們去測試，不要一下子在短時間過來大量的需求；

（3）一線開發的RD希望，到自己手上的需求是明確的，不能充滿不確定性，模糊性，視覺後端等資源也要明確；

針對這些問題，我們乾脆遮蔽掉點評和美團的各自的需求開發迭代節奏，不再遵循點評或者美團的流程，我們只需要關注App的提測和釋出時間點即可。讓PM有需求就每週提一次過來，如果評審通過（PRD明確），就加入需求池中，如果需求所需要的資源明確之後，我們直接從需求池中移除，分配給對應的RD去開發；這樣，慢慢地再一次形成了新的一套開發節奏，我整理了如下：

自從需求按周迭代之後，PM固定每週一給我們提需求，給PM留下了“空間絕後”的靈活與方便。自此，我們和PM團隊之間的延續很久的鬥爭，第一次降到了最低，這個迭代流程目前一直執行到現在，目前運轉良好，直到現在。

四、總結

有人讀完此文，也許會產生共鳴，很多人經歷過“混亂”的團隊。當然，這個過程並不易，中間有RD因不堪忍受選擇了離開了團隊。自此，我也意識到，流程規範的變動，儘量讓一線RD收到的影響最小，尤其是我們這種經歷公司合併，業務變動頻繁的團隊。當然，能夠堅持留下來並且並推動團隊走向完善，首先，你得有一顆積極向上、充滿信心、樂觀並且擁抱變化的心。