From 3ac3d3f4bb4f127f78fda93e4675952e4bddc50a Mon Sep 17 00:00:00 2001
From: Misaka <pengqiangqiang@gmail.com>
Date: Sun, 12 Apr 2026 16:11:08 +0800
Subject: [PATCH] Add project discussion retrospective document

- Document project background establishment process
- Record research interview document design iterations
- Track project planning document evolution (v1.0 to v1.3)
- Summarize core principles followed throughout
- List pending items and potential gaps

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---
 docs/01-项目启动/项目复盘.md | 131 +++++++++++++++++++++++++++++++++++
 1 file changed, 131 insertions(+)
 create mode 100644 docs/01-项目启动/项目复盘.md

diff --git a/docs/01-项目启动/项目复盘.md b/docs/01-项目启动/项目复盘.md
new file mode 100644
index 0000000..a45273b
--- /dev/null
+++ b/docs/01-项目启动/项目复盘.md
@@ -0,0 +1,131 @@
+# 项目讨论复盘
+
+**项目：** 调节阀工厂信息化管理系统建设  
+**文档用途：** 梳理前期讨论思路，供内部复盘，识别遗漏  
+**覆盖范围：** 从项目背景澄清到项目规划文档定稿的全过程  
+
+---
+
+## 一、项目背景的建立过程
+
+### 初始信息极为有限
+
+讨论起点时，已知信息只有三点：客户是调节阀制造企业、希望引入信息化系统、找到我们团队来做。其余信息几乎空白。
+
+### 通过追问逐步补全
+
+背景信息是通过多轮提问逐步建立的，补全的关键信息包括：
+
+- **客户画像**：中小型工厂，年产值约1亿，信息化基础为零，主要依赖 Excel 和口头传达管理生产
+- **客户诉求**：不要复杂的大型系统，想要小巧、灵活、高度定制、成本可控的解决方案
+- **团队构成**：两人团队，领导负责行业判断和客户对接，技术实施由我负责
+- **领导背景**：具备数十年调节阀生产管理经验，这是客户找到我们的核心原因之一
+- **技术背景**：团队具备信息化搭建能力，有在相近场景下的实践经验，借助 AI 辅助开发效率可显著提升
+- **合作背景**：双方因私人关系促成，非正式商业招标，已有几次非正式沟通
+
+### 一个关键判断的形成
+
+在背景信息补全之后，形成了一个重要的认知调整：由于领导本身就是行业资深从业者，调研的目的不是"从零了解这个行业"，而是**确认这家具体工厂的现状和特殊之处**，找出与"典型工厂"的差异点，以及领导层真正的诉求优先级。这个判断直接影响了后续调研提纲的设计方式。
+
+---
+
+## 二、调研访谈文档的设计过程
+
+### 定位的确立
+
+在动手之前，先确立了文档的定位：不是问卷，不是表格，而是**访谈时的"对话地图"**。核心要求是口语化、模块清晰、每个模块只抓核心、并在问题后注明提问目的。
+
+这个定位来自对使用场景的判断：客户更习惯语言沟通，不擅长技术性和文字性内容；文档的实际使用者是领导和我，在面对面洽谈时作为引导工具使用。
+
+### 结构设计
+
+最终确定的结构是**两层**：
+- 第一层：模块划分，按业务流向排列（订单 → 技术 → 采购 → 仓库 → 生产 → 发货）
+- 第二层：每个模块内 2～4 个引导问题 + 每题附备注（说明提问目的）
+
+### 问题设计的核心原则
+
+问题措辞刻意口语化、场景化，例如"客户问你们货到哪了，你们怎么回答"，而非"你们是否有订单跟踪系统"。目的是通过具体场景引出真实答案，而非让客户对着系统功能清单作答。
+
+### 版本迭代
+
+- **v1**：包含"工厂基本情况"热身模块，每个业务模块 3 个问题
+- **v2**：移除热身模块，每个模块补充 3 个问题至 5～6 个，收尾模块同步补充，最终约 35 个问题
+
+---
+
+## 三、项目规划文档的设计过程
+
+### 补全关键信息
+
+在进入规划设计之前，通过追问补全了四类关键信息：
+
+- **技术栈**：VBA 为主，Python 按需补充，Access 或 SQL Server 作为数据库，本地部署
+- **项目边界**：部署在客户本地，非云端服务
+- **时间预期**：无客户方明确要求，由我方制定，参考周期 4～6 个月
+- **文档受众**：内部自用，客户看的是后续基于此文档制作的演示 PPT
+
+### 两个前置判断
+
+在开始写文档之前，先同步了两个判断：
+
+**关于开发工作量**：技术实施以业余时间为主，但 AI 辅助开发可成倍提升效率，整体可行性良好。
+
+**关于模块优先级**：物料编码 + BOM 是整个系统的数据地基，所有后续模块依赖它，应作为第一阶段的核心建设内容。这一判断得到了确认。
+
+### 文档结构
+
+规划文档最终分为七个部分：项目背景与目标、技术选型、模块规划、分阶段实施计划、时间节点总览、风险识别与应对、项目成功标准。
+
+### 迭代过程中的关键修正
+
+**v1.0 → v1.1：数据库与部署方式的修正**
+
+初版将 Access 作为唯一数据库方案，经讨论发现两个问题：Access 文件型数据库存在多人并发时文件损坏的风险；普通 Windows 系统对局域网并发连接数有约 20 个的上限限制，多人使用场景下需要 Windows Server。修正方向：数据库改为 SQL Server Express，服务器操作系统明确建议使用 Windows Server。
+
+**v1.1 → v1.2：技术选型补充 Access 作为可选方案**
+
+考虑到文档需经内部讨论，Access 和 SQL Server 两个方案各有适用场景，不宜只保留一个。修正方向：将两个方案并列列出，分别说明优点和局限性，加入"数据库方案对比"小节，便于领导对照决策。
+
+**v1.2 → v1.3：订单变更处理的引入**
+
+原始模块规划未考虑订单变更场景，而这在小型定制化制造工厂中是高频事件。修正方向：在订单管理模块加入变更发起、记录和确认机制；在生产管理模块加入变更响应机制，区分暂停、修改、作废重开三种处理方式。两个模块形成上下游联动的完整变更处理链。
+
+---
+
+## 四、贯穿全程的核心原则
+
+以下几个原则在整个讨论过程中始终被强调，值得在后续工作中持续遵守：
+
+**聚焦可行性，不追求高大上**：团队非专业信息化开发团队，客户也不需要复杂系统，所有决策优先考虑能不能落地，而非技术是否先进。
+
+**地基优先**：物料编码和 BOM 是整套系统的数据基础，必须在第一阶段落实，后续模块不能在地基未稳的情况下开始建设。
+
+**分阶段交付**：系统按模块拆分，逐阶段交付，每个阶段有明确产出物，避免一次性交付带来的风险。
+
+**文档服务于使用场景**：每份文档在设计前都先明确了使用者是谁、在什么场景下用、用来做什么，不做脱离使用场景的内容。
+
+---
+
+## 五、待确认事项与潜在遗漏
+
+以下内容在当前讨论中尚未涉及或未深入，后续需要关注：
+
+**调研阶段**
+- 领导与客户前几次非正式沟通的具体内容尚未掌握，调研前需内部对齐
+- 客户工厂的并发用户数尚未确认，直接影响数据库和部署方案的最终选择
+- 客户是否已有服务器，或是否有意愿采购服务器，需在第一阶段明确
+
+**技术决策**
+- Access 与 SQL Server 的最终选择尚未定论，需内部讨论后确认
+- 系统是否需要支持手机端或仅限电脑端访问，尚未讨论
+- 多人同时使用时的权限管理（谁能看什么、谁能改什么）尚未纳入规划
+
+**项目推进**
+- 客户演示 PPT 尚未启动，这是当前已知的下一个待办任务
+- 项目报价和合同层面的内容完全未涉及
+- 系统上线后的运维和迭代支持方式尚未规划
+
+---
+
+*复盘文档 · 整理自项目前期讨论过程 · 供内部参考*
\ No newline at end of file