我们应该成为什么样的人才？- 转载
小虾米+++ title = ’ 我们应该成为什么样的人才？- 转载 ' date = ‘2024-01-26T14:15:40+08:00’ +++
我们应该成为什么样的人才？- 转载
原文：为什么国内 IT 公司 leader 以上就不怎么写代码，而据说 Google 的 Jeff Dean 还写代码？到底哪种情况好呢？ - GXSC 的回答 - 知乎
作者：GXSC
原文
最近面了一些国内的人后，我印象最深的是一位有着 10 年经验的人来面中级开发（SDE II）。他从名校毕业，在国内几家大厂工作过，还创过业。我们对他很看好，但是最后没能让他通过。由于他的缺陷在北美很少见，我一开始不太理解，于是找同事和导师探讨其原因。最后我们的结论是：跳跃式升职。
- 首先，所谓跳跃式升职，是指员工升职后，不去干之前职位的活了。
- 其次，跳跃式升职的公司效率会较低。
- 最后，这种公司中美都有。
像程序员升职了之后不写程序、不做运维，就属于典型的跳跃式升职。相对而言，非跳跃式升职后，高级程序员也会少写一些程序，但是不会不写。
不论是哪种升职，都很少会让一个只会写程序的人升上去。跳跃式升职的情况，有时候会需要人去干越级的活儿；非跳跃式升职会需要人去转移侧重。
话说回来，其实这题我看了很久，一直不知道怎么吐槽好，直到最近面过这位开发之后。
一位奇怪的开发
这位开发简历很优秀。他 10 年间游走于各种国内大厂，还创过业。他做的项目看起来难度都很高。这个过程中，他从基层一直做到了技术总监。他毕业的学校是清北这类的，虽然这么多年经验的人我们基本上不会看学校。
我们面他之前，我还担心级别会不会给低了。大家面完之后一讨论才发现，不论是哪个级别我们都不能要他。
这位开发对于面试做过充分的准备。我们公司很多人头疼的 Behavior Questions 他也能对答如流。技术层面，单个环节他也做得不错：给他问题，他能分析需求；给他需求，他能做出设计；给他设计，他能写出程序。
但是我们发现一件很诡异的事情：每次他做完第一步，就做不了第二步了。比如给他问题，他分析出了需求，却无法根据这个需求做出设计；给他需求，他做出了设计，却无法根据这个设计写出程序。
每次他都只能拿我们给的输入，来得到下一步的输出，而无法用自己的输出进行下一步。
我们拿需求和设计举例。 一般来说，需求定义得越模糊、混乱，设计时所需要的理解能力就得越高。因为我们面试时给他的需求是明确的、清晰的，所以在他能理解的范围内。也因此用我们给的需求他能做出设计。而他自己分析出的需求，是模糊的、混乱的。虽然他分析出的需求也不算太混乱、还在我们的理解范围内，所以从单个面试关节而言，结果不算坏，但是却超过了他自己的理解范围。于是他自己分析出来的需求，自己没法做设计。
也就是说，我们给了他问题之后，他对自己分析出的需求是没信心的，甚至不理解的。他对细节也是没有把握的。哪里难、哪里简单、哪里有风险、哪里没风险，他根本看不出来。
虾说：我也看不出来，不仅看不出来，我根本就没有从实际问题中分析出需求的能力，😂
在我们想更多了解他的经验时也发现，虽然他给的几乎是我们 Behavior Question 的标准答案，但是他却不知道为什么要那样做。
虽然这样的缺陷不是没法更正，但是招聘他对我们的潜在代价太高。因此我们决定放弃这位候选人。毕竟开公司也既不是开学校也不是做慈善。
跳跃式升职
面试后的讨论中，我们总结出了他的缺陷：他的不同抽象层的开发能力都是不衔接的，是有空隙的。
至于造成这种缺陷的原因，我们可以对比两种成长模式。
首先是我们熟悉的，我们自己所在的公司的：
在我们这里，从实习生开始就是一个人带项目从头带到尾。从分析问题（甚至发现问题），到分析需求（更多是跟 stakeholders 沟通需求），到设计，到写程序，都得做。甚至有些组的实习生会把设计分给别人实现。都是实习生了还能分给谁实现？当然是分给高级开发。实习生设计的一般会比较混乱，所以分给高级开发去实现，刚好能弥补这个缺陷。
实习生唯一不需要做的是运维，因为毕竟实习时间比较短，来不及学这些。
这样的开发升职时，侧重会慢慢改变，但是基本上只是项目更复杂了、需要的人更多了。不会出现职责上有不连续的地方。
这个也是前面提到过的，非跳跃式升职的特点，非跳跃性升值时，只是工作内容的侧重点转移了，做的仍然是全链路的工作
我们这里的常见的问题，是升高级开发后，有些人没意识到自己的角色的转变、侧重的改变，而过度把时间放在写程序上、没能更好的领导自己的组织。
总结起来，我们不同级别的开发的职责大概长这样：
- 实习开发：发现、分析问题，分析需求，写程序、测试和部署解决方案。做小问题，侧重执行。
- 初级开发：发现、分析问题，分析需求，写程序、测试和部署解决方案，做运维。做小问题，侧重执行。
- 中级开发：发现、分析问题，分析需求，写程序、测试和部署解决方案，做运维。做中型问题，侧重辅导和执行。
- 高级开发：发现、分析问题，分析需求，写程序、测试和部署解决方案，做运维。做大型问题，侧重领导和设计。
我们招聘技术经理（薪资待遇是非技术经理的两倍），通常也要求经理至少有低一个级别的开发的能力。额外还会要求有支持团队、培养人才、利益交涉的能力。
对比起来，我猜测这位开发的经历就不太一样了。我想象他的公司里，不同级别的开发的职责也许是这样的：
- 实习生只打杂、做运维
- 初级开发只拿着别人给的设计写程序
- 中级开发只拿着别人给的需求做设计
- 高级开发只拿着别人给的问题分析需求
因为我没见过这样的公司，所以我找了一位见多识广的导师问了下，是不是真有这样的公司。他说有，还不少。而且他说，这种跳跃式升职恰恰是这位候选人的缺陷的元凶。
跳跃式升职的问题
跳跃式升职的公司里每次升职都是完全的角色转换。每个人升职之后就不用干之前的活了。所以会有人为了不做自己现在的一些活而去升职。甚至会有人因为现在做得不好，所以才拼命升职、做上级的活。而且大家也知道，自己之前做的事情、培养的能力，对于下个阶段都没有用，所以对于积累是一种消极的态度。这些公司对于级别低的人、他们做的事情，都存在一定的鄙视。
这种模式是低效的。我们可以想象一位纸上谈兵、不用负责写程序的高级开发。他做了一个设计，而这个设计在底层执行时出现了问题。这种情况下，由于下面的人没有被赋能去自己做设计，修正问题是需要上报给他、让他去改设计的。这大概率将会是漫长的、多层的、充满政治斗争的，因为大家都想把责任推卸给底层执行者的无能。而且他由于不会去做底层的活儿，很可能是不理解自己设计的缺陷的。
久而久之，如果这个还公司活了下来，你会发现越无能的人越在高层：如果底层的人无能，它根本活不下来。它的高层因为长期脱离了项目底层的反馈，根本就不可能培养出优秀的决策能力和领导能力。所以他们必然会需要底层有优秀的人才才能让公司活下来。
我们公司很多高级开发最大的价值，在于他们能够快速点出项目上哪些问题会对执行造成风险。这意味着他的各个层次的能力必须是衔接的。
为了培养这样的高级开发，我们必须给他们项目完整的反馈：也就是说他必须实现项目中一些高风险的部分，分配一些他觉得低风险的部分给别人，并且为这些决定负责（比如如果分配错了，他是得负责的）。如果他只做设计、不写程序，那么他是无法拿到完整的反馈的。
根据 Conway’s Law，软件系统往往会追随公司的结构。如果公司结构上有空隙较大的分层，那么他们的软件系统中也会有同样的分层。
我所在的公司，大体上希望每个组的范围是垂直的：一个功能从用户体验到后台、到运维、到商务报告，最好都属于一个组。这样修正问题会很有效，不会多组之间有很重的耦合。
而跳跃式升职的公司，往往系统不同的层是分给不同的组的。因为他们的员工只希望在一个层次工作，所以系统也会这样分。最后甚至会有专门搞数据库的组，而数据库组跟后台业务逻辑是割裂的；后台跟前台也是割裂的。
最大的低效出在这些层的边缘上。因为没人拥有完整的功能，所以没人理解完整的功能。层和层之间的沟通也就往往是低效的。为了解决边缘上的复杂度，有些公司可能会再在后台和前台之间再加一层。但是这只会让问题恶化：层次更多了、低效沟通也更多了。
我想到了国内前段时间特别火的中台
美国为什么会有这样的公司？
对于国内我不了解。导师提到，美国会出现这样的公司，是因为有这样的市场：当你有一个项目找人做时，你是会找一个 100 万给你做出来的大公司，还是 10 万给你做出来的小公司？
导师说，之前他们遇到一位 VP 是这么说的：如果他找了要他支付 100 万的外包公司，项目失败了外包公司负责；如果他找了 10 万的，项目失败了他自己负责。最后果然大外包公司项目失败了，退了一半的钱。他们又拿这个钱去小外包公司把项目做了出来。
跳跃式升职的公司的产生，源于对缺乏组织管理和人才培养的能力，并盲目地进行专业化分工和分层。这种低效的分工和分层能正当化大量的人力需求，把小项目说大。而市场上恰恰又有人觉得，一个项目 100 个人做风险总是比 10 个人做小，而不仔细调查公司的开发模式。最后导致这种低效的公司也能活下来。
其实很多时候人太多、分工太细会增加风险，会产生“多单点故障”。
工作中我们有时会遇到自己或者他人对于“单点故障”这个概念产生谬误。比如一个系统，它的某个服务非常重要。只要这个服务挂了，整个系统就挂了。于是有人把它拆分成了三个服务，号称这样就根除了单点故障。实际上，这三个服务中任何一个挂了，都会造成之前同样的效果。于是我们的系统由有“单点故障”变成了有“多单点故障”。风险反而增加了。
而有些人把这种谬误也带到了分工中去。他们发现有些人管得太宽、职责太多、少了这些人公司就没法运作了。于是为了保证公司不论缺了谁都能照常运作，把职责掰开了分配给不同的人。这显然是不对的：现在每个人走都可能造成一个空缺。这种分工反而是给公司制造了“多单点故障”。只有让多个人有重叠的职责，才是少了谁公司都能正常运作。所以做法上不应该是根除职责太多的人，而是增加这种人。
这段话真的是醍醐灌顶
10 个人的项目拿 100 个人去做，往往最主要的问题是沟通问题。其次就是分工太细，导致多单点故障。开发一个系统通常没有哪个组件是可以缺失的。分工太细之后，一个人的失误可以延迟整个项目。人越多，这种问题就越容易发生。一个例外是你把这 100 个人拆分成 10 个团队，平行开发同一个系统。不过这样做很昂贵，虽然降低了风险，但也是另一种低效。更有效的做法是小团队做迭代式的开发。
当然不是所有人都觉得项目越贵风险越低。但是只要有，就可以养活一些低效的公司。当然，这是美国这边的情况。美国科技大厂基本上没这毛病。美国这边问题主要出在大厂以外的公司，比如传统行业、外包公司、还不太成熟的小公司。国内是什么情况我不了解。
总结
人才在培养过程中，的确会出现侧重的转移。但是责任上应该还是重叠的。一个高级开发、首席开发，可以少写程序，但是不能不会写。他需要能融汇贯通他各个层次的能力，才能成为一个有效的领导人。一个项目的难点和痛点大多存在于职能和级别的缝隙间。因此一个人越有跨职能、跨级别的能力，越能够为项目增效。
归根结底，职业的成长应该是一种累积，而不是一种跳跃。今天走的捷径，有时会是明天的天花板。
我的想法
我的感觉就是我当前工作的公司的架构就是此篇文章中提到的完全分工的组织架构，我之前对部门效率的低效的疑虑也在本文中找到了答案，因为项目的管理者根本不懂写代码，所以他对实际的代码开发的工作量时没有实际的概念的，这就导致了项目进度的管理者压根儿就无法跟开发人员对话，因此，只能在配备一个技术负责人，负责平衡项目的进度要求，对实际的开发任务进行取舍，对每个人的开发工作进行安排，而实际执行开发任务的人员因为对项目的进度（被技术负责人安排）、项目需求（被做需求的人安排）都不能自行控制，只是一个用代码实现功能的机器，因此，话语权极低，存在感，工作积极性也低，如果设计或者需求出现问题，做需求的人只需要花一天重新做需求，技术负责人只需要花半天重新排进度，技术开发人员却需要花三天时间重新写代码，整个项目的执行压力全都在开发身上，因此，矛盾不断，而且整个项目组看起来三四个人，但是干活的只有一两个人，冗余人员占到了 50%，人力浪费，效率低下。
以上这些问题，是公司权责划分上的问题，是组织架构上的问题，作为一个普通开发，我们无法改变这些问题，我们能做的，只能是提升自己的能力，让自己称为一个拥有全链路能力的人，发现、分析问题，分析需求，写程序、测试和部署解决方案，做运维。而不是只会写程序。