大清早的，看了左耳朵耗子的《開發團隊的效率》，一百萬個贊同。從產品經理的角度來說說“產品小團隊”。

去年底，蟬小隊并入攜程。那時我們有3RD/2PM/1UI，產品團隊一共6個人，做蟬游記/蟬游畫報/蟬游攻略這3款產品。后面兩款很快停止維護。

就在最近的6-7月，我同時做攜程周末大版本迭代，生辰大版本迭代，蟬游記小版本迭代，即將發布的玩票新App，剛剛立項的正式新App(全套原型定稿)，一共5款產品，你猜猜蟬小隊的產品團隊增加到幾個人？

7個人，上周剛來了一位Ruby工程師。

攜程其他部門的人跟我說，太羨慕蟬小隊的研發速度了。我們的產品團隊人數多3倍，速度慢3倍。

你沒聽錯，3X3=9倍。

說說我的看法。

1、
我打死不加產品經理，就我和策策兩個人。兩個人不僅可以同時推進以上5個項目，策策還在搞自己的玩票App原型，我還在幫另外兩三個友商友情重構產品原型(產品性饑渴)。

大家都知道，品相好的產品汪數量極少。一旦產品汪的需求不夠精煉，從根子上就摧毀了整個項目研發效率。所以我不加人，我和策策自己扛，加班就加班。

不僅如此，我倆還兼職做所有產品的QA呢。

2、
UI設計師，一個就夠了。

以前我設過2位UI設計師，很快發現喂不飽……總是有人閑著沒事干，我還得為他們專門想點任務出來做。而且2位UI設計師必然有主有次，誰是主誰是次呢？在超級扁平化的蟬小隊，我很不愿意設主次之分。

后來一位UI離職，我索性不補人了，另一位UI頂住……她果然就頂住了。蟬小隊特別適合獨立，傲嬌的人，也就是和我個性相似的人。

我知道很多缺氧傻逼這時要嚷嚷起來了，黑心老板壓榨員工。你媽逼，我司UI妹子幾乎從來不加班。

缺氧傻逼繼續嚷嚷，上班時間排得太滿，不給員工學習充電的時間。

你知道新浪微博有一個功能叫“拖黑”嗎？

3、
基本上，1后端/1iOS/1Android客戶端的研發配置就夠了。

因為后端太重要，不希望Quake是唯一瓶頸，所以近期又有一位Ruby工程師加入。

iOS工程師兼H5與Web端研發，Android工程師同時也會iOS研發。

研發速度像風一樣快。

攜程其他部門的產品汪向我吐槽，說我改一個列表頁，就要通知4位工程師，他媽的我只是改一個列表頁的信息展示方式啊。4位工程師都得我來通知到位，解釋清楚，漏任何一個人，上線出了問題就讓我背黑鍋。他媽的我只是調一下列表頁的顯示順序和內容元素啊。

這件事情在蟬小隊怎么處理呢？我把一條任務寫在Tower上，指派給iOS工程師，然后他QQ群里跟后端工程師說一聲，幾小時后API改好，iOS工程師也很快改好，在Tower上勾掉任務，通知我去測試。當天內解決。

這時候很多缺氧傻逼又要嚷起來了，舍不得花錢加人，黑心老板壓榨員工。你媽逼，我司工程師最近一年加班的天數估計不到2周。

從我對攜程團隊的觀察來看(我一直當自己是雇傭兵而非攜程員工)，這并不是工程師能力的問題，而是技術管理風格導致。攜程也有很多很好的工程師，但分工一旦細致起來，你只做模塊A，他只做模塊B，大大束縛了工程師的發揮。人數增加首先大大提升了溝通成本，其次大大拉低了責任心，因為“共同負責”嘛，總能找到推諉的理由，也時常被豬隊友氣得撒手不管。

4、
熟悉我的人都知道，我堅持PM兼任QA，也就是不設專職QA。

我自己創業3年多，身體力行，產品只出過一次上線后緊急打補丁的大bug(注冊環節測漏掉了)，Crash率低于iOS端千分之一，Android端千分之三。

這件事說起來太細，總之，我證明這是能做到的。少一個QA環節，增加的故障率是能容忍的，卻大大減少了溝通成本。

但QA在大公司是必須的，攜程主App的穩定性完全依賴于QA來保障，PM兼QA，也只是在體量不到千萬的獨立App才能實現。

缺氧傻逼繼續嚷，黑心老板壓榨員工……等等，這家伙自己就是老板兼PM？好吧，不可能再找到另一個像你這樣自虐的人了。

第一，我司另一只產品汪策策也兼QA，所有產品由我和他輪流測試兩次。第二，很多人想學習我的產品能力，為什么不能同時學習我這種“一肩背”的產品態度呢？何必葉公好龍。

5、
一邊寫這篇文章，系統一邊彈新浪微博的評論消息。有不少反對意見，說小團隊不是萬能的，不能解決所有問題。

這不是廢話嗎……

對于不到百萬日活，不算特別大研發量的中小產品來說，小團隊是最佳配置。

走小團隊的路數，有三個前提。首先得有一兩個熱愛小團隊的核心人員來驅動，比如我和Quake，比如左耳朵耗子。

其次，這樣的核心成員對進度管理得有實權，能容忍磨合過程中，短時間的進度損失。比如我曾經把整個項目停下來一兩個月，工程師學習新的開發語言。

最后，還得控制好產品需求，如果根子上出了問題，就別談什么效率了。做什么都是錯的。

我在微博多次發表和效率有關的幾個觀點，羅里吧嗦的，最后重復一次吧。

任何產品，至少50%的需求對成敗是無影響的。包括錯誤的方向，錯誤的設計，以及并沒有錯但是然并卵，僅僅是設計者自我陶醉的細節。我做了8年產品經理，還是只能將有效需求控制在50%這個比例上，其他人更是可想而知。多做有效需求，少做無效需求，研發效率翻著倍地提升。

我還有一個“少兩成”理論，即工程師的研發時間永遠都應該比產品經理(第一稿)的需求少兩成，逼著他去精簡需求，挑出最重要最緊急的需求來，即便對我這樣的老手也是如此。就在昨天，我還哭喪著臉跟工程師說，好好好，趕檔期，這個功能先不做，那幾個功能壓到1.1版本，胸口跟插了兩刀一樣痛……

但這是對的。

Quake有句名言，任何功能多拖幾個版本，很可能產品經理自己就不想做了。因為前面幾個版本已經驗證出來這是無效需求了。

總之，提高效率的終極方案是“砍需求，砍人頭，控制版本節奏”。砍需求減少無效研發，砍人頭減少溝通成本，而版本循序漸進，分批驗證設計更加是金科玉律。“再招幾個人”的應對思路總歸是下下策，解決一時的進度，卻帶來長久的內耗。產品團隊人招得越多，則研發效率越低，產品經理扎堆更是無人可破的黑魔法，中招必死，死相難看。