大厦新搬进来一家创业公司，老板红光满面地提着果篮上楼拜访，说是刚拿到了投资人的钱，正准备扩充团队大干一场。那个时候的他踌躇满志，顾盼生辉。当时我想，能在这个大环境下拿到投资的公司，做的产品应该是有前景的。
没想到几天后在电梯遇见时，却发现这位老板已经没有了往昔的风采，整天愁容满面。他在电梯看到我以后问道：“我记得你们是做技术媒体的吧，有个问题想请教一下。”
原来他烦心的症结在于：
我们公司拿到投资以后，人员配置到位还算及时，业务扩张的速度还是挺快的。没过多久我们技术团队的人就跟我说，现在业务发展势头比较好，现有的技术架构快扛不住了，得招些技术牛人来团队负责整体架构规划、升级。
我不是搞技术出身的，以前总是在各种论坛上听说阿里巴巴的 P8、P9 多牛逼，技术多厉害，我就想这种级别的程序员应该可以满足我们的需求吧。于是我用年薪百万的offer砸了个阿里新升的P8来我们团队做CTO，可是现在问题不仅没得到解决，反而更复杂了。技术团队的人觉得他名不副实，他觉得我们找他来是打杂的，干得也不开心，两头乱。
我问他，你们觉得他哪里不好？
- 他只会写Java，我们用Go；
- 他只会搞后端，前端基本不懂；
- 他算法不太行，我们要做推荐；
- 他只会写Web，我们要做App；
- 他只晓得用开源工具，我们要造自己的轮子；
咨询师：“那等于是他哪哪都不如你们意呗？”我问他。
ceo：对啊，我也没想到阿里P8这么水。
咨询师：“可你一开始要招的不是可以给你们重构系统架构、偿还技术债的CTO吗？”
ceo：这……有啥区别吗？
咨询师：“区别大了。你这又是要让前端后端都会，又是要精通各种编程语言，还要能搞移动开发，你这想要的是个全栈，而不是CTO。哪有CTO干这些活儿的，你这是想让一个在大厂流水线上拧螺丝的人来给你把每个窟窿都堵上，不可能啊。”
ceo：合着我钱白花了呗？
咨询师：“倒也不是白花了，BAT这些大厂都有一套流程化的线上线下、开发管理机制，一般能升到P8的，碰到水货的可能性相对较小。你的问题是需求跟招聘方向不匹配，你要招的这是全栈工程师，人家大厂的技术专家是流水线作业，差别大着呢，你听我跟你分析分析。”
软件工程作为一个行业，发展至今已经有超过50年的历史。软件开发在互联网的数次浪潮冲刷下，已经是一个非常完备的成熟行业。在一线互联网公司，比如硅谷的 Google、Facebook、Amazon，比如中国的阿里巴巴、百度、腾讯等，其软件开发已经是一个成体系的流水线式作业。
就以前文提到的阿里巴巴为例，作为国内最有代表性的互联网企业之一，阿里巴巴的软件开发已经形成规模化的效应，直接体现在软件开发的模式上就是一条完备的流水线式作业。
流程化、规范化是大厂软件开发最大的特点。一次完整的需求开发流程是这样的：1. 需求预审、评审；2. 概要设计与评审；3. 测试用例撰写与评审；4. 开发；5. 测试与 bug 修复；6. 发布；7. 版本总结 / 项目过程总结。在这个过程中，每个开发人员都各司其职，拧着各自负责的螺丝。
很多新人在加入技术团队后，通常会有一个资深的员工作为师兄帮助其更快地融入工作、掌握相应的技术。一般而言，在开始阶段新人的任务都是从简单的程序开始写起，比如迁移部分系统代码（从上游系统迁移到下游系统），做一些简单的小需求（如修改 bug，增加某一个字段等）。
这些需求看似简单，实则不然。因为哪怕涉及一行的改动，都需要进行大量的测试进行覆盖，很多人以为这些都该是测试去做，但实际上，测试往往只能进行黑盒测试，而且测试对于代码的了解程序一定不如开发，所以在这些细节上的测试都是由开发自己自测完成。因此，往往改动一行代码，开发就可能都会花上半天的时间用各种方法进行测试。
不仅是测试，阿里技术团队在 2016 年左右开始了一次大的组织架构调整，即把日常的运维工作交给研发做。原来的 PE（Production Engineer）要么转岗去做工具平台开发，要么作为运维专家做产品规划和设计，还有一部分无法适应的只能黯然离开。这是阿里运维从工具化到自动化最重要的一个过程。
规模化、流程化、自动化，这几个关键字放在一起，你第一眼可能想到的是生产车间，但在阿里巴巴，这是其技术团队多年沉淀下的一个行之有效的软件开发模式。
阿里巴巴相对而言是一家业务驱动的公司，项目以业务优先，对于团队来说其重要性不言而喻。在阿里巴巴，这是一个需要多人开发，团队协作的事情。对于那些研发人数动辄超万人的大型互联网公司，要前端就找前端，要后端就找后端，规模化以后要求的不是全才，而是专才。
规模越大的互联网公司，程序员干的事情反而越机械，在软件开发的流水线上做着增删查改的拧螺丝活儿，但这些人，在入职前可是通过了“面试造核弹”般的筛选才进来的。越是高级别的技术专家，出现水货的可能性也越小，同样，他也不可能成为一个小公司需要的全栈开发。什么都会一点的结果，就是什么都不精。
产品规模上去以后，各个模块复杂度都很大，全栈未必适合，规模上去以后势必也要拆分一些项目出来，由专人维护，全栈存在的意义不大。大公司讲究专人专岗，你就做好自己那点事就得了，就算你离职，找到替代你的人相对也比较容易。
“所以你想挖一个阿里的P8做你公司需要的全栈是不现实的，你就是把行癫挖过来这问题也解决不了啊。”
ceo：那小公司的技术咋整？
咨询师：小公司要的全栈开发，“人们一提起‘全栈开发工程师’，大家的印象肯定是：这号人啊，堪称大神！会很多技术，前端后端都精通，不掌握七八种语言都不好意思出来打招呼，热点技术名词全都知道，也都会点儿，跟谁都能谈笑风生。”
ceo：对对对，我们要的就是这样的人！
咨询师：“但是呢，全栈工程师更像是一个神话。每个人的精力都是有限的，你需要人家精通前后端，自己能写代码还能做测试搞运维，能写网站还要能写 App，你咋不上天呢？”
ceo：百万年薪挖了个P8程序员，难道是“水货”？
咨询师：全栈工程师，一定程度上更像金庸小说里的慕容复，刚出场时牛逼哄哄，什么都会，自带光环。可后来随着剧情（业务）的展开，逼格直线下降，被武林同道所笑话。
事实上，创业公司一般比较喜欢招全栈，这和创业公司的需求有关系，因为创业初期的公司可能需要一个人做几个人的活。另外，可能老板是技术出身，了解部门之间衔接所需要付出的巨大沟通成本，所以倾向于更少的沟通单位。
对于个人和公司，全栈的定义是不一样的，初期公司肯定是希望全栈的技术广度和深度刚好能满足公司业务要求，本质上只是想要个全干。但对于个人来说，大多数普通人的时间精力有限，很难真正在广度和深度都做到专业，如果只是为了满足公司需求点技能点的后果就是——项目发展起来之后公司有钱了，全栈差不多就该扫地出门了。
对于创业公司而言，为了压制成本，需要全栈完全能够理解。毕竟一个优秀的程序员也不便宜，能让一个人干两人甚至三人的活儿好像对于成本控制是个好办法。然而，显性的成本控制住了，隐性的成本呢？
“你想没想过，当你的项目到了关键时刻，比如要上线了，或者上线出bug了，这时候分分钟就是几十上百万的流水，而你的技术团队因为缺乏专人出问题了。你急急忙忙地去找你的全栈CTO，他却说：稍等，我上Stack Overflow 查下这是什么故障。你崩溃吗？会上 Stack Overflow 的还算好的，他要是个面向百度编程的全栈，你就只有哭的份了。“
再进一步，一个比较复杂的项目，如果一个全栈走了，项目受到的影响会很大，你很难再招到一个完全匹配该项目的另一个全栈。我们见过太多创业公司因为技术团队关键人物离职直接导致项目失败的案例，你越是想省钱，越是省不下钱。
ceo：听你这么说，怎么觉得全栈就这么不堪入目呢？
咨询师：”非也非也。你们这些当老板的，总是认为都是写代码，前端后端没什么区别，Java、Go 没什么两样，这本身就是最大的误解。全栈工程师一定是有其存在的意义的，但你如果想让全栈工程师把什么事儿都全干了，996都没你这么狠的。全栈工程师也许是未来的一个发展趋势，但现在那些简历上写着全栈的程序员，大概率才是你们认为的水货。“
ceo：所以总结下来，他不是个水货P8，我是个水货CEO喽？
咨询师：“佛曰，不可说。”