码农的胡思乱想系列--业务驱动

说到底，什么都是业务驱动。只会埋头编程，在德国人眼里就是一个Code Monkey。

开发组招一个Senior开发，周三来了一个求职的候选人面试，照例分两场： 先HR面，再技术面。 组长说你来一起参加技术面吧，把把关，顺便看看气场合不合。 结果HR部门安排预约出错，HR姐姐来不及赶来了。 组长，一个架构师加上我，三人提前开始技术面。

候选人是一个土生德国码农，w-info专业，20年工作经验，其中七八年是自由职业，期间换了不少咨询公司。 我们一起看了提前一天发给他的任务----做出一个REST项目雏形。 整个项目结构和代码都写得相当规范清楚，基本上各个大方面他都考虑到了，讲解时思路也比较清晰。这么多年自由职业和咨询经验带给他的开发功底，在德国人中算是属于上乘了，毕竟20年还在一线开发的德国人本来也不多见。他强调自己一直热爱编程，业余时间也玩coding。

非要挑什么毛病的话，就是在数据库持久层这里研究的浅了些，只到了CURD那一层，对优化、事务和乐观锁、悲观锁等不太理解，不符合20年的经验；还有在防注入和攻击这块没有考虑。但这些可以完全地被他灵活的嘴皮子所弥补（不愧多年老咨询）。在他讲解以前做过的一个物流项目时，我们构架师突然冷不丁问他能不能把区块链结合进去。他对区块链基础知识事先是有了解的，对这种比较脑洞的问题也都能自圆其说。

事后我问构架，为什么问那个突兀的问题，构架说我就是看看他的应变能力。其实再怎么牛的程序员来面试，你如果想把他给面死是很容易的，每个人的技术面和深度都是有长处和短板的，不可能所有方方面面都精通。如果抓住短板一直深挖，换谁谁挂。

在候选人对申请的职位提问时，他说的一段话我印象很深，大意是：

我做了那么多年项目，发现业务技术非常非常重要，我现在做的项目，基本上编程和业务流程讨论时间对半分。一半时间是在和同事或外包团队协调工作，分析需求，这一部分工作重要也很有挑战性，如果贵公司只是需要一个只会编程的Code Monkey，那么我肯定不是这种人，这些纯Coding的活让印度人来干就好了。

我当时心里一惊，心想这么直白的想法你憋在心里别说呀。其实开发组的刚需是一个能立刻参与开发的Senior，候选人这么说给人感觉是你来了很快就不想干活，从而走PO或者咨询路线。

组长先把公司项目领域介绍了一遍，解释说我们是工业生产领域，业务流程在我们这里是首位，有很多PO和咨询都在一起和开发团队协调工作blabla......直到技术面结束了HR还没来，组长只好顶上充当HR的角色，问了一连串HR面试经典问题。

整个面试结束，告别候选人后，我先说了自己的感觉：“从技术层面说，候选人的开发和技术功底不错，虽有短板但是正常，不过万一他进来不愿继续编程怎么办？” 潜台词是本来就缺开发，再进来个光说不做的，郁闷的是可是我们开发组 。构架和组长说这个没问题，他只是说不想100%时间开发，我们的生产领域的业务你是知道的，是非常复杂的blabla......所以25-50%时间开发都是常见的。

放在五年前，我会不赞同这样的候选人进组，因为开发编程是程序员安身立命之根本，不过现实一次次打脸教我做人。我现在的想法已经变为：开发技能是程序员安身立命之根本，但业务领域是程序员屌丝翻身之途径。再说，能找到一个愿意用25%时间开发的德国程序员，已经可以烧高香了。

在德国各行业的数字化进程中，技术绝大多数时间是为业务服务的，如果业务需求方向错了，落实到技术应用层面就是资源浪费。作为技术的执行者，核心技能既包括技术细节的落地，也包括业务逻辑的理解。上周末听一位参与德国国家电网建设的专家的报告，说当前德国电网数字化系统开发是一边开车一边修车，第三方小公司几乎没有机会参与工程，因为电网的业务流程复杂到爆，只有大公司参与过项目的才理解。

那么什么时候较深水平的技术层面才显得重要呢，那就是整个项目正常运转起来之后的大规模网格化，这时候什么大数据，AI，分布式等等才会发挥作用。 其实工业领域第一线操作员的有些需求，有时在程序员眼里是非常无聊可笑的。 PO曾提过一个需求，就是在生产线上物料系统页面中，当添加新物料时，要让新物料在屏幕下方单独闪烁两分钟并显示属性。

开发人员问： “界面上不是已经很明显地显示了已经更新的物料了吗，怎么还要单独闪啊闪，要不要给你加个跑马灯悬浮飞行特效送你上天呢？ ” 原因是一线操作员不能像办公室员工那样一直盯着显示屏工作的，所以当有新物料送达时，他可能不在屏幕边上。 当他回到工作位置时，需要很醒目的看到新物料达到的提醒，以及详细属性。

有一次PO提出一个需求，就是生产线操作员遇到问题时，界面上要有一个按钮，一点击就可以收集当前的错误日志发到后台。一个Junior开发问：“我们Product Server上不是有完善的日志系统吗？为什么还要多此一举？” 原因是生产线上的IoT硬件设备和软件组件繁多，当出现错误时，单从后台日志很难确定是哪里的问题。而且服务器上日志因为空间限制只能保留15天，而操作员的问题通过客服反馈到开发组时，很可能已经超过15天了。一键收集当前日志的功能，可以让开发组更快地定位错误。

如果程序员不能理解第一线业务需求的逻辑性，那么就很容易变成一个Fachidiot，不能理解也不愿去开发别人提的任何需求。

这里 绝不是 说程序员不要专研技术领域或不要看重编程能力！

至少在德国传统行业数字化领域，除了技术领域之外，业务领域才是重中之重。 说到底，所有以盈利为目的的公司都是业务驱动型，技术驱动可以改进业务，可以变革业务，但不可能取代业务驱动。 很多技术驱动型公司的坟头草，已经三尺高了。

而且，不关心业务的程序员，在德国人眼里，也就是一群可以随时被替代的Code Monkey而已。