附录 · 常见陷阱与对策¶
用途：4 周项目里，每周翻一次，对照自己有没有掉坑里。 来源：业财一体化项目失败案例 + 央企/国企项目特殊性。
一、需求调研阶段的 10 大陷阱¶
陷阱 1：变成"访谈员"¶
症状： - 笔记本写满，但回家不知道画什么图 - 访谈纪要堆了 50 页，但开发拿到说"这个我做不了" - 每个部门说的都对，但拼起来对不上
根因： 你只听不问、只记不挑战。访谈对象给你什么你就收什么。
对策： - 每次访谈前写下 3-5 个假设（"我猜他会这么说"），用访谈验证 - 访谈中当场画图（数据流、状态机），让对方在图上指 - 听到"应该"、"大概"、"差不多"，必须追问到具体
陷阱 2：被"听话的关键用户"带偏¶
症状： 某个对接人特别热情、配合度高，所有访谈都靠他安排，结论也基本是他的观点。
根因： 他可能是甲方内部"想推动二期"的派系代言人。他的需求未必代表全部。
对策： - 强制访谈反对派：找一个对二期最不感冒、最忙、最难约的人聊 - 让甲方一把手指定 2-3 个对接人，分摊视角 - 警惕"特别会配合的人"——通常背后有立场
陷阱 3：方法论冲突——B 类做 C 类项目¶
症状： 画了一堆漂亮流程图，但开发问"营收这个字段从哪个表的哪个字段来"答不上来。
根因： 你用的是"业务流程梳理"方法（B 类），但项目要的是"数据架构重构"（C 类）。
对策： - 翻 00-方法论与思维框架.md 第一节，重新对齐 - 每个流程图旁边必须画一份数据流图 - 每周一查："这一周我新增了几张数据流图？"为零就是出问题了
陷阱 4：陷入"鸡毛蒜皮"漩涡¶
症状： 访谈中花 30 分钟讨论"页面按钮该叫'保存'还是'提交'"。
根因： 没控制访谈焦点。或者怕场子冷，对方说什么都跟。
对策： - 访谈前写好"今天必答 5 题"，贴在显眼位置 - 跑题时礼貌打断："这个我们记下来，今天先把 5 题问完" - 鸡毛蒜皮类问题单独开"细节确认会"，不要混在主访谈里
陷阱 5：跟岗变成"陪聊"¶
症状： 跟岗回来发现，对方主要跟你聊天，没看到几个真实操作。
根因： 对方为了配合你，改变了真实工作方式。
对策： - 跟岗前明确："您按平时做，我只看，不打断" - 选有任务在身的时段（如月末、申报前）跟岗 - 不要看着对方的脸，看着屏幕 - 等对方"忍不住给你解释"时再问
陷阱 6：工作坊变成"汇报会"¶
症状： 工作坊开了 3 小时，每个部门轮流讲了 30 分钟自己的现状和困难，最后没产出。
根因： 你没有当主持人，你当了"听众"。
对策： - 工作坊开场就写下"今天要产出 X"，贴在最显眼处 - 每 30 分钟提醒一次："我们还差 X 才能完成今天的产出" - 跑题 5 分钟后强行打断："这个先记下，回到主题"
陷阱 7：决策被推到"会后再说"¶
症状： 工作坊上每次要拍板，"再向上汇报一下"、"会下沟通"。结果一周过去，啥都没决。
根因： 来开会的人没有决策权，或者有权但不想担责。
对策： - 邀请函里写明："本次会议为决策会，需有决策权的代表出席" - 关键决策事项会前一天发给一把手，告知 "X 决策今天需要拍板，否则方案延期" - 不能当场决的：给一个 deadline（"3 天内书面答复，否则按 X 方案推进"）
陷阱 8：被甲方"已知答案"绑架¶
症状： 甲方很坚持某个做法，你私下觉得不对，但又不敢反驳。
根因： 你想"客户开心至上"，或者你自己不够确信。
对策： - 你是主导方，不是"听话的乙方" - 用数据/案例反驳，不用观点反驳 - 反驳的话术："理解您的考虑。我想再确认一下风险点：如果按这个方式做，X 会发生 / Y 会失败。我们能接受吗？"
陷阱 9：低估"主数据"复杂度¶
症状： 方案里说"我们用统一的项目编号、客户编号、科目体系"，但落地时发现： - 项目编号几个系统不一致 - 客户名称有错别字、有简称、有曾用名 - 科目体系业务和财务各一套
根因： 主数据治理是"看不见的冰山"。
对策： - 第 1 周必须明确主数据现状（项目、客户、供应商、员工、科目） - 二期方案必须单独有一章"主数据治理" - 主数据迁移工作量按你估算的 3 倍 报
陷阱 10：低估迁移与历史数据¶
症状： 方案做完了，临上线发现： - 一期数据迁过来对不上 - 历史合同/项目的"血缘"接不上 - 没法回看 3 年前的报表
根因： 调研阶段没把数据迁移当回事。
对策： - 第 1 周做"数据源分析"时同步评估迁移工作量 - 第 4 周的 SRS 必须有数据迁移章节：哪些迁、哪些不迁、对应关系、清洗规则 - 与甲方约定"历史数据查询要求"（多久、多深）
二、央企/国企特有的陷阱¶
陷阱 11：账面合规 vs 实际操作脱节¶
症状： 访谈中财务说"我们严格按 X 规定执行"，跟岗时发现完全不是。
根因： 央企的合规要求非常严，但执行层往往有"事实标准"和"合规标准"两套。说出来的是合规标准，做的是事实标准。
对策： - 跟岗时重点关注"绕过规则"的行为 - 私下沟通时（不在会议室）问："实际操作时还有什么是规定没明说的？" - 方案里不要试图把所有事实标准都"合规化"，会被甲方一线抵制
陷阱 12：领导口径 vs 一线口径¶
症状： 副总说"项目利润率是核心指标"，一线项目经理说"这个数没人看"。
根因： 管理层希望的 vs 实际执行的脱节。央企里常见。
对策： - 高层访谈得到的是"应然" - 一线跟岗得到的是"实然" - 你的方案必须两边都对得上——既能让一线落地，又能给高层看 - 不要替任何一方说话
陷阱 13：集团合规与单位灵活性的冲突¶
症状： 集团要求统一的指标口径，但单位实际业务跟其他兄弟单位不一样。
根因： 集团 vs 单位的张力是结构性的。
对策： - 数据模型上双口径并存：内部管理口径 + 集团报表口径 - 自动转换规则单独定义 - 不要强行让单位完全按集团口径——你 hold 不住
陷阱 14：审计与日常的双轨¶
症状： 甲方一边要求"留痕、可追溯、不可篡改"，一边要求"灵活、能调整、不要太死板"。
根因： 日常需要灵活，审计来时需要严谨。两个要求都对。
对策： - 业务流程允许灵活，但所有变更都留痕 - 审计需要的数据通过查询/快照获得，不要硬塞到主流程 - 灵活和严谨不是矛盾，是两层
陷阱 15：换届与项目周期¶
症状： 项目做到 80%，甲方一把手换人。新领导提出全新想法。
根因： 央企领导换届频繁，每个新领导都想"留下自己的印记"。
对策： - 项目越早签字越好 - 关键决议会议纪要 + 签字 + 盖章 三件套 - 方案设计成模块化，万一新领导想改某块，影响范围可控
三、技术陷阱¶
陷阱 16：一期遗留代码的"考古学"¶
症状： 一期代码看了 3 天，发现 30% 的代码没有文档、没人懂、没人敢碰。
根因： 一期开发离职、文档丢失、需求文档与代码对不上。
对策： - 不要试图"完全理解一期再做二期"——会陷入泥潭 - 以数据库为事实标准，应用代码作参考 - 二期保留与不保留的边界画清楚
陷阱 17：相信"数据库里有的就是干净的"¶
症状： 拿数据库字段直接用，结果发现： - 一个字段几种值（拼写不一致） - 历史数据脏（如 2020 年的项目编号格式是另一套） - NULL 和空字符串混着用
根因： 数据治理薄弱。
对策： - 第 1 周做数据质量抽查：每张核心表抽 100 行，看异常 - 二期方案必须有数据清洗章节 - 报表如果对历史数据有要求，要明确"清洗到什么年份"
陷阱 18：接口都"差不多能用"¶
症状： 访谈 IT 时说"我们和 X 系统有接口"，落地时发现接口三天两头出错、字段不全、数据延迟。
根因： 接口的可靠性比想象中差。
对策： - 关键接口必须实测：发请求看响应 - 接口失败处理是必须设计的：重试、告警、人工补录 - 接口延迟必须明确告知业务方（"数据 T+1 才有"）
四、人际关系陷阱¶
陷阱 19：与甲方 IT 关系处不好¶
症状： IT 部门觉得你越权、抢功劳，配合积极性降低。
根因： 你"主导"姿态过强，让 IT 觉得自己被边缘化。
对策： - IT 部门是项目落地的核心盟友，不是敌人 - 经常和 IT 主任私下沟通："我们怎么让你这边落地更顺" - 方案里明确 IT 的角色和贡献 - 重大决策会议前先和 IT 通气
陷阱 20：与业务部门"过度共情"¶
症状： 跟某个业务部门跟岗久了，方案里全是为他们说话。
根因： 熟悉 → 同情 → 站队。
对策： - 跟岗不超过 1 个部门连续 2 天 - 写跟岗摘要时用第三人称，强迫自己抽离 - 方案里有部门冲突时，找数据，不找观点
五、自我陷阱¶
陷阱 21：完美主义拖延¶
症状： W4 整理交付物时，每份都想做到 100 分，结果延期 1 周。
对策： - 第 4 周第一天先把 8 份文档都填到 60% - 留 2 天专门"打磨"——但只打磨 P0 文档（②⑧） - 接受："完成比完美重要"
陷阱 22：怕错不发声¶
症状： 工作坊上你觉得有问题，但不确信，没说出来。
对策： - 你是顾问，有义务表达专业观点——哪怕错也比沉默好 - 措辞可以委婉："我有个 concern，可能不对，但想和大家确认一下..." - 主持人不发声，工作坊会跑偏
陷阱 23：单兵作战¶
症状： 所有事都自己扛，4 周下来心力交瘁，最后 1 周质量下滑。
对策： - 第 1 周就明确分工：你不一定是架构师 + 主持人 + 文档撰写一肩挑 - 找团队里的搭档（架构师、记录员、行业顾问）协同 - 每周五主动复盘：哪些可以分出去？
六、最后的元陷阱¶
陷阱 24：把"完成调研"当成目标¶
症状： 4 周到了，8 份文档交了，签字也拿到了，觉得"任务完成了"。
根因： 调研不是目的，方案落地才是。如果开发拿到你的文档做不出来，你的调研就是失败的。
对策： - 每写一句需求，问自己："开发能照着这个做吗？" - 第 4 周末预留时间和开发团队对接——他们能看懂吗？有疑问吗？ - 真正的成功标志：6 个月后系统能跑起来，不是签字完了
自查表（每周末过一遍）¶
打勾的越多越危险，需要立刻调整：
第 1 周末¶
- 我的访谈纪要超过 30 页但拿不出数据模型
- 我没拿到数据库只读账号
- 我没找到"假数据源"
- 我的对接人都很热情
- 我还没和 IT 主任见面
第 2 周末¶
- 跟岗时对方主要在跟我聊天
- 我的访谈对象都是 IT/财务主管，没碰过一线
- 我没发现任何"矛盾点"（不同部门说法不一）
- 月末关账期间我没在现场
第 3 周末¶
- 工作坊上没有人当场反对过任何决策
- 每次工作坊都超时
- 关键决策都被推到"会后"
- 我没让任何人签字
第 4 周末¶
- 我的 SRS 没有具体的字段映射
- 我没和开发团队对接过
- 8 份文档我都还在打磨第 1 份
- 返场确认会甲方一把手没来
如果勾选 ≥ 3 项，立即找你的项目经理 / 高级顾问求救。
回到 → README