Update project startup documents

- Interview map v2.1 → v2.2: Add Office version, workstation, and network questions
- Project retrospective v1 → v2: Document two-round discussion, add version tracking, reorganize pending items
- Planning document v1.4 → v1.5: Add frontend deployment strategy, early demo, and client cooperation items

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docs/01-项目启动/项目复盘.md

@@ -2,7 +2,8 @@
 
 **项目：** 调节阀工厂信息化管理系统建设  
 **文档用途：** 梳理前期讨论思路，供内部复盘，识别遗漏  
-**覆盖范围：** 从项目背景澄清到项目规划文档定稿的全过程  
+**覆盖范围：** 从项目背景澄清到项目规划文档定稿的全过程，以及后续审查与补充讨论  
+**文档版本：** v2
 
 ---
 
@@ -50,7 +51,9 @@
 ### 版本迭代
 
 - **v1**：包含"工厂基本情况"热身模块，每个业务模块 3 个问题
-- **v2**：移除热身模块，每个模块补充 3 个问题至 5～6 个，收尾模块同步补充，最终约 35 个问题
+- **v2.0**：移除热身模块，每个模块补充 3 个问题至 5～6 个，收尾模块同步补充，最终约 35 个问题。移除热身模块的原因：领导和客户领导本身就认识，领导对工厂基本情况已有基础认知，且这类信息在后续对话中会自然聊到，无需单独设模块
+- **v2.1**：将复盘文档中"待确认事项"转化为访谈问题，新增"模块七：系统环境与使用条件"（并发用户数、服务器、移动端、权限管理、运维期望）；在技术与图纸模块补充存量数据摸底问题
+- **v2.2**：新增 Office 版本确认、工作站数量与操作系统、局域网基础情况等问题，为前端部署和版本管理策略提供调研支撑
 
 ---
 
@@ -75,7 +78,7 @@
 
 ### 文档结构
 
-规划文档最终分为七个部分：项目背景与目标、技术选型、模块规划、分阶段实施计划、时间节点总览、风险识别与应对、项目成功标准。
+规划文档最终分为八个部分：项目背景与目标、技术选型、模块规划、分阶段实施计划、时间节点总览、风险识别与应对、客户侧配合事项、项目成功标准。
 
 ### 迭代过程中的关键修正
 
@@ -91,6 +94,20 @@
 
 原始模块规划未考虑订单变更场景，而这在小型定制化制造工厂中是高频事件。修正方向：在订单管理模块加入变更发起、记录和确认机制；在生产管理模块加入变更响应机制，区分暂停、修改、作废重开三种处理方式。两个模块形成上下游联动的完整变更处理链。
 
+**v1.3 → v1.4：模块依赖图重做与数据摸底补充**
+
+模块依赖关系图从 ASCII 改为 mermaid 格式，增加可读性，并加注说明"此图为建设顺序与数据依赖方向，非业务流程图"。第一阶段工作内容和产出物中补充了客户现有数据摸底的相关内容。
+
+**v1.4 → v1.5：前端部署策略、早期 Demo 与客户配合事项**
+
+这一轮修正来自对项目整体审查后的讨论，涉及三个方面：
+
+一是**前端部署与版本管理策略的引入**。此前的文档只关注了数据库层面的并发和部署问题，忽略了前端 Excel + VBA 在多人使用场景下的实际挑战。讨论后明确了核心设计原则——一人一份应用文件，前端不存储业务数据，所有读写走数据库。同时明确了 Office 版本统一的必要性，以及应用更新分发机制需结合客户 IT 环境在实施阶段确定。
+
+二是**早期 Demo 的引入**。原计划中，客户要到第 8 周才能看到第一个可用模块（物料编码 + BOM），而这个模块对客户来说感知价值低、过于抽象。在一个尚未签约的项目中，两个月没有可见产出存在信任风险。因此在第二阶段增加了一个早期 Demo 的要求：在基础数据初步录入后，尽早搭建一个简单可演示的功能点（如物料查询），让客户能看到实际成果，建立信心。
+
+三是**客户侧配合事项的独立成章**。此前文档中散落提到了一些需要客户配合的事项（如服务器采购、数据整理），但没有系统整理。考虑到本项目是私人关系促成，预期管理尤为重要，因此新增了独立章节，将启动前、实施中、以及建议书面化的事项分别列出，并建议以备忘录形式与客户达成共识。
+
 ---
 
 ## 四、贯穿全程的核心原则
@@ -105,27 +122,61 @@
 
 **文档服务于使用场景**：每份文档在设计前都先明确了使用者是谁、在什么场景下用、用来做什么，不做脱离使用场景的内容。
 
+**尽早让客户看到成果**：抽象的地基建设阶段也要有可感知的产出，通过早期 Demo 维持客户的信心和参与感。
+
+**预期对齐要书面化**：私人关系项目更需要用书面形式明确边界和责任，避免后期因预期不一致产生分歧。
+
 ---
 
 ## 五、待确认事项与潜在遗漏
 
-以下内容在当前讨论中尚未涉及或未深入，后续需要关注：
+> **说明：** 本章节记录当前已识别但尚未解决的事项。其中部分事项已转化为调研访谈中的问题（见调研对话地图 v2.2 模块七），部分为内部待讨论事项，部分为后续阶段再处理的事项。
 
-**调研阶段**
-- 领导与客户前几次非正式沟通的具体内容尚未掌握，调研前需内部对齐
-- 客户工厂的并发用户数尚未确认，直接影响数据库和部署方案的最终选择
-- 客户是否已有服务器，或是否有意愿采购服务器，需在第一阶段明确
+### 调研阶段（部分已纳入调研对话地图）
 
-**技术决策**
-- Access 与 SQL Server 的最终选择尚未定论，需内部讨论后确认
-- 系统是否需要支持手机端或仅限电脑端访问，尚未讨论
-- 多人同时使用时的权限管理（谁能看什么、谁能改什么）尚未纳入规划
+- ✅ 客户工厂的并发用户数 → 已纳入调研对话地图 v2.2 模块七
+- ✅ 客户是否已有服务器 → 已纳入调研对话地图 v2.2 模块七
+- ✅ 系统是否需要支持手机端 → 已纳入调研对话地图 v2.2 模块七
+- ✅ 权限管理需求 → 已纳入调研对话地图 v2.2 模块七
+- ✅ 客户各工作站 Office 版本和操作系统情况 → 已纳入调研对话地图 v2.2 模块七
+- ⬜ 领导与客户前几次非正式沟通的具体内容尚未掌握，调研前需内部对齐
 
-**项目推进**
-- 客户演示 PPT 尚未启动，这是当前已知的下一个待办任务
-- 项目报价和合同层面的内容完全未涉及
-- 系统上线后的运维和迭代支持方式尚未规划
+### 技术决策
+
+- ⬜ Access 与 SQL Server 的最终选择尚未定论，需调研后结合客户并发用户数和服务器情况内部讨论确认
+- ⬜ 应用更新分发的具体机制（共享文件夹、远程协助或其他方式）需结合客户 IT 环境确定
+
+### 项目推进
+
+- ⬜ 成本与报价分析：将单独出初稿文档，由领导讨论确认后再与客户沟通。定价模式（按阶段还是整体打包）尚未讨论
+- ⬜ 客户演示 PPT 尚未启动，这是调研完成后的下一个待办任务
+- ⬜ 项目边界备忘录：建议在调研后、正式开发前，与客户形成书面备忘，明确系统范围、配合责任和后续服务方式
+- ⬜ 系统上线后的运维和迭代支持方式尚未规划
+
+### 已明确暂不讨论的事项
+
+以下事项在讨论中被提出，经评估后决定暂不深入，记录原因备查：
+
+- **数据备份策略**：属于技术实现细节，后期项目开展时处理，当前阶段不影响规划
+- **时间估算的精确化**：当前为感性估算，后续需重新评估，但不影响当前文档的框架价值
+- **质检流程的深入设计**：属于具体业务流程，在调研阶段通过访谈了解现状后再做判断
+- **客户功能优先级排序的引导方式**：调研收尾模块的排序题仅作参考，实际实现顺序按系统架构需要决定
 
 ---
 
-*复盘文档 · 整理自项目前期讨论过程 · 供内部参考*
+## 六、文档版本管理
+
+项目文档使用 Git 进行版本管理，所有变更可追溯。当前各文档最新版本如下：
+
+| 文档名称 | 当前版本 | 主要内容 |
+|---------|---------|---------|
+| 项目讨论复盘 | v2 | 覆盖两轮讨论的完整复盘 |
+| 项目规划文档 | v1.5 | 含前端部署策略、早期Demo、客户配合事项 |
+| 调研访谈对话地图 | v2.2 | 含系统环境调研、Office版本与网络情况 |
+| 成本与报价分析 | 待启动 | 单独文档，初稿后交领导讨论 |
+| 客户演示 PPT | 待启动 | 基于规划文档制作，调研后启动 |
+| 项目边界备忘录 | 待启动 | 建议调研后、开发前与客户书面确认 |
+
+---
+
+*复盘文档 · v2 · 整理自项目前期讨论过程 · 供内部参考*