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

21天Excel零基础速成训练营,导师带学+答疑辅导+实战作业,让你真正掌握Excel技能,了解一下>>

本文作者分享了自己作为一个产品新人,在接到一个需求时,是怎么去做流程图和PRD,以及怎么通过评审的。

业务现状:现在的业务需要用户填写个人资料,且上传身份证或营业执照,提交审核后由管理端人工审核。

现在有几个弊端:

  1. 上传的图片需要是扫描件,这个条件的门槛很高;
  2. 人工审核的成本较高;
  3. 用户的等待时间较长。

然后说一下改进方案:上传图片放弃扫描件的校验,即图片的尺寸、分辨率、宽高比例,调用别的部门的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和流程图可以一步到位吧。来回改流程图真的是让我逻辑爆炸,领导甚至发给了我《如何正确的画功能流程图》这么一份资料…

很是尴尬……

——————————————-分割线—————————————–

把精确的信息给到研发,看表是熟悉业务一条不错的途径

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!最后下了营业执照识别接口,但是这个也是在需求前就可以知道的,只需要问运营一句话而已,但是我没有做,这就造成了资源的浪费。

现在为止,这个需求也没有发生什么问题了,写此篇的目的就是能够时刻警醒我,产品路上,我还只是个小白。

 

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

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
5人打赏
评论
欢迎留言讨论~!
  1. 楼主在什么形式公司上班,公司是做什么业务的呀

    回复
  2. 我也是本周一 做了我人生的第一份 关于产品方面的汇报 我自己认为很清楚 但是领导认为及其复杂 这次讨论也让我学到了很多

    回复
    1. 一起加油啊!

      回复
  3. 请问转岗到产品助理,你们都是怎么拿到Offer的

    回复
    1. 我是应届生,可能要求会低一点吧,如果是社招的话,我觉得内部转岗和从小厂干起会比较简单点吧

      回复
    2. 自己先自学部分产品的东西。比如学会Axure,xmind等相关常用的工具,最好自己能模仿目前市面上一款APP作出原型图。然后就是锻炼自己的产品思想(凡是多想为什么要做这个,界面上为什么要这么化等原因),流程逻辑(这个比会画原型图还重要),最后,姿态放低,薪资标准低一点。加油!

      回复
    3. 谢谢,现在已经入职了

      回复
  4. 加油,下次会更好

    回复
    1. 多谢!

      回复
  5. 1、数据库已有一张表来记录资料
    2、所有的提交资料都走后端的一个接口读写资料表

    可以考虑为你这个需求重新一个新接口,然后存入现有这张资料表?
    不过这有两个坏处:1、两个接口都对同一张表进行读写,不规范后期会比较乱,2、会污染原现有记录资料的表,因为会掺杂不正确格式资料
    坏处1解决办法是改造现有接口,坏处2办法解决办法是新建一张表

    所以死循环了,说明需求有问题

    回复
    1. 原来的需求是有问题的,所以前端产品也说不做了,今天站会又统一了,做阉割版的,即经过校验再入库

      回复
  6. 哈哈哈,我曾经也是这么过来的,好在这些都当自己的经验就好。
    还是给你点赞,看到了曾经的自己,加油!

    回复
    1. 多谢!

      回复
  7. 我也想要《如何正确的画功能流程图》这个资料~可以给我发一份么~

    回复
    1. 人人都是产品经理中搜“浪子”,这个作者写了很多流程图和PM相关的文章,领导发给了我其中一份,我打开他的主页,又看了很多

      回复
    2. 同问

      回复
    3. 我也想要。😂😂😂

      回复