悠活马上版项目总结

很幸运的参与到了一个涉及多个第三方的项目里，较之前的项目，悠活马上项目自身的特殊性也值得唠叨唠叨，在重构版上线前悠活产品部门已经开始了悠活马上版的规划设计，由不确定到中间反复沟通，从我正式接手设计产品，到需求沟通及确认经历了一个复杂坎坷的过程。随着项目上线临近，借此梳理下项目的前前后后和中间出现的问题及处理措施。

1，项目背景
在重构版的基础上，接入马上资金方，符合监管要求，同时通过导流获取一定的公司盈利，符合公司发展的需求；
2，时间跨度表
产品设计阶段：2018.3.15-2018.3.21
业务需求评审：2018.3.21-2018.3.21
UI设计：2018.3.22-2018.3.22
技术评审：2018.3.29-2018.3.29
技术开发：2018.4.9-2018.4.30
测试：2018.5.2-2018.5.14
产品业务验收：2018.5.15-2018.5.16
联调测试上线：2018.5.17-2018.5.24
3，项目特色
接入马上，是我们接入资金方的一次尝试，为以后是否接入更多资金方及如何更好的接入提供参考；
截止目前为止，该项目是接入第三方最多的项目，多方合作中考验着项目人员的技能和各自平台的接口服务性能，同时给了我们与外部沟通彼此学习的机会；
4，问题梳理
4.1测试数据
第三方数据提供：马上老用户 集奥 阿福 姨妈通讯录等，按照严格的测试流程，无法满足测试需求的，我们也要争取在技术改数据的前提下，看下测试效果，减少出错的可能性；
4.2与第三方的合作
此次上线较重构版在与第三方合作上明显增多如姨妈通讯录，马上，集奥，因此与第三方的合作要预留不确定因素，比如马上服务挂掉，接口不通等
4.3业务架构设计
与外部合作方绑定的紧密，如姨妈通讯录在风控流程中是必须项，姨妈通讯录能否正常上线对该项目是个风险；马上流程与悠活流程捆绑关系，使得马上服务挂掉这种情况也会是个风险项；业务需求很大程度上影响了系统架构设计；
4.4需求变更
以风控前端原型为例，从技术评审版开始截止到5.14，共13次修改记录，每次修改的内容有多有少；马上那边也有需求逐步确定的过程，在开发对接中出现诸如上传文件接口 上传人脸识别结果接口都需调用，在上线前马上联调测试时，出现合同期限有效期要修改的情况等；
因需求改动次数多每次改动琐碎，要求需求文档原型及时更新，对应当下需求；
4.5团队协作
团队分工明确，具体任务落实到位，避免任务跟进无着落；
需求对接，多头对接导致信息遗漏或者信息传达偏差，接收者层级越多问题越严重；
尽量与第一线的人员直接沟通，出错的几率会小些，前因后果细枝末节都知晓，拿别人的结果来用时要持怀疑态度；
沟通中出现意见分歧，本着项目往前推进的原则，最终都会达成一致解决掉；
4.6信息同步
需求变更，及时做到同步项目组人员，避免项目信息不对等或者项目信息遗漏导致的；
4.7测试机
测试机比较老旧，使用起来反应过于迟钝，且测试机数量有限，长期来看影响测试进度；
4.8上线时间
定好deadline , 在时间紧迫情况下，非紧要的需求要考虑砍掉，确保主流程正确走通，在联调的最后几天出现了接口变动 双方需求不一致的情况等，由此总结出上线前的诸多因素都是不确定项，要核实到位

总结：
本项目不算是从0到1的过程，但出现的问题却比较新颖，借鉴此项目进行经验总结。以上大部分是对项目执行过程中出现的情况的总结，而对行业中的上下游追溯，行业中巨头的策略、管理、资金等方面的调整，它们的演变如何体现市场的变化，行业中主要的商业模式和商业格局，然后使用不同产品去尝试等等这些需要另外一篇去写了。
补充一点感悟：为了项目上线，项目小伙伴们也是拼了，加班熬夜赶工期成了家常便饭，提交测试，测试验收，联测验收，项目人员拿到马上额度，项目中的一个个节点，也是我们的一个个的喜悦；
互联网金融产品与其他产品还是有区别，其他产品可以天马行空的去想象 巴不得出点小创意，互联网金融产品有条框限制，有一定的拘谨性在里面，具体的拘谨欢迎讨论。
以上信息如有缺漏或不妥，欢迎回复；