• 🧩 先把问题定义清楚：团队与项目计划、背景调研（literature 加实地）、问题陈述
• 再设计方案的形状：需求与备选方案、用户画像与系统叙事、用户界面
• 然后落到技术细节：数据流图 DFD、业务流程图 BPMN
• 最后处理组织怎么用起来：风险与缓解
• 到第十三周，全队站到客户面前讲 3 分钟，再接 5 分钟问答

这条链顺手解释了两件事。系统思维和设计思维那两周再抽象也跳不过去，问题陈述紧跟着就要交；Week 7–9 突然要画图也有出处，DFD 和 BPMN 本身就是链上的部件。

一个部件被做出来大概长什么样，课上有个在线书店的例子可以直接看。现状流程里，客服先核对订单、生成标签、转给仓库，仓库这才去查库存；一旦缺货，前面几步全部作废。改进的版本把库存检查提到下单那一刻，两张标签合成一张数字标签。你交上去的，就是这种先画现状、再画目标、每处改动都说得出理由的东西。

🔁 lecture notes 教完一个方法，一到三周内它就会变成要交的东西。跟课的节奏和交付的节奏，在这门课里是同一条线。

🔨 手里拿着锤子，看什么都像钉子

链条的第三环是问题陈述。它听起来最轻，只有几句话，可它要全队一起写，而且必须能从上一周的背景调研逻辑推出来。lecture notes 给了两条自查：一条看你写下来的落点，一个事件还是一个结构；另一条把偷偷藏进问题句里的解决方案挑出来。

☕ 举个例子。门店高峰期排队二十分钟，这件事你们都看到了。第一种写法是「门店缺少线上点单 App」，读起来很顺，问题也算说清楚了。可你把它交上去以后，后面九个部件全被锁死：需求围着 App 写，界面画 App 的界面，风险评估评的还是 App 的风险。第二种写法是「点单和制作共用同一个柜台，顾客的等待时间被制作速度封顶」，它停在结构那一层，没有替方案表态，后面你才有几个方向可以比较取舍。两句话的差别，落在它们各自允许后面出现多少种方案。写第一种的时候，你其实已经替客户把决定做完了。

Week 4 lecture notes 配了一句「For a man with a hammer, every problem looks like a nail」，对应的学科陷阱写得很直白：技术背景的人容易把所有问题都看成「做个 App」。同一周的项目反馈说得更狠，造成用户那种体验的原因可能跟数字系统一点关系都没有，而你最后要交的方案一定是个数字系统。所以先查成因，别让手里的工具替你决定问题长什么样。

后果是可查的。路演的四条 marking criteria 里，「问题讲没讲清」和「方案怎么解决它」各占一条；最终报告要求 relevant、consistent、aligned，早期的问题定义跟后面的流程、风险章节对不上，会反复失分。

⭐ 每周那份交付，按能直接进最终报告的标准写

📄 final 那份提案有 50 页上限，不含 reference list 和附录，lecturer 明确说过更长不等于更好。内容来源同样清楚：完整报告等于所有改进过的周交付的整合。

所以 final 那一步的工作性质是整合和改进，writing 压力被整体前移到了每周。

顺着这个，法则就出来了：每周交的那一份，按最终报告的标准写。当周多花的那点时间，final 会以少改一遍还给你。第三周那份团队计划、后面那句问题陈述、Week 7–9 画出来的 DFD 和 BPMN，最后要在同一份文件里彼此对得上；lecturer 给的判断标准也停在这里，第十三周站到客户面前讲清两件事，他们的问题是什么，你们的方案怎么帮他们解决它。

⏱️ 工作量他写得很直白，每个团队在这个项目上集体投入至少 150 小时，一名全职员工连着干一个多月。第一讲还有一页叫 EXIT，想用最小的力气换 credit、把活拖到学期末、躲开 group assignment，lecturer 直接写了 this unit of study is not for you。grade 档位指向同一处，P 对应 threshold knowledge，high score 那一档要的是批判性评估、原创和迁移到新情境，把 lecture notes 背熟拿不到那里。

📖 黄金法则就一句：每周交上去的那份按最终报告的标准写，final 只做整合和改进。