人是目的
共 1419字,需浏览 3分钟
·
2021-12-28 01:10
之前看过一些文章有个观点:人是过程,借人修事。
但最近我对这个观点变了:人是目的,借事修人。在很多事情上人对了,事情也就对了。
比如我问一些同学你现在对这个系统打多少分,或者你能把这个系统做到多少分。很多同学可能给了一个比较高的分,给的理由是基于自己对这件事情的认知得来的,也就是说他参照的是自己的能力,而不是业界的水平。
有可能你做的觉得80分的产品,在业界也就是60分的水平,所以一个人的能力真正决定了这个系统达到的水平。
我们知道一件事情从规划、实现、落地是由不同同学参与的,而且落地与实现才真正决定了我们看得见的这个产品及架构,一个系统的架构的上限是由团队的平均水平决定的,而下限是由参与这个系统水平最差的同学决定的。
比如很多系统的架构是由阿里的P8、P9同学设计的,但落地编码是由很多P5、P6同学参与开发的,所以从预期的设计到看得见的落地差异是比较大的,也会导致很多人说的那种PPT架构师的问题,“我接触到的架构和PPT上说的不一样啊?这个架构师是PPT架构师”。
我们在工程架构层面遇到的很多问题,其实都可以抽象为技术债问题。
比如系统维护性差,牵一发而动全身,系统稳定性差,经常出现抖动、故障,交付延期,修改、测试、交付成本都非常高。
我们拆开来说可能觉得是代码问题、设计问题、需求问题,但归根接地是人的问题。
为什么有的系统稳定性好呢?为什么有的系统交付快呢?通过上图我们会发现,随着时间推移,一个系统会变得越来越好,有的会变得越来越差。
好的系统中每一个好的设计和思考,都被很好的实现到了代码里面,这样持续积累下来的就是一笔笔可观的资产,时间越久,价值越大。
如果反过来每次代码实现都和预期相差甚远,那么持续积累下的就是庞大的债务,大到连利息都还不完,我们的时间就被这样一点点消耗。
怎么解呢?
光靠架构设计,代码模式这种外在的术是很难根本上解决的。还是需要提高大家的内功,也就是人的能力维度。
如果每个产品同学都可以在需求阶段进行了非常好的评估,每个需求都是很有用户洞察可以真正解决用户问题的需求,每一个被交付到研发同学手里的需求都是有价值的,那对应的投入就是有价值的。
如果每个研发同学的每个设计方案都可以考虑实现、维护、下线的成本最低,后续我们处理债务的几率就非常低,效率也会高很多。如果每一次迭代都做了很多有价值的小的优化,那么系统长期下去就会不断向好的方向发展。
张一鸣说过:一个人对一件事情的认知是真正决定这件事情的,其他生产要素都是可以构建的。
在职场中我们需要提升的认知范围非常大,我们的专业素质,软素质都是需要不断提升的,这是一场无限游戏。
同时需要刻意练习,学习、训练、反馈这三个齿轮应该在日常生活中无时无刻不在转动。
这也是很多好的老板在做的事情,好的老板真正要做的事情是打造一个有战斗力的团队,团队是由人组成的,每个人都有是需要被打造的,也就是说好的团队人仍然是根本。
所以很多时候要学会借事修人,就是在做事的时候不能简单的结果导向,或者目标导向,要看在过程中人成长了哪些,认知是否有提升。
当一个个的人被塑造了起来,这个团队可以低成本、有默契、高效率、有质量的做很多事情,交付很多事情。