3ac3d3f4bb
- 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>
131 lines
6.9 KiB
Markdown
131 lines
6.9 KiB
Markdown
# 项目讨论复盘
|
||
|
||
**项目：** 调节阀工厂信息化管理系统建设
|
||
**文档用途：** 梳理前期讨论思路，供内部复盘，识别遗漏
|
||
**覆盖范围：** 从项目背景澄清到项目规划文档定稿的全过程
|
||
|
||
---
|
||
|
||
## 一、项目背景的建立过程
|
||
|
||
### 初始信息极为有限
|
||
|
||
讨论起点时，已知信息只有三点：客户是调节阀制造企业、希望引入信息化系统、找到我们团队来做。其余信息几乎空白。
|
||
|
||
### 通过追问逐步补全
|
||
|
||
背景信息是通过多轮提问逐步建立的，补全的关键信息包括：
|
||
|
||
- **客户画像**：中小型工厂，年产值约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 尚未启动，这是当前已知的下一个待办任务
|
||
- 项目报价和合同层面的内容完全未涉及
|
||
- 系统上线后的运维和迭代支持方式尚未规划
|
||
|
||
---
|
||
|
||
*复盘文档 · 整理自项目前期讨论过程 · 供内部参考* |