本页目录

项目上线后，你还看得见设计漏洞吗

需求评审总在来回解释同一件事

回看最近一个已经上线的项目。需求评审阶段，开发和业务围着同一个问题反复确认了几轮？

如果高频往返都落在“这一步谁发起”“这个状态何时变化”“这个字段从哪里来”，问题不在沟通态度，问题在业务流和数据流没画透。稳定的口径不是“大家最后懂了”，而是第二轮评审后，同类问题明显变少。

再看需求文档的修订记录。后两版还在大改主流程和核心字段，说明前期调研没有把骨架站稳。

统计一个迭代里，开发因为字段来源、状态流转、实体关系来回找产品确认了多少次。

零追问不现实，但如果追问集中在核心对象上，比如订单、审批单、库存、角色这些基础元素，说明数据建模仍是松的。设计如果站住了，讨论重心会被推到边缘情况，不会反复卡在主干结构上。

还有一个简单口径：开发提问如果多数围绕“逻辑怎么走”，而不是“页面怎么摆”，那就别急着怪开发没看文档，先回头补模型。

复盘最近两三个项目。权限相关的改动，最密集地出现在什么时候？

如果总是到联调、验收、甚至上线前一周才补“这个角色其实不能看”“那个岗位还要多一步审批”，说明权限不是一开始就被当成骨架，而是被当成页面附属条件。B端项目里，这种补洞几乎一定带返工。

可以盯一个很实用的信号：同一项目里，权限规则被临时新增或改写超过三次，就要怀疑前面的组织关系和数据边界没有想清楚。次数不是考核分数，但它能提醒你，问题出在前面，不在最后那几个按钮。

上线前的验收记录最能暴露设计有没有贴住现场。看你们当时跑的是功能清单，还是完整业务场景。

如果验收主要在点按钮、看弹窗、核对字段展示，业务流程本身还没人用真实数据走完一遍，这个项目即使上线，也只是“页面能用”，不是“业务能跑”。有效的复盘口径是：主流程能不能一次跑通，异常分支要不要产品在旁边口头解释。

再看谁在验收。若主要是测试和产品自己在跑，而一线操作人很少进场，验收结论通常偏乐观。

项目上线一个月后，先别急着看活跃人数。去看两个地方：备注字段、线下沟通。

备注里如果长期塞满本该结构化的信息，说明数据模型漏了关键维度。线下先确认、系统里再补录如果成了常态，说明流程设计没有贴住组织真实的决策方式。系统还在，但系统已经不是工作发生的地方。

这两个信号都不需要很精密的统计。只要在几个核心页面上连续抽样，就能看出倾向。抽三次都出现同一种绕行方式，基本就不是偶发问题了。

把上线后的问题单按方向分一遍，比只看总量更有用。

如果抱怨主要是“该看的看不到”，多半是数据权限收得过紧；如果主要是“有人改了不该改的内容”，多半是操作权限放得过松。两类问题方向相反，修法也相反。只记得“权限投诉很多”没有用，必须看它偏向哪一边。

另一个值得回看的口径是，投诉到底集中在主流程，还是集中在例外流程。主流程出问题，说明骨架有误；例外流程出问题，说明你低估了现场的复杂度。

最后看团队的复盘纪要。复盘里讨论最多的是页面细节，还是业务规则？

如果一场复盘结束后，留下来的结论还是“某个按钮位置不顺手”“某个弹窗文案要改”，而对角色分工、状态流转、数据边界几乎没有回看，说明团队仍在用C端的视角理解B端问题。这样的复盘会持续修表面，不会修地基。

更好的状态是，复盘能明确说出哪一段流程判断错了，哪个实体定义太粗，哪条权限边界画反了。能说到这一层，下个项目才会真的变轻。