不要让业务牵着鼻子走

最新推荐文章于 2023-01-12 01:10:26 发布

MavenTalk

最新推荐文章于 2023-01-12 01:10:26 发布

阅读量182

点赞数

原文链接：https://www.raychase.net/5302

版权

这篇文章算是要和之前写的《程序员懂业务有多重要？》“唱反调”了。

从工作开始，我就不断被灌输着一种业务至上的观点，无论在中国的公司，还是美国的公司，衡量一个决定或者一个需求的价值，都是在业务上有多大的帮助，都说 business impact 是什么。我从不怀疑单纯这样做的初衷，但是我质疑单纯这样做的结果。我觉得，即便是一个业务驱动为主的团队，在决策的时候，技术的占比，应当占据显著的地位。因而我说，不要被业务牵着鼻子走。继续把这一点发扬光大，我认为它对团队发展，对个人发展，都是如此。

曾经认为，这样的观点应该是公认的，但是我越来越发现，事实并不是这样。应该说几乎所有程序员都看到了业务上面的价值，都明白所谓“用技术创造业务价值”的意义，但是其中却有很多人忘掉了技术的根基，技术是程序员吃饭和安家立命之本，它不只是在实施过程中的一门工具和一种途径，它本身就有着决定项目和产品走向的能力。

自己的经历

我把做的项目，或者写的代码，非常粗略地，可以分为两类：

一种是基于现有代码设施，来写基于业务逻辑的实现，包括新的接口、新的条件分支等等，这种代码被称为“业务代码”；
另一种则是拓展基础设施，实现新的可复用特性，本身不混入业务概念，不直接“变现”，这种代码被称为“非业务代码”。

看起来前者更偏向于业务，而后者更偏向于技术，但是话说回来，在许多场景中，这二者是很难彻底分离开的。有时，要用非业务代码实现某种可被不同业务重用的基础特性，却是由业务驱动的。应该说，硬要分类的话，通常我们遇到的大多数情况，都属于前者。

我在业务和技术的团队中都呆过。在 2008 年的时候，我首先加入的是华为的彩铃团队，写的是彩铃服务端的业务代码，扩展 SOAP 接口和存储过程算是业务为主的代码，但是重新实现的定时任务功能算是用实现业务无关的基础设施。后来在连续几年的和视频平台有关的项目中，做过一个比较小的 service，也做过一个比较大的 portal，专职做过性能优化，由于基本都是重头来做，因此业务和非业务代码都必须涉及，而考虑到我所在的基线团队，以为定制团队提供基础设施为主，因而非业务代码写得更多一点。

在 Amazon 呆的时间比较久，做的东西也比较宽泛，做过 data visualization，big data 的采集和处理，分布式计算，以及分布式的 workflow，还维护过一个 service。这些代码一半属于技术代码，而业务的部分主要由团队中的 scientists 和 data analysts 们精通并持续研究，工程师在多数情况下只负责提供好用的工具。（其实这一点分工很难做好，Amazon 是做得相对不错的，介绍过分工，也吐槽过工具）

在 Oracle，所在的大 team 下我也算参与过三个小团队了，一个前端的团队，一个后端 service 的团队，再到现在稳定在这个 distributed workflow 的团队。前两者都属于业务代码远大过非业务代码的团队。事实上，在 OCI（Oracle Cloud Infrastructure）多数团队都是如此，几乎都是业务驱动，所谓的纯技术团队（比如做出 lib 或者 service 这样的基础设施来给其它业务团队使用）比较少。很荣幸的是，目前我在的团队就是如此，我们维护一个 distributed workflow 的 software stack，也维护基于它最主要的 service。

总体来看，最近几年和以前比，所在的团队和参与的项目要更加偏重技术一点，日常工作也相对更有趣一点。

项目的角度

业务驱动可以让你赚钱，但是技术支撑不足的业务驱动，也足以毁掉这个项目，甚至它所属的产品。专注于业务和技术的人眼光是很不同的。专注于业务的人可以让项目的工作围绕着核心价值和“挣钱”这样直接的目标而工作，但是专注于技术的人才可以让项目踏实并具备长远的可持续发展性。

业务驱动可以让用户得到引导，需求得到满足，但是技术驱动才可以让产品具备稳定性和扩展性这些软件工程层面的要素，从而真正发展起来，而不是三天两头地救火。这也是一个项目，最好具备 TPM 和 Dev 这样两种不同角色的其中一个原因。

在被质问道 business impact 的时候，程序员们一定在心里对技术上的优劣有杆公平的秤。毕竟，在做 trade-off 的时候，有那么多人从业务的角度帮你思考价值的问题，却只有你们自己能从技术的角度考虑和评估。下次再有人质疑有什么业务影响的时候，程序员也可以说，无论 xxx 有没有业务影响，它有着 yyy 的技术影响。

团队的角度

我记得以前说过，技术并不一定只体现在产品本身，时髦的、有趣的的技术带来的影响力，还能帮助吸引人才。这是技术对团队的影响之一，也恰恰是很多人忽视的一点。听起来很功利是不是？但是现实就是如此，我记得当时在北京 office 的时候，我们给新员工做宣传说，来我们组吧，我们做大数据，我们做分布式计算，我们做机器学习。我看到有的人眼睛就亮了。事实上，对于这些新员工来说，他们可能并不了解，这些事情并不好做，很多情况下都是苦差事，并且，业务影响可能还不如老老实实做传统业务的团队。

但，那又如何？

我知道很多程序员的想法是，不只是完成工作，还想要学到东西，并且向学到那些技术前沿的东西。你不能责怪他们不能立足根本，不能责怪他们好高骛远，这是一个技术人自然而然的追求。最起码，我能看到对方敢于打破舒适区的勇气。

反之，如果一个程序员说，我做什么都可以，我不在乎我加入的团队使用什么技术，做什么不是努力干活，挣钱吃饭？我反而会觉得这样百适的风格可能意味着没有方向上的品鉴和偏好，没有技术上的追求，也就没有持续学习的动力。我对这样的程序员加入团队，反而感到担忧。

我希望看到团队在技术上的追求和氛围，考虑扩展性、复用性和稳定性等各个方面，争论各种工程层面的解决方案，而不是用业务价值衡量一切。

个人的角度

技术上，需要精进，但是在技术上的投资，总体来说是不容易跑偏的。技术需要持续积累的过程。如果你发现自己每天写的代码无非就是加个接口，写一堆一堆的 if-else 面条式的代码，天天折腾在复杂的业务逻辑里面，而没有什么设计，没有什么技术问题的分析，那我觉得你大概应该需要寻求改变了。如果能在自己的组里面找适合自己的项目可以，如果不行，去寻求外部的团队，甚至其他公司，也是一个选择。

要明确的是，这些业务上的知识，只有少数能够积累下来，积累下来的部分，叫做领域知识。而绝大多数，都没有长期的价值，换言之，到了一个新环境，只有技术的东西是自己的，其他的多数都用不着了。这里不是说业务知识没有用，而是说，多数业务知识，对个人的发展，并不能提供持续的价值。有少部分，或者在确定了领域的基础上，当然是有用的。比如我有长期做 billing 的同事，就有着相当的业务积累，但是，这样的人才也会面临跳槽选择面过窄的问题。

有人说，技术上也一样啊，比如几年前的技术，到现在就淘汰了。MFC 淘汰了，CGI 淘汰了，WAP 淘汰了，我们现在用的技术，很快也要淘汰了，而体力跟不上年轻人，学习速度跟不上刚毕业的年轻人，是不是程序员也要被淘汰了？

我认为，技术是个复杂的事情，不是几个知识点，学会了就搞定一切了。这里有积累，并且技术在变化的过程中，绝大多数内容都是相通的，也就是说，所谓学习新的东西，这部分当中到底有多少是真正的“新东西”呢？年纪大了，体力跟不上年轻人，可是学习新东西的速度应该更快，而不是更慢。如果一个老程序员，学习某一项相关新技术的时间，或者掌握的深度，和新程序员一样，那么我会怀疑这个老程序员是不是靠谱。

技术上的积累，并不只是在解决实际问题的时候带来有价值的思路，更能够在学习新技术的时候，可以类比。在和更年轻的程序员竞争的过程中，老程序员的优势，应当是经验、眼界，而不是体力、反应。这也是为什么不要只写那些纯业务代码的原因，同样是写码拿钱，还是很不一样的，写纯业务代码，技术上积累的经验和眼界会很局限，并且由于照猫画虎实现就可以了，容易废弃掉了人思考的习惯，并且，随便招个年轻人就可以替代掉你。

如果程序员的你发现自己一直在忙于填充业务代码，不做设计，不做架构，如果自己还不对技术世界那么敏感的话，那么要小心了。如果这都不算“搬砖”，那还有什么是“搬砖”？这样长久的工作，会把自己对于技术的热情慢慢消磨掉。

我们都知道要懂得业务变现的重要性，不要变成迂腐的技术 nerd，就仿佛那“回字有三种写法”一般，而且似乎这个社会的大流都有这样的观点；可是我却觉得，我们更要看到，只有技术，才是程序员继续充满价值存在的最重要的理由。