工程之丰度与细度

工程之丰度与细度

之前定义了粒度，后来想想，粒度的划分不太清晰，应该再拆分，拆为丰度与细度。丰度和细度，有什么不同？

细度指精细程度，面向微观，内在，把同一对象，深层次细化，0，0.000000***1，…，0.99999***9,1. 可以无限小。

丰度指丰富程度，面向宏观，外在，增加多个对象，水平层次扩张，0，1，2... ，可以无限大。

比如：

一个新买的房子，从毛胚到精装，就是一个细度提升的过程。

这个月在浦东买个房子，下个月买辆宝马，这是对象外部对象扩张，这是丰度。

如果站在围观角度，不管有限无限，跟自己屁关系都没有，就静静地坐着围观好了。一旦要置身于工程中，需要对这两个度，有一个清晰的认识。因为这两个度都有个共性，一旦控制不住，就会变成无限。无限即无形，是无法攻克的，必败。

要攻克无限，就要将其有限化，有形化，在工程中，即划清范围。理论上，清晰与力所能及的范围，是工程成功的保证。但是要注意，将范围清晰化，还有另一个同义词，叫范围细化，细化什么意思？如果细化的范围没有限定，一样是会导致无限化。

所以工程宏观需要范围定义清晰，定义本身的细化程度的范围，同样也要根据项目情况，人员配给，限定范围。

现实中，其实没有绝对的有形工程，都是介于有形与无形之间。一个工程的无形程度，与风险程度成正比。每个无形，都可能涉及丰度与细度，只要有丰度与细度的地方，就有丰度与细度过度的风险。

在it技术领域，有一个词，叫“过度设计”，由于设计发生在深度上，可以理解为过度细化。如果把投入分为高，中，低三级，本来设计到中级，就可以达到产出最大化。从中级到高级的投入与产出没有半毛钱关系，但多出来的投入不只是半毛钱的时候，这就是过度设计带来的风险。所以我说过一句话：

不以解决问题为目的的设计，就是耍流氓。

在程序领域，有一种叫“设计模式”的设计方式，有很多程序员，包括我自己在学习阶段的时候，也干过这样的事情，为研究而使用“设计模式”中的某些设计方法，而事实上，不是因为现实中需要解决问题而用到，只是单纯为自己学习，或者为自己装逼而使用，还有一种是，糊里糊涂模仿着用了，以为用了就是高手…

同样的动因，同样的结果也发生在UI设计，交互设计…可以说几乎每个领域或多或少都存在相同的问题。

如企业管理，有时候看到一些媒体为标榜一些企业牛逼，而宣扬其管理如何精细。衡量一家企业是否真正的牛逼，本质其实只看一点：是否有持久的盈利能力。跟管理精细程度，没有直接关系，从上边的细化理论，管理越是精细，成本越是高昂。而且“收益”只会在一定程度上与精细程度成正比，不可能是无止境成正比，拐点就是边界。

从情怀角度，做事情要做到极致，极致另一个意思也是细化到极致。细化到前无古人，后无来者，让人为之惊叹。从企业经营角度，如果把眼球效应计算在内，细化的程度在成本控制内，也不是不能这样去做。 还有一种可能是，把成本在时间维度拆分，自己一个人，或者家族用时间来承担投入的成本，去追求细化度。比如日本有花一代人甚至几代人磨练一种手艺，有竹艺，刀艺，甚至旧书恢复。但企业不计成本投入去追求细化程度的，很少成功的。因为个人能承担得起自己时间的浪费，企业承担不起。

再如今晚，我定的计划是每天一篇文章，写完才能睡觉，最大的成本，就是自己的身体熬夜承受成本，第二天也还要上班，作为有职业道德的人，又不能影响上班，各项成本限制，就注定我写东西必须要在细化程度上有所控制。不能无止境细化。

总结：

1、 没有绝对的有形工程，都是处于有形和无形之间。

2、丰度与细度在工程中无处不在，风险也无处不在。

 

3、解决丰度与细度风险的办法，就是有形化，划分范围。