【电子通识】如何写好一份硬件工作经验总结文档？

阳光宅男@李光熠

于 2024-05-02 08:30:00 发布

阅读量65

点赞数 26

分类专栏：硬件文章标签：经验分享学习

本文链接：https://blog.csdn.net/weixin_51792779/article/details/138373179

版权

硬件专栏收录该内容

129 篇文章 47 订阅

订阅专栏

我们在工作中不可避免会碰到一些复杂的硬件问题，这些问题可能出现在项目研发过程中，也可能来自客户的反馈。

当困扰大家很久的棘手问题被解决完后，如果被总结成一篇文档，这样不仅方便他人获取到我们总结的经验，还能提醒别人在项目中避免犯同样的错误。因此，这种写文档的能力在公司是很有必要的，也是必须的。

本文在https://mp.weixin.qq.com/s/pgvR4N9TUbZYp6uvGY0p9w基础上融入了自己的一些思考与实践中的收获。

写上背景

大部分人写经验文档，会按照时间顺序，写下这个单板或电路出现了什么问题，自己做了哪些工作，电路又是怎么变正常的。按照调试的过程，记录了一些波形，这一篇经验总结就写完了。我们叫这种写法成为记流水账。

记流水账型的方法，最常见的使用场合是记录一天的工作内容，方便自己下班前查看这一天做了哪些事。但是这种记流水账的方法用在写问题解决后的总结文档上，不是好的选择，那应该怎么写呢？

经验总结最大的作用是让别人知道这个问题是在什么样的情况下出现，在调试过程中，具体做了哪些措施，问题的直接原因，根本原因是什么，在后续的项目中怎么做能有效避免。因此，记流水账，很难将上面的几个点包含进来。

一篇好的经验总结一定要写清楚背景，是什么项目，什么设备，是什么单板，是哪些模块的哪个电路异常了。正常工作是什么样的，异常的现象是什么样的，什么样的情况会触发异常情况。我们称之为背景。下次记得在总结文档上写上问题的背景。

写出结论

当我们写完背景后，常规的思路是开始贴出电路，放上波形，然后分析这种异常现象的原因是什么问题导致的。先分析直观原因，直观原因写完以后，会逐步深入，写到根本原因，等根本原因写完了，会给大家一种恍然大悟的感觉，然来是这个原因导致的！上面的写法我相信很多人用过，包括我自己。但是后面渐渐地发现，这种方法其实不对。

工作中除了经验总结文档，还有一个比较常见的场景就是做问题总结汇报，如果我们的PPT也按照总结文档的思路来一步一步呈现问题的解决过程，先背景，再直观原因，再根本原因，再结论，那么报告的结果，可能达不到我们想要的结果。

为什么这么说呢？上面这种写法，对于写文档的人或者汇报的人来说，是在按照问题分析进展过程进行描述，在逻辑上其实没有任何问题。但是对于读者或下面的评委来说，看到这样的文档或者汇报，他们像在读东野圭吾的小说，读者和作者在一起找问题的原因，一起破案。

所以，在工作中，并不建议这样做，无论是写文档还是PPT汇报，建议在写完背景后，直接给结论，把导致这个问题的结论给出来。然后再分析原因。 为什么说写完背景就要给结论？读过《金字塔原理》这本书的应该都知道，作者讲述了职场很重要的一个思维——结论先行。

经验总结在开头结论先行有两个好处：

（1）如果你所总结的问题，人家刚好以前遇到过，那么不用读完全文才知道结论。

（2）带着结论去看问题，会引发读者更多的思考。然而，如果一开始不给结论，破案式的文档或者讲述方式可能会让读者注意力都在好奇上，大脑里面更多想的是到底是什么原因，而忽略了你在讲什么东西。下次记得在给老板汇报你终于解决了一个非常棘手的，涉及软件，硬件，算法这样多资源的问题时，讲完背景请直接说结论。

分析原因

上周同事给我看他的文档，他写的原因分析就是在已知结论情况下，将几个重点的怀疑点和排查点进行描述，加上了一些波形。对于那些不了解整个问题的解决过程来说，当前写的内容好像一切是那么合理，整个分析都很顺利。但事实是，在分析的时候，可能走了很多弯路才有当前的结果。

大部分人在写这种问题被解决后的总结文档，只是在文档中呈现了最终最正确的那个结论。而在这个过程中，多次的尝试，多次的分析，多次的思考，并没有写上。相比最后呈现的正确结果，实际的分析过程对后面的看文档的人才是最重要的。

这也是我自己比较喜欢思考的问题，我看了他的总结，我能学到什么。于是，我和同事说，写总结文档有两种思路，一种是写给自己看，一种是写给别人看。前者更多关注自己做的事情，后者更多关注的是结论。然而，其实还有一种思路，把自己的分析思路清楚地表述给别人看。无论是写给自己看，还是写给别人看，常见的文档会呈现出看着每一步都是正确的，问题被这样解决是很自然的一件事这种现象。主要原因是他们想不就是一篇总结嘛，反正只要自己知道根本原因就行，至于当时怎么思考的，没必要写出来，只要最后给了正确的结论就行。但是我不这么理解。

经验总结，在写的过程中，你要把当时自己是如何思考的，做了什么尝试，得到了什么样的结果写出来。在写的过程要重新梳理和总结，当时使用了什么样的方法，哪些方法用的对，哪些方法用的不对，导致走了弯路。对于他人而言，更重要的是学习在这篇案例解决过程中，你使用的方法和思维，而不是一个正确的结果。同事听完我的理解，对此也认同。对于自己而言，这个总结文档是自己对方法的总结，对思维方式梳理，对方法论的提炼。这个复盘的过程，可以让自己在后续面对类似的问题，快速能从大脑中提取这一次的经验。如果没有经过前面深入的分析和总结，很难在下次遇到问题时快速提取这么内核的思考。 因此，这些深层次思考的东西，才是核心内容，至于最后的结论，如何有效避免这种问题在项目中发生，其实并不那么重要。干硬件的都知道，同样的电路都可能出不一样的结果，学结果没有用，硬件问题解决一个还有一个，只有学思路和方法才能以不变应万变。