最近产品行业流传“唯快不破”四字诀，这话我是信的，只有实际运行的数据才能提供最可靠的指引。所以数据来得越快，方向就走得越准。敏捷发布，小步快走这些道理都是互联网产品项目的真理。问题是，单单从一个“快”字延伸出去，很容易唱一曲“爱拼才会赢”，6X12，甚至6X14之说大有市场。
加班并不可怕，至少我自己不怕加班，而且是习惯性每天多做几小时。过去五年的历史记录有两个，一是连续半年以上每周工作70+小时，另一个是带队报道车展的时候，连续四五天，每天工作16+小时。但正因为我加班很有经验，才对6X14持以异见。更直接点说，我不赞同把加班作为整个团队的一条口号，一种工作常态。
第一，产品项目以设计与开发为主，加班若要加出效率来，行政命令是没有用的，只能靠“质朴的热情”，即对项目有着发自内心的认同、喜爱与紧迫感，然而拥有这种热情的人终归是少数。让多数人陪着少数狂热者加班，会造成多数人的效率下降，状态疲惫。我们常见自上而下的以己推人……因为自己着急，就觉得所有人都该着急;因为自己全身心投入，就觉得所有人都不怕牺牲;可惜多数人的加班工时与进度收益之间并不成正比。
第二，有很大一部分工作，并不能靠加班来显著地推进，比如写出优质的代码，设计细腻的交互与精巧的算法，策划有创意的活动等等。简单来说，凡是脑力活动剧烈的工作，都要求在良好的精神状态下进行，才能保证质量。这就牵涉到第一条——部分人由于被迫加班，状态疲惫，不仅工作效率下降，质量也滑坡得厉害。可能是赶了两周工期，最后反而给项目带来更多的损失。
第三，产品项目中的每个工种都有农忙、农闲的时候。比如策划阶段，工程师的事儿就不多;到了开发阶段，设计师又得以清闲一段时间。调研和设计完成之后，我会建议PM休几天假放松一下，接下来，测试和发布阶段就得拼拼老命。因此将6X12设置为一种工作常态，这未免也太变态。我不止一次听见(其他公司)有人抱怨说，自己的活儿早就干完了，但下班后不准走，得留下来随时待命。这又是何苦……
前些日子，有件关于加班的事情让我印象深刻。我这边有一位资深工程师调换了部门，在新部门里升任主管职务，然后常常加班，累得够呛。之前不论我怎么激励整个团队，也很少见到他加班，现在却是主动大量地加班，任劳任怨。看来我以前对他“不愿意加班”的看法完全是个误解。这个例子说明质朴的热情往往来源于自我驱动，自己给自己设定目标，安排任务，“这是我的事情”。如果你的目标和任务来自上级，则驱动力大打折扣，“那是你的事情，我去帮你完成”。
可惜，强有力的自我驱动是件极为罕见的事情。有些人觉得自己不在其位不谋其政，有些人过于看重阶段性的物质奖励，有些人特别在乎自己的私人空间，有些人对项目的认同感始终提不起来，还有些人干脆对这份职业的投入度都不高。我在类似问题上困扰多年，积攒了几条经验：首先精简团队，至少是精简核心小组，参与(主持)项目的人越少，则归属感越强，不容易互相推卸责任。其次，核心小组要得到足够的授权，让他们感觉在做“我的事情”而不是“你的事情”，至少保证核心小组的自我驱动力。最后，我这个主管也要以身作则地加班，起到表率作用。
换个角度来看，加班对于产品成功真有那么重要吗?
最近恰好见一位豆瓣的朋友，问，你们加班多吗?答，一到19点办公室基本上就空了，早上通常是10点后才来上班……
这当然不能阻止豆瓣是一款好产品。
我在微博上说过一句话：2周一次小迭代，和3周一次迭代没有本质区别。产品胜出不会因为你每个版本的迭代都比别人快一周，而是你的判断更准确，设计更有效，实现更细腻。过度强调快快快，不仅令员工疲乏，也容易做不好产品减法。因为你能加班嘛，反而有更多工时去做次要需求。
我们都知道，产品并不是功能越多越强就越有竞争力。你拼命加班，飞快迭代，发布各式各样的型号版本，把自己搞得鸡血沸腾，但最终决定胜负的并不是速度，而是精度。拿我很钦佩的Instagram举例子，至今不开发Android版也不去完善网页端，平均一两个月才更新一个版本，不到一年用户数已经突破了700万大关!故而产品的理念与方向，比速度与激情更重要得多——但我看国内很多团队就知道抄，东抄西抄，自己的想法很少，就算有想法也往往是“抄这家”“抄那家”的贪多求全。这样的6X12，6X14又有何意义呢?真没见过几款产品单单靠“抄得快”“抄得全”就能成气候。勤不仅不能补拙，还有可能造成设计过度与产品失衡，结果越补越拙……
所以把6X12作为一句招聘提示，提前警示“有时候会非常忙哦”，这是没有问题的。但如果真心诚意这么执行下去，员工天天个个加班，时时刻刻在线，则一声叹息。从团队管理的角度上来讲，对市场与用户群的研究，尤其产品理念神马的过于飘渺，依赖超强的个人产品素质，无法用管理手段来衡量与促进，只好不得已而求其次，采用“加班”这种简单可量化的竞争手段。此法有效但不可滥用。