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