产品实习笔记(4)---从一个小需求看用户－产品－开发

这是一个小需求，很简单，商业部的同事反馈一些用户在针对同一个项目时可能会有两种甚至三种的交易币种需求。经过讨论在现实场景中这个需求的确是存在的。那么就需要开始实施，首先，显而易见的是填写页面需要改变。但是等等，难道这件事应该从界面上开始发起推动吗？因为一旦涉及到程序上改动的话就是产品、开发、BD部门共同的问题，所以在开始之前让我们先明确一下问题。
多选的币种，意味着对应多个金额，那么后台程序中利用金额进行匹配这一过程势必要改动，而这改动直接与币种－金额的逻辑挂钩。显而易见，多选的币种－金额实际上有两种解读：1.开放多选，每个币种的金额之间可以不相关；2.开放多选，每个币种的金额按汇率换算。先与开发讨论两者在技术上的难度，1在实现上对表的改动更大，如果考虑三种货币，那么比原来的表至少多两列币种和金额，此外在匹配过程中相当于对币种金额最多进行三次比较。2.如果按照汇率换算的逻辑，在表中金额还是可以只存一个，那么币种来说可以分开也可以一起存，在匹配过程中虽然也是多次比较，但是对数据库操作减少，直接按汇率算即可。难度上1>2。再与BD讨论需求，用户需要多选，那么他们是否能确定需要哪种多选。在BD与用户沟通后大致得到这样的情况：绝大部分针对同一项目的多币种实际上是按汇率直接换算的大概范围即可。既然如此，我们就可以确定2的方案。最后在交互上，可以采用下图的提醒方式。

币种.jpg

感想：这一件小的需求在一定程度上反映了产品的工作职责，提出需求或者收集需求，然后是可行性的讨论，再到实施。我在一定程度上也意识到了一直关于对产品的抱怨，比如在这次更改中如果事先没有评估需求，贸然采用看起来更完整的1方案的话，在开发上将会耗费的更多，但是对用户来说并不是最优的。所以产品跟开发的工作应该是相互配合的，产品的存在应该是提高开发的效率，一旦产品有不明确的方案，那么可能会做很多无用功。