项目复盘平台需求的批量操作功能

　　本文是一个PaaS平台设计的一个复盘，笔者结合了实际的设计过程一一分享。
　　一、背景
　　PaaS平台，公司内部产品线的名称。PaaS平台即服务，我的理解差不多就是中台，只是在叫法上有所不同。平台能力覆盖范围很广，这个需求只是其中UI框架层部分。
　　批量操作功能web端已有，本次只是mobile端的能力拉平。需求来源于多个业务需求，比如，审批流程中的批量同意、批量拒绝，工单流程中的批量签名等等。
　　二、开始设计
　　1。批量的入口放在哪里？
　　最初，我的想法是将入口放于页面右上角的更多按钮里（下图方案一）。
　　但是，这个想法很快遭到了PM的反对，因为右上角的位置目前在代码层面配置了普通按钮，如果要将批量的入口选在这里，意味着技术上的改动会很大。而且平台型产品在设计上有一个普遍的原则需要遵守，那就是组件和组件在迭代时应互相不干扰。
　　企业级软件满足客户定制化的需求，就像是用积木去拼一个乐高城堡，不能因为需要多一个积木，就把之前的破坏掉重新做，那产品就有可能在无休止的返工改旧功能。当然这一定不是绝对的，但在批量入口的选择上，还不足以耗费这么大的成本。
　　右上角的入口不行了之后，又去调研了一些竞品。本着不隐藏便于找到的初衷，又设计了多个入口方案，最后AB测试，选了右下角的悬浮按钮。
　　多种入口的设计方案
　　2。全选的上限是多少？
　　WEB端可以批量处理的上限是1000条，移动端本身窗口唯一的特性决定了它不具备处理这么多数据的的场景；
　　列表页目前采用的是分页加载，全选的话，希望能做到选中的是所有列表条目，而不只有已加载出来的，这一点是要和研发明确确认的，万幸的是可以做到。
　　3。数据处理量大的话该怎么办？
　　数据批量处理的操作不同决定了所需耗时，批量关注和批量转移数据耗时肯定差别很大的。
　　那在移动端进行数据的大批量处理场景是否存在呢，也许做业务线需求的时候你需要考虑，但是在做平台需求的时候，doit，因为你猜不到用户会怎么用这么功能。功能本身是无属性的，但我们在设计的时候，这是一个需要考虑的异常情况，需要给出解决办法，至少要确定用户不会玩崩你的系统。
　　（和研发同事讨论，暂定50条以上定义为大数据。小于50，数据由前端处理，走同步，大于等于50，数据由后端处理，走异步）。
　　那问题就来了，异步开始处理的提醒，过程中数据处理的队列，完成后如何通知，一个异步队列存在时是否还允许第二个队列同时存在，队列里数据有几种状态，队列中时是否能离开、离开后回来是什么状态
　　抱着这些问题，与PM和研发多次沟通确定方案，因为判断的节点过多，我做了一份流程图：
　　流程图1。0
　　流程图1。0完成之后，看起来太过于复杂和繁琐，不清晰，又优化了流程图2。0版本，感觉好了很多：
　　流程图2。0
　　4。把所有的特殊情况都考虑上，那这个流程的闭环该是什么样？
　　根据已有的流程图和组件规范，结合批量的需求，输出了页面的常规流程和考虑上特殊情况的全流程：
　　常规流程及交互说明
　　全流程
　　三、最后
　　至此，项目进入研发阶段，等待产品验证。
　　复盘了一下之前做业务线需求的过程，两者在思考方式和关注点上还是有挺大差别的：
　　权限的考虑：业务需求基本都需要多问一句：分权限吗，而平台需求是不考虑权限的；
　　场景：业务需求有比较明确的使用场景，而平台需求则需要在多种业务场景里提炼出一个流程来，更多的是要做到通用；
　　验证环节：业务需求设计完成之后，需要对着最开始的需求点一一比对，查漏补缺。而平台需求则需要把多种业务场景嵌入流程中，校验是否做到了通用。
　　以上，谢谢阅读！