问题 01
需求会上都点头，不代表理解的是同一件事
如果边界和关键动作没有写清楚，返工通常会在中后期集中爆发。
高频问题
项目里最常见的问题，往往不在代码写不出来
很多交付问题在爆发时看起来像技术问题，根源其实在边界、口径和推进机制上。
问题 02
看板很多，不代表数据已经能支持决策
口径不统一、来源不稳定时，展示越多反而越容易放大混乱。
问题 03
AI 做了演示，不代表已经接进业务流程
只有接到岗位动作和知识源治理里，AI 才算进入项目现场。
问题 04
系统上线了，不代表组织已经切换成功
培训、权限、责任边界和使用反馈往往决定后续系统能否持续被使用。
观察维度
我们通常会从这几个维度看一个交付问题
不只判断技术路线，也会一起看业务、组织和执行链路。
维度 01
边界有没有被清楚说清
重点看先做什么、谁来拍板、哪些需求暂缓，以及成功标准是什么。
维度 02
口径和责任有没有对应起来
如果数据、流程和结果没有责任归属，后续大概率会不断反复。
维度 03
交付节奏是否符合组织承受力
项目再合理，也需要考虑团队是否有能力接住上线和变化。
维度 04
有没有留下后续复用的结构
包括代码、接口、工作流、报表口径和文档方法，而不是一次性交差。
写作方式
每篇交付观察都尽量落回具体动作
比起抽象观点，我们更想把问题拆到下一步该怎么做。
先写真实问题
从项目中反复出现的卡点入手，而不是先谈抽象概念。
再拆失真原因
把沟通断层、结构漏洞和执行卡点分别拆开，避免混在一起谈。
给到可执行动作
尽量落到先问什么、先定什么、先做哪一段链路，而不是只停留在观点。
持续根据项目经验修正
随着新的项目反馈出现，内容会继续更新，而不是一次定稿后不再动。
继续浏览
如果你想把内容和实际方案、合作入口连起来看，可以继续往下走
把能力判断、AI 与数据方法、沟通入口放在一起，会更容易找到当前最适合的下一步。
交付能力
看业务系统建设
如果你当前已经明确要做系统，可以直接看能力专题。
查看能力专题AI 与数据
看 AI 与数据治理
如果你更关心 AI 落地方式和数据口径问题，可以继续往下看这一组方法。
看 AI 与数据方法联系入口
提交想讨论的问题
如果你想让我们针对某类问题继续展开写，也可以直接告诉我们。
提交问题