[[128547]]

一個好的產品，一定要有非常給力的工程師在幫忙張羅著產品，也有非常給力的產品尊重、理解、配合技術，這是這次項目給我的一個重要的啟示。作為一名沒有技術底子的產品經理，自慚對研發的深層次架構和技術的理解是淺嘗輒止，這篇文章是對項目研發流程的一些感觸，班門弄斧，權當學習。

［關鍵詞一：不斷演習和優化，弱化需求變更概念］

從1月中旬，當春晚搖一搖的大部分功能初步完成開發的時候，開發側就發起了演習。每周四晚上8點到凌晨12點半，模擬春晚當晚的實際情況進行內部的體驗和測試。演習范圍一開始是項目內相關的幾十個成員，后來慢慢擴展到微信內部的幾百個成員。每次演習都能收集非常多的反饋，演習之后產品和開發跟進修改。值得一提的是，演習過程中，不僅提出bug，還能發現產品設計階段沒有發現的體驗問題，面對這些體驗問題，開發并不會認為是需求變更而厭煩不愿修改，相反，開發們抱著非常開放而且樂意的態度擁抱這些體驗優化。

當然，在開發實現之前，產品也是經過深思熟慮，盡量避免大的產品變更。微信很講究每個產品經理的邏輯思考能力，產品經理講究做出來的東西要讓自己爽，并且要能說清楚什么爽，這樣既能說服設計、開發，也能說明老大。整個春晚搖一搖項目，基本上視覺稿或者交互稿給到老大都能大方向通過。所以春晚的項目后期緊張的時候，有些不是很大的方案，都是先開發，再同步給老大匯報，因為老大的時間畢竟難約。這種情況下，產品先跟開發說清楚情況，開發很能理解，而且當給老大匯報之后方案不用改，那么開發對產品的信任度也就進一步增加了。

有另外一個小細節體現了項目的敏捷。當給測試將需求的時候，測試最關注的是交互邏輯和開發的實現方式，但對wording并不關注，有位測試說：“現在先不關注wording了，誰知道你們產品后面會不會改wording，wording的體驗問題就產品來把關。”這也是一個側面體現對需求變更的包容。但是測試并不是真不關心wording。當測試過程中看到有影響體驗的wording或者錯別字甚至錯誤的符號，測試都會提出來，真是靠譜。

春晚項目的前一周，每天下午一到兩個會議討論細節，每次討論都能初新的問題，每次討論都會引起一些方案的小修改。第二天就是除夕了，前一天晚上都還在改需求。大家通宵達旦，需求版本經過了“最終版”，“最終版v2”，“打死不改版”等搞笑的改名。但開發gg們都挺過來了。只要不是愚蠢的修改，只要有足夠的理由，大家都非常配合。內部有傳統，微信是到上線***一刻都還在改，真不是虛傳。

［關鍵詞二：沒有固定的項目經理］

項目經理，對于軟件工程管理來說是個蠻重要的角色。在很多團隊，項目經理的角色非常重要，因為其把控著開發、設計資源，安排版本節奏，協調人力。有這個角色在，好處在于，涉及多個項目的共搶資源的時候，有人從中做協調；涉及項目進度時，有人從中做把控，以免進度落下。但是這樣，也會導致一個問題，每個環節都涇渭分明，這樣每個環節的人對變更都非常敏感和抗拒，進而導致每個環節的決策時間加長，上升到老大再開工，等到分配資源了再開工，這樣下來，流程就變重了。我們要做的是一個好的產品，而不是一個好的流程。流程是為產品服務的。

在春晚搖一搖項目中，沒有一個專門的項目經理的角色。項目經理都是產品經理或者開發在必要的時刻才兼任的。一開始的項目經理由產品承擔，組織好相關部門來涉及和開發相應的產品。到了后期，進入開發階段，由一位開發負責把握整體的開發進度。到了***關鍵時刻，也是由一位開發兼任項目經理負責同步需求變更。在一個涉及這么多團隊的項目里能沒有項目經理介入，前提是微信的里每個人都非常有主人公精神，每個人保證做好自己的事情，跟上整體進度，并整合其他資源，將自己的資源也告知別人。因此整個過程中，項目經理最主要的任務不是跟進進度、分配資源，而是同步信息，保持各位信息的統一，以便做重要決策。

［關鍵詞三：不僅開發配合產品，反之亦然］

在春晚前，2月12號，微信做了搶紅包的預熱活動。當時正值搶紅包大戰剛開始興起，支付寶在前一兩天開始搶紅包活動。當微信2月12日做了搶紅包活動之后，輿論一片傾向于利好微信。說這個這紅包大戰中贏的是微信。當時很多人不知，微信這個搶紅包活動只是春晚前的牛刀小試，對于內部而言，***個目的是預熱，還有一個意義在于提前為春晚做更大范圍的真實演練。一開始有人提出更大范圍的演習這個想法的時候，內部有些人其實有顧慮。但是更懂開發的老大決定還是要做這次真實的演習，做得好，演習也是一次預熱，一次好的產品嘗試。后來事實證明，他的這個決策是正確的。

達成要做演習預熱的目標之后，產品圍繞演很深思熟慮地想了蠻多方案，既要能夠驗證業務邏輯，又要能到達到預熱的目的讓用戶體驗爽。這兩個目的顯然有點多和干擾涉及。后來，我們決定用微信一貫的思維，從用戶出發，產品怎么樣最爽怎么樣來，不管它是不是肩負研發的目的。經過了幾版方案之后，最終選擇了最簡單的產品方案，只做紅包預熱，不做其他互動方式的預熱，也不為這個預熱活動做更多的互動方式，就簡單地搶紅包，搶幾分鐘。刺激用戶最爽的點，玩法簡單。

終于，2月12日的搶紅包活動較***地完成了任務。從這個例子來看，從研發目的出發的需求也能做成很好的用戶需求。

從研發流程線學習到的東西，歸根結底是“人”。書上多少“需求變更”、“項目管理”的理論，在實際操作中都被證明是錯的或者不必要的，所以上面我總結的關鍵詞也將會在某種情況下變成錯的。只有有志同道合人組成的團隊會在試錯中不斷制造驚喜。