246 lines
8.9 KiB
Markdown
246 lines
8.9 KiB
Markdown
# 摩通电气 · 研发管理方案说明
|
||
|
||
> 面向：深圳摩通电气有限公司
|
||
> 文档目的：说明「代码怎么管、进度怎么看、结果怎么呈现在飞书」的整体架构，便于管理层与技术负责人理解与评审。
|
||
> 版本：演示版（基于已搭建的飞书多维表格「摩通电气-研发管理」）
|
||
|
||
---
|
||
|
||
## 1. 要解决什么问题
|
||
|
||
摩通电气从事电网运行状态检测类仪器设备（核相测量、电缆探测、校验等），研发同时覆盖：
|
||
|
||
- 嵌入式固件
|
||
- 上位机 / 手持机软件
|
||
- 硬件与试验相关资料
|
||
- 版本发版与售后追溯
|
||
|
||
技术人数较多时，常见痛点是：
|
||
|
||
| 痛点 | 结果 |
|
||
|------|------|
|
||
| 代码与文档分散 | 找不到、难协作、难追溯 |
|
||
| 进度只在口头/群聊 | 负责人看不到全局 |
|
||
| 提交很多但看不出交付 | 无法判断是否按期发版 |
|
||
| 固件版本与任务脱节 | 现场与售后难以追责 |
|
||
|
||
本方案的目标一句话：
|
||
|
||
**Gitea 管研发资产（代码与技术文档），飞书管协作与呈现（任务、排期、发版、统计）；中间由自动化能力把代码动态同步进飞书。**
|
||
|
||
---
|
||
|
||
## 2. 整体架构（先看这一张图）
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph Dev["研发侧 · 真相源"]
|
||
Gitea["Gitea<br/>代码 / 文档 / PR / Release"]
|
||
end
|
||
|
||
subgraph Sync["同步层 · 匠厂平台技能"]
|
||
Skill["RPA / API 技能<br/>读取 Gitea 事件与数据"]
|
||
end
|
||
|
||
subgraph Feishu["飞书 · 协作与呈现"]
|
||
Base["多维表格：摩通电气-研发管理"]
|
||
Board["看板 · 按状态"]
|
||
Gantt["甘特 · 按产品线"]
|
||
Dash["仪表盘 · 研发总览"]
|
||
end
|
||
|
||
subgraph People["使用角色"]
|
||
Eng["技术工程师"]
|
||
Lead["组长 / 负责人"]
|
||
Boss["管理层"]
|
||
end
|
||
|
||
Gitea --> Skill
|
||
Skill --> Base
|
||
Base --> Board
|
||
Base --> Gantt
|
||
Base --> Dash
|
||
|
||
Eng --> Gitea
|
||
Eng --> Board
|
||
Lead --> Board
|
||
Lead --> Gantt
|
||
Lead --> Dash
|
||
Boss --> Dash
|
||
```
|
||
|
||
### 三层分工（务必记住）
|
||
|
||
| 层级 | 用什么 | 干什么 | 不干什么 |
|
||
|------|--------|--------|----------|
|
||
| 资产层 | Gitea | 存代码、技术文档、合并请求、发版包 | 不承担公司级进度汇报 |
|
||
| 同步层 | 匠厂技能（RPA/API） | 把提交、PR、发版等写入飞书 | 不替代项目管理决策 |
|
||
| 呈现层 | 飞书多维表格 | 任务流转、排期、发版台账、管理看板 | 不替代 Git 作为代码仓库 |
|
||
|
||
---
|
||
|
||
## 3. 和摩通业务怎么对齐
|
||
|
||
官网产品线大致分为：**核相测量、电缆探测、校验系列**（另有公共平台与代理类）。
|
||
飞书里的「产品线」按此划分，任务、仓库、发版都用同一套口径，避免各说各话。
|
||
|
||
示例对应关系：
|
||
|
||
| 产品线 | 典型型号（示例） | 常见研发对象 |
|
||
|--------|------------------|--------------|
|
||
| 核相测量 | MT-870、INPUT-6600 | 固件 + 手持/上位 + 授时/通信 |
|
||
| 电缆探测 | K-90、K-73 等 | 固件 + 探测算法 + 地图/定位相关 |
|
||
| 校验系列 | 开关柜校验类设备 | 固件 + 试验验证 |
|
||
| 公共平台 | BSP、协议库等 | 跨产品复用组件 |
|
||
|
||
---
|
||
|
||
## 4. 飞书里建了什么（客户可直接打开看）
|
||
|
||
飞书多维表格名称：**摩通电气-研发管理**
|
||
|
||
### 4.1 六张数据表
|
||
|
||
| 表名 | 作用 | 演示时怎么讲 |
|
||
|------|------|----------------|
|
||
| 研发任务表 | 任务主表：谁做、做到哪、何时完成 | 「日常工作入口」 |
|
||
| 仓库台账表 | 有哪些 Gitea 仓库、归属哪条产品线 | 「代码资产目录」 |
|
||
| 人员档案表 | 人员 ↔ Gitea 账号映射、团队与角色 | 「人和账号对齐」 |
|
||
| 版本发布表 | 固件/软件发版记录、适用型号、测试结论 | 「发版可追溯」 |
|
||
| 提交流水表 | 从 Gitea 同步的 commit 明细 | 「代码活跃证据」 |
|
||
| 合并请求表 | 从 Gitea 同步的 PR 状态与超时未审 | 「评审与风险」 |
|
||
|
||
> 说明：表与表之间的深度关联（双向关联）可按实施节奏逐步加强；当前演示版以「字段对齐 + 同一套仓库名/任务编号」保证能讲清楚闭环。
|
||
|
||
### 4.2 三种看法（同一套数据，三种用途）
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
T["研发任务表"] --> K["看板-按状态<br/>看流转"]
|
||
T --> G["甘特-按产品线<br/>看排期"]
|
||
T --> D["仪表盘-研发总览<br/>看结果"]
|
||
C["提交流水 / 合并请求 / 版本发布"] --> D
|
||
```
|
||
|
||
| 视图 | 回答的问题 | 主要给谁看 |
|
||
|------|------------|------------|
|
||
| 看板-按状态 | 现在卡在评审 / 开发 / 联调 / 测试 / 发布哪一环？ | 工程师、组长 |
|
||
| 甘特-按产品线 | 什么时候开始、什么时候该完成？会不会撞期？ | 负责人、项目协调 |
|
||
| 仪表盘-研发总览 | 在研多少、提交多少、PR 多少、发了几个版？ | 管理层、周会 |
|
||
|
||
### 4.3 任务状态（看板列，统一语言）
|
||
|
||
```
|
||
待评审 → 待开发 → 开发中 → 联调中 → 待测试 → 待发布 → 已发布 → 已关闭
|
||
```
|
||
|
||
嵌入式场景保留 **联调中**，避免「写完代码就算完成」。
|
||
|
||
### 4.4 仪表盘关键指标（研发总览）
|
||
|
||
- 在研任务数
|
||
- 本周提交数
|
||
- 打开中的 PR 数
|
||
- 已发布版本数
|
||
- 任务按状态 / 按产品线分布
|
||
- 开发者提交活跃度
|
||
- PR 状态（可突出超时未审）
|
||
- 发版明细、阻塞任务明细
|
||
|
||
---
|
||
|
||
## 5. 数据如何从 Gitea 到飞书
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant Dev as 工程师
|
||
participant Gitea as Gitea
|
||
participant Skill as 匠厂同步技能
|
||
participant FS as 飞书多维表格
|
||
|
||
Dev->>Gitea: Push / 提PR / 发Release
|
||
Gitea-->>Skill: Webhook 或 API 拉取
|
||
Skill->>Skill: 账号映射、仓库归属、字段清洗
|
||
Skill->>FS: 写入提交流水 / 合并请求 / 版本发布等
|
||
Note over FS: 任务看板仍以人工维护状态为主<br/>代码动态自动进表作证
|
||
```
|
||
|
||
**原则：**
|
||
|
||
1. **任务状态以飞书为准**（人要确认是否联调完、是否可测、是否可发）。
|
||
2. **代码事实以 Gitea 为准**（提交了什么、PR 是否合并、发了哪个 Tag）。
|
||
3. **同步层只搬运与对齐**，不在飞书里「发明」第二套代码库。
|
||
|
||
---
|
||
|
||
## 6. 推荐使用方式（落地后怎么干活）
|
||
|
||
| 角色 | 每天/每周怎么用 |
|
||
|------|-----------------|
|
||
| 工程师 | 代码提交到 Gitea；在飞书任务看板更新自己的任务状态；阻塞打勾并注明原因 |
|
||
| 组长 | 看看板堵点；看 PR 是否超时未审；看甘特是否撞期 |
|
||
| 负责人 | 看甘特产品线排期；看版本发布表是否按计划出包 |
|
||
| 管理层 | 打开「研发总览」仪表盘；周会只看数字与风险，不翻聊天记录 |
|
||
|
||
---
|
||
|
||
## 7. 为什么这样设计（给决策用）
|
||
|
||
1. **客户已在飞书**：学习成本低，看板/甘特/仪表盘都在熟悉环境里。
|
||
2. **Gitea 适合内网研发资产**：权限可控，符合电力行业对代码与资料的管理习惯。
|
||
3. **不把「提交次数」当唯一考核**：仪表盘里的活跃度只作参考；真正交付看任务完成与发版。
|
||
4. **按产品线（核相/电缆/校验）组织**：贴合摩通实际销售与研发布局，而不是抽象「项目编号」。
|
||
|
||
---
|
||
|
||
## 8. 实施节奏建议
|
||
|
||
| 阶段 | 内容 | 结果 |
|
||
|------|------|------|
|
||
| 已完成（演示版） | 飞书六表 + 看板 + 甘特 + 仪表盘 + 模拟数据 | 可对外讲清架构与呈现 |
|
||
| 下一阶段 | 正式 Gitea 仓库规范 + 账号映射 + 同步技能接通 | 流水/PR/发版变为真实数据 |
|
||
| 加强阶段 | 任务与仓库/PR/发版深度关联、权限分级、周报自动化 | 周会与售后追溯更省力 |
|
||
|
||
---
|
||
|
||
## 9. 演示时建议打开的页面顺序
|
||
|
||
1. **架构说明**（本文档 / 口述三层分工）
|
||
2. **看板-按状态** → 任务怎么流转
|
||
3. **甘特-按产品线** → 排期怎么看
|
||
4. **提交流水 / 合并请求** → 代码动态如何进飞书
|
||
5. **版本发布表** → 固件版本如何追溯
|
||
6. **研发总览仪表盘** → 给管理层的一页纸
|
||
|
||
---
|
||
|
||
## 10. 总结
|
||
|
||
本方案不是「再买一套项目管理软件」，而是：
|
||
|
||
> **用 Gitea 把摩通的研发资产收拢，用飞书把进度与结果讲清楚，用同步技能把两边连起来。**
|
||
|
||
当前飞书「摩通电气-研发管理」已具备可演示的完整呈现骨架；接入真实 Gitea 与同步技能后，即可从演示版升级为日常生产用法。
|
||
|
||
---
|
||
|
||
## 附录 A · 表职责一览（速查）
|
||
|
||
| 表 | 一行代表什么 |
|
||
|----|----------------|
|
||
| 研发任务表 | 一个可交付研发任务 |
|
||
| 仓库台账表 | 一个 Gitea 仓库 |
|
||
| 人员档案表 | 一个研发人员及其账号映射 |
|
||
| 版本发布表 | 一次发版（Tag/Release） |
|
||
| 提交流水表 | 一次代码提交 |
|
||
| 合并请求表 | 一个 PR |
|
||
|
||
## 附录 B · 文档信息
|
||
|
||
| 项 | 内容 |
|
||
|----|------|
|
||
| 方案对象 | 深圳摩通电气有限公司 |
|
||
| 参考官网 | http://www.szmtdq.cn/ |
|
||
| 飞书载体 | 多维表格「摩通电气-研发管理」 |
|
||
| 文档性质 | 架构与呈现说明（客户可读） |
|