一、产品经理和开发经理对产品实现认知上存在偏差
1、偏差一：产品认为实名认证和客户征信授权是相互独立的功能。而开发最终发现我们要对客户授信，需要一个权威的识别标识来将客户不同维度（学历，公积金，社保，运营商等）的信息统一起来。这样也就产生了一个开发自己的需求：实名认证必须在客户征信授权之前。但以目前的设计来看，实名认证是只有在进件之后才会认证成功的，可是客户征信授权又是进件之前。流程上完全矛盾。最后只能做出妥协：只要客户填写完实名信息即可进行征信授权，而不需认证成功（没法认证）。
2、偏差二：产品认为摩卡项目是一个整体，不能够理解我们的微服务架构。比如：数尊身份认证接口是中途发现偏差以后，才加进来的需求（最终没有实施），目的是，保障客户的填写的身份证号码和姓名是一致的（仍无法断定实名成功），减少客户不合规输入的实名信息的概率。 实名认证本身属于客户域，是客户中心的功能。实际上由于目前架构的设计和网络隔离情况，客户中心是不能访问外网的，这就需要从某个网关将信息透进来，这整个链路需要规划。产品人员最后延缓这个的需求，我感觉他们是不够理解的。
二、组间沟通的滞后，增加了额外工作量
就拿授权模块来说，从外往内涉及到C端、摩卡应用、客户中心、征信平台、爬虫网关。
在前期，我定义好接口是只跟C端、摩卡应用有交互，能保障我们直接的定义是一致的。但没有和爬虫网关有过流程上面的讨论，也没有接口字段定义上面的约定，最后，征信平台和爬虫网关对接的时候，发现客户中心的出参和爬虫的入参名称定义大多不一样，需要一一做映射，而对数据的安全性、一致性的认证机制也不一样，客户中心用请求流水+授权码，而爬虫是使用入参+时间戳形成token令牌，这有致使了征信平台又需要将两者的凭证做KM.
所以如果这些事情提前有文档上面的确认和互认，相信可以避免后期开发上面的障碍，也能简化征信平台的代码，增加代码的可阅读性。
三、自身问题
由于银辉去做需求分析，客户中心的整体工作暂由我这边负责。在摩卡开发期间，我同时要负责开发个人信息、授权模块还有征信平台的征信报告查询接口。另外还需要把握客户组的开发和缺陷修复情况以及催收系统的开发计划制定和进度推进落实的情况。
最初是比较难从开发角色和管理角色之间来回切换的。好在并没有出现太大的问题。
这让我更深刻的理解了做事情的轻重缓急，排好优先级的重要性，新的事情来了先记录下来，等更重要的事情完成了，再一一处理。
网友评论