互联网金融产品实战——设计篇

上接前一篇：互联网金融产品实战——备战篇

功能设计

        最好采用思维导图工作来完成，按功能大小，逐步拆分，直到很细小的功能点。可按功能体划分，也可以按功能页面划分，直到将全部功能点覆盖为止。早期直接采用纸笔，将功能细化下来，最后再腾挪到设计稿中。

推荐工具：xmind

页面设计

        有PO牵头，对接业务人员，确定原型稿，要求有完整的交互设计、字段，提示信息显示明确。原型设计采用Axure进行，为提高全员对业务的参与程度，当时是要求所有开发人员都参与到原型设计中。原型设计早期直接采用纸笔即可，效率高，沟通快。最终定稿时才使用axure等工具，固化后留档。

        评审通过后交付UI进行设计，评审通过后方可交付开发人员着手开发。切记开发人员不要随意变动原型中元素的位置及显示，都要与需求确认后才能改动。相信搞过外包开发的朋友都有一个感受，客户需求变代太快，如果有要求就改的话，做很多无用功，一定要找一个项目接口人，统一对外接受需求变更，降低团队直接对外的频率，一定程序上保证了开发团队的工作效率。

推荐工具：Axure RP

存储设计

        业务数据基本存储在mysql库中，系统日志存储在文件中，交易日志存储在mongodb，后期对账的关键依据。一些公用的热数据存储在redis中，比如基金代码，基金产品的7日年化收益，用户的近7日收益等等。

        一些产品的计算较为复杂的部分，喜欢采用存储过程来做，这样做效率高，但也有一个坏处就是业务逻辑写在存储过程中，不便于维护。特别是全部功能都采用存储过程来做，对后期维护人员是相当的头疼，这块当时是采用子代码与存储过程并用的一个处理逻辑。

推荐工具：Sysbase PowerDesigner

接口设计

        依据业务整理，及与基金公司的交流结果给出的交易接口，项目组出一份接口文档，包括与各方交互的接口。

        接口调试中最多的应该是接口传递的参数问题了，一是对调用者，二是对被调用者。参数的类型、大小、长度等等，都有可能导致接口调用失败。

        评审结束后，交由开发着手开发。同时制定接口开发调试计划，因接口属不可控因素，需提前开发，以免延误开发进度。最好交由一人负责，避免分散到各个开发人员身上，不利于接口的编写，也不利于接口的联调测试。

推荐工具：Microsoft Excel

相应的文档输出是必要的，即便采用敏捷开发。千万不要以为敏捷开发不需要留存文档！

下文将继续分享开发过程中一些深刻的总结......

歪脖贰点零 ∣一个有逼格的WEB2.0

长按，识别二维码，加关注