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

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

这题我会。

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

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

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

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

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

我复盘过这个问题，为什么会这样：

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

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

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

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

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

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

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

1. 拆解业务流程

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

2. 拆解交互逻辑

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

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

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

3. 切换身份代入

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

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

总结

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

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

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

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

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