作者回复: 👏如果你能总结成思维导图那再好不过了，无论对你自己，还是分享出来对其他人，都很有帮助

作者回复: 👍很好的反思。

极客时间的音频，确实是使用场景确定的，有时候不是不想，而是不能对着电脑屏幕，比如在路上、在开车。

作者回复: 大家目标不一致很正常的，合作，就是要寻找共同的目标，找到折中的解决方案。

举个相似的例子：
我们程序有些功能是通过Http Header的值来控制开启的，某个功能默认是不开启的。

前几天我们测试的同事希望开发能打开这个功能，不需要设置Http Header。开发的同事就不愿意了，因为改了后可能还会影响其他组使用，另外过些天他们测完，估计还得改回去。

所以我问了一下测试，原来他们的测试工具不支持设置http header。也就是他如果能通过其他方式测试也是OK的，并不需要修改默认行为，于是建议开发增加支持通过url参数开启功能的方式，对测试来说达到目的，对开发来说改动也不大，也不影响其他组和后续的维护。

这个例子不一定和你的情况一样，只是作为一个参考，这样下次你也可以尝试思考一下有没有折中的方案。

作者回复: 这是个好问题。理论上来说，需求分析是产品经理的事，但不意味着程序员不需要懂。

具体我在下一篇《19 | 作为程序员，你应该有产品意识》有详细解释，为什么开发也应该懂一些需求分析的知识。

作者回复: 没需求当然不能开工，需求是项目的源头。

没想清楚就开工，然后边做边改也是软件项目一大特色。

不过没有想清楚的需求，第一版最好快猛糙快速原型式开发，另外聚焦核心需求，否则后期变更太痛苦。

作者回复: 是的，很多时候用户并不知道自己想要什么，你得先给他看到一个东西，然后他再会想到更多的需求。

但是如果被用户牵着鼻子走成本就太高了，所以要分析需求，要做原型设计低成本的确认需求。

分析的挺好，音频就是契合用户的各种特殊使用场景的需求。

作者回复: 1. 成本是相对的，需要在成本和满足需求之间寻找平衡。这就好比手机从几百到上万都有，能满足不同层次需求。
游乐场和秋千的差别主要也在于成本的差异。

2. 产品需求也叫产品设计，应该不矛盾

3. 分析隐性需求可参考文中“挖掘真实需求”

4. 可行性研究的基础也是要先了解清楚用户的需求，在根据需求去寻找可能解决方案以及可行性

5. 立项一般是在对需求了解，并做完可行性研究觉得可行之后再立项

6. 似乎没有产品工程师，只有产品设计师。需求分析师一般是去了解业务，了解用户的需求是什么，把专业的需求翻译的让产品设计能理解；产品设计师基于理解的需求设计出来相应的解决方案。

举例来说，建筑行业软件的需求分析师需要懂建筑行业的专业知识，能明白建筑行业的专业术语，同时也要懂一些产品设计和软件开发，他们要把建筑行业的专业需求提取成软件中可行的需求，描述成产品设计师、软件工程师能理解的语言。

作者回复: 提出解决方案阶段，产品经理、程序员和测试一起参与是非常必要的，这样可以协助提出技术上的可行性分析、估算工作量，避免提出一些不切实际或者成本过高的需求。

解决方案写的文档是从客户的需求角度，提出要解决什么问题，比如客户说想要一个交通工具帮助通行。
产品经理写的文档是从设计的角度，提出如何解决问题，比如说设计一个马车。
程序员则是对方案进行具体实施，比如建造马车。

作者回复: 抱歉，暂时没有其他形式的文字材料

作者回复: 不建议你把需求分析和UML放一起理解，UML是一种用来做设计时的手段，是偏向对已经设计好的产品需求进行建模分析的。

收集需求通常是指的用户原始需求，产品经理需要进一步分析处理才能变成最终的产品需求。

用例模型一般是针对已经设计好的产品需求，对用例进行建模。

原型设计只是对产品设计的一种有效手段，但也不是唯一的手段，比如有的程序员，自己在脑子里就能构建出产品的模型，然后代码实现，都不需要借助原型。

作者回复: 建议参考我后面需求变更那一章的策略，比如可以提升客户变更的成本，或者降低响应变更的成本。

另外可以把客户提前确认，在半成品的时候确认时提出的小修改相对容易加进去，正式发布了问题也会少一点。

作者回复: 你说的对，这两个环节是有关联的，所以我在文章的图片是用的环形表示，因为整个过程是迭代进行的，评估后提出方案验证，验证后修改再评估。

作者回复: 👍是的，音频主要还是结合用户使用场景的。
总结是很好的学习习惯

作者回复: 1. 多练练就好了，刚开始肯定吃力，多看看就越来越熟了。
2. 如果不是上学不需要。但是英语不好确实限制很多，比如不便于工作上的交流。

作者回复: 👍是的，其实主要和文章中的知识点“使用场景”相关的。

作者回复: 你可以尝试从用户场景角度再考虑一下：）