1 背景
工作这几年观察到一个非常有意思的现象：有些开发会深陷开发思维。
案例1：纯数据思维：
产品让你做一个导出功能，其中有一项是性别字段字段，数据库存的是0表示女，存1表示男，有些同学导出 excel 时，直接讲值导出为 0 和 1 ，😳......
案例2：已删除问题：
团队中有些同学负责维护员工信息、群信息和部门信息等，员工、群、部门有可能被删除，那么对他们而言，删除之后查询就查不到了。
但是设想一下，对于商家而言，创建一个活动时选择了 5个员工，有些员工被删除之后，再查看之前的某个活动时，只有1个员工了或者1个员工都没有了，作何感想？
或许我们可以做降级，如果查不到员工或群，可以降级为[该员工已删除]、[群已解散] 等字样，如果一个活动出现多个 [该员工已删除]、[该群已解散] 这种是不是也很崩溃呢？
案例3：快照问题：
比如你在做电商平台，用户下单之后产生了争议，如商品的功能和描述不符，并提供了截图，如果提起申诉之前商家删除了商品或者修改了商品描述，不认账，那该如何是好？
案例4：深翻页问题
比如团队做一个查看某个直播的用户观看记录的功能，有些直播可能关键人数特别多。
观看记录包括：用户昵称、观看开始时间、观看结束时间、观看时长、性别、省份等。
产品要求支持跳页，可以翻到最后一页，技术上挺难实现怎么办？
2 启示
2.1 使用角度：以终为始/换位思考
我们做某个模块，想清楚这个功能是给谁用的，如果他用这个功能会有哪些不方便的地方，如果有该怎么改进？
很多开发，尤其是工作年数不多的开发，很容易将技术视角带到产品层面，最后的东西很像是数据库表字段直接映射的管理页面。
我们要站在用户视角去看功能，而不仅仅是技术视角去开发功能。
有了这种思维之后
案例1：我们自然地想到需要将 0 和1 转为对应商家更容易理解的描述。
案例2 的情况我们可以要求底层接口支持查询已删除的员工、群和部门的接口来更好地满足业务需求，给用户提供更好地使用体验。
案例3： 如果我们没有思考清楚业务上要解决的问题，商品编辑后只保存最新版这种“直线思维”似乎也没错。但是遇到纠纷时就很难查证。
我们可以在订单中存储商品的版本，商品每次编辑都存储快照，保存证据。
即使产品没有思考到这一点，我们甚至也可以主动去反馈。
2.2 业务角度：思考价值
站在业务角度可以思考这个功能对用户的帮助的程度，该功能的必要性究竟多大。
思考功能的本质是为了满足用户什么样的要求，权衡投入产出比。
为了满足 案例4的要求需要付出很大的代价或者现有的公司存储方案还不支持，可以和产品聊非要做到这么“极致”的代价。
翻到最后一页，无非是为了看观看时长最长的数据，那么我们提供排序接口不就可以了吗？
产品可能会说商品还有查看所有数据的场景，那么我们提供数据导出的excel 的功能不就可以了吗，商家还可以自己通过 excel 进行个性化统计等。
总结
工作越久越发现很多问题不仅仅是技术问题更是产品层面的问题，开发人员不仅要懂技术，还要思考产品的价值和未来发展方向。
懂产品的技术才可以更好地设计好方案来满足当前需求，应对未来的变化，才能更好地发挥技术的价值。
