我接到一个需求时，是怎么做的。。

　　本文作者分享了自己作为一个产品新人，在接到一个需求时，是怎么去做流程图和PRD，以及怎么通过评审的。
　　业务现状：现在的业务需要用户填写个人资料，且上传身份证或营业执照，提交审核后由管理端人工审核。
　　现在有几个弊端：
　　上传的图片需要是扫描件，这个条件的门槛很高；
　　人工审核的成本较高；
　　用户的等待时间较长。
　　然后说一下改进方案：上传图片放弃扫描件的校验，即图片的尺寸、分辨率、宽高比例，调用别的部门的OCR（信息识别）接口实现自动审核。
　　接到需求之后不能马上凭想象做流程图和PRD，要先去了解业务
　　8月8日，领导分配给我这个需求，我随即便火急火燎的做好了流程图和PRD。
　　之后，在公司的公用文档中，找到了OCR接口的所在部门，很奇怪，公司有两个部门都做了这个功能。
　　第一个部门，只有身份证自动审核，且估计是很忙的原因，回一次话都要好几个小时，于是找到了第二个部门；
　　第二个部门不仅具有身份证OCR的接口，还有营业执照OCR的接口，而我们的业务恰恰是需要这两个OCR接口的，并且，第二个部门的人也很热情，对于我的疑问都一一耐心的解答，于是选择调用第二个部门的OCR接口。
　　选择调用接口之后，我找研发确定了一下现在的上传图片接口的校验条件，发现了几个拍照上传不需要的校验，即“图片尺寸”、“分辨率”、“宽高比例”这三个校验，我找到了领导，和领导确认去除这三个校验，领导也同意了。
　　这时，同部门的另一个产品来了，因为我的这个需求他的功能也需要，于是他把“分辨率”“图片尺寸”这两个校验又加了回来，其实也没什么所谓，因为原来针对扫描件的“分辨率”“图片尺寸”的校验很小，现在的大部分拍照都能实现。
　　有多个选择的时候，要考虑对用户和研发的影响
　　接着是委托研发申请接口token，token相当于一个验证码，调用接口需要验证，故需token。但是第二个部门的OCR接口有四个方法，有入参是url格式的和base64数据流格式的，研发不知道调用哪个，这是研发给我挖的坑。还好我问了他那种格式的相对于我们更容易实现，研发回答url格式的，于是又和第二个部门沟通。
　　这就是不懂业务流程的苦，你会逻辑爆炸，心态爆炸
　　然后第二个星期是准备PRD和流程图，可是我8月8号需求出来的时候就已经做好了PRD和流程图，这里为什么又要做一个星期呢？
　　因为，当时的流程图和PRD简直是狗屎不如，我还不知羞耻的一遍一遍的拿给领导看，领导估计都对我无语了吧，于是我改了一版又一版的PRD和流程图，一星期差不多改动50次左右。
　　产品就是要考虑各种特殊情况
　　终于，在8月16日这天，我要主导我的第一次需求评审了，评审之前，我就犯了几个错误：
　　我发送的是邮件，不是会议邀请
　　第二次发送会议邀请的时候，又忘了加附件PRD
　　没有邀请测试参加需求评审。
　　进入了评审，参加的人有：我领导，组内的技术领导，我和另外两个技术新人。评审开始，我就顺着PRD，一条一条顺着往下说。期间，技术领导提了一些问题，我解答了其中我知道的一部分，还有一两个技术问题，我实在不会，眼神望向我领导，于是他帮我回答了。
　　还有一些问题是我应该想到的特殊情况，但是我没想到，比如说：身份证的有效期是“长期”怎么办？临时身份证可以识别吗？字段的增加是否有意义？如何区分人工审核还是自动审核出来的结果？
　　针对这些问题，又改动了PRD。这次的评审也算是顺利结束了，后来和领导谈心，我向他承认了前几分PRD就是狗屎，但是评审自我感觉虽然不能说的上好，起码也算顺利结束了，领导毫不掩饰的告诉我评审的那个PRD也是狗屎因为我是新人的原因，研发领导没有深入的追究而已，好吧，心态爆炸。
　　接着是开发排期，技术领导把这个需求交给了一个技术新人，分成3个子任务，排了8天。
　　开发的时候会有各种问题出现，如果不懂技术的话这些肯定是想不起来的
　　开发的时候，又是问题重重，所以后端产品懂一些技术是非常必要的，奈何，我什么技术都不会
　　比如：有一些枚举值没有把所有的情况包括，我只考虑到了进入审核job之后的情况和枚举值，审核之前还需要一个枚举值。还有身份证有效期“长期”的情况，连第二个部门也没有想到，和他们沟通之后，他们将长期的返回值定为29991231，营业执照的有效期返回的是string类型。
　　而我们需要的是data类型的，因为营业执照有效期的特殊情况有很多种，所以如果我们这边做校验会花费巨大的成本，且开发也是个新人，也不一定能做得出来，而第二个部门也不会同意改接口，所以最后只能把这个字段的存储砍掉。
　　不过还有一点第二个部门很配合，因为我们需要url做入参的接口，但是这个接口当时因为故障已经屏蔽了，因为我们需要，他们也抓紧开发修复，说实话挺感谢他们的。
　　沟通出现问题，希望以后可以吸取教训
　　开发时的第二段小插曲，因为前端在完善信息的时候做了一个保存的功能，保存后再次打开页面信息回显，所以我们后端也要跟着改，改就改呗，我配合。
　　但是保存这个功能的原意是不进行格式校验的，后端只有两个选择：
　　新建表，应该是成本高，开发不同意新建表；
　　改接口，但是税务那边需要这个校验，肯定不能改。
　　总之，开发的意思就是不改！最后经过讨论，做出了不改的决定，这时问题出现了，我的理解是回显继续，只不过需要经过校验。而几天后我又和前端产品沟通的时候，他说当时不是说不做这个需求了吗，空气突然僵硬了起来然后我又向开发解释，因为开发也是新人的原因吧，也没有怪我，不过我还是很自责的，这个错误确实是不该出现的。
　　最后
　　现在是8月22日，开发已经做好了那个没有什么用的需求，还有两个任务，一个是匹配信息job，一个是调用OCR接口识别信息功能。
　　目前随着对业务的理解不断深入，还在不停地改PRD和流程图，希望之后的PRD和流程图可以一步到位吧。来回改流程图真的是让我逻辑爆炸，领导甚至发给了我《如何正确的画功能流程图》这么一份资料
　　很是尴尬
　　分割线
　　把精确的信息给到研发，看表是熟悉业务一条不错的途径
　　8月23日，研发在开发第二个任务，审核job，这个任务需要做的事情是拿识别信息和用户信息进行匹配，匹配不成功转人工审核，而我当时写在PRD里的就是这句话。如果你看上句话没毛病，可能你也不是一个优秀的产品，问题在于识别的信息，接口可以识别出来，用户信息去哪里找？一定要给到研发精确的表名，甚至是字段。在我刚入职的时候，领导给了我几个表名，就让我去看表，我极其敷衍，扫了几眼就感觉没什么用，心里还抱怨，为什么不给我做需求，在评审那天和领导谈话，才明白，领导说他刚来那会，也是不懂业务逻辑，又没人教，怎么办，只能看表，把表看懂了，业务也差不多了。
　　8月24日，周五了，第二个部门那边故障也修复完成了，然后，我就和我们的开发一起调试对方接口，入参需要一串url，这个还好我原来自学过python爬虫，不然又得一次次的拜托研发，通过开发者工具拿到url之后，给到研发，url是有有效期的，所以我每隔一段时间给研发一串url，我是万万没想到啊，这一调试就是一天，还好下班前的一分钟，终于成功了，我看了一下出参结果，身份证的还差不多，营业执照的识别结果堪忧啊，不过，这都是以后的事了，现在调试成功了就是向前迈了一大步。
　　和研发朋友打好关系
　　8月30日，我一直催着第二个部门赶紧上线url的识别接口，他们一推再推，原来他们想要增加一个token作为入参，我自然是不知道他说的是什么意思，然后直接把手机给了研发，研发跟他沟通说配置文件里有了token，不需要作为入参，然后给他们怼回去了，结果当天接口就上线了，这是和研发关系搞好关系的结果，也是不懂技术的苦。
　　9月12日，自动审核上线前一天，在线上环境测试功能，怎么测就是得不到结果，原因是第二个部门不支持我们的服务器，这个当时我也不知道要确认服务器，果然，犯了错就记住了。
　　当时为什么没有考虑这些因素？
　　9月13日，终于，我的第一个需求上线了，撒花撒花！自动审核的通过率也达到了80，虽然说这个需求我不做也有其他人来做，但是也算对得起我的实习工资了。第二天就遇到了需求设计上的问题，自动审核后的数据，管理端没有审核次数1和审核时间。
　　接着两天，营业执照识别接口的调用频率是每天20个！这ROI简直就是0！最后下了营业执照识别接口，但是这个也是在需求前就可以知道的，只需要问运营一句话而已，但是我没有做，这就造成了资源的浪费。
　　现在为止，这个需求也没有发生什么问题了，写此篇的目的就是能够时刻警醒我，产品路上，我还只是个小白。