乔布斯的名言“顾客并不知道自己想要什么”通常是在讨论产品创新和市场研究的语境中提出的。他认为，消费者往往不能准确预知未来科技的具体形态或功能，因为他们缺乏足够的知识和经验来理解和预测技术的可能性。这种观点暗示了发明新产品的过程与满足现有市场需求的研究是不同的，后者可以通过市场调研等方式来实现。

乔布斯的这句话更多是在强调技术和市场的复杂性以及创新的不确定性，而不是说消费者完全不知道自己想要什么。相反，他的意思是提醒企业在开发新产品时不要过分依赖市场调查，而是要勇于冒险和对未来的信念。

以个人的理解：

1、每个客户是站在自己的视角的，而产品经理应该站到整个行业的视角。

2、产品经理要根据市场情况、技术的可实现性、客户的反馈、自己的概括总结、可能的创新点，有一个新产品定义的雏形。

3、有了新产品的定义雏形之后，千万不要闭门造车，应该不断地针对α客户的反馈修正产品定义模型。产品定义会渐进明细。

4、当α客户能够给予非常正向的反馈，并帮助修正细节的建设性意见。那么产品定义大概率成功了。

所以，我们没有乔布斯的天赋，就需要有正确的战略指导、脚踏实地地收集和整理客户反馈、不断地迭代和成长。

我们需要做好：看趋势、看客户、看竞争对手、看自己

然后做好策略制定：定机会点、定目标、定策略

开始打仗前做好：战役制定，五个明确，明确目标、明确策略、明确措施、明确团队、明确计划。

我们需要从原始需求提炼出来我们定义产品的实际需求点，形成需求表。

在落实将需求点落实为“产品规格”的时候，需要做好外部输入的管理，客户需求变成产品规格是总体设计输入的一部分，我们还要以“内部视角”从产品自己演进原则，设计规范等角度梳理出设计约束。

例如，我们为什么选这个处理器，为什么需要8核，是否需要NPU，NPU的算力能力需要多少TOPs，需要多大的内存。

除了我们的处理器选型，还需要考虑公司内部技术归一化、产品规划、能力储备，否则我们很可能在整个过程中卡死。

首先要把产品的业务需求进行转化，变成硬件系统和模块要达成的规格目标，最后要形成产品规格全景图，需要确定的硬件规格包括产品的关键业务处理能力要求、处理器要求、业务接口的要求、管理接口要求、产品体积大小、电源规格要求，整机规格要求等等。

用户需求（ user requirement ） 描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

首先，对于用户需求，不要主观臆断，闭门造车，有的研发人员往往主观臆断出一些需求，因为程序员、硬件工程师往往会把自己放在客户的角色上，但是开发人员往往不具备客户的行业经验，或者不具备客户使用产品的场景。用主观意识去使用和认知产品，往往就往往不符合客户需要的原本的模样。

另外，对于运营商产品，客户的表述往往就是用户需求，因为客户是长期从事相关产品的使用，属于专业人员，专业能力较强，而且产品往往配套培训和材料；但是对于个人消费品或者是一些企业用户，用户说的往往并不是用户需求。因为

由于开发人员往往会把自己放置在用户的角度思考，往往就会出现需求的范围蔓延，无端的增加了很多原本没有讨论过的需求。避免需求在开发过程中的走样。往往我们需要进行“范围管理”。

项目范围的管理也就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。它包括用以保证项目能按要求的范围完成所涉及的所有过程，包括：确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理以及范围核实等。项目范围是指产生项目产品所包括的所有工作及产生这些产品所用的过程。项目干系人必须在项目要产生什么样的产品方面达成共识，也要在如何生产这些产品方面达成一定的共识。

范围管理的目的是在项目开发过程中，出现范围蔓延。制约一个项目的条件是项目“三约束条件”——范围、时间、成本。

范围的蔓延，势必影响项目的时间和成本。

在一个项目中这三个条件是相互影响、相互制约的，而且往往是由于范围影响了时间和成本。项目一开始确定的范围小，那么它需要完成的时间以及耗费的成本必然也小，反之亦然。很多项目在开始时都会粗略地确定项目的范围、时间以及成本，然而在项目进行到一定阶段之后往往会变得让人感觉到不知道项目什么时候才能真正结束，要使项目结束到底还需要投入多少人力和物力，整个项目就好像一个无底洞，对项目的最后结束谁的心里也没有底。这种情况的出现对于公司的高层来说，他们是最不希望看到的，然而这样的情况出现并不罕见。造成这样的结果就是由于没有控制和管理好项目的范围。可见项目的三个约束条件中最主要还是范围的影响。

产品工程过程分为需求分析、概要设计、详细设计、编码、测试、安装试运行、验收等七个阶段，项目保障过程包括项目计划、项目跟踪与监督、需求管理、质量保证、配置管理、同行评审等保障性工作过程。上图也体现了各个环节对需求的控制和理解，这个过程管理的。

功能需求（ functional requirement ） 规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（ behavioral requirement ），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。

对于硬件项目，在项目启动后，会写一个《需求规格跟踪表》。

需求为什么需要文档化呢？

Ø开发人员通过文档化的过程查错补遗；

Ø便于评审，在早期发现技术上的问题；

Ø后续阶段开发任务可能由他人承担，输出文档便于他们开展工作；

Ø维护人员开展维护工作需要；

Ø文档是必要的交付件；

“所有的过程分析都要形成文档。我们现在有一个严重的问题是，大家好像不喜欢写文档，对于需要的实现方案，通常都是一个负责人在脑袋里想想该怎么实现，然后邮件或电话找几个相关人员讨论一下就算可以了，可能连个会议材料或会议纪要都没有。而老外可不是这样的，他们非常非常重视文档，他们认为一个人在脑袋里想的东西是不清晰也不全面的，有时候心里想的认为很正确的方案实际上可能存在致命缺陷。他们要求必须把心里的想法形成文档才能有效地避免这种问题。写文档的过程中，可以更加有效的、更进一步去整理您原来思路，很多问题在您写过文档的过程中您就能发现；另外，文档写作多使用图表，浪费口水的文字尽量少用，和我们一起工作的系统工程师在系统架构分析中就画了五六十张图，就算看不懂他写的英文，从图中我们就能够很清晰的指导整个产品的系统架构。”

——摘自一位华为员工的瑞典出差报告

上面的表单的后面几列是在开发的各个阶段去检查，原先确定的需求、规格等数据是否变化。例如在原理图、PCB、测试阶段，去检查是否出现了需求丢失，或者发生需求变更。如果发生需求变更，需要记录原因，决策者。

系统需求（ system requirement ） 用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。最终决定市场对产品的综合评价是否满意。

对有很多子系统的巨大产品进行跟踪能力管理是一项巨大的工程，但这很必要。并不是所有的公司都会因为软硬件问题而造成严重的结果，然而应该严肃地对待需求跟踪，尤其对涉及你业务核心的信息系统。考虑了应用技术的成本和不使用的风险后，才能决定是否使用任何改进的需求工程实践。随着产品的发展，要把时间投向回报丰厚的地方。

需求管理系统包括模型管理、与WBS关联、版本管理、条目化管理、需求追踪、需求控制、模板管理、统计查询功能，系统组成结构如下图所示。

需求管理和需求跟踪是研发工程师的入口，所以我们需要重视和理解。

如何避免硬件项目进度拖延

好的管理是“过程管理”

项目成功的精髓：做好价值管理

研发KPI迷思

绩效管理

了解全流程开发，可以了解这本书

有没有一本书读后，相当于华为工作十年经验？