解读软件工程中的”反直觉“现象

- 业务越不行，研发反而越忙 -

这个结论看着不对吧。业务不景气不是意味没有需求要做，研发不是应该不忙才对吗？

但其实恰恰相反，由于业务增长放缓，产品团队不得不做更多的所谓“创新”来止住颓势。要么是不断地拓展产品的边界，在一个应用里加入更多的功能，要么是不断地优化现有功能，比如通过调整排版布局来从心理学角度提高用户停留时长和点击率，要么是进一步优化产品的交互流程，也就是所谓的提升用户体验，从而提升口碑确保留存。

这些所谓“创新”，对应到开发团队，那自然就是有更多的需求。一个需求不能提升指标，那可能就得再来两个，两个不行就来三个，有枣没枣打一杆子万一中奖了呢。一个策略效果不及预期，那下次就得上多个策略同时做实验。这些做法势必就会加剧研发团队的开发压力。

另一方面，由于业务增长放缓，花钱不像以前大手大脚了，人不能继续招了、硬件要考核资源使用率了、研发流程改进与优化也没有优先级了，大家都陷入了短视下的拼命奔跑。总之一句话：对外卷不动了，只能对内卷了。问组织要红利的时代来临，对工程师来讲就是”既要、也要、又要“，所以不比以前忙是不可能的了。

- 软件工程能力提升了，业务依然无法获得成功 -

最近大家都在说要通过提升研发效能来提升软件工程能力，但是你有没有想过，软件工程能力即使很强，就能保证获得业务成功吗？

显然这两者之间并没有必然的因果性。

软件工程能力只能保证研发过程本身的高效，进而保证业务不会因为研发进度而被耽误。但是如果业务本身遇到了增长瓶颈 ，或者业务本身商业模式有问题，软件工程能力是完全无能为力的。但是，倒过来看，当业务高速发展，需要软件系统高速迭代和演进的时候，卓越的软件工程能力就能助力业务的成功。

所以结论是：从业务的角度来看，软件工程能力只能是锦上添花，不能是雪中送炭。

- 大厂的研发热衷于重复“造轮子” -

其中的原因有很多，比如别人的轮子不好用，或者使用别家轮子的沟通成本高，这些都是原因。但究其本质，“造轮子”还是由大厂的绩效考核制度导致的。

在业务研发的稳定期，研发的技术性产出往往不会很多，业务研发更多的是CRUD仔和API Boy，这样想要获得晋升和加薪往往就比较难，只有打造所谓通用能力的轮子才能获得上升的通道，程序员往往戏称其为“以能定级，以轮定能”。

而且即使自己不“造轮子”，别人也会去“造轮子”，最后只能自己背低绩效，卷就是现状。于是，不同部门间重复“造轮子”，同部门的不同团队重复“造轮子”，同组的不同成员也在重复“造轮子” 。

另外，由于基本采用单线评价，一般直接的行政上级有强的考核权。这些都导致研发为了获得高绩效评价而定向“演戏”，“轮子”自然就成为了最佳“道具”。

- 敏捷模式下，架构的黑暗森林法则 -

架构设计和模块抽象只能面向当下，它天然是短视的，或者说是有局限性的，这种局限性即使是最优秀的架构师也是不可逾越的。在敏捷开发模式下这个问题更被凸显了出来。

每个迭代，你能拿到的信息仅仅是宏大视图中的小小一角，根本没有全貌，你并不能像瀑布流开发那样拿到产品的整体视图。仅仅凭借这一点点信息，再牛逼的架构师设计出来的方案也总是有局限性的。这不是人的问题，这是开发方式的问题。

在这种开发方式下，需求本身就是支离破碎的，目标也是模糊和变动的，在没有全局视图的情况下，架构自然就是有局限性的，只能适应当下。而随着项目的发展，只能适应当下的架构就会失效，如果意识不到这个问题，后续在这种失效的架构上进行的任何修修补补和魔改可能都会进一步加剧它的腐化，导致代码更难以看懂。

面对架构腐化，唯一能做的就是在适当的时候进行重构。而重构说白了，就是当事后诸葛亮，当你拥有了到更多的信息后再回过头来看当时设计的局限性，然后再来对之前的设计进行归纳总结，该解耦的解耦，该提取公因式的就提取公因式，同时根据近期的经验预测未来产品的发展方向，去刻意设计一些灵活性。

但重构的收益到底是什么，重构完能带来多少需求吞吐率的提升，你能给出数据吗？你无法度量收益，就没法问业务要资源。

另外，还有一个视角也很重要。架构腐化本质上就是技术债务的积累，但是债务不总是有害的，那些年贷款在北京上海深圳买了房的人，甚至会后悔杠杆没拉满。所以技术债务或许也不是什么坏事，它甚至可以被认为是时代的红利。但是请记住，出来混总是要还的，技术债务也不例外。

- 产研关系越紧张，产品反而做地越好 -

产研关系越紧张，产品反而做地越好，这背后是有坚实的理论基础的。

“产品经理制”最伟大之处，就是做了清晰的权力分割：绝不让研发部门决定产品应该做成什么样。研发部门只管按时、按质完成开发，至于决定产品应该做成什么样的权力，剥离给单独的产品经理部门。为什么？

因为研发部门为产品研发付出了太多心血，每一行代码都是一把什么一把什么做出来的。产品就是研发的心头肉，别说枪毙了，就是骂一句，都等于在要他们的命。

有时研发爱上的不是产品，而只是研发自己付出的心血。一旦研发被心血蒙蔽双眼，研发是做不出好产品的。

那应该怎么办？让一个没有日日夜夜为产品付出心血的人，来决定产品的形态；让一个没有十月怀胎的人，来说这个娃是美是丑。这个人，就是产品经理。必要的时候，产品经理甚至会说：这娃太丑，不要了，重生一个。这是妈妈永远都做不出来的。

所以，产品经理可以更加客观，更加中立地对研发的产出进行评价，以确保终端用户的利益最大化。

-  -

最后，我想说，有时候，资源有限未必是坏事，它是倒逼你创新的最好方式。“因为牌烂，所以能打得精彩。”