外甥打灯笼，今晚照旧和产品一起碰下周要迭代的需求。
其中一个需求是要对接新的支付渠道————北京农商银行。北京农商提供了T0结算请求接口，接收批量要结算的支付单号。溢+之前未对接过这种场景的结算。就是说，如果溢+给一些T0商户配置的渠道路由是北京农商，那么，这些商户在溢+的支付单的结算需要我们溢+来触发，即溢+要把结算的支付单发给北京农商，北京农商进行结算出款给商户。
入职不久的支付产品经理刚介绍完这个接口，冠林说，那就是要在oms里的支付单列表页，让运营批量选择支付单，然后我们程序拼接支付单发起请求。中威接着说，那多麻烦啊，直接弄个全选多好啊，运营只需要一页一页的翻，然后点全选，我们程序就把这一页的支付单拼接起来发起请求。大家积极思考实现方案的精神值得点赞。产品经理听着大家的看法，没有言语，似乎有种插不了话的感觉。程序员多数是直性子，不绕弯，包括我。我立即抢着说，肯定应该是这样的，应该是让运营人员选择商户和日期，然后点按钮就ok了。运营只需一次点击操作，然后我们程序来按照要求分批次调用接口发起结算请求。产品经理听完，点了点头。大家也不再争论了，默许了我的看法。这时，我注意到一个细节，我的老大投来了异样的眼光。
页面原型呢？按我的想法，是新建一个页面，简单来设计是下面的样子。当然，不如更详细一些：做一个列表，显示商户、日期、订单数、总金额等信息，每行后面加一个结算的按钮，这样更便于运营操作。
注意，上面页面的title是“北京农商T0”。由于目前只有北京农商有这个需求，所以，不妨先这么“写死”。待日后有新的渠道也有这样的结算需求的话，我们可再扩展也不迟。我认为，这才是迭代。
为什么？
溢+支付是公司刚投产不久的项目，还有很多的事情要尝试、摸索、探索，项目内缺乏专业的支付人才包括结算、运营、产品和技术，对于创业公司的这种项目，而不是总是想着大而全。那样只会耗费人力和时间成本。单就支付渠道对接来说，我们对接的渠道也有十几家了，但是，目前在商用的也就是中信、易宝的支付和代付，更多的对接工作变成了无用功。这其中，大家免不了相互吐槽，带来负能量。所以，小步稳跑或许才是比较好的节奏。
