R2.12.3joint-review timing设计
共同评审的时机决定返工量
别名: 会评时机 · 评审过晚的返工 · when joint review happens
概念解释
设计和实现一起看稿、看原型、看已写出的界面，能发现单方看不见的结构冲突。什么时候一起看，决定后面要扔掉多少已经做完的工作。交互模型刚写清、生产布局还没铺开时做会评，改的是意图；像素已经进分支、测试已经按旧结构写完时再评，改的是拆除。
时机谈的是「已经压了多少下游工作」，不是「要不要一起看」，也不是探索和交付该不该分列。晚到的会评仍然能找出问题，只是账单从改稿变成拆代码。
机制
错误假设上叠的实现越多，推翻它要付的工时越陡。结构（有几步、状态怎么分、哪个动作在哪一层）是后面布局、组件和测试的地基；地基在会评里被改写，上面每一层都要重做。会评若发生在地基已浇、墙已砌之后，发现的是真问题，支付的是重建。会评若发生在地基只存在于稿上、还没有被代码咬死时，同样的结构问题只改文件。
「一起看」本身不降低返工。两个人在发布前夜对着已经合进主干的界面挑错，和两个人在交互稿阶段对着流程挑错，找出的问题可以同类，返工量不在一个数量级。决定量的是会评发生时，错误假设已经被建造锁住了多少。
边界
改一句文案、挪一个图标，无论何时会评，拆除成本都低，不必为这种改动单独卡一个「结构会评点」。从零开始、仓库里还没有可拆之物时，晚评的重建账单也轻，但会迅速变重，一旦第一条生产布局合入就不再是绿场。只有一个人既设计又实现，「共同」评审退化成自检，时机规则仍然有用（自己也该在写生产布局前停一次），只是不再有第二个角色。会评早到还没有可评的意图（只有情绪板、只有未选方向）时，会评会空转，随后真正的结构会评仍可能来得太晚。
怎么落地
- 在交互模型已经可陈述、生产级布局尚未开工时，固定一场设计与实现的会评，专门审步骤、状态和层级，不审视觉细节。
- 把「已写出的界面才第一次一起看」标成晚评；晚评只处理不得不改的结构，并单独记录拆除范围。
- 视觉和文案的会评可以更靠后，不要和结构会评挤在同一场、同一时间点。
- 验证：回顾最近合入的返工票，标出会评发生在「布局代码之前」还是「之后」。凡是拆掉已写布局或已写测试才能改的结构问题，都记作时机过晚；目标是这类票趋近于零。