世界上没有技术驱动型公司？-InfoQ

科技公司到底是为技术驱动还是业务驱动的争论古来有之。对于技术人员而言，拥有良好工程师文化、代码文化，核心竞争力是技术、尊重技术、技术人的公司似乎就可以称得上是技术驱动型公司。但事实果真如此吗？本文作者给出了不一样的看法，他认为，世界上没有技术驱动型公司，谷歌、脸书不是，阿里、腾讯也不是。

免责声明：本文仅代表作者一家之言，不代表 InfoQ 立场，欢迎评论区有理有据的讨论。

世界上没有技术驱动型公司，不论 Google、Facebook，还是腾讯、阿里，都不是技术驱动型公司。因为技术不是源头，需求才是。因此一切技术问题，都要服从产品交付和市场反馈。所以，任何公司，都不可能以技术去驱动自身。人可以以技术驱动自己进步，但公司不行。一家公司可以以技术切入某个市场，但如果它想生存下去，就一定不能以技术为导向，坚持以技术为导向的公司的生命力为零，其下场有两个：破产或者在破产之前被收购。如果你真的很痴迷钻研技术，请读研读博最后留校或者进研究院让国家用纳税人的钱养你。

客观看待加班问题

资本富集的地方，每个人都得加班。加班的本质，是人跟着机器跑、人跟着钱跑。更为本质地说，资本富集的地方，人作为劳动力，也是资本的一种。即，人是资本而不是人本身。

资本的运转是不能停的，因为停一下损失的钱太多了，中国、外国，都一样。知道发达国家为什么产业工人不加班吗？因为制造业已经不是这些国家主要创造财富的领域了。发达国家资本富集的地方是金融行业，所以西方国家的金融狗一样加班。

劳动法？加班费？都不存在的。劳动法和加班费只有在资本离开这个市场后才能给你保证。一般公司的策略是：付给你高于其他行业的薪水、换取你“自愿”加班。不想加班的同学们，你们可以去考公务员或者去欧洲做 IT，我保证你不加班、不但不用加班，你甚至会闲出病。

多读书，但别迷信技术

IT 是工科，不是理科，和 IT 行业相似度最高的行业是盖楼房。真的，相似度相当惊人。

IT 领域最重要的是经验而不是你有多聪明，不聪明的人或者更准确地说不适合做这个行业的人，大学毕业后就改行了。记住：你做得好不好，不取决于你是否聪明，而取决于你是否愿意不断读书不断学习和不断积累。因此，如果你打算投身这个行业而你还在学校，请抓紧一切时间多读书。

公司是你创造财富的地方，公司不是学校。你可以在工作中学习，但你不能放下工作然后去学习，除非你的工作已经做完了。

能大规模商用的技术，都不需要智商，否则这种技术就不可能规模化。某些程序员们，请停止你们的蜜汁自信。

技术栈，一旦确立了，就很难改了。一个技术人员是如此，一家公司也是如此。根本原因是：每一个栈的 size 都太深了…就像是 ulimit -s unlimited 过一样。

一个程序员，应该花 80%的时间做代码设计、画 UML 图、画时序图，20%的时间写 code 和 debug；菜鸟程序员的这个比例恰好是反的。一句话，不论这个需求有多紧急，你都一定要“想好再动手”；“想好”的标志就是设计文档写好了；文档一旦写好，写代码就是纯粹的无脑工作。

写文档的目的是让你在 coding 的时候，不需要停下来思考更不需要推倒重来。如果没有文档也可以做到这一点，你当然可以不写文档同时思考下自己水平这么高是不是可以要求升职加薪了……或者，你是不是在做无聊的 if else 编码工作？

要关注说烂了的软技能

英语很重要。能否使用英语查阅资料，是区分技术人员水平的重要指示之一。寄希望于“有人迟早会翻译成中文”的人是愚蠢的、是会被淘汰的。

要有分享精神，不要担心你知道的东西告诉了别人你就没价值了。你最大的价值在于你知道那些东西的过程，而不是那些东西本身。你愿意和别人分享别人自然也会愿意和你分享，最终达到 1+1 大于 2 的效果。不分享，就像一个失去了互联网的程序员，试问他还能创造多少价值？恐怕他连日常工作都无法展开了。持有“我把别人知道的都学会、我把自己知道的都藏起来别让别人学去”想法的人，其实是默认全世界只有你聪明别人都是傻瓜，这样的人，在信息传输成本高的时代，可以活下去，但是在今天这个时代，他们的路会越走越窄最后会自己走入死胡同。当然，如果你真的知道了了不得的黑科技，那就请你保护好自己的知识产权然后自己开公司玩吧。

工作要有热情。智商决定你的起点，情商决定你能走多远爬多高；混职场，靠的是情商。情商高就是：别人愿意和你一起工作、你有问题的时候别人愿意帮你。智商有时候可以稍微弥补一下情商但不起决定性的作用。

如何让自己变得不可替代？

现代管理学的精髓，就是让每个人（包括老板本人）都变得可替代。如果你觉得自己不可替代，要么是你的错觉，要么是你在一家管理非常原始的、摇摇欲坠马上要完蛋的公司。

怎样让程序员变得不可替代？三个字：写文档。不愿意写文档的程序员，应该立刻马上毫不犹豫地开掉。程序员工作创造的价值，至少一半是通过文档体现出来才对。“一个项目换一个人就要让项目大地震一下、解决 bug 换一个人就不行因为只有老人知道要改哪一行的哪个关键字”，这不说明这个项目所涉及的技术有多复杂、不说明这个老人是什么技术大牛，而只说明这个项目的项目经理是蠢货，因为这个项目已经失控了。

文档不是事无巨细的流水账，写文档以及组织文档是需要智商的、是需要架构师去设计的。美国的航天飞机那么复杂，但是在飞行员手里的手册也就那么多，而这个手册可以在航天飞机出问题的时候协助飞行员快速定位绝大多数问题。

不可替代的打工者只有一种：以中高层领导的身份跟完了一个项目而且这个项目正处于大红大紫的阶段，公司为了防止你跳槽到竞争对手那里，愿意付给你薪水养着你天天在办公室喝茶。只要项目一直红着，公司就愿意一直养着你。

文档的作用

给正在 Coding 的自己看；给几个月后已经忘记这个模块当初是怎么开发的自己看；给要接手自己工作的新人看；给周边有关联开发任务的同事看；给领导等有关人员看……这是产品出 bug 的时候用来和别人怼的武器。如果没有文档，这些工作量都会成倍增长。

代码再精简再直观，也不可能有人类语言直观，谁觉得自己厉害到读代码和读人类语言写的文档速度一样快，那我给你一个我上大学时候写的小程序，麻烦你读一下代码，看看你多长时间可以看明白。

这段代码本身并不复杂，应该说非常简单，但是没有文档……读读看吧。简而言之，文档，就像盖楼房的设计图，没有图纸，你是不能开始搬砖的。

领导有没有给你看需求分析文档？有没有拿着需求分析文档给你宣讲你要做什么？没有？不干活。
测试的同事有没有给你看测试用例文档？有没有给你宣讲？没有？不干活。
你自己明白领导的意图了吗？明白测试同事的意图了吗？想明白后，开始想自己要开发的模块里的各个功能模块之间的关系，可以画时序图。
时序图画完了，看看是否有（可能）频繁变化的模块/需求，如果有，请务必使用一些设计模式，如果要用设计模式，请务必画UML类图，如果没有频繁变化的模块/需求，请一定不要用设计模式。
在一个功能模块中，有没有逻辑比较复杂的地方，如果有，请画流程图。
模块和模块之间有没有需要明确的协议？如果有，请把协议写出来。

上面这一段话，就是你要写的文档，这个文档的读者主要是你，在你的模块出问题之前，别人通常不会读这个文档（不排除你的领导会要求看你这个文档）。如果你既不需要时序图又不需要类图又没什么协议需要明确，那么，你就可以不写这个文档。另外，如果这个文档写得好，你的代码是不需要任何注释的。

技术驱动是个伪命题？

如果一家公司打着“我们是技术驱动型公司”的名号在招人，我劝你一定要想好考察好，再决定是否去这家公司。

为什么呢？因为我知道他的那句“技术驱动”很吸引你，你想学东西，但是对小公司来说，它最大的任务是活下去，然后才是其他。我不是说小公司学不到东西，我只是说小公司很难很难做到真正的技术驱动。有人坚持认为微软这种公司是技术驱动，但微软从没大张旗鼓地说自己是“技术驱动”公司，并以此忽悠新人。

以华为为例。华为成功的内在原因，早就敲锣打鼓地告诉全世界了：以客户为中心，以奋斗者为本，长期艰苦奋斗，坚持自我批判。这四句话，没一句是直接和技术相关的。

这里我先特别声明一下，我不是说，技术人员在华为就不会搞技术、不会提升自己的技术水平、华为的技术水平差。我绝不是这个意思。

华为的技术，不需要我多说，全世界的人都是有目共睹的，华为公司的技术专利数就摆在那里，那是谁也抹杀不了的，华为公司里的技术大牛多了去了。但在这里，我要说的还是第一段的意思：一个人可以以技术驱动，但一家公司不行。

华为公司的核心理念，本质就是“成就客户”，你把客户成就了，你就把自己成就了，华为不是先成就自己再去成就客户的公司。你去华为工作，你可以以技术驱动自己，但华为不能这样做。

这一点和微软与 IBM 的合作极其相似：IBM 说，你们微软现在搞的东西我愿意用，但是我需要你们给我搞个操作系统，这样我们才能继续合作。然后微软怎么做的呢？它马上购买了另外一家公司搞的 DOS 操作系统，然后直接授权给 IBM 使用。

这里面有四个问题值得思考：

为什么那家开发DOS的公司没能直接和IBM合作？
微软购买DOS系统的钱哪里来的？
微软为什么不自己开发操作系统？
技术在前三个问题中的角色和作用是什么？

至于有人说 Intel 是技术驱动公司，我建议大家可以去了解一下 Intel 为什么放弃了手机市场：重点关注 Intel 决定放弃手机市场的原因，你就会发现，这个原因的本质，就是一种技术情节的产物。

Intel 放弃手机市场与华为决定进军手机市场是截然不同的。华为本来是做基站、路由器和交换机的，这是它的主营业务。

那么华为为什么决定进入手机市场？是什么原因驱使华为在没有任何技术积累的前提下进入手机市场？以至于最初华为的手机被华为员工戏称为“暖手宝”，倒贴钱都没人愿意用，而现在却如此成功？

所以，我还是那个观点：世界上没有技术驱动型公司。

我本人就是程序员，我一直都以技术在驱动自己，努力提升自己的技术水平。但是我还是要说：世界上没有技术驱动型公司。

一个新的team要开发一款软件，它首先要解决的问题，是在产品1.0开发出来并且赚到钱之前这个team的经费。
其次，它要提前找好产品的客户群和可能存在的销售渠道，并且做完相应的工作。
再次，它要做产品规划，如什么时候出1.0版本的产品、哪个模块开发大概要多久、什么类型的问题可以暂时搁置、什么类型的问题不能搁置、要组织公关组公关等（全是项目管理相关内容，和技术没有直接关系）。
最后，进入产品开发阶段。一旦进入产品开发，就像工厂的流水线一样，是不可能出现什么导致产品开发进行不下去的技术难点的（否则技术leader就是白痴，这种产品在头脑风暴阶段就应该被拍死才对）。

所以，“期望出现决定产品生死的技术难点，然后自己 nb 闪闪地搞定”这种事情，是不可能发生的。同时，在开发过程中，难免出现各种意料之外的 bug，比如，你负责的模块出现了三个 bug，其中一个是必现问题，且直接影响功能实现，那这是一定要搞定的，如果你搞不定，team 会找其他老手和你一起攻关。

攻关结果有两种，一种是 bug 解决了，但是不知道为什么；另一种是 bug 解决了也知道了是为什么。

对于第一种情况，team 是不会为了找到原因而让你潜心研究几个月的，为什么？因为你还有后续工作要完成，而这个 bug 已经解决了，不影响用户使用了。

什么时候才有可能让你继续跟进这个问题呢？1.0 版本的产品市场反馈符合预期，且公司决定要继续投入 2.0 版本 ——只有这个条件满足，你才有可能继续跟进这个问题，为什么是有可能呢？

因为这个 bug 已经不影响客户使用了，没必要投入人力去研究了，你如果花几个月的时间去找这个 bug 的原因，那么请问：2.0 版本的工作谁做？

在很多项目中，类似这种“问题解决了但是不知道原因”的 bug，是比较常见的，很多时候，直到这个产品生命周期结束，这些 bug 的原因都没有找到。因此，“期望碰到神秘 bug，然后自己潜心研究几个月，终于把原因找到”这种事情，很多时候是不存在的。

接着上面的“三个 bug”继续：另外两个 bug，是概率发生且发生概率很低。

这个时候如果工期比较赶，公司会想办法绕过这两个 bug，比如定时重启服务器、定时清理缓存等（这些方法通常可以绕开低概率 bug），不会给你“潜心研究三个月然后把 bug 解决”的机会的。

什么时候才有可能让你继续研究这两个 bug 呢？和第一个 bug 一样，只有后续继续开发，才有可能让你继续跟进。

现在，请各位再重新品味一下“技术驱动”这个词。到底什么是技术驱动？

其实这个词真正的含义就是：我们公司效益很好，能养活 nb 的技术团队，所以产品能不断迭代演进开发，随着产品的不断迭代，技术人员有可能会遇到一些其他公司遇不到的问题。

所以，如果一家新成立的小公司说自己是技术驱动的……连 1.0 版本的产品都没有，就敢说自己是技术驱动？你信吗？不管你信不信，反正我不信。