diff --git a/docs/01-项目启动/调研访谈地图.md b/docs/01-项目启动/调研访谈地图.md index 34c6ef3..69bdb93 100644 --- a/docs/01-项目启动/调研访谈地图.md +++ b/docs/01-项目启动/调研访谈地图.md @@ -2,7 +2,7 @@ **项目：** 调节阀工厂信息化系统建设 **用途：** 内部访谈引导 · 非逐题照读，按对话节奏灵活使用 -**版本：** v2.1 +**版本：** v2.2 --- @@ -162,10 +162,16 @@ 2. 你们现在有没有自己的服务器？就是那种专门放在机房里、大家电脑都连着它的那种机器？ → 确认是否已有服务器硬件，如果没有，需要在项目启动前推动客户采购，避免影响部署 -3. 你们现在不同岗位的人，看到的信息和能做的操作有没有区别？比如仓库的人能不能看到订单的价格，车间工人能不能改库存数据？ +3. 你们办公电脑上装的 Office 是什么版本？各台电脑上的版本一样吗？ + → 系统基于 Excel + VBA 开发，Office 版本不一致可能导致兼容性问题；需要提前了解现状，后续可能需要统一版本 + +4. 你们办公的电脑大概有多少台？用的是什么操作系统？这些电脑之间是通过网线连在一起的吗？ + → 了解工作站数量、操作系统版本和局域网基础情况，直接影响系统的部署方式和分发策略 + +5. 你们现在不同岗位的人，看到的信息和能做的操作有没有区别？比如仓库的人能不能看到订单的价格，车间工人能不能改库存数据？ → 了解客户对权限管理的需求程度，判断系统是否需要角色权限控制功能 -4. 系统上线以后，如果遇到问题或者想加新功能，你们希望怎么处理？是希望我们随时响应，还是攒一攒集中处理？ +6. 系统上线以后，如果遇到问题或者想加新功能，你们希望怎么处理？是希望我们随时响应，还是攒一攒集中处理？ → 了解客户对运维和后续迭代的期望，为后期服务模式的规划提供参考 --- @@ -190,4 +196,4 @@ --- -_内部工作文件 · v2.1 · 可根据访谈进展持续更新_ \ No newline at end of file +_内部工作文件 · v2.2 · 可根据访谈进展持续更新_ \ No newline at end of file diff --git a/docs/01-项目启动/项目复盘.md b/docs/01-项目启动/项目复盘.md index a45273b..319fe0c 100644 --- a/docs/01-项目启动/项目复盘.md +++ b/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 尚未启动，这是调研完成后的下一个待办任务 +- ⬜ 项目边界备忘录：建议在调研后、正式开发前，与客户形成书面备忘，明确系统范围、配合责任和后续服务方式 +- ⬜ 系统上线后的运维和迭代支持方式尚未规划 + +### 已明确暂不讨论的事项 + +以下事项在讨论中被提出，经评估后决定暂不深入，记录原因备查： + +- **数据备份策略**：属于技术实现细节，后期项目开展时处理，当前阶段不影响规划 +- **时间估算的精确化**：当前为感性估算，后续需重新评估，但不影响当前文档的框架价值 +- **质检流程的深入设计**：属于具体业务流程，在调研阶段通过访谈了解现状后再做判断 +- **客户功能优先级排序的引导方式**：调研收尾模块的排序题仅作参考，实际实现顺序按系统架构需要决定 --- -*复盘文档 · 整理自项目前期讨论过程 · 供内部参考* \ No newline at end of file +## 六、文档版本管理 + +项目文档使用 Git 进行版本管理，所有变更可追溯。当前各文档最新版本如下： + +| 文档名称 | 当前版本 | 主要内容 | +|---------|---------|---------| +| 项目讨论复盘 | v2 | 覆盖两轮讨论的完整复盘 | +| 项目规划文档 | v1.5 | 含前端部署策略、早期Demo、客户配合事项 | +| 调研访谈对话地图 | v2.2 | 含系统环境调研、Office版本与网络情况 | +| 成本与报价分析 | 待启动 | 单独文档，初稿后交领导讨论 | +| 客户演示 PPT | 待启动 | 基于规划文档制作，调研后启动 | +| 项目边界备忘录 | 待启动 | 建议调研后、开发前与客户书面确认 | + +--- + +*复盘文档 · v2 · 整理自项目前期讨论过程 · 供内部参考* \ No newline at end of file diff --git a/docs/01-项目启动/项目规划文档.md b/docs/01-项目启动/项目规划文档.md index eb79883..21e1ae2 100644 --- a/docs/01-项目启动/项目规划文档.md +++ b/docs/01-项目启动/项目规划文档.md @@ -4,7 +4,7 @@ **项目性质：** 定制化轻量信息化系统 **实施团队：** 内部两人团队（领导 + 技术实施） **文档用途：** 内部规划参考，指导项目全周期落地 -**文档版本：** v1.4 +**文档版本：** v1.5 --- @@ -79,6 +79,22 @@ - **本地部署**：系统部署在客户本地机器或服务器上，数据不出厂，安全可控 - **不追求技术先进性**：以稳定、可维护、易交付为第一优先级 +### 前端部署与版本管理策略 + +系统前端基于 Excel + VBA 开发，部署和版本管理需要提前规划，避免在多人使用时出现文件冲突或版本混乱。 + +**核心设计原则：一人一份应用文件，避免多人同时操作同一文件。** + +每个使用系统的员工在自己的电脑上运行独立的 Excel 应用文件，所有数据的读写通过后端数据库完成，前端文件本身不存储业务数据。这样既避免了多人同时打开同一 Excel 文件带来的锁定和冲突问题，也使得应用更新时只需替换各工作站上的文件即可。 + +**Office 版本统一要求：** + +由于 VBA 在不同 Office 版本间存在兼容性差异（如控件行为、函数支持、界面渲染等），需要在项目启动前确认客户各工作站的 Office 版本情况。建议推动客户将所有工作站的 Office 统一到同一版本，以降低开发和测试的复杂度，避免出现"在一台电脑上能用、在另一台上出问题"的情况。 + +**应用更新与分发：** + +当系统功能迭代或修复 Bug 时，需要将新版本的 Excel 应用文件分发到各工作站。具体的分发机制（如通过共享文件夹统一存放最新版本，或由我方远程协助更新）需结合客户的 IT 环境在实施阶段确定。设计应用文件时应考虑版本标识，便于确认各工作站是否运行的是最新版本。 + ### 部署方式 部署方式取决于数据库方案的选择： @@ -178,7 +194,7 @@ graph TD - 记录客户当前各环节的操作方式和痛点 - 确认各模块的具体需求和优先级 - 摸底客户现有数据状况：盘点现有 Excel 及其他载体中的物料数据、BOM 数据、订单数据等的规模、格式和质量，评估数据整理与迁移的工作量 -- 确认客户 IT 基础条件：并发用户数、是否已有服务器、是否需要移动端访问等，为数据库选型和部署方案提供决策依据 +- 确认客户 IT 基础条件：并发用户数、是否已有服务器、是否需要移动端访问、各工作站 Office 版本及操作系统等，为数据库选型、部署方案和前端兼容性提供决策依据 - 输出需求确认文档，作为后续开发的依据 **产出物** @@ -202,16 +218,19 @@ graph TD - 搭建物料主数据管理模块（录入界面 + 数据库） - 设计 BOM 数据结构，搭建 BOM 管理模块 - 协助客户完成存量物料数据的整理与录入 +- 在基础数据初步录入后，尽早搭建一个可演示的小型功能点（如物料查询界面），供客户实际体验，建立对系统的直观感知和信心 **产出物** - 物料编码规则文档 - 可用的物料主数据管理模块 - 可用的 BOM 管理模块 - 初始物料数据库（含客户现有物料数据） +- 可演示的早期 Demo（如物料查询功能） **阶段目标** - 物料编码体系落地，数据库中有真实可用的物料数据 - 为后续所有模块提供数据基础 +- 客户能够通过早期 Demo 看到实际成果，对项目方向建立信心 --- @@ -282,7 +301,7 @@ graph TD | 阶段 | 主要内容 | 时间区间 | 关键产出 | |------|---------|---------|---------| | 第一阶段 | 调研与需求确认 | 第1～3周 | 需求确认文档、数据摸底报告 | -| 第二阶段 | 物料编码 + BOM | 第4～8周 | 物料与BOM模块上线 | +| 第二阶段 | 物料编码 + BOM | 第4～8周 | 物料与BOM模块上线、早期Demo | | 第三阶段 | 库存 + 采购 | 第9～12周 | 库存采购模块上线 | | 第四阶段 | 订单 + 生产 | 第13～17周 | 订单生产模块上线 | | 第五阶段 | 发货 + 整合交付 | 第18～20周 | 完整系统交付 | @@ -297,14 +316,38 @@ graph TD |------|------|---------| | 需求变更 | 调研不充分导致开发中途改需求 | 第一阶段重点投入，确保需求文档经双方确认后再开发 | | 数据录入量大 | 存量物料数据录入可能耗时超预期 | 第一阶段完成数据摸底，提前评估工作量；协助客户设计数据整理模板，分批录入，不影响开发进度 | -| 客户使用习惯 | 员工不习惯新系统，使用率低 | 界面设计贴近 Excel 操作习惯，降低学习成本，上线前做培训 | +| 客户使用习惯 | 员工不习惯新系统，使用率低 | 界面设计贴近 Excel 操作习惯，降低学习成本，上线前做培训；尽早提供可体验的 Demo，让客户逐步适应 | | 并发访问限制 | 普通 Windows 系统对局域网并发连接数有上限，多人同时使用时可能出现连接被拒的情况 | 服务器操作系统必须使用 Windows Server，在项目启动前与客户确认并推动采购落实 | | 数据库稳定性 | Access 文件型数据库在多人并发写入时存在文件损坏的风险，一旦损坏数据难以恢复 | 采用 SQL Server Express 替代 Access 作为数据库，从根本上规避此风险 | | 开发时间有限 | 技术实施以业余时间为主 | 借助 AI 辅助开发提升效率，各阶段设置缓冲时间，优先保证核心模块 | +| Office 版本不一致 | 不同工作站 Office 版本不同，可能导致 VBA 程序出现兼容性问题 | 调研阶段摸清各工作站 Office 版本，推动客户在项目启动前统一 Office 版本 | +| 应用分发与更新 | 系统迭代后需将新版本分发到各工作站，若缺乏机制可能导致版本混乱 | 采用一人一份应用文件的设计，应用内置版本标识；结合客户 IT 环境确定分发机制（如共享文件夹存放最新版） | --- -## 七、项目成功标准 +## 七、客户侧配合事项 + +> **说明：** 以下事项需要客户方配合完成，建议在项目启动前或调研阶段与客户明确沟通，形成书面备忘，避免后期因预期不对齐产生分歧。 + +**项目启动前需客户配合确认的事项：** +- 是否同意将各工作站 Office 统一到同一版本（我方指定），并在项目开发启动前完成 +- 是否已有服务器或是否愿意采购服务器（若选择 SQL Server 方案） +- 指定一名内部对接人，负责协调访谈安排、数据收集和日常沟通 + +**项目实施过程中需客户配合的事项：** +- 安排相关岗位人员参与调研访谈 +- 配合整理现有物料、BOM 等存量数据，按模板格式提供 +- 每个阶段交付时安排人员进行试用和反馈 +- 系统上线前安排员工参与使用培训 + +**建议形成书面备忘的事项：** +- 系统包含哪些模块、不包含哪些（明确项目边界） +- 交付后的维护和修改如何处理（响应方式、是否收费） +- 客户方需承担的配合责任（数据整理、硬件采购、版本统一等） + +--- + +## 八、项目成功标准 - 系统覆盖从接单到发货的完整业务流程 - 客户可以独立完成日常操作，无需长期依赖技术支持 @@ -314,4 +357,4 @@ graph TD --- -*内部工作文件 · v1.4 · 可根据调研结果和项目进展持续更新* \ No newline at end of file +*内部工作文件 · v1.5 · 可根据调研结果和项目进展持续更新* \ No newline at end of file