技术下午茶：产品经理是如何工作的？如何才算一份好的需求文档？如何设计一个简单的列表，它应该具备哪些基本功能？
前言
经常会被产品童鞋问到关于求职面试相关的问题，作为一只从业经历5年的B端产品汪，再回过头来看待这些标准的面试问题，总是有些不同的感悟。
那么今天就来分享下在产品求职面试中会被经常问到的几个问题，供刚入职不久的产品萌新，或者想要转岗的童鞋作为参考。
如有歧义，以你为准。
1、产品经理是如何工作的？
我们先来看看计算机是如何解决问题的，首先从具体的问题抽象出一个适当的数学模型，然后设计一个求解该数学模型的算法，最后用某种计算机语言编写实现该算法的程序，调试和运行程序，直至最终得到问题的解答。
产品经理的工作方式也类似，首先将具像化问题抽象出一个可以描述用户痛点的用户场景，然后设计一个最优的可以解决用户场景中的痛点的产品方案，最后编写详细产品设计方案，经由开发实现、测试、交付直至最终解决用户的痛点。
2、如何才算一份好的需求文档？
我们先来看看如何评价一个算法的好坏：能正确地实现预定的功能，满足具体问题的需要；易于阅读、理解和交流，便于调试、修改和扩充；即使输入非法数据，算法也能适当地做出反应或进行处理，不会产生预料不到的运行结果；应当考虑算法的时间性能和空间性能。
一份优秀的需求文档参考维度也类似。
首先是正确性，需求文档需要正确地描述产品的功能及其满足的用户场景；
其次是易读性，需求文档是面向于开发人员、测试人员，其书写的逻辑结构必须容易理解并且可实现，而且产品功能不能固化写死，需留出后期扩展的空间；
再次是健壮性，需求文档应该描述各种输入内容下经由产品功能处理后的输出结果，并且考虑到各种用户输入性错误处理和系统判断规则处理，简单的如非空判断，格式错误，编码不存在，编码未启用等；
最后是时空性，需求文档规划的功能需要考虑其时间复杂度和空间复杂度，即时间效率和空间效率。
时间复杂度是产品功能逻辑所带来的系统计算量，运算过程会消耗时间，示例：计算机读取数据效率为1000条/秒，假设读取的数据为组合结构，商品+颜色+尺码，则500个商品，每个商品5个颜色，每个商品20个尺码，数据量为5W，则读取该数据需要50秒。当使用并行20个POD节点，则需要2.5秒即可完成。
空间复杂度则是在系统运算时所占用的存储空间，包含程序运行占用的空间、输入的数据占用的空间，以及一些辅助运算的算法占有的空间。示例：多人同时使用系统，所带来的操作占用了系统进程，后来的操作就需要排队才能执行。
3、如何设计一个简单的列表，它应该具备哪些基本功能？
我们可以先来看看线性表的基本功能：初始化一张不包含数据元素的空表，求表长、读取表中的元素、定位表中的元素、插入一个新数据元素、删除表中的数据元素。
一个常规的列表应该包含增删改查4项基本功能。
- 增为增加，即用户根据列表字段规则输入内容，完成后系统在列表中插入一条数据；
- 删为删除，即用户首先定位列表中的数据行/列，然后删除定位的数据；
- 查为查找，即用户根据某一指定的数据，列表读取并筛选符合条件的数据并更新列表；
- 改为修改，即用户首先定位列表中的数据行/列，然后修改其内容，系统重新赋值更新数据。
了解了基本功能后再考虑基本的交互逻辑，设想下用户常用的操作场景，首先点击菜单入口打开一个列表页面，查看列表数据或是通过筛选条件查看指定数据，找到某条信息后修改或者删除数据，若没有符合的数据，则通过新增数据的方式插入信息。
除了基本的增删改查外，还可以引入批量操作的功能，对某些具有相同业务场景的数据进行批量修改。
另外，列表页面可以有2种设计方式，一是展示一个缺省图，即空白列表，需要用户输入指定筛选条件才能查询数据，常用于数据报表等列表设计。由于其数据量大，查询效率低下且不具有一定业务查询确定性，则可以让用户先提供条件，再根据条件进行查询。
另一种则是页面初始加载指定数据，系统已经按照用户常用使用场景预设好一定的条件规则，并且在页面打开时便展示列表数据供用户查看。这一种列表设计方式常用于数据量少，且具有高频业务场景使用的情况。
未完待续
以上观点仅为个人闲暇之余对于一些面试题的思考。想起以前做面试官的时候，开场来来回回问的也就这些，也没有什么新意，后面问具体做过什么项目以及项目细节才是核心。
在此写下了并分享，算是有做了一次个人复盘，对比以前的回答也有了些许的不同，这应该算得上是一种进步吧～
