随想002：设计规范_规范的制定者,拥有最理解
赞
踩
经理们大都喜欢成文的规范。嵌入式程序设计规范、原理图设计规范、PCB设计规范...
但是
试图用规范来消除重复错误的尝试可能是徒劳的！
规范能够起到多大作用，取决于研发人员的理解程度和执行程度。
知与行，缺一不可。
问题往往出现在对规范的理解上，规范制定者表述的内容与规范使用者理解的内容会产生偏差。
出现这个现象的原因是知识层面的不对等。
就像一个厨房新手熟读各种菜谱也做不出星级酒店的风味来。
不理解规范会带来问题。
如果对一个事物理解的不够透彻，看到的只是局部，是一个个离散的点或线段，形成不了知识面，容易产生错误观点。就像盲人摸象一样，摸到耳朵的就认为大象是蒲扇、摸到腿就认为大象是柱子...这些都是错误的观点。
所以仅仅制定了规范是达不到目的，规范必须要宣贯：向规范使用者宣传并使他们透彻地理解。
宣贯的难点是如何做到有效的信息传递（避免信息衰减）以及让没有背景知识的人理解规范的含义（避免信息失真）。
如果一个事物我们没有亲身体验过，只是靠语言描述，是很难理解的。就像你无法向盲人解释红色是什么一样：必须亲眼看到了，才能知道其含义。
对事物的理解过程，大都是从错误中学习的，如果没有遇到错误，可能都不会意识到其中蕴含的道理。这也是绝大多数人总是在产品出现危机后，才会改进、才会进步的道理。因为在危机发生前，他是没有问题意识的。
通过对危机事件的处理，会对这个问题的理解程度加深，这是进步的表现。
换句话说，大部分人类需要经历修复错误的过程，才更有可能避免类似错误！所以如果将消除重复错误的希望寄托在一个文档上，恐怕带来的只有失望。
基于上面现状的思考，我有了一些推论：
推论1：试图用规范来弥补新人缺失的经验是行不通的，换句话说，新人必定会失败【注1】几次才堪用。
对规范的理解能力是要在实践中积累的，然而新人缺乏的就是积累，所以更难理解规范。就像刚开始烧菜，总是要经过手忙脚乱的过程，不清楚放多少油盐酱醋合适，更不要提火候。而比不能理解规范更糟糕的事情是误解规范。
如果我们要备份数据，比较安全的做法是在相距很远的不同地方放置备份数据，比如在北京放置一份、苏州放置一份、贵州放置一份，最大限度地避免天灾人祸把这些数据一锅端。但有些新人不能够理解这个道理，知道数据需要备份，但会把数据备份在同一个地方。
失败虽然意味着产品上的不成功，但它培养了人才。所以新人失败并不意味着对公司损失很大，真正损失大的是新人蜕变成工程师后，他离职了。
注1：这里所说的失败通常在短时间内看不出来，新人是完全可以做出符合功能的产品来，但长期稳定性可能不足，表现为发布的版本经常出现错误，更重要的是增加新的需求可能会很艰难，甚至要推翻重做，这种产品是失败的。
推论2：让某个研发人员跨领域接手一个项目时，要给他理解这个项目原理的时间
如果经理希望换一个研发人员去拯救一个面临失败的项目，一定要给研发人员充足的时间去了解项目的系统原理，不要马上修改电路或代码，因为只有理解了系统原理，才能合理设计和迅速排错。
经理要有耐心。你心里知道这个项目是烂摊子，你心底更深的地方也知道收拾烂摊子并没有什么速效方法，所以不要着急出结果。
推论3：如果员工在某个领域做得非常好，不要随便将他调岗
熟悉一个领域，是用多次失败的代价换来的，给他调到另一个领域，他会变成那个领域的新人，必定会重来一次用失败换理解能力的过程。
推论4：新产品的前几个版本一定会有问题，做好应对准备
对需求理解不够、对现场环境理解不够、对逻辑的思考不够、程序存在BUG等等，新产品或多或少会出问题。所以要有小批量试制、要找几个现场环境做工业性测试等等，控制问题出现的范围。
读后有收获，资助博主养娃 - 千金难买知识，但可以买好多奶粉 (〃'▽'〃)
