大家好，这里是大话硬件。今天想给大家分享上周末在家写的读书笔记，内容来源于重读《硬件十万个为什么——开发流程篇》这本书的一些启发和总结。

1. 为什么我要重读这本书籍？

这本书收到快递的时间是2022.8.26，拆开快递的那个晚上大约花了2个小时从头到尾快速浏览了一次，感觉好像没写什么东西，没有硬件技术，没有理论公式，因此就将书搁置在了一边。

上次是粗读，所以我一直告诉自己，要找个时间再读一下。上次还有好多东西没有看到，也没深入的理解，做笔记。于是这周末就在家重新读了一次。

这篇文章主要是结合书籍前3章的内容，加上自己对本书的思考和总结。

写的内容不能保证全部一定都对，所以非常欢迎大话硬件的同学们质疑，可以一起交流。

2. 为什么这本书的目录有10章内容？

首先，大家看看这本书的目录。目录总共写了10章，剔除第一章的概述，剩下的9章我们看下每章的标题讲了什么。

仅仅分析标题，不看内容，我想这9章的内容咱们需要拆分成两个部分来看。两个部分其实作者在传递不一样的内容。（有点像废话，哈哈）

第一部分，也是我看到的第一个维度，是第2章~第8章。这七章的内容讲项目开发流程，当然也包含了硬件的开发流程，按照典型的硬件项目开发流程顺序写的。第二部分，也是我看到的第二个维度，是第9~10章。这两章讲的反而不是具体的流程，作为一名硬件工程师，其实可以完全不用在意后最后两章的内容。反正你是介绍开发流程的书籍，前面你都写完了，我知道就好了。

于是，我就在想，为什么作者要写出最后两章呢？如果你第一感觉是凑字数或者认为可以去掉，那可能没有真的理解这本书的逻辑。所以，我不认为最后两章是凑字数，反而，我觉得最后两章很重要！

为什么这样说？

我想，作者是站在了更高的维度来写的后2章！

最后两章的内容，明显，而且完全就不是从一个硬件工程师的维度来写的！更像，几乎就是从一个管理者的角色，可以是硬件主管，也可以是硬件总监的维度来写！

为什么会得出这样的结论？

理由很简单，团队建设一般是对管理者工作考核的维度，在你还不是管理者，是执行者时，几乎很少，甚至也不需要，也不会从团队建设的维度去思考问题。

硬件工程师，干好你的事情就好，至于团队需要多少人，团队建设的好不好，和独立的个体硬件工程师有啥关系，你说是不？难道你说招聘谁来，谁就能来的嘛，显然不是呀，对不对。

所以从这本书的标题，我有这样的启发：

作为一名硬件工程师，在执行者的阶段，需要对2~8章的内容掌握；当工作到一定的年限或者有机会成为管理者时，这时候9~10章的内容就是我们可以努力提升的方面。

因此，当你角色即将要发生变化，或者在你不知道如何准备来面对这种角色的变化时，9~10章的内容就是一个突破口，也是能力提升的方向。

所以，我说最后两章最重要，一方面是基于前面分析的最后两章能提供我们能力成长的突破口，另一方面是思维的转换。

读最两章的内容，我们的思维需要发生转变。2~8章的内容是你让我按照流程这样做，我就按照流程做；而9~10章的内容是你要想着让别人怎么做，甚至是怎样做会更出色。这种思维的转换，才是最难的东西，也是最有价值的东西，不然培根就不会在《习惯论》中说，认知决定了思维,思维决定了行为,行为决定了最后的成果。

3. 第一章：为什么公司要那么多流程？

如果将流程比作是写文章，制定公司的流程就是文章的框架，开头，过渡段，结尾，流程都帮你安排好了，你要做的就是在流程要求下，填素材，加内容。

所以，在书中作者介绍了流程有下面3个作用：

（1）员工的动作标准化，通过流程来规范行为，按照流程来就行；

（2）项目结构化，通过流程进行拆解任务，有章法，有计划，有保证；

（3）建立流程开发的文化，员工都认同按流程做事，比较高效；

当然，流程的好处还有很多 ，比如，流程可以作为和其他资源对接的渠道；流程执行的过程可查；流程可以使成果归档化等之类。

那是不是流程就完全没有坏处呢？

我认为全依赖流程也有一定的局限：

在风险管理或者是需要创新时，流程会固化大家的思维，僵化动作执行的顺序。在降低风险的情况下，风险管理经常需要做出与平时不一样的动作，但是流程可能就要求不允许。

比如在新器件导入时，我们需要先提流程，才能往下继续执行，而继续往下的时候需要牵扯多个资源组。这个时候，如果一直等流程可能会影响正常的开发，有时候需要灵活变通。

4. 第二章：如何进行立项？

如何立项，作者在书中提出了5步法：

硬件工程师要参与立项？

作为硬件工程师，更多时候是执行者。大部分都是产品经理提出需求，项目经理立项，我们来实现。

按一般的项目发展方式，立项更多的是SE，产品经理，项目经理，产品BP来做；那么，硬件工程师在这个阶段所能参与的程度有限。

可能有些硬件工程师和我一样也有这样的想法，我一个搞硬件的，你跟我说立项，扯的有些远了吧！其实不然，试想现在你们部门现在要开发一个新产品，没有技术，没有方案，没有任何基础的条件下，但产品就是要干出来。

那在立项时，必须要有硬件工程师参与，而且还要输出如技术方案，方案可行性，初步成本评估，竞品分析等等之类的成果。在收集各资源组的信息后，产品才会做出综合评估，然后开始立项。

所以硬件工程师在前面的参与度其实是可以非常高的！

硬件工程师怎么参加立项？

在回答硬件工程师怎么参加立项之前，我们需要明白立项的意义是什么——最大化项目的商业价值。那什么样项目是具有商业价值的呢？从我的理解角度，一个具有商业价值的产品，至少，至少，至少需要满足下面3个方面吧：

所以，作为硬件工程师，在这本书中，我得到了启发，硬件工程师在参与立项的时候，可以从下面3个方面发力：

在这一章里面有很多关于立项需要考虑的问题，我没有读，我留着等后面遇到需要竞品分析的时候，遇到需要找竞争对手的时候，再回头看！

5. 第三章：需求是什么？

对产品来说，需求是最重要的，也是龙头。一款产品之所以诞生是因为有需求，而需求来自哪里？通常可以将需求分为三个层次。

将需求变为产品的过程中，必不可少的就是收集需求，收集需求之前需要将不同的需求进行分类，因为不同的需求适合用不同的方式来进行收集。

我们经常遇到这样的现象：产品做出来以后才发现在市场上不好卖，而造成这种局面的主要因素就是需求收集不全或者没有真正理解客户的需求或者是理解的有偏差。

有些硬件工程师在项目开发中经常会抱怨需求改来改去，光图纸就迭代了七八个版本了， 刚把这个方案的原理图画好，项目经理过来说需求变了，于是又要从新来过。

如果我们能理解做项目的过程其实就是在不断完善需求的过程，有些客户他自己可能都不知道想要什么样的产品，所以在收集的需求的时候，要多次和客户进行确认，渐进明细。

但是软件项目相对就会好一点，他们可以有多种方式来规避这种情况，比如使用原型法，或者敏捷项目管理的方法，发布多个版本，上午的版本有问题，下午就可以升级覆盖。而硬件没办法像软件那样快速迭代，经常是使用瀑布模型进行开发，环环相扣。所以，硬件在完成总体方案设计的后，最好拉上项目经理一起进行评审，对需求进行双向的确认。

补充一下原型法和瀑布模型，属于项目管理知识。

以上内容即是对前面3章内容的读书笔记，欢迎一起交流！