純銀：產品小團隊

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

去年底，蟬小隊并入攜程。那時我們有 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 有句名言，任何功能多拖幾個版本，很可能產品經理自己就不想做了。因為前面幾個版本已經驗證出來這是無效需求了。

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