IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

唯快不破?

坏脾气的小肥 2011-08-03 13:30:16 累计浏览 1,468 次
本机暂存
    最近产品行业流传“唯快不破”四字诀,这话我是信的,只有实际运行的数据才能提供最可靠的指引。所以数据来得越快,方向就走得越准。敏捷发布,小步快走这些道理都是互联网产品项目的真理。问题是,单单从一个“快”字延伸出去,很容易唱一曲“爱拼才会赢”,6X12,甚至6X14之说大有市场。

    加班并不可怕,至少我自己不怕加班,而且是习惯性每天多做几小时。过去五年的历史记录有两个,一是连续半年以上每周工作70+小时,另一个是带队报道车展的时候,连续四五天,每天工作16+小时。但正因为我加班很有经验,才对6X14持以异见。更直接点说,我不赞同把加班作为整个团队的一条口号,一种工作常态。

    第一,产品项目以设计与开发为主,加班若要加出效率来,行政命令是没有用的,只能靠“质朴的热情”,即对项目有着发自内心的认同、喜爱与紧迫感,然而拥有这种热情的人终归是少数。让多数人陪着少数狂热者加班,会造成多数人的效率下降,状态疲惫。我们常见自上而下的以己推人……因为自己着急,就觉得所有人都该着急;因为自己全身心投入,就觉得所有人都不怕牺牲;可惜多数人的加班工时与进度收益之间并不成正比。

    第二,有很大一部分工作,并不能靠加班来显著地推进,比如写出优质的代码,设计细腻的交互与精巧的算法,策划有创意的活动等等。简单来说,凡是脑力活动剧烈的工作,都要求在良好的精神状态下进行,才能保证质量。这就牵涉到第一条――部分人由于被迫加班,状态疲惫,不仅工作效率下降,质量也滑坡得厉害。可能是赶了两周工期,最后反而给项目带来更多的损失。

    第三,产品项目中的每个工种都有农忙、农闲的时候。比如策划阶段,工程师的事儿就不多;到了开发阶段,设计师又得以清闲一段时间。调研和设计完成之后,我会建议PM休几天假放松一下,接下来,测试和发布阶段就得拼拼老命。因此将6X12设置为一种工作常态,这未免也太变态。我不止一次听见(其他公司)有人抱怨说,自己的活儿早就干完了,但下班后不准走,得留下来随时待命。这又是何苦……

    前些日子,有件关于加班的事情让我印象深刻。我这边有一位资深工程师调换了部门,在新部门里升任主管职务,然后常常加班,累得够呛。之前不论我怎么激励整个团队,也很少见到他加班,现在却是主动大量地加班,任劳任怨。看来我以前对他“不愿意加班”的看法完全是个误解。这个例子说明质朴的热情往往来源于自我驱动,自己给自己设定目标,安排任务,“这是我的事情”。如果你的目标和任务来自上级,则驱动力大打折扣,“那是你的事情,我去帮你完成”。

    可惜,强有力的自我驱动是件极为罕见的事情。有些人觉得自己不在其位不谋其政,有些人过于看重阶段性的物质奖励,有些人特别在乎自己的私人空间,有些人对项目的认同感始终提不起来,还有些人干脆对这份职业的投入度都不高。我在类似问题上困扰多年,积攒了几条经验:首先精简团队,至少是精简核心小组,参与(主持)项目的人越少,则归属感越强,不容易互相推卸责任。其次,核心小组要得到足够的授权,让他们感觉在做“我的事情”而不是“你的事情”,至少保证核心小组的自我驱动力。最后,我这个主管也要以身作则地加班,起到表率作用。

    换个角度来看,加班对于产品成功真有那么重要吗?

    最近恰好见一位豆瓣的朋友,问,你们加班多吗?答,一到19点办公室基本上就空了,早上通常是10点后才来上班……

    这当然不能阻止豆瓣是一款好产品。

    我在微博上说过一句话:2周一次小迭代,和3周一次迭代没有本质区别。产品胜出不会因为你每个版本的迭代都比别人快一周,而是你的判断更准确,设计更有效,实现更细腻。过度强调快快快,不仅令员工疲乏,也容易做不好产品减法。因为你能加班嘛,反而有更多工时去做次要需求。

    我们都知道,产品并不是功能越多越强就越有竞争力。你拼命加班,飞快迭代,发布各式各样的型号版本,把自己搞得鸡血沸腾,但最终决定胜负的并不是速度,而是精度。拿我很钦佩的Instagram举例子,至今不开发Android版也不去完善网页端,平均一两个月才更新一个版本,不到一年用户数已经突破了700万大关!故而产品的理念与方向,比速度与激情更重要得多――但我看国内很多团队就知道抄,东抄西抄,自己的想法很少,就算有想法也往往是“抄这家”“抄那家”的贪多求全。这样的6X12,6X14又有何意义呢?真没见过几款产品单单靠“抄得快”“抄得全”就能成气候。勤不仅不能补拙,还有可能造成设计过度与产品失衡,结果越补越拙……

    所以把6X12作为一句招聘提示,提前警示“有时候会非常忙哦”,这是没有问题的。但如果真心诚意这么执行下去,员工天天个个加班,时时刻刻在线,则一声叹息。从团队管理的角度上来讲,对市场与用户群的研究,尤其产品理念神马的过于飘渺,依赖超强的个人产品素质,无法用管理手段来衡量与促进,只好不得已而求其次,采用“加班”这种简单可量化的竞争手段。此法有效但不可滥用。

同分类推荐文章

  1. 从零重建 macOS 开发机:可复现的环境初始化流程 (2026-06-14 20:36:00)
  2. 百度物理网络监控工具开源第二弹:毫秒级监控工具 baize,让你的网络问题无处遁形 (2026-06-11 08:10:28)
  3. How to Set Up Homebrew Tap for Private CLI Tools: A Complete Guide (2026-05-27 02:13:03)

查看更多 DevOps 文章 →

建议继续学习

  1. 谷歌是如何做代码审查的 (累计阅读 6,666)
  2. 一个程序员的血泪史 (累计阅读 6,323)
  3. 加班与效率 (累计阅读 6,195)
  4. OKR 工作法简介 (累计阅读 5,616)
  5. 献给有裸辞想法的朋友们 (累计阅读 5,541)
  6. 从Code Review 谈如何做技术 (累计阅读 5,217)
  7. 软件测试工程师的职业素质 (累计阅读 4,998)
  8. 互联网的人才储备 (累计阅读 4,992)
  9. 给程序员们的工资报价提醒 (累计阅读 4,839)
  10. Facebook是如何开发软件的 (累计阅读 4,813)