IT外传：老郑和老钱

正式声明：以下内容完全为道听途说，肆意杜撰。请勿对号入座，自寻烦恼。

老郑出门去厕所，瞥了一眼旁边测试工程师的屏幕。

他还在整理Excel表格，里面是老郑参与的项目，上面列满了红红的风险点，像是堵车时的尾灯一般。

老郑刚做了一个智能识别的AI项目。这个项目快提交测试时，老郑还在别的项目组干活。这个智能识别干了没几周，又被调走干别的事情了。

即便如此，老郑开发的智能识别项目，在识别率和识别能力上，在整个业内也是领先。这得益于他长久以来的经验积累以及巧妙的算法设计。

但是，大家却不这么看。即便业内识别率只能到50%，老郑做出了85%，但是大家也会盯着那无法识别的15%。

刚刚测试工程师就在整理那15%，他们要把这15%里的100%全部汇报给领导：你看，这些一塌糊涂，这种情况能不能用？请领导定夺。

言外之意：上线后有问题跟我们无关，风险已经全部抛出来了。

其实……老郑也习惯了。

上次另一个识别项目，老郑把准确率从刚提交测试时的50%提高到97%。而测试工程师在给领导汇报时，开头说识别率很差，只有50%。领导很忙，听完这个结论就走了。剩下一些中层，又听了40分钟他是如何通过围追堵截的测试方法一步步将识别率提高的。

大家都没错，也都很辛苦，这些老郑并不关心。老郑的心情很差，因为有一个同事离职了。

老郑的这个同事，技术能力很强，强到一个人可以顶一个团队。

在体力劳动上，一个人顶一队人可能很难。比如普通的劳工一次扛3袋水泥，有个大力士可以一次扛30袋，而且速度还很快。这很罕见。

但是在科技或者软件行业，这种情况很普遍，但是很少有人被认可。

老郑的这个同事老钱，就是这样一个人。

老钱设计的代码，简洁纯净，他擅长使用中间件和编程语言的特性，代替大量的代码逻辑。其代码格式规范、文档注释清晰。也正是得益于简洁和巧妙，他的效率还很高。同样的功能，其他同事需要3个人写两周，老钱1个人一周就能搞定。

对于速度，这顶多算是多扛几袋水泥，在软件行业，这点贡献算不了什么巨大改善。

关键是老钱写的代码很少出问题。程序员写的代码出了问题（bug），会引发后续一堆人的投入。测试同事会测试，前后端要排查、修改，产品经理要做决策，市场要应对用户的投诉。这bug就像是喂鸽子时的粮食，往东边撒一把儿，一群鸽子蜂拥而至，往西边撒一把儿，西边又密密麻麻。

老钱设计的代码，很少有bug，这一点就避免了三四个部门、10多个人白忙活几周的情况。这个隐形成本的节省是巨大的。

除了代码的设计，老钱还有个优势，那就是有远见和守原则。

项目开发中，会面临很多的技术选型和方案选定。大到使用什么框架，小到一个参数选用何种数据类型。

很多的时候，在进行技术讨论时，老钱会对其他人的方案提出建议。比如一个参数不要传来传去，就要以一方为准，否则会出问题。

其他人一般会有自己的理由，比如，传来传去不用给数据库增加额外字段。但是，往往过不了多久，问题就出现了，传着传着就传乱了。于是大家又聚到一起调试：你传给我啥，我收到啥，又传给了他啥……在广场的空地撒了一把粮食，远处的鸽群放弃了旧粮，急忙朝这里飞奔而来。

老郑和老钱也合作过一个项目。老钱曾经建议老郑不要那么搞，否则会出问题。老郑没听，结果后面确实走不通了，最终老郑还是改了回去，那一个星期白干了。

然而，老钱却离职了。

他的离职半含被迫，半含自愿。首先，经济形势不好，导致公司出现了拖延工资的情况。

其次，在拖延工资的背景下，不同员工的发放情况参差不齐。有的人拖延5个月，有的人拖延3个月，有的人正常发放。而老钱的工资，拖得最久，向领导反馈也没有结果。

领导说，公司现在的回款出现延迟，前年该给的钱，去年才刚刚给。不过，每个月也都是有回款的。这点回款，首先要保证公司的日常运作，其次保证新员工，再次保证有贡献的员工。其他人，只能克服一下了。

好像意图比较明显。老钱也是个智商和情商都在线的人。

老钱提出了离职，领导立马批准，限两周内办好手续。老钱说，我原本打算能有1个月缓冲期的。

其实，老钱和老郑早就被投诉多次了。

甚至连人事都看不惯他们：凭什么这俩人工资比我们高，还不拼命加班？我不平衡……不是，他们没有大局意识！

而同为技术人员，兄弟部门的意见就更多了：再复制一份接口，随便改个字段都不配合！群里半夜@你的消息，为什么没有及时回复？我们换个对接人问你问题，你不培训他，让他看接口文档是什么意思！

老钱和老郑有个观念：用工作时间的高效率工作，换取下班后的安心休息。但是，似乎大家并不都想这样，往往是白天静悄悄，只要一下班，工作群里立刻变得活跃起来。

老郑和老钱有时候就讨论，你说领导是否知道一个员工的真实水平或者价值。

比如，A员工干的活能顶B、C、D，3个人。或者，他手下有个员工的水平在整个行业中处于上层还是下层。

“好像不知道！”

老钱说，交接工作期间，有个问题找来，领导还问他：你也参与这个项目了？

其实就上个月，老钱还在这个项目上干了半个月，日报、周报、早会、周会地定期汇报。显然领导没有关注过，因为没有发生过大的问题。一贯零失误的工作，让老钱变成了一个小透明，而且还是经常提意见的那种问题员工。

一线的员工常常辗转于项目代码之中。领导们则开会，看书，制定考核KPI指标。长期脱离一线阵地，会让领导从业务管理上浮到任务管理（从如何带领人解决问题，变成安排人去解决问题）。

软件其实是一门工程学，而非玄学。

软件工程的最佳的实践是多进行工程管理，而非思想管理。

现实很多情况都是反过来的，大家都很重视思想管理。

如果把完成一个软件项目比作攻下一座城池。那么，策略要比士气更重要。

讲策略的将军会规划好完整的攻城计划。首先，他会盘点自己有多少人员和器械，会分析对方城池有几个薄弱点。然后，部署几个分队：哪个队伍扛着云梯往城墙上驾，哪个队伍推着木车从东门撞击。其实，队伍主力要从北门水路强攻。等到把敌方守卫都引到东门时，以山坡黑烟为号，北门发起进攻。最终全面进攻，一举取得胜利。

类比到项目开发中，其实就是各个工种的配合，结构的定义和数据的流转。安排好整个项目每个端口，从上游拿到什么数据，做怎样的处理，然后给下游如何提供。最终，定好流程和时间节点，一气呵成。肯定没法想得完全周到，不过即便有问题，也都是局部问题，整体还是丝滑的。

讲士气的将军则不然，他不考虑每个环节，或者技术更新太快，他已经不擅长每个环节了。他的主要精力是给士兵做思想工作。他告诫士兵们，我们又要攻打一座城池了，大家要有大局意识，不想当将军的士兵不是好士兵，士兵就是要解决问题的，不是提出问题的。他不关注粮草，不关注器械，不关注目标城池的特征，主要强调大家一定要攻下城池，这是所有人的目标和责任。然后，一声令下，众士兵蜂拥上前，去哪儿的都有。

最后没有攻下城池。将军要求手下将领做复盘，开会讨论为什么没有成功。然后，再次鼓舞大家要有建功立业的雄心。而手下的将领回去也纷纷效仿，告诉士兵们，一定要有建功立业的雄心壮志，遇到问题要解决问题而非吐槽问题，人人都是主人翁，没有粮草你要想办法去搞些粮草。第二次，士兵们又向敌方发起总攻……

这不仅仅体现在软件行业，其他行业也一样，正如一些专家、教授频频发出雷人的言论。

在国内，大家都有上级崇拜。针对如上言论，一般会有人怼你：能当领导的人，必然有过人之处，否则为什么不是你当领导？

其实这句话也没错，还真不是一个把产品做得越好就能生存得越好的环境。

老郑不知道老钱以后会不会改变，正如他不知道自己还能坚持多久。

老钱离职前，曾经问过老郑：老郑，你说那帮“埋头苦干”的年轻人，是以前的我们呢？还是我们的以后呢？