最近產品行業流傳“唯快不破”四字訣，這話我是信的，只有實際執行的資料才能提供最可靠的指引。所以資料來得越快，方向就走得越準。敏捷釋出，小步快走這些道理都是網際網路產品專案的真理。問題是，單單從一個“快”字延伸出去，很容易唱一曲“愛拼才會贏”，6X12，甚至6X14 之說大有市場。
加班並不可怕，至少我自己不怕加班，而且是習慣性每天多做幾小時。過去五年的歷史記錄有兩個，一是連續半年以上每週工作 70+小時，另一個是帶隊報導車展的時候，連續四五天，每天工作16+小時。但正因為我加班很有經驗，才對6X14持以異見。更直接點說，我不贊同把加班作為整個團隊的一條口號，一種工作常態。
第一，產品專案以設計與開發為主，加班若要加出效率來，行政命令是沒有用的，只能靠“質樸的熱情”，即對專案有著發自內心的認同、喜愛與緊迫感，然而擁有這種熱情的人終歸是少數。讓多數人陪著少數狂熱者加班，會造成多數人的效率下降，狀態疲憊。我們常見自上而下的以己推人……因為自己著急，就覺得所有人都該著急；因為自己全身心投入，就覺得所有人都不怕犧牲；可惜多數人的加班工時與進度收益之間並不成正比。
第二，有很大一部分工作，並不能靠加班來顯著地推進，比如寫出優質的程式碼，設計細膩的互動與精巧的演算法，策劃有創意的活動等等。簡單來說，凡是腦力活動劇烈的工作，都要求在良好的精神狀態下進行，才能保證質量。這就牽涉到第一條——部分人由於被迫加班，狀態疲憊，不僅工作效率下降，質量也滑坡得厲害。可能是趕了兩週工期，最後反而給專案帶來更多的損失。
第三，產品專案中的每個工種都有農忙、農閒的時候。比如策劃階段，工程師的事兒就不多；到了開發階段，設計師又得以清閒一段時間。調研和設計完成之後，我會建議PM休幾天假放鬆一下，接下來，測試和釋出階段就得拼拼老命。因此將6X12設定為一種工作常態，這未免也太變態。我不止一次聽見(其他公司)有人抱怨說，自己的活兒早就幹完了，但下班後不準走，得留下來隨時待命。這又是何苦……
前些日子，有件關於加班的事情讓我印象深刻。我這邊有一位資深工程師調換了部門，在新部門裡升任主管職務，然後常常加班，累得夠嗆。之前不論我怎麼激勵整個團隊，也很少見到他加班，現在卻是主動大量地加班，任勞任怨。看來我以前對他“不願意加班”的看法完全是個誤解。這個例子說明質樸的熱情往往來源於自我驅動，自己給自己設定目標，安排任務，“這是我的事情”。如果你的目標和任務來自上級，則驅動力大打折扣，“那是你的事情，我去幫你完成”。
可惜，強有力的自我驅動是件極為罕見的事情。有些人覺得自己不在其位不謀其政，有些人過於看重階段性的物質獎勵，有些人特別在乎自己的私人空間，有些人對專案的認同感始終提不起來，還有些人乾脆對這份職業的投入度都不高。我在類似問題上困擾多年，積攢了幾條經驗：首先精簡團隊，至少是精簡核心小組，參與(主持)專案的人越少，則歸屬感越強，不容易互相推卸責任。其次，核心小組要得到足夠的授權，讓他們感覺在做 “我的事情”而不是“你的事情”，至少保證核心小組的自我驅動力。最後，我這個主管也要以身作則地加班，起到表率作用。
換個角度來看，加班對於產品成功真有那麼重要嗎？
最近恰好見一位豆瓣的朋友，問，你們加班多嗎？答，一到19點辦公室基本上就空了，早上通常是10點後才來上班……
這當然不能阻止豆瓣是一款好產品。
我在微博上說過一句話：2週一次小迭代，和3週一次迭代沒有本質區別。產品勝出不會因為你每個版本的迭代都比別人快一週，而是你的判斷更準確，設計更有效，實現更細膩。過度強調快快快，不僅令員工疲乏，也容易做不好產品減法。因為你能加班嘛，反而有更多工時去做次要需求。
我們都知道，產品並不是功能越多越強就越有競爭力。你拼命加班，飛快迭代，釋出各式各樣的型號版本，把自己搞得雞血沸騰，但最終決定勝負的並不是速度，而是精度。拿我很欽佩的Instagram舉例子，至今不開發Android版也不去完善網頁端，平均一兩個月才更新一個版本，不到一年使用者數已經突破了 700萬大關！故而產品的理念與方向，比速度與激情更重要得多——但我看國內很多團隊就知道抄，東抄西抄，自己的想法很少，就算有想法也往往是“抄這家” “抄那家”的貪多求全。這樣的6X12，6X14又有何意義呢？真沒見過幾款產品單單靠“抄得快”“抄得全”就能成氣候。勤不僅不能補拙，還有可能造成設計過度與產品失衡，結果越補越拙……
所以把6X12作為一句招聘提示，提前警示“有時候會非常忙哦”，這是沒有問題的。但如果真心誠意這麼執行下去，員工天天個個加班，時時刻刻線上，則一聲嘆息。從團隊管理的角度上來講，對市場與使用者群的研究，尤其產品理念神馬的過於飄渺，依賴超強的個人產品素質，無法用管理手段來衡量與促進，只好不得已而求其次，採用“加班”這種簡單可量化的競爭手段。此法有效但不可濫用。
原文：壞脾氣的小肥