feat: 按 V2.1 更新中心 Skill、流程图与项目记录模板

This commit is contained in:
liyun committed 2026-10-20 18:46:19 +08:00
1 parent 98541d682b
commit 206aabc06c
26 files changed
+592 -83

No files matched your search

+7 -5
View File
@@ -11,8 +11,8 @@ description: 作为项目中心,按八阶段管理交付任务、真人确认
- 按可独立确认的交付结果管理任务;同一负责人承担的内聚工作可组成任务包。每项任务有一名主责真人、明确输入、范围、结果、期限与完成条件,不拆成中心监督的内部步骤。
- 真人可以直接协作,任务接收与结果提交可以在线下完成;必须保留实际接收、提交和确认的依据。成员 Agent 之间的信息仍经中心定向中继。
- 同一阶段内,任务确认完成后可启动依赖已经满足的后续任务;跨阶段推进须取得中心真人明确决定。中心决定不能替代专业判断、业务授权、产品资源排期确认或外部验收。
- 正式成果只保存真人完成并确认的最终有效版本及确认记录;草稿、旧版、历史确认和中心推进决定进入过程记录。链接交付只记录地址,不要求复制、截图或重新下载。
- 同一阶段内,任务确认完成后可启动依赖已经满足的后续任务;跨阶段须有中心真人明确决定,已有条件授权实际满足后按原范围执行并记录依据,不重复申请。中心决定不能替代专业判断、业务授权、产品授权范围内的资源排期确认或外部验收。
- 正式成果保存真人完成并确认的全部有效成果、配套资料或完整外部入口及确认;草稿、旧版、历史确认和中心推进决定进入过程记录。链接交付不强制下载、截图或复制;本地复制按项目明确授权处理。
- 实际完成时间是任务提交后,经对应真人明确确认完成的时间。提交、送达、已读、Agent 检查或工具任务完成都不能替代这一确认。
- 项目层持续显示当前阶段、整体进度、当前待处理事项,以及未完成事项的原计划、当前计划、影响范围和必须完成的阶段;跨阶段沿用原任务记录。
- 不重复要求已有有效确认;成果或版本发生实质变化、适用范围扩大或出现相反证据时,仅重新确认受影响部分。
@@ -23,14 +23,16 @@ description: 作为项目中心,按八阶段管理交付任务、真人确认
| 要做什么 | 读取什么 |
| --- | --- |
| 接收请求、组织交付任务、收取结果或交接阶段 | [中心工作流](references/hub-workflow.md) |
| 向中心真人汇报阶段结果、请求推进或执行条件授权 | [阶段汇报与推进决定](references/stage-reporting.md) |
| 判断阶段、应交成果和推进条件 | [八阶段与结果要求](references/project-lifecycle.md),只读当前阶段及受影响阶段 |
| 建立目录、更新任务、阶段和项目进度 | [记录与留档](references/project-records.md),其中链接五类 Markdown 模板 |
| 评估工时、衔接周期、编排或更新计划主表 | [工时、周期与项目计划](references/project-planning.md) |
| 建立目录、更新任务、阶段和项目进度 | [记录与留档](references/project-records.md),按需使用其中的记录模板 |
| 判断成果、真人确认、版本替换或完成时间 | [成果与确认](references/artifacts-and-confirmation.md) |
| 处理延期、阻塞、变更、退回、豁免或放行 | [异常与决定](references/exceptions-and-decisions.md) |
| 处理延期、阻塞、变更、退回、豁免、放行或 Bug 双方确认 | [异常与决定](references/exceptions-and-decisions.md) |
| 配置中心与成员、使用 Etunel 或排障 | [Etunel 分工](references/etunel-boundary.md),再使用已安装的 etunel-use 对应参考 |
| 选择旧模板、历史样例或外部成果格式 | [模板复用](references/document-templates.md) |
| 编写或发送钉钉项目通知、提醒真人 | [通知规则与消息模板](references/dingtalk-progress-reporting.md);实际调用时再读其脚本用法 |
## 本轮输出
用简洁中文逐条说明已确认进展、需要处理或决定的事项、遗留及影响。先更新事实记录,再依据授权交接、推进或通知。未知的负责人、时间、确认与影响如实标明,不能为补齐格式编造事实,也不把一次问答变成新的交付文件。
用简洁中文逐条说明已确认进展、需要处理或决定的事项、遗留及影响。先更新事实记录,再主动在中心会话汇报阶段结果;只更新文件不算汇报。需要真人查看时逐项提供本次全部有效成果入口。再依据授权交接、推进或通知。未知的负责人、时间、确认与影响如实标明,不能为补齐格式编造事实,也不把一次问答变成新的交付文件。
+4 -1
View File
@@ -25,10 +25,13 @@
## 成果与确认
- **接收情况**:记录真人实际接收时间及依据;只有发送证据时标为接收待确认。
- **提交情况**:每次提交单列提交人、时间、成果版本和保存位置。
- **提交情况**:每次提交单列提交人、时间、成果版本和完整入口、用途;本人说明其他渠道已提交时据实登记,入口缺失、接收待确认与验收待确认分别列出。
- **完成情况**:说明已完成、未完成部分及具体缺口。
- **确认情况**:每项单列确认人、真实确认时间、任务/成果及版本、结论、范围和条件。
- **确认来源**:记录直接确认或线下转述;转述保留实际确认人、转述人、来源及补录时间。
- **采用与存放调整**:适用时分别记录采用对象和日期、本地复制授权、原路径到正式路径映射及操作日期,不覆盖原提交或确认日期。
需要评估时在此嵌入 [工时与周期栏目](工时与周期评估.md);涉及 Bug 时沿原问题/共用记录保留中心先确认、产品再次确认的 [字段与历史](../../references/exceptions-and-decisions.md#bug-处理与双方最终确认)。生成实际项目记录时仅保留适用内容和真实入口,不将模板链接当项目事实。
## 下一步与影响
@@ -0,0 +1,35 @@
# 工时与周期评估栏目
> 使用指引:仅在需要评估时嵌入原任务记录;按真实工作项展开,不另建一套任务。先列已交接的全部有效需求文件和版本入口。各角色内部执行方法自行决定。
## 工作范围
- **主责真人/角色**:填写已确认分工。
- **需求输入**:逐项列全部有效文件、版本和入口。
- **已有成果与剩余工作**:分别说明。
- **未估项**:说明缺什么信息及受影响部分;不能把未知填零。
## 工作项评估
| 工作项/初版或轮次 | 主责真人 | 原估值及单位 | 当前估值及单位 | 周期及起算条件 |
| --- | --- | --- | --- | --- |
| 按真实工作项填写 | 按实际分工填写 | 保留首次评估 | 保留有效评估 | 周期与人时分开 |
### 对应工作项的条件与依据
- **投入与人数**:记录可投入情况及资源是否已确认。
- **外部等待**:单列条件、等待周期及来源。
- **提交**:实际提交人、时间、版本及入口。
- **确认**:确认人、时间、对象、结论、适用范围及来源。
- **当前状态**:区分已估、待补充、待确认及已确认。
- **评估变更**:保留旧值、新值、原因和真人确认,关联原任务关键历史。
初版单列,后续迭代不包含初版。开发/自测/修复、独立测试/回归和外部等待分别记录。工作日不直接换算成人日或小时。
## 技术核实与测试衔接
- **技术核实**:记录技术负责人、真实日期、核实的对象及版本、范围/依赖和结论,引用原任务已有有效确认。
- **交给测试**:记录实际交接日期、版本、范围及渠道。
- **测试接收与衔接**:记录实际接收人、时间和依据,以及初版、各轮、回归的周期与资源衔接结论;未知部分标明待确认。
沿用已有确认和接收记录,仅补实际缺口,不为此重批评估或另建交接文件。
+2 -1
View File
@@ -7,5 +7,6 @@
### 成果名称
- **当前最终版本**:记录实际有效版本。
- **位置或链接**:只填写实际文件或链接地址,不复制外部内容。
- **位置与用途**:逐项登记全部有效原件/包、配套资料或真实完整外部入口与用途;包内容可引用有效索引,不强制复制外部内容。
- **确认记录**:链接对应阶段的正式确认栏目,确认详情由那里统一维护。
- **存放调整**:适用时关联本地复制授权、原位置与正式位置映射、操作日期;不改原提交、采用或确认时间。
@@ -0,0 +1,32 @@
# 结项资料归档
> 使用指引:作为既有《结项资料归档》的内容结构,沿用项目已确认格式,不新增第五类结项成果。以下说明替换为真实资料与依据。
## 归档范围
- **项目与范围**:明确实际采用的版本和本次整理范围。
- **当前成果索引**:关联项目唯一成果索引。
## 各阶段有效资料
### 阶段名称
- **管理开始日期与依据**:中心真人实际启用;条件授权时记录实际切换。
- **管理完成日期与依据**:明确结束/下一阶段决定;条件授权交接取实际切换日期,阶段八为关闭日期,进行中留空。
- **工程实际日期**:按实际需要分别记录开发、测试和验收日期及来源。
#### 成果名称
- **有效版本与用途**:列每项成果、配套资料及包内容;一包多成果可引用有效内容索引。
- **完整入口**:已保存原件/包的实际路径,或真实完整外部地址;不能只列概括目录。
- **提交与采用**:分别记录真人、日期、对象、范围及依据。
- **最终确认**:记录确认人、真实日期、对象版本、结论、范围与条件。
- **原任务及过程记录**:关联原任务、旧版和历史确认。
- **本地复制或地址调整**:适用时记录授权、原路径与现路径映射、操作日期;不得覆盖原提交、采用、确认或完成时间。
## 关闭及承接
- **Bug 处理与承接**:引用原报告/共用记录中的中心和产品双方最终确认,保留未修复事实与后续责任。
- **其他遗留**:逐项列状态、责任、原计划、当前计划、影响及必须完成阶段。
- **业务结项确认与中心关闭决定**:分别列真人、日期、原话、范围、条件和依据。
- **关闭后登记**:记录概览、进度、阶段、原任务、索引、报告与汇总的同步情况,以及有效成果锁定和停止重复催办情况。
@@ -0,0 +1,33 @@
# 阶段成果汇报
> 使用指引:可直接作为中心聊天的汇报结构;也可写入阶段过程记录。不新增正式成果要求。将以下说明替换为真实事实。
## 当前阶段
- **项目与汇报日期**:记录项目名称和本次真实汇报日期。
- **阶段与状态**:记录阶段编号、名称、当前情况及管理开始/完成日期;进行中完成日期留空。
- **本轮需要决定**:说明推进、补充、退回、暂缓或承接的具体事项。
## 逐项任务与成果
### 任务名称
- **主责真人与完成情况**:记录实际负责人、完成部分和未完成部分。
- **应交成果**:逐项列必需/选填及适用条件。
- **已交成果**:每份单列名称、版本、确认用途和完整可点击入口;同一成果包可引用有效内容索引。
- **确认情况**:逐项列确认人、真实时间、对象、结论、范围、条件和来源;缺失确认单列。
- **时间**:分别列原计划、当前计划、提交时间和提交后真人确认的实际完成时间。
- **原任务记录**:引用唯一原记录。
## 未完成与待确认
- **事项**:每项单列状态、原因、依赖、主责、原计划、当前计划、影响及必须完成阶段。
- **需要的决定**:列已有安排、建议和待决定内容,分别标明。
确实没有时写“未完成项:无;待确认项:无”。资料不足时说明待核实部分。
## 下一步安排
- **建议**:按当前事实提出下一步。
- **已有决定或条件授权**:记录真人、原话、日期、范围与条件;条件满足及实际切换日期另记。
- **仍待决定**:列需要谁确认什么,以及确认后的动作。
+20 -2
View File
@@ -3,7 +3,9 @@
> 填写指引:标题改为阶段编号与名称,紧接一句当前情况。下面两个栏目分别保存最终成果和任务过程;每个任务都要逐项汇总。
- **阶段状态**:记录未开始、进行中、待确认、已完成或实际例外状态。
- **阶段时间**:记录已约定计划、实际进入与阶段决定时间。
- **管理开始日期与依据**:中心真人实际启用日期;条件授权时取实际切换日期。
- **管理完成日期与依据**:明确结束或进入下一阶段的决定日期;条件授权交接取实际切换日期,阶段八取明确关闭日期,进行中留空。
- **工程实际日期**:按实际需要另记开发、测试和验收日期,不以管理日期计算工程延期或人时。
- **当前情况**:概括本阶段完成到哪里。
## 正式成果及确认记录
@@ -12,7 +14,8 @@
- **成果名称**:每项最终成果独立列出。
- **最终版本**:记录真人完成并确认的当前有效版本。
- **保存位置**:使用实际文件位置或外部链接。
- **保存位置与用途**:逐项给全部有效文件、配套资料或包内有效索引的完整实际入口及用途;不能只列总目录。
- **提交与采用**:分别记录实际日期、对象和来源;复制或补地址日期另记。
### 对应真人确认
@@ -33,6 +36,7 @@
- **确认情况**:列已确认人、时间、对象、结论和未完成的必要确认。
- **原计划完成时间**:记录首次期限。
- **当前计划完成时间**:记录最新有效期限。
- **实际提交时间**:记录本人提交事实与来源;线下已交但入口缺失时分别说明。
- **实际完成时间**:任务提交后经真人明确确认完成的时间;未确认写“尚未确认完成”。
- **影响及下一步**:列责任、动作、必须完成的阶段及跨阶段承接。
- **任务原记录**:链接该任务的唯一记录。
@@ -40,5 +44,19 @@
### 阶段决定与未完成事项
- **决定**:每次单列决定人、时间、推进/补充/退回/暂缓结论、依据、范围和理由。
- **条件授权**:适用时分别记原授权日期、原话、条件、条件实际满足日期与依据、实际切换日期;不倒填已推进。
- **未完成事项**:逐项引用原任务,列原计划、当前计划、必须完成阶段、影响、承接与阶段结束提醒情况。
- **历史资料**:链接旧版、草稿、历史确认及替代关系。
### 汇报与通知
- **中心会话汇报**:记录本次汇报时间、涉及任务与成果、未完成/待确认事项及待决定内容。
- **群总结**:记录对应交接或关闭决定、已发送正文及实际结果;区分未发送、请求已接受、送达和已读,只写有依据的状态。
- **补充汇报**:仅实质变化时补充受影响内容;核对前次记录避免重复通知同一次交接。
### 关闭后登记(阶段八适用)
- **Bug 双方确认**:引用原问题或共用记录中的最终确认与分歧历史。
- **关闭决定**:记录中心真人、真实日期、原话、范围和条件,业务结项确认另列。
- **同步与锁定**:记录项目概览、进度、原任务、索引、报告和汇总同步情况,以及有效成果锁定情况。
- **停止催办与后续**:停止已结束/已确认事项的重复催办;未完成承接和队列未送达分别记录。
+6
View File
@@ -18,6 +18,12 @@
## 资料与协作入口
- **项目进度**:链接实际进度记录。
- **唯一计划主表**:链接已确认使用的实际主表;已有项目沿用,新项目默认使用 Excel。
- **成果索引**:链接当前有效成果索引。
- **资料来源**:列已提供的项目资料位置。
- **交接方式**:说明已确认的通信渠道、接收与提交方式。
## 项目关闭
- **关闭决定**:实际关闭后记录中心真人、日期、原话、范围、条件及依据;未关闭时不预填。
- **承接入口**:链接仍需跟进的原任务及当前进度,保留未完成状态。
Binary file not shown.
+6
View File
@@ -6,6 +6,7 @@
- **更新时间**:记录本次更新的时间。
- **当前阶段**:记录有效阶段编号、名称及推进依据。
- **唯一计划主表**:引用实际主表,本记录只维护阶段及当前事项摘要。
- **已完成阶段**:逐项列出,跳过或暂缓的单独说明。
- **关键成果**:说明已经完成、待确认和缺失的关键结果。
- **下一步**:说明待推进的工作及必要条件。
@@ -28,3 +29,8 @@
## 已完成或已处置
- **事项**:每项单列完成或处置结论、真人及时间、原记录入口;仍有后续跟进的继续保留在当前事项中。
## 关闭决定与后续
- **决定依据**:实际关闭后引用中心真人、真实日期、原话、范围及条件。
- **承接事项**:沿原责任与计划在当前事项中持续跟进,不把关闭写成全部 Bug 已修复或测试通过。
@@ -14,6 +14,16 @@
中心真人可在会话中明确转述线下接收、提交或确认事实。保留实际确认人、真实确认时间、对象、结论和范围,并注明转述人、来源及补录时间;缺失信息写待补充。不要求另做审批单、截图或重复确认,不能把转述者写成专业确认人。
本人明确已通过其他渠道提交时,登记已提交。资料入口未提供、接收人尚未确认可用、验收尚未取得结论是不同缺口,逐项记录;无聊天附件、Agent 本端无法读取或队列仍待投递不推翻线下提交事实。
## 供真人查看的成果
请求中心真人确认前,逐项列出本次范围内全部有效文件的名称、版本、确认用途和完整可点击地址,或直接展示文件。成果包可使用能逐项定位内容的有效索引;只给概括目录、摘要或中心确认记录不足以支持查看。
专业内容和接收可用性由相应真人判断。Agent 无法读取本地盘、共享盘或外部链接,只能说明本端访问失败,不能推定成果不存在、未提交或不兼容。不把下载、解包、截图、重算哈希设成固定前置条件。已有包身份和真实入口时交相关真人确认可用,仅补实际缺口,不要求重做或反复上传。
文件、需求或版本存在差异时,由有权真人决定采用的内容、对象、版本和范围。分别记录当前同步情况、历史实际审阅对象及差异对原结论的影响;不能补造历史审阅或把当前采用倒填为过去已审阅。
## 实际完成时间
**任务提交后,经对应真人明确确认该任务完成的时间,才是实际完成时间。**
@@ -27,11 +37,13 @@
## 正式成果与历史
- 正式区只保存真人完成并确认的最终成果,每项一个当前有效版本。登记名称、版本、文件位置或链接;确认另列确认人、时间、对象及版本、结论、范围和条件。
- 正式区保存真人完成并确认的全部有效成果和配套资料,每项一个当前有效版本。保存原件/包,或登记真实完整外部入口;确认另列确认人、时间、对象及版本、结论、范围和条件。概括目录或确认记录不能代替资料本身。
- 待确认稿、部分成果、候选固件、旧版及其历史确认进入过程区。任务记录关联所有提交,阶段正式栏目只列最终成果。
- 新版获真人确认后才替换当前条目;先保留旧文件、旧确认及替代关系到过程区,再更新正式记录,不能覆盖丢失历史。外部链接成果保留旧地址、版本、确认及替代关系;不额外下载快照,外部系统是否保留历史如实记录。
- 中心推进、豁免、版本放行、产品接收等事实放过程记录,引用相关正式成果。名为《变更记录》《流程闭环总结》的交付文档,在真人确认最终版后仍属于正式成果。
- 链接交付只记地址与确认;内容核实由真人负责,不把复制内容、摘要、截图或可下载检查变成中心必做事项。
- 同一文件或连贯成果包可承载多个结果,不为凑名称拆造文件。名称含“草稿/预览”不自动否定真人已确认采用的正式地位;按实际确认判断,不为分区删改成果正文。
- 链接交付登记真实地址、用途、版本与确认;内容核实由真人负责,不强制复制、摘要、截图或可下载检查。项目明确授权本地复制时,把已取得且确认有效的原件和配套资料复制到对应阶段正式区,保留原交接记录及原路径到现路径的映射,更新索引到正式位置。
- 复制或补地址日期单独记录,不替换提交、采用、确认、实际完成或阶段日期;未取得的原件仍如实列缺口,不能写已归档。
- 实质变更、范围扩大或相反证据需要重新确认受影响部分;仅改存放位置、阶段引用或转述补录不自动触发重签。
测试“不通过”可被真人确认是实际测试结论,不能因版本获放行改成“通过”。测试结果确认、版本放行、阶段推进与外部验收分别保留。
@@ -18,6 +18,14 @@
Hub 必须先核对真实事实,更新对应任务、阶段和项目进度记录;涉及正式成果变化时再更新成果与索引,然后发送钉钉消息。不为一次通知新增成果文件。钉钉发送失败不回滚留档,也不阻塞项目主任务。
## 阶段交接与结项总结
- 每次中心真人批准推进,或已有条件授权实际满足并已执行交接后,在已启用且获授权的通知范围内,将上一阶段总结与下一阶段安排合为一条 `milestone`。标题使用实际当前阶段。
- 等待推进决定时,先在中心会话按 [阶段汇报规则](stage-reporting.md) 说明成果、未完成项及待决定事项,不发宣称已进入下一阶段的总结;已授权的实质进展或阻塞通知仍可按实际事件发送。
- 正文仍用“已确认的进展/待办事项/遗留”:进展写上一阶段成果和真实推进决定;待办写下一阶段全部已确认任务、主责和期限,未知字段如实说明;遗留写未完成及待确认、影响和承接。完整成果汇报放中心会话,群里可引用适合接收者访问的有效记录入口,不能为缩短篇幅遗漏待办或停止事项。
- 第八阶段取得明确关闭决定后发送一次 `complete` 结项总结,列有效成果、关闭决定及承接事项的主责和计划。后续资料整理、补地址不重复发关闭通知。
- 将总结正文、对应决定和实际发送结果记入阶段过程记录;生成前核对是否已通知同一次交接或关闭。复用原记录,不增加通知队列或脚本外重试。API 接受、投递和已读分别记录,未知结果不盲目重发。
## 事件判定
### start
@@ -34,7 +42,7 @@ Hub 必须先核对真实事实,更新对应任务、阶段和项目进度记
- 正式阻塞解除,项目恢复到明确下一动作;
- 统一固件、版本矩阵、测试结论、验收或发布组合形成。
同一处理轮或同一波次合并成一条,不逐个小任务刷屏。没有固定时间间隔;依靠事件语义和去重控制频率。
保留已授权范围内的阶段关键进展通知;同一处理轮或同一波次合并成一条,不逐个小任务刷屏。同轮发生阶段交接时合入交接总结,核对阶段过程记录避免重复。没有固定时间间隔。
### blocked
@@ -48,7 +56,7 @@ Hub 必须先核对真实事实,更新对应任务、阶段和项目进度记
### complete
整个项目或用户明确指定的整体目标最终完成时发送一次。模拟项目必须明确写“模拟完成”,不得表达真实发布、客户验收或生产就绪。
项目生命周期中,阶段八满足必要条件、业务已确认结项且中心真人明确关闭后发送一次。开始结项整理不使用 `complete`。用户明确指定的独立整体目标最终完成时,限定在该目标范围表述,不能冒充项目关闭。模拟项目必须明确写“模拟完成”,不得表达真实发布、客户验收或生产就绪。
### failed
@@ -85,7 +93,9 @@ Hub 必须先核对真实事实,更新对应任务、阶段和项目进度记
- 结项资料整理:由中心真人负责人组织四类结项成果,Hub 协助整理工作稿。
- 资料补充:由产品负责人、业务负责人补充现有线下成果及确认记录,不重做验收。
- 旧事项停止:由 Hub 停止此前的验收准备催办。
- 结项确认:四类成果及遗留承接安排具备后,由 Hub 请 @示例业务负责人 确认结项。
- Bug 事实确认:由 Hub 请 @示例中心负责人 先确认全部 Bug 的对象、版本和实际处理或承接,已有有效确认直接引用。
- Bug 处理确认:中心确认事实后,由 Hub 请 @示例产品负责人 再次确认,并在职责内决定处理方式;双方无异议后记录最终安排。
- 结项确认:四类成果、遗留承接及 Bug 双方确认具备后,由 Hub 请 @示例业务负责人 确认结项。
- 关闭决定:业务确认结项后,由 Hub 请 @示例中心负责人 决定是否关闭;结项必需项完成后锁定四类成果。
- 本轮工作范围:不新增应用修复、设备测试或发布验证。
@@ -97,6 +107,32 @@ Hub 必须先核对真实事实,更新对应任务、阶段和项目进度记
示例标题、时间和栏目只说明最终呈现方式;调用时正文文件仅含正文,项目名、阶段标题与时间由脚本生成,不重复粘贴整条通知。
### 已关闭项目的结项总结示例
以下仅说明格式。事实、决定人、日期、有效成果入口、后续主责和期限都须替换为项目真实记录,不把此例当成关闭依据。
```markdown
**示例项目|阶段八:复盘结项**
项目进度自动汇报 · 发送时自动生成带时区的时间
**已确认的进展**
- 四类结项成果已取得必要确认,有效文件和入口已登记在项目成果索引。
- 全部 Bug 的处理或承接已由中心先确认、产品再次确认,双方无异议。
- 业务已确认结项,中心真人已明确关闭项目;决定的日期、范围和条件已记录。
- 已同步相关记录、锁定有效成果,停止已结束阶段的重复催办。
**待办事项**
- 遗留跟进:请 @示例处理人 按原问题记录中的当前计划继续处理已承接事项,原计划和变更历史保留。
**遗留**
- 已接受延期的 Bug 尚未修复,责任、原计划、当前计划和影响沿用原记录;项目关闭不代表问题已修复。
- 原测试不通过结论保留,版本放行、验收和关闭决定分别记录。
```
保留个人消息的 AI 标识和自动汇报说明,让群成员知道这是 Hub 自动通知,不是负责人本人新增批准、验收或承诺。
根据事件选择必要内容:已验证进展、关键成果、下一步和责任角色;阻塞时再说明问题、影响以及需要谁采取什么动作。尽量简短,但不能为了控制篇幅省掉本轮需要决定或处理的事项。专业细节留在成果或问题系统中,通知不新建另一份问题台账。
+17 -2
View File
@@ -39,14 +39,16 @@ python scripts/dingtalk_notify.py progress milestone --stage "阶段八:复盘
- 结项资料整理:由中心真人负责人组织四类结项成果,Hub 协助整理工作稿。
- 资料补充:由产品负责人、业务负责人补充现有线下成果及确认记录,不重做验收。
- 旧事项停止:由 Hub 停止此前的验收准备催办。
- 结项确认:四类成果及遗留承接安排具备后,由 Hub 请 @{示例业务负责人} 确认结项。
- Bug 事实确认:由 Hub 请 @{示例中心负责人} 先确认全部 Bug 的事实、对象、版本和实际处理或承接,已有有效确认直接引用。
- Bug 处理确认:中心确认事实后,由 Hub 请 @{示例产品负责人} 再次确认并在职责内决定处理;双方无异议后登记最终安排。
- 结项确认:四类成果、遗留承接及 Bug 双方确认具备后,由 Hub 请 @{示例业务负责人} 确认结项。
- 关闭决定:业务确认结项后,由 Hub 请 @{示例中心负责人} 决定是否关闭;结项必需项完成后锁定四类成果。
- 本轮工作范围:不新增应用修复、设备测试或发布验证。
**遗留**
- 原测试不通过的结果如实保留,不因进入结项阶段改为通过。
- 已接受延期的问题如实保留,后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例业务负责人" --at "示例中心负责人"
- 已接受延期的问题如实保留,后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例业务负责人" --at "示例中心负责人" --at "示例产品负责人"
python scripts/dingtalk_notify.py progress blocked --stage "阶段三:方案设计" "**已确认的进展**
- 本轮无新增已确认进展。
@@ -75,6 +77,19 @@ python scripts/dingtalk_notify.py message --title "阶段三:方案设计|
- 脚本只接受唯一姓名匹配,自动构造个人消息所需的 `openDingTalkId` 和提及标记。查不到、重名或权限不足时停止,不让负责人手填编号,不删掉 @ 降级发送。
- 默认且仅发配置的项目群。同一事项合成一条,事件通知可直接 @ 人,不额外重复提醒。提醒讨论结果通过已约定渠道返回并留档,不在群里另派任务或批准。
## 阶段交接和关闭通知
中心真人已批准推进或条件授权实际满足后,将上一阶段总结与下一阶段已确认安排合为一条 `milestone`。阶段内已授权的关键进展、阻塞、失败通知保留,同轮合并。等待决定时先在中心会话汇报,不宣称已进入下一阶段。
项目实际关闭后,用 `complete` 发送一次结项总结,保留未修复 Bug、失败测试和已确认承接;后续整理资料不重复发送。完整示例见 [通知规则](dingtalk-progress-reporting.md)。较长正文可保存为 UTF-8 文件,先离线预览:
```text
python scripts/dingtalk_notify.py progress milestone --stage "实际当前阶段" --file "阶段交接正文.md" --at "已确认完整姓名" --dry-run
python scripts/dingtalk_notify.py progress complete --stage "阶段八:复盘结项" --file "结项总结正文.md" --at "已确认完整姓名" --dry-run
```
正文文件和姓名须替换为实际值,正文无真人提醒时省略 `--at`。通知范围已授权且本次满足触发条件后,真实调用去掉 `--dry-run`;用户要求先审核时先取得本次发送确认。脚本仅渲染和发送,推进授权、Bug 确认和是否已发由中心查原记录判断。正文及真实结果回写阶段过程记录,不新增队列或外层重试。
## 检查与结果
排障可用 `python scripts/dingtalk_notify.py check --at "完整姓名"`,省略 `--at` 只查登录;它联网但不发送,不是每轮必做。两个发送入口加 `--dry-run` 可完全离线预览,条目中的标记显示为“@姓名”;不查人、不验证目标或 @ 效果。
+2
View File
@@ -2,6 +2,8 @@
仅在选择已有专业模板或历史样例时读取。中心维护的项目、阶段和任务模板见 [记录与留档](project-records.md)。
项目计划的默认 Excel 模板及维护规则见 [项目计划](project-planning.md)。已有主表沿用已确认格式。结项报告和汇总按项目已确认格式制作,单工作表 Excel 仅作参考;不因模板字段齐全就补造工时、轮次、评审、签名或确认。
- 从当前任务、有效流程基线、成果、平台/机型、SDK 和版本选择适用资料;不因目录有多份就全部要求提交。
- 区分空白模板、历史样例、平台规范、器件输入与当前项目成果。只复用适用栏目和组织方式,旧人员、日期、参数、执行结果及签名不作为当前事实。
- 角色真人决定专业内容及内部制作方法。中心不将模板每一栏变成额外任务,不要求新增内部评审步骤;结果要求按 [八阶段与结果要求](project-lifecycle.md)。
@@ -25,3 +25,21 @@
- **测试不通过拟放行**:必须有项目、产品双方真人明确核实,记录版本、不通过项与实际影响、剩余问题及责任、依据、放行范围与条件、双方确认人和时间;原测试结果保留不通过。实质变化重新核实。
未知影响不写“无影响”,未知责任或日期不编造;汇总为需要真人决定的具体问题。已有明确停止事项、暂不修复或无需新增清单等条件必须沿用,不借汇报重新分配。
## Bug 处理与双方最终确认
结项前对全部 Bug 的处理或承接核对双方确认,包含此前已处理及后续发现的问题。沿用原测试报告、Bug 系统或阶段七共用遗留记录,不要求测试再交独立清单。日常进展据实更新;以下是处理或承接结论的确认顺序,不把每次状态更新变成重复审批。
1. 中心真人先确认问题事实、对象及版本、实际处理结果或承接安排。事实未确认前,不要求产品代为调查中心尚未核实的事实。
2. 产品真人在上述事实基础上再次确认,并在自身权限内决定处理方式。产品调整处理方案时,中心协调受影响的安排,再补受影响部分的确认。
3. 双方无异议后,在原记录登记最终结论、范围、条件与后续安排。已有适用于当前对象、版本和范围的有效确认直接引用,仅补缺失或变化部分。
每项保留:
- **问题**:已有 Bug 编号或名称、原记录入口、对象及版本。
- **实际状态**:已修复、延期、暂不修复或其他真实状态;处理方式已确认不等于问题已修复。
- **中心确认**:实际确认人、时间、事实与结论、范围、条件和来源。
- **产品确认**:实际确认人、时间、再次确认及处理决定、权限范围、条件和来源。
- **承接与分歧历史**:主责、下一步、原计划与当前计划、影响、必须完成阶段;保留每次调整、分歧及最终决定。
双方无异议可以对应修复、延期或暂不修复,不代表全部已修复或测试通过;不因此重测已有有效验收结果。后续发现的问题依同一确认顺序处理,按原责任或新的明确授权跟进,不自动撤销既有关闭决定。
+14 -7
View File
@@ -6,7 +6,7 @@
读取当前项目概览、进度和正在处理的任务,确认有效流程基线、当前阶段、中心真人负责人、相关角色真人及已有决定。沿用已有项目记录,不因安装新 Skill 自动迁移项目或重开中心会话。实际人员与接收对象取自已确认记录及当前运行时信息,不从示例推断。
开始阶段时向负责人说明三类内容:本阶段必须完成、后续阶段处理、当前不需要。以后阶段的资料不提前成为当前完成条件。阶段 4、8 由中心真人组织,Agent 可协助整理;其他阶段按主责真人组织工作。
开始阶段时向负责人说明三类内容:本阶段必须完成、后续阶段处理、当前不需要;先汇报安排,再按真人决定执行。以后阶段的资料不提前成为当前完成条件。阶段 4、8 由中心真人组织,Agent 可协助整理;其他阶段按主责真人组织工作。排期和资源协调按 [项目计划](project-planning.md) 办理。
## 交付任务
@@ -34,14 +34,21 @@
1. 登记实际提交时间、成果版本和位置、提交人的完成说明以及已有真人确认。
2. 核对结果是否对应任务要求、必需项是否齐备、版本及确认范围是否一致、依赖和授权是否满足。链接内容由真人核实,中心不代作专业审查。
3. 缺口只退回受影响部分,保留有效成果。已提交但未确认完成时保持“待确认”,不登记实际完成时间。
3. 缺口只退回受影响部分,保留有效成果。已提交但未确认完成时保持“已提交,待确认”,不登记实际完成时间。本人说明已通过其他渠道提交时据实登记,入口缺失、接收可用待确认、验收未确认分别记录,不因聊天无附件或队列待投递改成未提交。
4. 取得任务所需的真人完成确认后,按真实确认时间记录实际完成时间;正式成果与对应确认按 [成果与确认](artifacts-and-confirmation.md) 留存。
5. 更新阶段逐任务汇总、项目进度和当前成果索引,再交接下游所需材料。
5. 更新阶段逐任务汇总、项目进度和当前成果索引;有计划主表时据真实回报同步实际执行情况,再交接下游所需材料。需要阶段决定或出现实质变化时主动在中心会话汇报。
## 阶段交接与关闭
- 向中心真人逐条展示本阶段每项任务的成果、完成与确认情况,以及未完成项、影响、责任、原计划和当前计划时间、必须完成的阶段。
- 中心真人决定推进、补充、退回或暂缓,Agent 记录决定及范围;缺项未解决时如实说明例外和承接,不写成正常通过。
- 按 [阶段汇报与推进决定](stage-reporting.md) 主动向中心真人逐条汇报本阶段每项任务的成果、完成与确认情况,以及未完成项、影响、责任、原计划和当前计划时间、必须完成的阶段。请求查看确认前提供全部有效文件的完整入口;本地更新不替代聊天汇报。
- 中心真人决定推进、补充、退回或暂缓,Agent 记录决定及范围;已有条件授权实际满足后依授权执行并留依据,不重复申请。缺项未解决时如实说明例外和承接,不写成正常通过。
- 阶段结束逐条提醒仍待交的延期成果,持续至交付或有明确处置;只影响部分任务时不停止无关工作。
- 下一阶段引用已有成果和确认,不重复转存大文件、不因换阶段重派同一未完成任务。
- 进入复盘结项只表示开始结项整理。业务确认结项、中心真人决定关闭后才记录关闭;未交付的承接项仍保持待交和后续跟进状态。
- 下一阶段引用已有成果和确认,不因换阶段强制重复转存大文件或重派同一未完成任务。已批准的交接,在通知授权范围内合并发送上一阶段总结与下一阶段安排,正文和发送结果进入阶段过程记录。
- 进入复盘结项只表示开始结项整理。满足阶段八的必要条件,包括全部 Bug 处理或承接取得双方确认、业务确认结项后,由中心真人决定关闭;未交付的承接项仍保持待交和后续跟进状态。
## 关闭后的同步
- 记录关闭决定人、真实日期、原话、范围与条件;同步项目概览、进度、阶段、原任务、成果索引、结项报告和流程闭环总结,引用同一决定依据。
- 锁定当前有效成果,保留旧版和历史;停止已结束阶段、已确认成果的重复催办。仍需跟进的承接项按原责任和计划记录。
- 队列未送达、工具未结算单独记录,不能推翻真人关闭决定或重派同一业务任务。关闭不证明测试通过、Bug 已修复、已量产或已出货。
- 在已授权范围内发送一次结项总结,后续补地址或整理文件不重复发送。项目反馈留在实际项目,拟整合到共享 Skill 的内容和入口须经有权真人统一确认范围后再修改;关闭本身不代表共享规则变更授权。
+15 -8
View File
@@ -4,7 +4,7 @@
## 通用推进规则
- 正常顺序按以下八阶段;每次跨阶段推进由中心真人决定,不因 Agent 判断满足条件自动进入下一阶段。
- 正常顺序按以下八阶段;每次跨阶段须有中心真人决定。已有条件授权实际满足时,按原范围执行并记录授权、条件依据和实际切换日期,不重复申请;无授权时不因 Agent 判断满足条件自动推进。详见 [阶段汇报与推进决定](stage-reporting.md)。
- 必需成果不能如期交付时,按 [异常与决定](exceptions-and-decisions.md) 记录真人确认、影响和补齐/承接安排。延期不等于交付,跳转不等于通过。
- 选填成果未提交不阻塞、无需豁免;已提供时登记有效版本及专业结论。可靠性、专项、提测佐证是否提交由中心真人决定,沿用已有有效决定。
- 下面的成果名称可由连贯成果包承载,已经有效的同内容成果无需重做。既有记录能够承载专业结论时,不为配齐文件名新增文档。
@@ -32,10 +32,10 @@
## 阶段四:项目规划
- **组织者**:中心真人;技术负责人、产品及执行真人提供评估,Agent 协助汇总。
- **组织者**:中心真人负责总排期与跨角色资源协调;技术负责人、产品及执行真人按职责提供评估,Agent 协助汇总。
- **成果**:《项目计划》、《角色分工》、《项目状态内部记录》。
- **结果内容**:计划含任务拆分、工时评估、实际排期;技术负责人给出技术结构、顺序与依赖结论。分工明确每项任务主责、协作、人员变化与交接,引用立项资料中的风险,不另建风险成果或《产品资料整合》。
- **推进依据**:技术结构及问题任务已有结论,产品确认授权范围内资源和排期,预算、采购、对外承诺等必要业务授权完成,首批任务输入与依赖就绪;中心真人决定推进。不要求全员重签整份计划,同步业务的回执不增加批准条件。
- **结果内容**:先交接全部有效产品需求,再由应用层、底层和硬件分别评估范围、已有成果、剩余工作、工时、周期、投入及等待。初版与后续迭代分开,技术负责人核实范围、先后、并行、合版和依赖后交测试衔接周期;测试可先估自身工作量。评估沿原任务留表,具体字段、八列唯一计划主表和执行更新见 [工时、周期与项目计划](project-planning.md)。分工明确每项任务主责、协作、人员变化与交接,引用立项资料中的风险,不另建风险成果或《产品资料整合》。
- **推进依据**:技术结构及问题任务已有结论,中心真人统筹的整体排期和跨角色资源安排已明确,产品确认具体授权范围内的资源和排期,预算、采购、对外承诺等必要业务授权完成,首批任务输入与依赖就绪;中心真人决定推进。产品不默认承担全部专业和工厂周期,不要求全员重签整份计划,同步业务的回执不增加批准条件。
## 阶段五:嵌入式软硬件实现
@@ -48,7 +48,9 @@
| 嵌入式应用层 | 嵌入式应用层固件包 | 正式/升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug 文件、Changelog、串口使能证书 |
- 硬件设计需要实际外设、关键器件规格书和结构板框图;缺失只影响对应任务,不将前置输入重新列为产出,不另设《硬件实现资料》。
- 软硬件、环境或样机缺失只阻塞依赖它的工作,其他输入就绪的任务继续。到样、系统、PQ、AI 和环境状态取自真人实际回报,不按计划日期推定,也不把收到输入写成后续工作已完成。
- 底层提供可消费 BSP/PSP,应用层负责合版并交唯一最终提测固件;底层不直接交最终固件给测试,定频固件仅供专项测试。
- PSP 仓库/commit、BSP 构建及输入入口不等于最终固件身份,不将其他构建结果移用于最终包。现有配置中已有有效 BSP 消费入口,且真人确认无需另行获取时,直接沿用。已知包身份和入口交相关真人确认可用,Agent 无法访问不构成重做或反复上传的理由。
- 设计、自测、联调由真人自行组织,中心核对提交结果。**推进依据**:适用成果齐备,最终统一固件和硬件版本匹配,技术负责人明确可提测,中心真人决定推进。
## 阶段六:测试验证
@@ -56,8 +58,8 @@
- **主责**:测试,实际需要修复时由对应实现角色主责修复任务。
- **成果**:《功能测试报告》必需,含通过/不通过结论、覆盖范围、用例执行结果及 bug log。缺陷信息可提供链接,**不要求缺陷清单文件,零缺陷也不另交零缺陷清单**。
- **选填**:《可靠性测试报告》(高低温,跌落/防水选填)、《专项测试报告》、《提测佐证》(视频、截图、log)。中心真人决定是否提交,未提供不阻塞,仍须执行已约定必测范围;外部平台要求与内部提交决定分开记录。
- **输入与修复**:使用统一固件、版本矩阵、测试计划及必要变更说明。底层实现资料、硬件设计包不作为常规必交输入。测试自行制定每次执行、复测和回归策略,不增加独立策略文件或审批。真人商议缺陷责任,每项缺陷一个主责角色和责任人;需修复时中心安排交付任务。底层修复由应用层重新合版,硬件 ECO 随结果交兼容、应用有效性及版本矩阵更新结论,测试独立复验。
- **提交确认**:测试真人提交后,中心真人须实际查看并明确确认或退回测试结果;确认前不宣布正式测试提交完成或进入正式验收。实质变化后的结果/被测版本重新确认。
- **输入与修复**:每轮明确统一固件和硬件版本、版本矩阵、测试计划、变更、必测范围、期限及提交要求。底层实现资料、硬件设计包不作为常规必交输入。测试自行制定每次执行、复测和回归策略,不增加独立策略文件或审批。真人商议缺陷责任,每项缺陷一个主责角色和责任人;需修复时中心安排交付任务。底层修复由应用层重新合版,硬件 ECO 随结果交兼容、应用有效性及版本矩阵更新结论,测试独立复验。
- **提交确认**:测试真人提交后,中心真人须实际查看并明确确认或退回测试结果;确认前记录“已提交,待确认”,不写未提交,也不宣称已确认完成或进入正式验收。实质变化后的结果/被测版本重新确认。
- **推进依据**:测试通过并获中心真人确认推进;或测试不通过,但项目与产品双方真人核实后明确同意该版本放行,再由中心记录放行及推进决定。保留原“不通过”,分别记录放行版本、范围、条件、未通过项、责任安排及双方确认。放行不代表外部验收通过。
## 阶段七:内部/外部验收
@@ -65,14 +67,19 @@
- **组织者**:项目;内部任务交相应真人,外部平台由产品确认、客户由业务确认。
- **成果**:内部验收结果记入已有验收记录;产品汇总《平台验收报告或结论》《客户验收通过报告》及共用《遗留问题清单》,按项目已约定的适用验收范围办理。
- **交接**:测试真人直接向产品真人交付已确认最终测试报告及已提供的提测佐证;中心沿用正式成果与确认,产品接收情况放过程记录。链接交付只记地址,不要求中心收转大文件。
- **执行分工**:联系平台、发包寄样、收件和跟进按具体项目明确唯一主责,不默认全部由产品或中心本人执行。实际协调、接收可用、平台结果和业务客户确认分别记录。
- **结果内容**:遗留清单标明内部/外部来源、实际验收方、版本、责任人、处置和状态。平台无需业务再次批准;客户报告由产品出具或更新,客户结果由业务确认。各项输入就绪可并行,客户反馈由有联络权限的真人取得。
- **推进依据**:约定的内部验收完成,适用外部验收取得对应真人确认;同时要求平台和客户验收时两项均须通过。版本一致、风险有承接,中心真人同意进入结项。内部验收或版本放行不能代替外部结果。
- **返工**:回到受影响环节。新测试结果重新执行阶段六的真人确认;仍不通过拟放行时重新取得项目、产品双方结论。版本变化影响其他验收项时更新对应结果。
- 共用遗留记录延续到阶段八的 Bug 双方确认,不给测试追加重复缺陷清单。
## 阶段八:复盘结项
- **组织者**:中心真人,各角色提供已有成果及复盘输入,Agent 协助整理,业务保留结项确认职责。
- **成果**:《结项资料归档》、《变更记录》、《结项报告》、《流程闭环总结》。
- **结果内容**:归档沿用已验收最终版及确认;过程资料包括草稿、旧版、历史确认、变更过程、进度和接收记录,单独保留。复盘说明目标完成、计划偏差、协作与质量问题、经验和改进;改进项写入流程闭环总结,明确责任与跟进,不另设正式成果。
- **关闭依据**:约定内部与外部验收已确认,归档可追踪、复盘完成、遗留已处理或落实承接,业务确认结项,中心真人决定关闭。结项必需项完成后锁定四类成果。仍有延期成果时,由中心真人明确补齐或承接安排后决定是否关闭,待交仍写待交,不伪报已归档。
- **结果内容**:归档沿用已验收最终版及确认,逐项包含全部有效资料、配套资料或完整外部入口,不能只给目录或确认记录。阶段管理起止及依据写入既有《结项资料归档》,提交、采用、确认和工程实际日期分别记录,参见 [归档栏目](../assets/templates/结项资料归档.md)。过程资料包括草稿、旧版、历史确认、变更过程、进度和接收记录,单独保留。复盘说明目标完成、计划偏差、协作与质量问题、经验和改进;改进项写入流程闭环总结,明确责任与跟进,不另设正式成果。
- **成果格式**:结项报告及汇总沿用项目已确认格式;单工作表 Excel 只是可参考形式,不强制各项目采用同一表或字段。缺少工时、迭代、评审或签名时保留未知,不从文件数量推算或补造。
- **Bug 处理**:覆盖全部 Bug,包括已处理及后续发现项。中心真人先确认事实和实际处理/承接,产品真人再次确认并在职责内决定处理,双方无异议后登记最终确认;复用有效确认。具体顺序和字段见 [Bug 双方确认](exceptions-and-decisions.md#bug-处理与双方最终确认)。
- **关闭依据**:约定内部与外部验收已确认,归档可追踪、复盘完成、遗留已处理或落实承接,Bug 处理或承接已取得中心及产品双方确认,业务确认结项,中心真人决定关闭。结项必需项完成后锁定四类成果。仍有延期成果时,由中心真人明确补齐或承接安排后决定是否关闭,待交仍写待交,不伪报已归档。
- 本阶段不安排冒烟、发布验证或重做固件;新实现/质量问题回相应环节。开始整理不等于关闭,结项不等于后续改进全部完成;模拟只能记录模拟完成。
- **关闭后**:按 [中心工作流](hub-workflow.md#关闭后的同步) 同步全部相关记录、锁定有效成果、停止重复催办并按授权发送一次结项总结。队列待送和工具未结算另记,不撤销真人关闭或重派业务任务;失败测试、未修复 Bug 和后续责任如实保留,不据此声称量产出货。
+36
View File
@@ -0,0 +1,36 @@
# 工时、周期与项目计划
阶段四组织评估、编排计划或后续更新执行情况时读取。中心真人统筹总排期和跨角色资源;角色真人决定本领域的执行方法。已有项目沿用已确认的唯一计划主表,新项目默认使用 [Excel 八列计划模板](../assets/templates/项目计划.xlsx)。Markdown 项目进度只维护摘要和主表入口。
## 收集评估与衔接周期
1. 评估前,向嵌入式应用层、嵌入式底层、硬件三方交接全部有效产品需求文件,列明版本和完整入口。各方分别说明本人范围、已有成果、剩余工作、尚不能估算的部分、可投入人员及外部等待。
2. 初版单列,后续迭代轮数不包含初版;每轮内容和周期可以不同。研发开发、自测、修复与独立测试、回归分别记录,外部等待另列。
3. 三方提交周期后,由技术负责人核实范围、遗漏与重复、先后和并行、合版以及软硬件依赖,再交测试衔接初版、各轮和回归周期及资源。测试可以先估自身工作量,不必等其他领域全部完成才开始评估。
4. 产品只确认明确授权范围内的具体资源和排期对象,记录权限及范围;不默认产品对全部专业工作或工厂周期负责。预算、采购、对外承诺等仍按业务权限办理,不要求全员重批整份计划。
评估沿原任务按工作项用表格记录,可嵌入 [工时与周期评估栏目](../assets/templates/工时与周期评估.md)。保留主责真人、原估/当前估及单位、周期及起算条件、投入和等待、提交与确认日期、来源和状态。变更保留前后值、原因及真人确认;未知写待确认,不能把工作日直接换成人日或小时。
## 唯一计划主表
固定八列:**里程碑、工作项、预排开始日期、预排结束日期、预排工时/人时、负责角色、参与人数、实际执行情况**。
- 空白模板不预填日期、工时、人数、任务或迭代轮数。根据项目真实评估展开工作项;不同项目不套用同一套参考任务或周期。
- 工时是任务合计人时,不再乘参与人数。人数不表示资源已落实;空白和 NA 不改成零。工作周期、工时、投入和外部等待分别记录。
- 客户目标、内部预计、当前有效计划和实际执行分开;客户验收目标与量产目标分别保留。计划主表显示当前已确认计划,原计划及历次改期保留在原任务记录中并可追溯。
- 预排日期不证明实际开始或完成;表格日期重叠不证明可并行、依赖已满足或已获跨阶段授权。
- 主表按项目已有位置维护;新项目在阶段四任务过程中编制,确认有效后按正式成果规则登记。后续持续使用同一主表,不另建 Markdown 全量副本。
## 更新实际执行情况
中心根据真实回报更新同一工作项的“实际执行情况”,按需要分行记录:
- 更新时间及事实来源。
- 已完成部分、未完成部分与当前进展。
- 真实开始和完成时间;任务实际完成仍取提交后真人明确确认完成的时间,工程实际发生时间另记。
- 成果名称、版本和实际入口,已有确认人、时间及范围。
- 偏差、影响、下一步,以及原任务记录入口。
没有回报时写“待补充执行情况”,不能推定未开始或未完成。日常事实更新直接据实登记并保留来源、历史,不重批整表。修改已确认日期、工作范围或资源安排时,由对应有权真人确认后更新当前计划,原值和决定保留在原任务/变更记录中。
已确认计划基线及历史版本仍按 [成果与确认](artifacts-and-confirmation.md) 保留。“实际执行情况”的后续更新应标明日期与来源,不把旧批准解释成对新发生事实的预先确认。
+12 -6
View File
@@ -39,9 +39,11 @@
使用 [项目概览模板](../assets/templates/项目概览.md)。
项目只有一份持续维护的计划主表。已有项目沿用已确认载体,新项目默认采用 [Excel 八列计划模板](../assets/templates/项目计划.xlsx),实际主表在概览和进度中登记入口;评估、改期和实际执行的维护按 [项目计划规则](project-planning.md)。
### 项目进度
作为项目当前情况的统一入口,每次相关事实变化后同步维护:
作为项目当前情况的统一入口,每次相关事实变化后同步维护;计划主表保留完整工作项和实际执行,Markdown 只显示摘要和入口:
- **当前阶段与整体进度**:已完成、当前、后续阶段,关键成果与下一步。阶段完成依据真人决定;有跳转时如实标记,不将经过阶段等同于完成。
- **当前待处理事项**:逐项写事项、所属阶段、负责人、当前情况、下一步与需要谁决定。
@@ -59,14 +61,14 @@
### 阶段记录
顶部列阶段状态、时间和一句话进展。正文固定分为两类:
顶部列阶段状态、管理开始/完成日期、决定依据和一句话进展。开始取中心真人实际启用日期,完成取明确结束/进入下一阶段决定日期,第八阶段取关闭日期;进行中完成日期留空。已有条件授权时分别记录原授权、条件实际满足及实际切换日期,管理交接日期取实际切换日期。工程实际日期另记,不用管理日期计算工程延期或人时。正文固定分为两类:
1. **正式成果及确认记录**:每项最终成果单列名称、版本、位置或链接;对应真人确认逐项列确认人、时间、对象和版本、结论、范围与条件。历史确认留在过程区。
2. **过程记录**:逐项汇总本阶段每个任务的负责人、应交/已交成果、完成情况、确认情况、原计划/当前计划/实际完成时间、缺口、影响、下一步及原任务入口。这里也列跨阶段引用、待确认成果、阶段决定、延期和历史资料入口。
每个任务都要覆盖成果、完成和确认三方面,不能只给过程文件链接。阶段已结束仍有未完成事项时,继续更新该阶段任务摘要并在项目层跟进;不因跨阶段复制任务。
阶段结束的正式小结只含最终成果与确认,未决项和后续安排放过程栏目。使用 [阶段记录模板](../assets/templates/阶段记录.md)。
阶段结束的正式小结只含最终成果与确认,未决项和后续安排放过程栏目。中心聊天汇报及群交接总结、发送实际结果也留在过程栏目,避免同一交接重复发送。使用 [阶段记录模板](../assets/templates/阶段记录.md),主动汇报见 [阶段汇报](stage-reporting.md)。
### 任务记录
@@ -81,19 +83,23 @@
使用 [任务记录模板](../assets/templates/任务记录.md)。
需要工时或周期评估时在原任务嵌入 [评估栏目](../assets/templates/工时与周期评估.md)。涉及 Bug 处理或承接时沿原问题/共用记录保存 [双方确认字段](exceptions-and-decisions.md#bug-处理与双方最终确认),不复制成另一份缺陷台账。
### 成果索引
按阶段列当前有效的最终成果名称、版本、位置及确认入口。确认详情只在对应阶段正式栏目维护,索引链接过去。任务状态、延期、草稿和旧版不混入当前成果索引。
使用 [成果索引模板](../assets/templates/成果索引.md)。原本就在外部系统的成果只记真实链接,不复制内容;外部系统旧版地址与历史情况放过程记录。
使用 [成果索引模板](../assets/templates/成果索引.md)。逐项登记全部有效成果和配套资料,或可逐项定位内容的有效包索引。原本在外部系统的成果登记真实完整地址、用途和版本,不强制复制;明确授权本地复制时按 [成果与确认](artifacts-and-confirmation.md) 保留原交接和路径映射,索引改为正式位置。复制或补地址日期不改变原提交、采用、确认和完成时间。
结项使用 [结项资料归档栏目](../assets/templates/结项资料归档.md),属于既有四类结项成果之一。沿用项目确认的格式;目录或确认记录不代表全部原件已归档。
## 更新顺序与避免重复
1. 在原任务中记录新事实与来源,更新现状,追加必要历史。
2. 若涉及正式版本变化,按 [成果与确认](artifacts-and-confirmation.md) 保留旧版及旧确认,再登记新最终版。
3. 更新所属阶段的逐任务摘要;涉及后续阶段时只添加原任务引用。
4. 同步项目进度的当前事项、影响与时间;正式成果变化时更新成果索引。
5. 取得必要真人推进决定并留档后再推进;需要通知时从这些记录生成摘要。
4. 同步项目进度的当前事项、影响与时间;有计划主表时据实更新执行情况并保留来源和历史;正式成果变化时更新成果索引。
5. 主动向中心真人汇报需要确认或决定的阶段结果;取得必要推进决定或既有条件授权实际满足并留档后再推进。需要通知时从这些记录生成摘要,正文及真实发送结果记入过程记录。
若更新中断,继续前核对原记录、阶段和项目摘要是否一致,以真实事实和确认依据为准补齐,不凭较新的文件时间覆盖业务结论。中心不新增一套任务数据库、通知队列或同步服务。
+35
View File
@@ -0,0 +1,35 @@
# 阶段汇报与推进决定
阶段结果需要确认、未完成事项需要决定或准备交接阶段时读取。汇报发在项目持续使用的中心会话中;更新本地记录不能替代向中心真人汇报。群通知另按 [通知规则](dingtalk-progress-reporting.md) 执行。
## 何时主动汇报
- 本阶段任务已全部确认完成,需要决定是否推进。
- 成果已提交但还有必要确认,或存在未完成、延期和跨阶段承接事项,需要中心真人决定。
- 已汇报的成果、版本、确认或遗留发生实质变化,补充受影响部分。
先更新原任务、阶段、项目进度及适用成果索引,再用 [阶段成果汇报栏目](../assets/templates/阶段成果汇报.md) 逐条汇报。可直接用于聊天,不为每次汇报另建独立成果文件;在阶段过程记录保留本次汇报与决定的依据。
## 汇报什么
1. 项目名称、本次汇报日期、当前阶段、阶段状态及概况。
2. 本阶段每项任务的主责真人、完成情况、应交成果、必需/选填与适用条件、已交成果及版本、完整入口。对应真人确认逐项写确认人、真实时间、结论、对象、范围与条件。
3. 原计划、当前有效计划、实际提交和实际完成时间;阶段管理日期与工程实际时间分开。
4. 未完成项和待确认项逐条说明原因、依赖、责任、原计划与当前计划、影响及必须完成的阶段。确实没有时明确写“未完成项:无;待确认项:无”;未知不填无。
5. 建议下一步及需要中心真人决定的具体事项。建议和已作出的决定分开,未决定保持待决定。
请求成果确认前,按 [成果与确认](artifacts-and-confirmation.md#供真人查看的成果) 展示本次全部有效成果的名称、版本、用途及完整可点击地址,或直接展示文件。目录或汇总描述不能代替实际查看入口。
## 推进和条件授权
跨阶段须有中心真人明确决定。已有条件授权时,逐项核实条件是否实际满足;满足后按原授权范围执行并记录依据,不重复申请同一批准。条件未满足、事实有变化或超出原范围时,说明缺口并取得相应决定。专业确认、业务授权及外部验收仍按各自权限办理。
在阶段过程记录分别保存:
- 原授权人、授权日期、原话、范围与条件。
- 条件实际满足的日期及各项证据。
- 实际切换日期和所执行的安排。
条件授权的阶段交接以实际切换日期登记阶段管理日期,不用早先授权日期倒填。正常阶段开始取中心真人实际启用日期,完成取明确结束或进入下一阶段的决定日期;第八阶段完成取明确关闭日期。进行中完成日期留空。工程开发、测试、验收的实际发生日期另行记录,不以阶段管理日期计算工程延期或人时。
取得推进决定或条件授权实际满足后,在已启用且获授权的范围内,将上一阶段总结与下一阶段已确认安排合为一条群通知。发送正文和实际结果记入阶段过程记录,核对既有记录避免同一次交接重复通知。