需求总有漏洞,跟开发过两三遍才能对完细节,该怎么办?

0 评论 1196 浏览 12 收藏 7 分钟

遇到“需求写好,与开发核对细节,但总有漏洞,需要核对两三遍”这种情况,你是如何应对的?本文就该问题进行探讨,一起来看看吧。

群友提问:最近遇到个问题,写好需求了,总有漏洞,总是跟开发过两三遍才能把所有的细节对完,大家遇见这种情况多吗?都是如何自查的。

这题我会。

从我入职现在的公司以来,渡过表现期后,需求有漏洞的问题频繁爆出,最严重的情况在预演环境代码回滚,以我为主的相干人等写事故报告。

同事对我的评价:有点粗心,粗心它是个中性词,再拓展一下就是不拘小节,这种评价有点无关痛痒。

领导对我的评价:不注重细节,不注重细节这个评价就有点挫脊梁骨了。这个点评点到了羞耻心上。

说来也讽刺,工作的前3年我在潜心修炼产品技能,后3年时间里用进废退。

想了一下,前3年对产品应是存有敬畏之心,后三年不排除油条嫌疑。

我复盘过这个问题,为什么会这样:

1、技术兜底。团队关系融洽,跟技术测试私交甚好,需求小修小改基本不是问题,技术同学非常负责,大部分时候产品遗漏的细节他们自己就完善了,比我更注重细节。

再来还有测试把最后一道关口,正常情况下我的环节遗留的细节问题经过两次严筛就被填满了。

2、懒,自我要求不高。惰性心理,小问题不会出大问题,出了问题也会有人解决。平日工作压力不大,一个月一个迭代,产品只要在上个迭代开发结束后给出下个版本的内容即可,这也给了我很多投机取巧的机会,我会把工作内容压到最后时间去做,慢工出细活,赶工的结果可想而知。

3、没有得到教训的错误不长记性。惯性使然,一旦习惯就很难改变。不失去些什么很难痛彻心扉,况且出现了上线前代码回滚情况也没有受到任何惩罚,流程性交了个事故报告这事就结了。

解决这个问题的唯一方法就一个字:查。

在需求有细节漏洞这个问题是有方法可寻的。在我0经验转行产品入职第1天被安排独自负责一个erp系统(无从下手,只想跑路),产品导师传授给我一个快速上手的方法:拆解->重构,也即找竞品进行拆解,然后结合自己的业务进行重构。

需求自查就是上述方法的逆用,需求建好了把它拆掉。拆的过程中遵循三个大方向:拆解业务流程、拆解交互逻辑、切换身份代入。

1. 拆解业务流程

先从业务流拆起,也即先拆框架。拆解业务流的关键点一是业务流程是否完整闭环;二是流程是否合乎业务场景;三是异常流程处理机制是否完善。

2. 拆解交互逻辑

拆解完框架业务清晰后就从交互入手,交互其实就是业务的呈现。也是从大到小查起:
一是页面呈现,信息完成度、优先级、表达是否清晰、少即是多原则;

二是页面跳转,跳转逻辑、最短路径、操作简单;

三是细节,组件使用是否准确、按钮状态、反馈是否友好、指引是否清晰、概念是否统一、用词是否专业恰当等。

3. 切换身份代入

需求文档就是面向产品相关岗位的人,切换身份代入就是从不同的视角去看需求的呈现。

  • 用户:易用性、使用成本;
  • 开发:逻辑、开发成本;
  • 测试:测试最关注边界问题、异常情况。

总结

以上只是列出了需求自查时的一些关键点,仅做经验分享,在工作中可以结合自己的实际情况建立需求自查表,并不断复盘总结进行自查表更新。

之前在星球里看到一位星友分享:如何避免错误和怎么面对错误。

有一条怎么面对错误的观点在需求自查里也很实用:复盘,吸取教训。将这次的错误获得的经验总结下来,形成你的“规则”,避免下次再犯类似的错误。

需求自查也是一样,把那些爱犯的小错误、容易漏掉的小细节总结下来,形成需求自查的规则,刻意关注这些规则,会减少犯类似的错误。

“刻意练习”是贯穿产品职业生涯的一个词,产品相关的任何技能都可以通过刻意练习达到。只是在练习的过程中需要对自己足够坦诚和有足够的耐心,毕竟宝剑锋出磨砺出,梅花香自苦寒来。

本文由 @关尔产品舍 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 目前还没评论,等你发挥!