产品经理的日常
与其说是，产品经理，不如说是专职调解
最近在做信用卡还款的业务，看起来简单实际差错处理、风控处理以及要考虑的细节较多；
一堆烂摊子
这个项目算是中途接手吧，前期与某行沟通方案、过内部风控评审，陆陆续续近一个月了，就是迟迟走不到开发那一步。
因为什么呢，风控部门一直卡着，说是合同上有风险，若有失败情况，会有成本亏损、信用卡逾期的责任。风控卡着，也不允许跟外部商户沟通开发细节，就这么一直僵持。
后来怎么办呢？丢给我让我输出细化方案。
我做了三场评审：
第一场，主要是开发，由于是新接手的业务，而且没有商户那边的明确诉求，主要是头脑风暴信用卡还款业务中的可能存在的问题，同名还款、大量还款失败预警机制、通信异常如何对调账、每种返回状态对应何种情形及系统处理机制。虽说是新业务，但也要在已有的中台前端加入业务平台，整体来说就是兼容和新业务的博弈，应该是讨论了1个上午吧。最终给出了接口文档，和基本的技术设计需求。
第二场，主要是风控，盘点出所有的交易异常风险以及应对的风控措施，再会上一点一点的把合同过完的。并附上了“业务规则”说明。同时，跟风控提出了系统上不能规避的风险点，合同中哪些条款如何去规避业务上的风险。风控老大开完会说，这样风险和业务规则梳理的就很细致了，我之前想要的就是这个。
第三场，主要是运营，解决好了风控，接下来是如何管理、配置、开通及维护的问题。由于是在原有中台上衍生的业务，对账、交易用的都是基本的功能，一个还款对应原来的收、付、退三个流程，对于运营来讲，日常维护和查询都是问题。但是现状就是如此的，从运营的角度出发，总是希望东西越简单越好。实际从项目整体而言，新项目最重要的是在整个流程闭环的前提下，快速上线运行。异常情况可以考虑应对方案，但是不是所有的异常情况都要做进系统中做自动化处理，开发当然希望少开发。所以结果呢，开发老大和运营老大就激动了一些，我像个居委会老大妈一样，前后调解安抚，找这种方案。
上午开完会，我关投影的时候，开发老大还没走，跟我说，像这样的会讨论讨论会发现很多问题。中午吃饭的时候，运营老大也顺带吹我了一波，之前的产品都是配置方案都不清楚，像这样讨论的会议，以后上线出错的概率会小一些。
第四场，还没开会，暂定是将上次会议的进行总结，主要把运维、开发测试、运营操作人员做培训，再次确认下运营管理后台的界面和操作手册，此次结束，就是开发设计评审和投入开发的阶段了。
作为工作方法的总结，也算是在这家公司工作前的最后一个项目
