上周看到有人提出了一个问题，大意是，“公司里头有很多部门，大部门的人员成长比小部门要好，可这也出现几个问题，一个是在大部门有机会去造大轮子，有更多场景，而小部门主要是在做业务；二是大部门内部晋升压力大，要是放到小部门可能早就升了，如何解释这些现象？”

什么是业务？

   一个程序员走向成熟的标准是什么？我认为，是他能够看清技术的本质，不再为那些高大上的名词和所谓的权威言论而为之动容。抱着这样一个共识，我们接着去讨论，什么是轮子？

   在公司里，可以看到两种类型的团队，一类是以技术专业为集合的团队，比如「端技术团队」，一类是以业务单元为集合的团队，比如「母婴行业团队」；前者工种单一，在大部门经常会产生这种团队，后者成员类型丰富，在大、小部门均较为常见，只不过在大部门中技术人员的汇报对象是同专业的技术 Leader，而在小部门很可能是业务 Leader。

   当一个团队出现四五个类似的「母婴行业团队」时，就很容易出现以专业方向为集合的团队调整，原因是，团队为了避免大量的重复建设，需要通过对业务的理解向下抽象一层基础设施，为上层业务持续供血。而随着业务规模的不断扩大，这层基础设施可能仍然无法满足业务快速发展的需要，于是就有了更多层的抽象和聚合，以提升所有业务成员的单兵作战能力。

   如上所示，我简单地画了一张图——团队因规模变大而几乎必然产生的面向专业方向的团队能力结构设计。聊到这里，我们再来看看，什么是轮子？

• 做一个基础框架算不算轮子，算，针对代码的运行容器，设计一套程序的执行流程，最后将编程模式和 API 暴露给上层开发者；

• 造一个监控中心算不算轮子，当然算，一系列的数据收集加上一系列的数据分析，然后定义好数据消费者，将最后的数据消费掉；

   有的是小轮子，有的是大轮子，需要注意的是，这些轮子都放在「业务支撑」的下层，也就是说，如果轮子制造出来不能直接或者间接服务于业务，那么这些轮子就是失败的轮子。

   那么，造轮子是在做业务么？这个问题不言而喻，只是在一些成熟的团队，我们会看到，轮子的权重被抬得很高，甚至平行于业务的发展，轮子不仅仅会去满足团队内部的需要，还会考虑走向全公司，甚至走出公司进到社区，比如 React、Element UI、Material Design 等等，他们丰富了整个行业的生态，事实上，是支撑了更加广泛的业务。

业务中的成长

   上面一大段，几乎是在阐释一个道理：轮子对业务来说十分重要，造轮子也是在做业务，只不过它需要更多的抽象，服务更大的体量。但是有个不争的事实是，作为一个技术人，在职场初期，技术上的成长比业务上的成长显得更有优势，所以大家都想有机会去造轮子，于是就出现了一个现状，在一个高速成长的团队中，轮子层出不穷，有的人在搞新轮子，有的人在优化已有的轮子，争取做大、做强，做到与业务并驾齐驱。

   不管是大团队还是小团队，总有那么一部分人是需要直接服务于业务的，这些业务同学看到身边或者隔壁部门的同学有造轮子的机会，有一点眼馋也是说的过去的，这个声音必然存在。所以这里本质要聚焦的问题是，业务同学如何成长的问题。

其实做业务的同学应该感到开心，因为你有机会冲到一线，直面企业和客户的核心问题。只不过有一个不够公平的现状是，公司通过产品去解决业务的问题，而产品的实际 Owner 通常并非技术人员，也就是说产品上拿到的结果很难直接算到技术人员的头上，本质矛盾是：技术拿到的是产品结果，却需要用产品背后的技术结果来评估自己的价值，这本身就是难以对等的。
不过我们也需要换一个视角去看待这个问题。

   踩在一堆轮子上，我们有足够的视野去分析业务的问题和解法。试想，让一个资深的轮子制造者跑到业务前线去打仗，他会遇到什么问题？彼时，他手里的这个轮子不再有效，只有当他在业务中遇到了跟自己轮子相关的问题时，他的效率才会高一点。业务开发人员，或者称之为产品工程师，他们的角色更像是车子发明家，有的人能够把各种轮子拼成一辆特斯拉，而有的人却只能拼装出一辆滑板车。针对产品工程师，这也给出了一个清晰的职责定义：产品工程师聚焦的内容应该是业务模型上，也就是手里的这辆车子上，不断去优化车子的引擎、制动、安全性和驾驶体验，这其实是个新的课题，也有丰富的场景。

技术经过多年的探索已经有了很多固定的模式和模型，因此轮子的制造具备很强的确定性，轮子制造者们主要工作是根据业务的特征进行基础的适配和升级；而业务所面临的问题和挑战是不确定的，因为市场的不确定性和用户的不确定性，因此业务同学想向上突破，需要去探索业务中确定的部分，聚焦到新的业务模型上，为这个模型添砖加瓦，升级换代**，这是一件有挑战的事情。

   关于成长的问题，以前做过一些探讨，我把链接贴出来：

• 《谈谈我这三年在技术上的成长》，2016 年

• 《谈一谈我在阿里的成长》，2016 年

• 《技术人的坚守》，2019 年

• 《新人在中小公司遇到的成长困境》，2019 年

   感兴趣的可以去读一下，在这里不做过多的讨论。

“我很强”的错觉

   在规模庞大的团队待着的人，会看到很多服务规模超大的技术产品或者技术工具，因此容易产生一种“我很强”的错觉，事实上，是业务比较强，业务有市场才能促进业务下的技术层变得厚重。相反的，如果业务还在初期发展阶段，也容易产生一种“我较弱”的错觉。

   对技术的评判不能单一地体现在业务的强弱上，事实上，每个人只要给予足够好的环境都可以得到快速的成长。有的人选择环境，有的人选择创造环境，做好分内的事情。

建议继续学习：

1. 我的程序员之路    (阅读：5633)
2. 创业三部曲之一――学技术    (阅读：5488)
3. 我这几年    (阅读：3479)
4. oracle技术方面的路线    (阅读：3441)
5. 我和Linux    (阅读：3254)
6. 小技术团队的成长    (阅读：3126)
7. 我的担忧：dba如何在稳定环境中成长    (阅读：3150)
8. 学习与成长的困惑    (阅读：3080)
9. 大学生毕业了，程序员之路如何走    (阅读：3032)
10. Apple 谈论产品 vs Microsoft 谈论技术    (阅读：2905)