范围为什么会失控
项目延期最常见的说法是需求一直在加，但复盘时往往发现，问题出在开工前没人把边界写下来。口头确认过的内容，双方记的不是同一件事；一句先做着看，等于把分歧推迟到开发后期暴露，那时候改一个字段的代价已经翻了十几倍。
控制范围不需要复杂的流程，关键在于把三类信息落到纸面：谁在用、要完成什么、什么算做完。这三份清单加起来往往只有两三页，却能在后面替双方省掉大量争论。
写清单的动作建议放在排期之前。清单没定，报价和工期都是估不准的，因为估的是想象，不是需求。
三份清单不是各自独立的文档。角色决定谁来写任务，任务决定验收写什么，验收又反过来检验角色有没有列全，三者应当能互相对照。
角色清单：谁在什么场景里用
角色不要写成职位名称的罗列。有用的一条是：谁、在什么场景下、需要多久完成哪件事。比如值班店长在交接班时段，用手机五分钟内完成一次排班调整，比管理员三个字信息量大得多。
每个角色后面标出使用频次和终端。每天要用多次的功能值得单独做入口，一个月用一次的功能放进二级页面就够了。这个判断直接决定后面导航和首页布局怎么排，而不是等设计稿出来再讨论。
角色数量控制在三到五个。超过五个时，通常是把同一类人的不同用法拆成了不同角色，合并回去能让需求讨论更快收敛。写角色时把主角色标出来。主角色是产品存在的首要理由，界面默认路径优先满足他，其余角色多一步进入是可以接受的代价。主次不清时，每次评审都会回到同一个争论点上。
角色信息要来自实际接触，而不是坐在会议室里推测。跟半天岗、看几段录屏、翻一遍客服记录，往往就能发现之前想当然的判断偏差在哪里。
任务清单：用户要完成的事
任务清单用动宾短语写，一条一件事，长度控制在二十字以内，整体不超过十五条。比如提交一次报销、查看本周排班、导出客户名单，都是合格的任务描述。
每件事后面标注优先级和验收口径。优先级按任务是否被阻断来分：不做这件事，用户是否就无法完成目标。能绕过去的排后，绕不过去的排前，优先级不按实现难度排。
清单定下来之后请对方确认一遍，最好由对方复述。复述时跑偏的地方，正是理解不一致的地方，当场改掉比开工后返工便宜得多。
清单里出现无法用一句话说清的任务，通常是范围本身太大，需要继续拆分。把导出客户名单拆成按条件筛选、选择字段、下载文件三步之后，实现难度和风险也更容易判断。每次评审任务清单时顺手划掉已经明确不做的内容，并写上一句原因。不做的判断记录下来，下一轮讨论就不会把它重新捡回来。
验收清单：什么算做完
验收标准要写成可判断的句子，不能出现简洁、美观、流畅这类形容词。操作简单这种说法没法验证，换成新用户不查文档也能完成首次提交，就能直接拿去测。
每条验收对应一个具体动作和预期结果，比如上传超过十兆的文件时给出明确提示而不是卡住。
验收清单还要标注由谁验证、在什么环境验证。测试环境通过但线上数据规模不同导致的问题，往往就出在验证环境没有约定清楚。把清单当作沟通工具而不是交付物。它存在的意义是让双方在动工前用同一套语言，而不是为了留下一份漂亮的文档。测试用例可以直接从这张表长出来，验收时也不会各说各话。
三份清单确认后放进项目文档，后续每次需求变更先改清单再改排期。范围不是一次谈完的，但每次变动都有据可查，主动权就还在自己手里。
