人是目的

之前看过一些文章有个观点：人是过程，借人修事。

但最近我对这个观点变了：人是目的，借事修人。在很多事情上人对了，事情也就对了。

比如我问一些同学你现在对这个系统打多少分，或者你能把这个系统做到多少分。很多同学可能给了一个比较高的分，给的理由是基于自己对这件事情的认知得来的，也就是说他参照的是自己的能力，而不是业界的水平。

有可能你做的觉得80分的产品，在业界也就是60分的水平，所以一个人的能力真正决定了这个系统达到的水平。

我们知道一件事情从规划、实现、落地是由不同同学参与的，而且落地与实现才真正决定了我们看得见的这个产品及架构，一个系统的架构的上限是由团队的平均水平决定的，而下限是由参与这个系统水平最差的同学决定的。

比如很多系统的架构是由阿里的P8、P9同学设计的，但落地编码是由很多P5、P6同学参与开发的，所以从预期的设计到看得见的落地差异是比较大的，也会导致很多人说的那种PPT架构师的问题，“我接触到的架构和PPT上说的不一样啊？这个架构师是PPT架构师”。

我们在工程架构层面遇到的很多问题，其实都可以抽象为技术债问题。

比如系统维护性差，牵一发而动全身，系统稳定性差，经常出现抖动、故障，交付延期，修改、测试、交付成本都非常高。

我们拆开来说可能觉得是代码问题、设计问题、需求问题，但归根接地是人的问题。

为什么有的系统稳定性好呢？为什么有的系统交付快呢？通过上图我们会发现，随着时间推移，一个系统会变得越来越好，有的会变得越来越差。

好的系统中每一个好的设计和思考，都被很好的实现到了代码里面，这样持续积累下来的就是一笔笔可观的资产，时间越久，价值越大。

如果反过来每次代码实现都和预期相差甚远，那么持续积累下的就是庞大的债务，大到连利息都还不完，我们的时间就被这样一点点消耗。

怎么解呢？

光靠架构设计，代码模式这种外在的术是很难根本上解决的。还是需要提高大家的内功，也就是人的能力维度。

如果每个产品同学都可以在需求阶段进行了非常好的评估，每个需求都是很有用户洞察可以真正解决用户问题的需求，每一个被交付到研发同学手里的需求都是有价值的，那对应的投入就是有价值的。

如果每个研发同学的每个设计方案都可以考虑实现、维护、下线的成本最低，后续我们处理债务的几率就非常低，效率也会高很多。如果每一次迭代都做了很多有价值的小的优化，那么系统长期下去就会不断向好的方向发展。

张一鸣说过：一个人对一件事情的认知是真正决定这件事情的，其他生产要素都是可以构建的。

在职场中我们需要提升的认知范围非常大，我们的专业素质，软素质都是需要不断提升的，这是一场无限游戏。

同时需要刻意练习，学习、训练、反馈这三个齿轮应该在日常生活中无时无刻不在转动。

这也是很多好的老板在做的事情，好的老板真正要做的事情是打造一个有战斗力的团队，团队是由人组成的，每个人都有是需要被打造的，也就是说好的团队人仍然是根本。

所以很多时候要学会借事修人，就是在做事的时候不能简单的结果导向，或者目标导向，要看在过程中人成长了哪些，认知是否有提升。

当一个个的人被塑造了起来，这个团队可以低成本、有默契、高效率、有质量的做很多事情，交付很多事情。