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

栏目: 编程工具 · 发布时间: 5年前

内容简介:本文作者分享了自己作为一个产品新人,在接到一个需求时,是怎么去做流程图和PRD,以及怎么通过评审的。业务现状:现在的业务需要用户填写个人资料,且上传身份证或营业执照,提交审核后由管理端人工审核。

本文作者分享了自己作为一个产品新人,在接到一个需求时,是怎么去做流程图和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协议


以上所述就是小编给大家介绍的《我接到一个需求时,是怎么做的……》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Mathematica Cookbook

Mathematica Cookbook

Sal Mangano / O'Reilly Media / 2009 / GBP 51.99

As the leading software application for symbolic mathematics, Mathematica is standard in many environments that rely on math, such as science, engineering, financial analysis, software development, an......一起来看看 《Mathematica Cookbook》 这本书的介绍吧!

在线进制转换器
在线进制转换器

各进制数互转换器

URL 编码/解码
URL 编码/解码

URL 编码/解码

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具