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

本文作者分享了自己作为一个产品新人，在接到一个需求时，是怎么去做流程图和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之后的情况和枚举值，审核之前还需要一个枚举值。还有身份证有效期“长期”的情况，连第二个部门也没有想到，和他们沟通之后，他们将长期的返回值定为2999-12-31，营业执照的有效期返回的是string类型。

而我们需要的是data类型的，因为营业执照有效期的特殊情况有很多种，所以如果我们这边做校验会花费巨大的成本，且开发也是个新人，也不一定能做得出来，而第二个部门也不会同意改接口，所以最后只能把这个字段的存储砍掉。

不过还有一点第二个部门很配合，因为我们需要url做入参的接口，但是这个接口当时因为故障已经屏蔽了，因为我们需要，他们也抓紧开发修复，说实话挺感谢他们的。

沟通出现问题，希望以后可以吸取教训

开发时的第二段小插曲，因为前端在完善信息的时候做了一个保存的功能，保存后再次打开页面信息回显，所以我们后端也要跟着改，改就改呗，我配合。

但是保存这个功能的原意是不进行格式校验的，后端只有两个选择：

• 新建表，应该是成本高，开发不同意新建表 ；
• 改接口，但是税务那边需要这个校验，肯定不能改。

总之，开发的意思就是不改！最后经过讨论，做出了不改的决定，这时问题出现了，我的理解是回显继续，只不过需要经过校验。而几天后我又和前端产品沟通的时候，他说当时不是说不做这个需求了吗，空气突然僵硬了起来…然后我又向开发解释，因为开发也是新人的原因吧，也没有怪我，不过我还是很自责的，这个错误确实是不该出现的。

最后

现在是8月22日，开发已经做好了那个没有什么用的需求，还有两个任务，一个是匹配信息job，一个是调用OCR接口识别信息功能。

目前随着对业务的理解不断深入，还在不停地改PRD和流程图，希望之后的PRD和流程图可以一步到位吧。来回改流程图真的是让我逻辑爆炸，领导甚至发给了我《如何正确的画功能流程图》这么一份资料…

很是尴尬……

本文由 @何冲 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议