简介这是关于华为集成产品开发项目管理方法论的讲解文档核心梳理了六步一法框架面向产品经理、项目经理及研发管理者特别适合正在推行集成产品开发模式的团队参考。文档以流程为主线依次说明定义、计划、开发、验证、发布、学习与改善六个阶段的关键任务并强调每个阶段末尾需通过决策评审作为控制关口从而保障项目在进入下一环节前达到预定目标。资源包仅含一个PDF格式文件大小3.01MB为2008年华为内部交流材料内容精炼、结构清晰便于直接通读或作为培训参考资料。目前已有262人学习说明该主题有实际借鉴价值。读者可获得完整的阶段划分标准、跨部门协作要点和风险控制方法有助于将华为式项目管理经验应用到自身的研发项目管理与评审机制建设中。1. 华为IPD项目管理六步一法一份2008年的内部材料凭什么到现在还在用做了这些年项目经理最怕的不是需求变更而是流程挂在墙上没人执行。华为这套IPD项目管理六步一法是华为公司国内项目管理部2008年7月的内部交流材料核心就一句话项目拆成定义、计划、开发、验证、发布、学习六个阶段每个阶段结束设一个决策评审Gate把门。它不讲高深理论全是能直接映射到日常项目的操作框架——每个阶段做什么、产出什么、卡什么标准都写得足够具体。适合正在带中大型产品项目、被跨部门协作反复折磨的从业者也适合刚转项目管理、想一次性把流程框架立起来的新手。这份材料最值钱的不是“六步”而是那个“一法”决策评审Gate。把Gate设计好项目才真正有了刹车和油门。2. 六步一法方法论拆解六个阶段的交付物、责任主体与退出标准2.1 定义阶段在定义什么市场调研、需求范围与商业目标定义阶段回答的不只是“做什么”而是“凭什么做”。六步一法把Define放在第一位明确要求在动工之前完成三件事市场调研、竞品分析、需求定义与商业目标确认。放到实际项目里我一般会让产品经理牵头先写一页纸的商业论证把目标客户、核心痛点、预期收益和验收口径写清楚而不是一上来就写几十页需求文档。需求规格书当然要写但要在商业论证通过之后再展开否则很容易写出一个市场并不需要的东西。定义阶段的交付物可以按下面这份清单来核对。重点在于每份交付物都要有明确的验收口径不能只交付一个“初稿”。我习惯在项目启动会上就把每份交付物的负责人和验收人当场确认而不是等阶段末才互相推诿。这个动作省不掉后面所有评审都依赖这些确认记录。交付物内容要求责任主体验收口径商业论证目标客户、市场容量、核心痛点、财务预期产品经理量化的商业目标与ROI估算需求规格书功能清单、优先级、边界与约束产品经理研发代表需求评审通过并冻结基线项目章程目标、范围、假设、关键干系人项目经理干系人签字确认定义阶段还有一个动作特别容易被跳过需求基线冻结。评审通过之后需求并不是不能改而是任何变更都要走变更控制流程评估影响范围后才能决定是否接受。不冻结基线后面每一个阶段的计划都建立在流沙上。我见过好几个项目就是因为省了这一步需求反复变化导致计划、成本、人员全部被动调整最后算总账发现最初省下的半天时间后面花了三个月去填坑。2.2 计划阶段时间表、资源分配、里程碑与风险预案怎么排计划阶段在六步一法里不等于“排个甘特图”。它要同时输出四类东西时间表、资源分配、里程碑和风险评估另外还要把质量标准和验收条件一并定下来。注意质量标准必须在计划阶段定而不是验证阶段才谈。很多项目把验收条件拖到测试开始前才讨论结果测试用例写得像临时凑数验证阶段漏洞百出这就是典型的顺序错误。计划阶段的产出我一般会用一张评审清单来把关避免计划会开成“看图说话”检查项常见问题正确处理活动依赖关系关键路径没跑过任务串行排队先建依赖图再算关键路径资源日历同一人同时被分到两个并行任务做资源冲突检查按优先级取舍里程碑定义只有日期没有完成标准每个里程碑挂一个可验证的产出物风险评估只列风险没有应对方案每条风险指定owner和触发条件计划评审通过之后时间表、资源表和风险表要作为基线冻结之后的调整必须通过Gate或变更流程来驱动。这样做的本质是让计划拥有“契约”属性而不是随时可改的一句话。我自己踩过的坑是计划阶段排期太满完全没有给风险应对预留空间结果一个关键供应商延迟两周整个验证阶段被压到只剩一周验证质量直线下降。后来养成的习惯是每个里程碑之间至少留出10%~15%的缓冲专门吸收不确定性。2.3 开发与验证跨部门协作的技术评审与测试准入准出开发阶段的重点不是写代码而是协同。IPD框架下的一个典型特征是跨部门集成落到六步一法里就是研发、设计、测试、供应链、市场等角色在同一个计划下推进。我一般会在计划阶段就把每个部门的“项目接口人”确定下来每个接口人对计划里属于自己部门的活动负责。这样做的好处是过程中出了问题能直接找到人而不是开会时让部门经理临时抓人。开发过程里要跑两种评审一种是阶段性的技术评审重点看设计文档、接口定义和风险项另一种是日常的代码审查和模块联调。技术评审在IPD语境里常被称为TRTechnical Review是保证“中间不烂尾”的关键手段。六步一法里的Gate偏决策性质也就是常说的DCPDecision Check Point两者配合使用TR埋在产品开发过程里管技术质量Gate放在阶段边界管业务取舍。验证阶段要回答一句话产品是否真的达到了定义阶段设定的验收条件。验证不是简单跑一遍测试而是几个维度并行内部测试看功能和性能是否符合规格用户测试看真实场景下是否可用第三方认证看是否需要满足行业合规要求。不是所有项目都需要认证但一旦需要认证周期往往被严重低估在计划阶段就提前排队这是很多项目拿命换来的经验。验证阶段的退出条件要量化我通常用两个指标严重缺陷清零以及验收测试用例通过率达标。两个条件都满足才算验证通过可以进入发布Gate评审。这就是“准入准出”的含义开发完成的准出是进入验证的准入验证完成的准出是进入发布的准入。用准出条件管理阶段边界比靠项目经理催进度可靠得多。2.4 发布与学习产品上市不是终点复盘才是闭环发布阶段管的是从验证通过到交付客户的全过程生产、包装、推广、售后支持。这个阶段容易被忽略的是“支持就绪度”——产品上市了客服团队还没有培训材料一线反馈渠道没有建立售后响应机制没有跑通。这些如果等到发布当天才发现就只能用事故来补课。所以发布Gate里必须有一项支持团队的培训记录和知识库条目已发布。学习与改善阶段是六步一法里最容易被跳过的但恰恰是整套方法论里最有长期价值的一环。项目结束后要做项目回顾输出经验教训清单和改进项。关键动作是每条改进项必须指定责任人和截止日期并落到下一个项目计划里。没有落点的复盘只是PPT上的自我感动。到这儿六个阶段就串成了一个闭环学习阶段的改进项进入下一个项目定义阶段的输入。这也是IPD“持续改进”思想的落地方式——不是靠口号而是靠流程把上一个项目的教训强制传递到下一个项目。在实际应用中这套方法论可以根据项目特性裁剪比如短周期的需求型项目可以把定义和计划合并、验证和发布合并但“每阶段有Gate、Gate有条件、条件可量化”这三条底线建议保留。华为后续在研发项目管理上也发展出过RDPM等更轻量的思路但六步一法的骨架逻辑一直在被复用。最后给一张速览表把六个阶段的核心任务和退出标准集中在同一张表里。我每次启动新项目都会把它打印出来贴在看板上它比任何流程图都实用。阶段核心任务关键交付物退出标准定义Define市场调研、需求定义、商业目标需求规格书、项目章程、商业论证需求基线冻结、商业目标量化计划Plan时间表、资源、里程碑、风险项目计划、风险表、资源计划计划评审通过、资源到位开发Develop设计、实现、内部测试设计文档、产品原型功能完成、冒烟测试通过验证Verify内部测试、用户测试、认证测试报告、验收记录严重缺陷清零、验收达标发布Release生产、包装、推广、售后发布计划、支持材料产品上市、支持就绪学习Learn项目回顾、经验归档复盘报告、改进项清单改进项落实到下个项目3. 把六步落成项目计划WBS、里程碑与RACI矩阵的可执行配置方法论拆完了接下来是把六步一法变成一张能执行的作战地图。我习惯用三件套来做这件事WBS把阶段拆成工作包里程碑把工作包挂到日历上RACI矩阵把每个工作包分到具体的人。三件套上手之后六步一法才真正从一份PDF变成项目管理的日常语言。3.1 WBS拆解把六个阶段拆成可验收的工作包WBSWork Breakdown Structure工作分解结构是计划阶段最底层的工作。六步一法的六个阶段天然是WBS的一级目录不需要另起炉灶。二级目录按每个阶段的核心任务展开三级目录是具体工作包。我平时拆WBS会坚持三条纪律工作包粒度控制在2~5人天每个工作包必须有一个明确的交付物交付物必须有验收标准。没有可验证输出的活动比如“开会讨论需求”要改成“输出需求讨论会议纪要”否则算不上工作包。一个基于六步一法的WBS结构大致长这样1.0 定义阶段1.1 市场调研1.1.1 竞品分析报告交付物1.1.2 用户访谈纪要交付物1.2 需求定义1.2.1 需求规格书交付物1.2.2 商业论证报告交付物1.3 立项评审Gate交付物Gate自检表2.0 计划阶段2.1 项目计划编制交付物时间表与资源计划2.2 风险评估交付物风险登记表2.3 计划评审Gate交付物计划评审材料3.0 开发阶段3.1 系统设计交付物设计文档3.2 原型开发交付物可演示原型3.3 内部测试交付物测试报告4.0 验证阶段4.1 内部测试执行交付物缺陷记录4.2 用户验收测试交付物验收报告5.0 发布阶段5.1 生产与包装交付物发布物料5.2 推广与售后准备交付物支持手册6.0 学习与改善6.1 项目复盘会交付物复盘报告6.2 改进项跟踪交付物改进项清单WBS拆完之后要做两件检查。第一把底层工作包的交付物全部列出来看每个交付物支持哪一个Gate的通过条件确保没有“悬空工作包”——只干活、不支撑任何评审结论的工作包要么合并要么砍掉。第二估算每个工作包的工期和人力这一步直接与下面的里程碑设置挂钩。不要跳过这一步直接画甘特图甘特图只是WBS的呈现方式不是计划本身。3.2 里程碑设置倒排排期与缓冲期放在哪里六步一法的六个阶段每个阶段末尾的Gate天然就是大里程碑。但只有大里程碑不够用我一般会在每个阶段内部再设一到两个内部检查点里程碑用来在阶段过程中暴露问题而不是等到Gate评审才发觉进度已经失控。内部检查点不需要像Gate那样正式一张进度核对表就能跑但它必须和Gate一样有明确的完成标准。里程碑设置的实操我用的是倒排法先定一个业务上不能动的发布日然后从发布日往回推每个阶段需要多长时间。倒排的时候要注意三点。第一每个里程碑挂一个可验证的完成标准而不是只写日期。比如“功能完成”的标准是“所有功能开发完成且冒烟测试通过”不是“代码写完了”。没有完成标准的里程碑评审时就会变成主观判断Gate也就失去了客观性。第二阶段之间要留缓冲。缓冲期比例我一般取10%~15%但不是均匀撒在每两个阶段之间而是放在高风险区域后面。从经验看开发完成到验证开始之间、验证完成到发布之间是两个最容易出问题的衔接带缓冲优先放在这两个位置。计划阶段末尾也可以放一小段缓冲用来预防“计划刚定就过时”。第三里程碑一旦定下来要同步给所有干系人确认。这个动作看起来是仪式性的实际价值很大干系人确认过日期后续延期时就没有“我不知道这个节点”的退路。对于跨部门协作里程碑承诺比项目计划书更能约束行为。3.3 RACI矩阵跨部门协作的分工底线跨部门协作最常见的翻车方式不是没人干活而是每件事都“有人参与、没人负责”。六步一法强调跨部门协作落到具体工具上我会用RACI矩阵来兜底。RACI是四种角色的缩写RResponsible是执行人AAccountable是最终负责人CConsulted是需要被咨询的人IInformed是只需要知会的人。一个典型的六步一法RACI矩阵可以这样画关键任务产品经理项目经理研发测试市场需求定义RCCII项目计划CRCII技术设计ICRCI系统测试IACRI发布推广CAIIR用这个矩阵时有几条不成文的规矩。每个任务只能有一个A两个部门都是A等于没有人A这种“双A”出现时要把其中一个降为R另一个留作A或者把任务拆成两个子任务。C和I要分清楚C是要被征求意见的I只是通知一声。很多项目把该C的写成I结果关键干系人到最后阶段才说“我不知道”这是最常见的协作事故来源。RACI排完后还要做一次“全员拉通”——把矩阵发到所有涉及角色手里请大家逐条确认。这个动作很像需求评审表面上是确认表格实际上是让每个人对项目计划产生承诺感。尤其是当团队来自不同部门、平时没有共同工作语言时RACI就是那个共同语言。不要省略这一步矩阵做出来没有人认领等于白做。4. 决策评审Gate怎么设计评审材料、通过标准与会议节奏前面把六步拆开了这一章专门写那个“一法”决策评审Gate。为什么单独开一章因为在实际项目里六步一法能不能跑起来不取决于流程图画得多完整而取决于Gate设计得硬不硬。Gate是整条项目管理链路上的刹车和油门设计不好前面所有阶段都会变成橡皮筋。4.1 Gate评审的本质把质量卡在入口而不是出口Gate决策评审的本质是在每个阶段边界上做一次正式的“准入放行”。它的定位不是“汇报进度”而是“判定是否可以进入下一阶段”。这两者有本质区别汇报的结论是“我们干完了”判定的结论是“我们准备好了可以进入下一段”。前者是信息同步后者是质量背书。把汇报当Gate开会是这条方法论落地时最常见的偏差。在IPD的完整语境里评审通常分两类一类是技术评审Technical ReviewTR埋在产品开发过程内部盯设计质量和实现正确性另一类是决策评审点Decision Check PointDCP放在阶段边界盯业务价值和资源投入是否继续。六步一法里的“一法”更接近DCP的定位但实际落地时不能只开DCP不开TR——没有TR把关开发过程中的技术风险等到阶段末的Gate才发现设计有问题纠正成本会高出一个数量级。我的习惯是TR在开发阶段按模块定时开DCP在每个阶段末尾开把DCP的评审材料里附上最近一次TR的结论作为技术维度的输入。Gate的另一个作用是给项目留“后悔药”。如果阶段末评审发现偏差太大可以触发两个动作一是调整计划进入下一阶段也就是有条件通过二是重新定义目标或终止项目及时止损。真正有价值的Gate是不怕说“No”的Gate这条后面还会反复提到。4.2 Gate评审材料五种文档装进同一个评审包Gate评审要高效第一步是材料标准化。我要求项目组每次评审前把材料整理成一个评审包固定包含五种文档并在评审会开始前48小时分发给所有评审人。没有材料不评审这可以作为项目管理办公室的一条硬规矩。文档回答的核心问题评审人重点看什么阶段计划与进展对照表这个阶段的计划偏差有多大偏差原因是否合理、纠偏措施是否有效本阶段交付物清单承诺的交付物是否全部完成每条交付物与验收标准的对应关系Gate自检表是否满足进入下一阶段的准入条件逐项打勾不能有“待定”偏差与风险报告当前最大的风险是什么风险owner和应对措施是否明确下一阶段计划下一段怎么干、资源够不够与Gate通过条件的衔接这里有个细节下一阶段计划也要放进评审材料而不是等Gate通过后再补。因为评审会的价值不只是审查过去更是审查未来——评审人对下一阶段计划提意见比他们对上一阶段工作提意见更有用。把未来计划排除在评审之外等于让驾驶员只盯后视镜开车。提示评审包发出后如果评审人在会前没有反馈任何意见默认视为“无异议”。这个规则可以倒逼评审人提前读材料而不是会上现翻。4.3 通过标准每个Gate挂上量化条件Gate能不能硬起来取决于通过标准是否可量化。很多团队设计的Gate通过标准是“基本完成”“总体可行”这种描述评审人很难凭这句话做出“不通过”的判断。六步一法值得借鉴的地方就是把“到达预定目标”这件事拆成了可验证的条件。下面是我按六步一法搭建的一套Gate通过标准可以直接套用到产品类项目上Gate所在位置核心通过条件G1立项评审定义阶段结束商业论证量化通过、需求基线冻结、项目章程签署G2计划评审计划阶段结束资源到位率≥90%、风险应对方案齐备、关键干系人签字G3技术评审开发阶段内部设计评审通过、接口定义冻结、缺陷趋势可控G4验证评审验证阶段结束严重缺陷清零、验收测试用例通过率≥95%G5发布评审发布阶段之前支持就绪、推广物料就绪、合规认证完成G6复盘评审项目结束复盘报告归档、改进项清单落实到人这套标准不是死的不同项目可以调整具体数值但有一个原则要保持措辞必须让评审人能够用“是/否”来回答。比如“产品可用”就不合格要改成“验收测试用例通过率≥95%且无未关闭的严重缺陷”。“质量不错”不合格要改成“与定义阶段的性能指标逐项比对偏差率在±5%以内”。只有通过标准能被证伪Gate才有存在意义。4.4 评审会节奏会前、会中、会后各做什么Gate评审不是一个会议而是一个有小周期的工作流。我把每个Gate拆成三段来执行。会前48小时发出评审包评审人独立阅读材料并在评审单上填写预审意见。这一步最大的作用是避免会上从头读PPT把评审会开成读书会。我还会要求项目组把预审意见中“不通过”的部分提前逐条回应不能回应的直接挂到会中议题。很多无效评审会就是这么救回来的。会中按Gate自检表逐项过先看偏差再看交付物最后讨论下一阶段计划。评审结论只允许三种Pass通过、Conditional Pass有条件通过、No Pass不通过。有条件通过必须写明整改截止日期和验证人由指定评审人在整改完成后单独验证关闭。这里容易翻车的点是把“有条件通过”当成“通过”整改项没人追风险顺延到下一个阶段。避免方法是下个Gate开篇第一项就是核对上一个Gate的整改关闭情况未关闭的整改项自动升级为下个Gate的“不通过”项。会后24小时发出评审纪要列明结论、整改项、责任人和验证人。纪要不是为了存档而是为了给下个Gate提供追溯依据。我在评审材料模板里固定放一张“Gate历史记录”表把所有Gate的结论和整改状态列在一起项目走到G5时回头看整条决策轨迹清清楚楚。5. 避坑指南六步一法落地时最常踩的五个坑方法论本身经得起推敲翻车基本都是落地姿势的问题。这些年我见过太多项目把六步一法做成流程空转材料挂在墙上项目还是原来的活法。这里把最典型的五个坑按“现象—原因—解决”记下来都是真实项目里反复出现的场景。5.1 评审会开完等于没开Gate为什么总说“通过”现象Gate评审会开得热热闹闹结论永远是“通过”项目进入下一阶段后问题照样集中爆发。评审人不是没有异议而是觉得“提了也没用反正最后都是领导拍板”于是会上集体沉默散会后私下抱怨。原因根子是通过标准太主观。评审材料全是“基本满足”“整体可行”这类定性描述评审人没法说“不”因为没有一个客观的尺子来判断“不”的依据。另一个原因是评审结论没有和后续责任绑定——即使说“不通过”也没有人会因此调整什么。解决把每个Gate的通过条件换成可量化的指标比如G2必须“资源到位率≥90%”G4必须“严重缺陷清零、验收测试通过率≥95%”。没有数据支撑的评审项直接标红退回。评审结论要留档并且把“No Pass”的次数纳入项目复盘。只要连续三次评审都无理由全票通过项目管理办公室就应该介入检查是不是评审材料出了问题。5.2 需求没冻结就冲进开发变更为什么管不住现象定义阶段需求还没谈清楚管理层一句“先干起来再说”项目就急急忙忙进入开发。开发过程中需求源源不断进来设计返工、代码重写、测试用例作废进度一周一周往后滑最后改到连最初版本长什么样都记不清了。原因大家把定义阶段当成文档流水线而不是决策关口。需求评审有没有通过、基线有没有冻结没有人检查“先干起来”在组织里又是一种政治正确的姿态谁反对谁像是不积极。解决在定义阶段强制设需求冻结点需求规格书评审通过后任何变更必须走CCB变更控制流程评估影响范围后才决定是否接受。项目经理要在项目启动会上拿到明确授权需求未冻结时有权拒绝排期。这一步需要高层授信否则很容易被一句“业务紧急”击穿。同时把“需求基线是否冻结”写进G1和G2的Gate通过条件没有冻结记录后面两个Gate都不放行。5.3 里程碑排得太乐观计划为什么两周就崩现象计划阶段的甘特图画得很漂亮里程碑一个接一个看起来无懈可击。结果项目运行两周发现关键路径上的任务被别的项目抽走人手一个里程碑还没到就延期了后面的计划全部连锁后移。原因里程碑“拍脑袋”式推导——只按日历倒推没有校验资源日历和任务依赖关系。更常见的情况是项目经理为了向上汇报“有冲劲”主动把日期往前提了两周完全不考虑并行任务之间的资源冲突。解决排里程碑前先跑一遍关键路径标记出每个里程碑的依赖前置任务再把资源日历对一遍做资源冲突检查。发现并行任务抢资源时要么调整里程碑日期要么申请增援二选一不能靠“到时候再说”。里程碑之间留10%~15%的缓冲放在验证完成到发布之间这种高危衔接带。这个动作会让计划图看起来不那么“漂亮”但至少它不会两周就崩。5.4 验证阶段被挤成“走过场”缺陷为什么漏到客户现场现象验证阶段一开始就发现严重缺陷但发布日是已经对外公布的死线于是开会讨论之后“带病发布”。结果产品到了客户现场就出问题售后团队上门救火品牌损失比延期发布大得多。原因验证阶段被视为“可以挤压的弹性区间”时间先被开发延期吃掉再被发布死线压短。更深层的原因是验收条件没在定义阶段定清楚测试用例没有明确依据测到哪算哪缺陷自然漏出去。解决在定义阶段就把验收条件写清楚每个功能点对应一条可测的验收标准验证阶段的测试用例由这些验收条件直接映射保证“验收条件逐条可测、测试用例逐条可溯”。Stage门禁上把“严重缺陷清零”作为发布Gate的硬门槛不达标就不签字。签字权要明确授权给QA负责人而不是项目经理一个人扛——项目经理往往顶不住业务部门的压力QA负责人可以。5.5 复盘会开完没有然后经验为什么留不到下个项目现象项目结束复盘会开了三个小时大家聊得挺热闹输出了一张PPT上面列了七八条“经验教训”。散会后没人跟进下个项目该踩的坑一个不少继续踩。再过半年连当初PPT放哪儿了都找不到。原因复盘报告没有落到可跟踪的载体上。没有责任人、没有截止日期、没有验证方式的改进项本质上等于不存在。另一个原因是复盘被认为是“项目结束后的仪式”而不是“下一个项目启动前的输入”所以也没有人会把它当真。解决复盘必须输出可跟踪的改进项清单改进点、负责人、截止日期、验证方式。规范做法是让每一项都挂到后续项目的计划里作为该项目的约束条件。我在项目归档时检查复盘输出有没有下个项目落点没有就退回重写。这个动作不复杂但能让“经验教训”从形容词变成动词——经验只有在被引用时才算是经验否则只是日记。6. Obsidian项目管理台账一个让六步一法持续跑起来的具体技巧6.1 把六步转成模板检查项即Gate条件方法论写得再好不落到日常工具里就会慢慢失效。我用Obsidian给每个项目建一个归档台账把六步一法做成可以直接复制的Markdown模板。Obsidian是本地笔记工具好处是纯文本、不锁格式、可以跨项目搜索特别适合用来做长期的项目积累。下面这个模板是我现在每个新项目都会先拉一遍的骨架# 项目名称xxx 负责人xxx 开始日期xxx 目标xxx ## 阶段状态总览 - [ ] 定义阶段 - [ ] 商业论证量化通过 - [ ] 需求基线冻结 - [ ] 项目章程签署 - [ ] 计划阶段 - [ ] 里程碑基线含缓冲 - [ ] 资源到位率≥90% - [ ] 风险应对方案齐备 - [ ] 开发阶段 - [ ] 技术评审TR通过 - [ ] 接口定义冻结 - [ ] 功能完成冒烟测试通过 - [ ] 验证阶段 - [ ] 严重缺陷清零 - [ ] 验收测试用例通过率≥95% - [ ] 发布阶段 - [ ] 支持就绪 - [ ] 推广物料就绪 - [ ] 学习与改善 - [ ] 复盘报告归档 - [ ] 改进项落实到下个项目 ## Gate日志 - G1 结果通过 / 日期 / 备注 - G2 结果有条件通过 / 日期 / 整改截止 - G3 结果通过 / 日期 / 备注 - G4 结果通过 / 日期 / 备注 - G5 结果通过 / 日期 / 备注 - G6 结果通过 / 日期 / 备注 ## 风险清单 | 风险 | 概率 | 影响 | 应对措施 | 负责人 | 状态 | | ---- | ---- | ---- | ---- | ---- | ---- | ## 复盘关联 [[项目xxx复盘]]模板里的方括号是Obsidian的复选框语法每个阶段完成一个检查项就勾一个方框Gate日志直接对应六步一法里的决策评审评审结论只写“通过/有条件通过/未通过”有条件通过就在备注里写上整改截止日期。风险清单用表格维护每周更新一次比堆在聊天记录里强得多。6.2 日常维护节奏每周十分钟更新台账台账建好只是开始真正让方法论跑起来的是维护节奏。我给自己定的规矩是每周五下午花十分钟做三件事勾掉本周完成的检查项更新Gate日志里新增的评审结论把风险清单里的状态列刷新一遍。如果装了Dataview插件还可以按标签汇总所有项目的阶段状态一眼看清哪些卡在验证、哪些已经发布。做第一个项目时我懒得维护台账结果G2评审前要连夜补材料从那以后每接一个新项目第一天就在Obsidian里把模板拉起来把每个Gate的量化退出条件写进检查项之后每周雷打不动花十分钟更新。六步一法给了项目一张完整的地图但真正让地图有用的是每天落笔的那十分钟。希望帮到你。本文还有配套的精品资源点击获取