6462cd8873
- Add Prettier as dev dependency - Apply formatting to interview map, retrospective, and planning document Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
184 lines
12 KiB
Markdown
184 lines
12 KiB
Markdown
# 项目讨论复盘
|
||
|
||
**项目：** 调节阀工厂信息化管理系统建设
|
||
**文档用途：** 梳理前期讨论思路，供内部复盘，识别遗漏
|
||
**覆盖范围：** 从项目背景澄清到项目规划文档定稿的全过程，以及后续审查与补充讨论
|
||
**文档版本：** v2
|
||
|
||
---
|
||
|
||
## 一、项目背景的建立过程
|
||
|
||
### 初始信息极为有限
|
||
|
||
讨论起点时，已知信息只有三点：客户是调节阀制造企业、希望引入信息化系统、找到我们团队来做。其余信息几乎空白。
|
||
|
||
### 通过追问逐步补全
|
||
|
||
背景信息是通过多轮提问逐步建立的，补全的关键信息包括：
|
||
|
||
- **客户画像**：中小型工厂，年产值约1亿，信息化基础为零，主要依赖 Excel 和口头传达管理生产
|
||
- **客户诉求**：不要复杂的大型系统，想要小巧、灵活、高度定制、成本可控的解决方案
|
||
- **团队构成**：两人团队，领导负责行业判断和客户对接，技术实施由我负责
|
||
- **领导背景**：具备数十年调节阀生产管理经验，这是客户找到我们的核心原因之一
|
||
- **技术背景**：团队具备信息化搭建能力，有在相近场景下的实践经验，借助 AI 辅助开发效率可显著提升
|
||
- **合作背景**：双方因私人关系促成，非正式商业招标，已有几次非正式沟通
|
||
|
||
### 一个关键判断的形成
|
||
|
||
在背景信息补全之后，形成了一个重要的认知调整：由于领导本身就是行业资深从业者，调研的目的不是"从零了解这个行业"，而是**确认这家具体工厂的现状和特殊之处**，找出与"典型工厂"的差异点，以及领导层真正的诉求优先级。这个判断直接影响了后续调研提纲的设计方式。
|
||
|
||
---
|
||
|
||
## 二、调研访谈文档的设计过程
|
||
|
||
### 定位的确立
|
||
|
||
在动手之前，先确立了文档的定位：不是问卷，不是表格，而是**访谈时的"对话地图"**。核心要求是口语化、模块清晰、每个模块只抓核心、并在问题后注明提问目的。
|
||
|
||
这个定位来自对使用场景的判断：客户更习惯语言沟通，不擅长技术性和文字性内容；文档的实际使用者是领导和我，在面对面洽谈时作为引导工具使用。
|
||
|
||
### 结构设计
|
||
|
||
最终确定的结构是**两层**：
|
||
|
||
- 第一层：模块划分，按业务流向排列（订单 → 技术 → 采购 → 仓库 → 生产 → 发货）
|
||
- 第二层：每个模块内 2～4 个引导问题 + 每题附备注（说明提问目的）
|
||
|
||
### 问题设计的核心原则
|
||
|
||
问题措辞刻意口语化、场景化，例如"客户问你们货到哪了，你们怎么回答"，而非"你们是否有订单跟踪系统"。目的是通过具体场景引出真实答案，而非让客户对着系统功能清单作答。
|
||
|
||
### 版本迭代
|
||
|
||
- **v1**：包含"工厂基本情况"热身模块，每个业务模块 3 个问题
|
||
- **v2.0**：移除热身模块，每个模块补充 3 个问题至 5～6 个，收尾模块同步补充，最终约 35 个问题。移除热身模块的原因：领导和客户领导本身就认识，领导对工厂基本情况已有基础认知，且这类信息在后续对话中会自然聊到，无需单独设模块
|
||
- **v2.1**：将复盘文档中"待确认事项"转化为访谈问题，新增"模块七：系统环境与使用条件"（并发用户数、服务器、移动端、权限管理、运维期望）；在技术与图纸模块补充存量数据摸底问题
|
||
- **v2.2**：新增 Office 版本确认、工作站数量与操作系统、局域网基础情况等问题，为前端部署和版本管理策略提供调研支撑
|
||
|
||
---
|
||
|
||
## 三、项目规划文档的设计过程
|
||
|
||
### 补全关键信息
|
||
|
||
在进入规划设计之前，通过追问补全了四类关键信息：
|
||
|
||
- **技术栈**：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：订单变更处理的引入**
|
||
|
||
原始模块规划未考虑订单变更场景，而这在小型定制化制造工厂中是高频事件。修正方向：在订单管理模块加入变更发起、记录和确认机制；在生产管理模块加入变更响应机制，区分暂停、修改、作废重开三种处理方式。两个模块形成上下游联动的完整变更处理链。
|
||
|
||
**v1.3 → v1.4：模块依赖图重做与数据摸底补充**
|
||
|
||
模块依赖关系图从 ASCII 改为 mermaid 格式，增加可读性，并加注说明"此图为建设顺序与数据依赖方向，非业务流程图"。第一阶段工作内容和产出物中补充了客户现有数据摸底的相关内容。
|
||
|
||
**v1.4 → v1.5：前端部署策略、早期 Demo 与客户配合事项**
|
||
|
||
这一轮修正来自对项目整体审查后的讨论，涉及三个方面：
|
||
|
||
一是**前端部署与版本管理策略的引入**。此前的文档只关注了数据库层面的并发和部署问题，忽略了前端 Excel + VBA 在多人使用场景下的实际挑战。讨论后明确了核心设计原则——一人一份应用文件，前端不存储业务数据，所有读写走数据库。同时明确了 Office 版本统一的必要性，以及应用更新分发机制需结合客户 IT 环境在实施阶段确定。
|
||
|
||
二是**早期 Demo 的引入**。原计划中，客户要到第 8 周才能看到第一个可用模块（物料编码 + BOM），而这个模块对客户来说感知价值低、过于抽象。在一个尚未签约的项目中，两个月没有可见产出存在信任风险。因此在第二阶段增加了一个早期 Demo 的要求：在基础数据初步录入后，尽早搭建一个简单可演示的功能点（如物料查询），让客户能看到实际成果，建立信心。
|
||
|
||
三是**客户侧配合事项的独立成章**。此前文档中散落提到了一些需要客户配合的事项（如服务器采购、数据整理），但没有系统整理。考虑到本项目是私人关系促成，预期管理尤为重要，因此新增了独立章节，将启动前、实施中、以及建议书面化的事项分别列出，并建议以备忘录形式与客户达成共识。
|
||
|
||
---
|
||
|
||
## 四、贯穿全程的核心原则
|
||
|
||
以下几个原则在整个讨论过程中始终被强调，值得在后续工作中持续遵守：
|
||
|
||
**聚焦可行性，不追求高大上**：团队非专业信息化开发团队，客户也不需要复杂系统，所有决策优先考虑能不能落地，而非技术是否先进。
|
||
|
||
**地基优先**：物料编码和 BOM 是整套系统的数据基础，必须在第一阶段落实，后续模块不能在地基未稳的情况下开始建设。
|
||
|
||
**分阶段交付**：系统按模块拆分，逐阶段交付，每个阶段有明确产出物，避免一次性交付带来的风险。
|
||
|
||
**文档服务于使用场景**：每份文档在设计前都先明确了使用者是谁、在什么场景下用、用来做什么，不做脱离使用场景的内容。
|
||
|
||
**尽早让客户看到成果**：抽象的地基建设阶段也要有可感知的产出，通过早期 Demo 维持客户的信心和参与感。
|
||
|
||
**预期对齐要书面化**：私人关系项目更需要用书面形式明确边界和责任，避免后期因预期不一致产生分歧。
|
||
|
||
---
|
||
|
||
## 五、待确认事项与潜在遗漏
|
||
|
||
> **说明：** 本章节记录当前已识别但尚未解决的事项。其中部分事项已转化为调研访谈中的问题（见调研对话地图 v2.2 模块七），部分为内部待讨论事项，部分为后续阶段再处理的事项。
|
||
|
||
### 调研阶段（部分已纳入调研对话地图）
|
||
|
||
- ✅ 客户工厂的并发用户数 → 已纳入调研对话地图 v2.2 模块七
|
||
- ✅ 客户是否已有服务器 → 已纳入调研对话地图 v2.2 模块七
|
||
- ✅ 系统是否需要支持手机端 → 已纳入调研对话地图 v2.2 模块七
|
||
- ✅ 权限管理需求 → 已纳入调研对话地图 v2.2 模块七
|
||
- ✅ 客户各工作站 Office 版本和操作系统情况 → 已纳入调研对话地图 v2.2 模块七
|
||
- ⬜ 领导与客户前几次非正式沟通的具体内容尚未掌握，调研前需内部对齐
|
||
|
||
### 技术决策
|
||
|
||
- ⬜ Access 与 SQL Server 的最终选择尚未定论，需调研后结合客户并发用户数和服务器情况内部讨论确认
|
||
- ⬜ 应用更新分发的具体机制（共享文件夹、远程协助或其他方式）需结合客户 IT 环境确定
|
||
|
||
### 项目推进
|
||
|
||
- ⬜ 成本与报价分析：将单独出初稿文档，由领导讨论确认后再与客户沟通。定价模式（按阶段还是整体打包）尚未讨论
|
||
- ⬜ 客户演示 PPT 尚未启动，这是调研完成后的下一个待办任务
|
||
- ⬜ 项目边界备忘录：建议在调研后、正式开发前，与客户形成书面备忘，明确系统范围、配合责任和后续服务方式
|
||
- ⬜ 系统上线后的运维和迭代支持方式尚未规划
|
||
|
||
### 已明确暂不讨论的事项
|
||
|
||
以下事项在讨论中被提出，经评估后决定暂不深入，记录原因备查：
|
||
|
||
- **数据备份策略**：属于技术实现细节，后期项目开展时处理，当前阶段不影响规划
|
||
- **时间估算的精确化**：当前为感性估算，后续需重新评估，但不影响当前文档的框架价值
|
||
- **质检流程的深入设计**：属于具体业务流程，在调研阶段通过访谈了解现状后再做判断
|
||
- **客户功能优先级排序的引导方式**：调研收尾模块的排序题仅作参考，实际实现顺序按系统架构需要决定
|
||
|
||
---
|
||
|
||
## 六、文档版本管理
|
||
|
||
项目文档使用 Git 进行版本管理，所有变更可追溯。当前各文档最新版本如下：
|
||
|
||
| 文档名称 | 当前版本 | 主要内容 |
|
||
| ---------------- | -------- | -------------------------------------- |
|
||
| 项目讨论复盘 | v2 | 覆盖两轮讨论的完整复盘 |
|
||
| 项目规划文档 | v1.5 | 含前端部署策略、早期Demo、客户配合事项 |
|
||
| 调研访谈对话地图 | v2.2 | 含系统环境调研、Office版本与网络情况 |
|
||
| 成本与报价分析 | 待启动 | 单独文档，初稿后交领导讨论 |
|
||
| 客户演示 PPT | 待启动 | 基于规划文档制作，调研后启动 |
|
||
| 项目边界备忘录 | 待启动 | 建议调研后、开发前与客户书面确认 |
|
||
|
||
---
|
||
|
||
_复盘文档 · v2 · 整理自项目前期讨论过程 · 供内部参考_
|