简介：面向企业项目经理与项目管理初学者的一份华为项目管理模板文档，聚焦项目启动阶段的策划与任务书撰写，帮助团队在立项之初统一目标、计划与各方预期。文档以中英双语表格呈现，涵盖项目基本情况、项目描述、里程碑计划、评价标准、假定与约束条件、主要利益干系人六个模块，并以“T客户考察公司项目”为完整示例，逐项演示背景与目的、工期与费用目标、关键时间节点及验收条件的具体填写方式。压缩包内仅1个docx文件，约17KB，体积轻便，可直接套用改写。已有939人学习下载。读者可据此快速搭起一份结构清晰的项目任务书，明确责任分工与风险边界，减少沟通反复，适合需要规范化立项材料的团队参考。

1. 一份 6 段式任务书，为什么比 20 页汇报材料更能挡住返工

接手一个客户考察类项目，最怕的不是资源不够，是没人说得清“做到什么程度算完”。这套华为项目管理模板里的 02 号文档——项目策划/任务书，就是干这个的：一份 .docx，六段结构，从项目基本情况、项目描述、里程碑计划、评价标准、假定与约束，一直排到干系人表，把项目开工前该吵的架提前吵完。它不属于看完就懂的那种读物，属于填的时候难受、填完省事的东西。适合手里有交付或客户关系类项目、又不想靠口头对齐推进的项目经理，也适合售前转交付的接口人，以及需要给下属派活却说不清验收口径的部门主管。下面按“每段填什么、判定标准是什么、哪里最容易翻车”拆开讲。

2. 六段骨架逐段拆：基本情况与项目描述怎么填才不空

模板的前两段是最容易被糊弄过去的，因为它们看起来像填空题：填个名字、编个号、写两段话就完事。实际恰恰相反，这两段决定了后面四段有没有意义。基本情况段提供的是检索锚点和责任锚点，项目描述段提供的是判断标准——后面里程碑排得对不对、验收标准定得狠不狠，全看这段把“商业问题”翻译成了什么。我见过太多任务书，背景写了三百字行业形势，目标写了“提升客户满意度”，结果执行到一半发现没人知道该交付什么。

2.1 项目基本情况：编号、版本、审核人三栏的埋点作用

这一段只有六个字段，但每个字段都在承担一个后续会被反复调用的功能。项目名称是检索锚点，项目编号是归档锚点，制作人和审核人是责任锚点，制作日期是版本锚点。字段少不代表可以随手填，恰恰因为少，每一栏的错误都会在项目中途被放大。

编号这一栏值得单独说。原料里的编号是“T0808”这种两段式，T 代表业务线，0808 代表年月。这种写法在项目量小的团队够用，一年做几十个项目就开始难受——同一个月超过 99 个项目就撞号，而且光看编号判断不出这是第几个。常见做法是改成“业务线字母 + 年后两位 + 月 + 两位序号”，比如 T250701，虽然长了点，但排序、筛选、反查都能直接用。编号一旦定下来就不要改，项目中途换编号等于把之前的邮件、会议纪要、合同附件的引用全部作废。

审核人这一栏的坑更隐蔽。很多人下意识填自己的直属领导，但任务书的审核人需要的不是行政层级，是资源调配权。一个客户考察项目，审核人应该是能拍板“调一台车、批一笔接待费、让某个高层出面”的那个人，通常是项目赞助人。如果审核人没有这个权力，后面“假定与约束”里写的东西就全是空话——假定内部接待资源能落实，谁来落实？审核人落实不了，这条假定就是自欺欺人。

制作日期和版本号要绑在一起看。我的习惯是：日期只记录首次成稿日，之后所有修改靠版本号体现，V0.1、V0.2 一直到 V1.0 审核通过，V1.1 开始是执行期变更。这样任何人拿到文件，看一眼版本号就知道这是草稿还是已批准版本，不用去翻修订记录。共享盘里的文件名也建议带上版本号，比如“项目策划任务书_T250701_V1.0.docx”，避免出现“最终版”“最终版2”“真的最终版”这种血泪经验。

2.2 项目描述：背景写问题，目的写动作，目标写数字

这一段是整份任务书的重心，它由三个小部分组成：背景与目的、项目目标。很多人把这两块写成一段抒情文字，读完的感觉是“知道了，但不知道要干嘛”。合格的写法有个简单的分工：背景负责说清“不解决会怎样”，目的负责说清“这次要改变什么状态”，目标负责说清“什么时间、交付什么、花多少钱”。

背景部分建议压成三段式。第一句交代商业背景，一句话就够，比如“某海外市场是公司的重点区域，当地第二大运营商是我们的目标客户”。第二句列问题，控制在三条以内，每条必须可量化，不能写“交付质量有待提升”，要写“近三个月延迟交货 X 批次、错发货物 X 次、初验遗留缺陷 X 个”。第三句写后果，也就是这些问题不解决，会损失什么——“客户高层开始观望，后续框架合同存在变数”。这三句的次序不能反，先有商业背景才有问题，先有问题才有后果，逻辑链断了，后面定目标就没有依据。

目的部分只写一句话，动词开头，指向一个状态变化。原料里的“改善客户关系，重建客户对合作的信心”就是合格写法，虽然还偏虚，但方向对。更硬的写法是“通过一次高层考察，把客户对我方供货与工程管理能力的质疑，从‘观望’拉回‘继续合作’”。

目标部分是唯一必须出现数字的地方。一个可执行的目标至少包含三个要素：时间节点、交付物、预算上限。原料里“7 月 31 号前邀请客户 CTO 带队考察，项目预算 20 万”就是标准结构，三个要素齐全。问题出在中间那句“打消客户关于供货能力的怀疑”——这是目的，不是目标，它没法验收。目标是“考察期间完成三个样板点参观、两场技术汇报、一次高层会面，考察结束后 10 个工作日内取得客户书面反馈”。质疑有没有被打消，靠这几项交付物和反馈来证明，而不是靠项目经理说“我感觉客户挺满意的”。

2.3 一段合格的项目描述长什么样：改写前后对照

拿原料里的场景做一次改写演练，能看清差距在哪。原始写法是“客户开始质疑我司软件版本管理和质量控制能力，这些问题引起了客户高层关注，对以后合作开始持观望态度”，这句话信息量不小，但全是定性描述。改写之后应该是“近三个月延迟交货 3 批次、错发货物 5 次、初验遗留缺陷 12 个，客户已两次发函要求说明，原定 Q4 签署的框架合同暂缓”。

差别在于：前者读完只能点头，后者读完能算出严重程度，也能反推出考察项目该重点展示什么——既然质疑的是版本管理和质量控制，考察议程里就必须有版本管理流程介绍和质量门禁演示，而不是泛泛参观展厅。目标写不清楚，议程就排不精准，这是连锁反应。

再往下推一层，目标里的预算也要拆。20 万不是一笔糊涂账，常见做法是拆成接待、差旅、物料、应急四块，应急留 10% 到 15%。拆完写进任务书的备注栏，不是为了审批好看，是为了验收时能对照。原料里“考察费用不超过预算则项目成功”这句话，如果没有分项预算，验收时只能看总数，超支发生在哪一块根本查不出来。

改写后的目标段落可以长这样：7 月 31 日前完成客户 CTO 带队一行 X 人的考察接待，交付物包括三日议程执行记录、样板点参观纪要、技术汇报材料一套、高层会面纪要，总预算 20 万元，其中接待 12 万、差旅 5 万、物料与应急 3 万。这段话读起来不漂亮，但每一句都能被验收，这就是任务书该有的样子。

3. 里程碑与验收标准：把“考察顺利”拆成可判定的条件

中间这两段是最能体现功力的地方。里程碑计划负责把目标切成可执行的片段，评价标准负责给每个片段装上判定开关。这两段写虚了，项目执行期就会变成一场关于“到底算不算完成”的拉锯战。原料里的里程碑写的是“成立项目组、递交邀请函、行程确认、启程、考察结束、回访”，六个时间点排得很整齐，但除了日期之外几乎没有可判定信息——启程算不算完成？人上了飞机算，还是落地算？这种模糊在跨部门协作里会被无限放大。

3.1 里程碑计划：时间点必须挂交付物

里程碑的判定标准只有一条：到期那天，能不能拿出一份东西证明它完成了。这个东西可以是签字文件、邮件确认、会议纪要、系统截图，但必须是第三个人能查证的。动作不算，“递交邀请函”是动作，“客户方对接人回复确认收到的邮件”才是成果。

里程碑数量上，短周期项目控制在 5 到 8 个，间隔不超过一周。间隔太长，中间出了问题发现不了；间隔太短，光写纪要就占满时间。上表六个节点，从 7 月 8 日到 7 月 25 日，平均三天一个，密度是合理的，问题只出在成果定义上。

还有一个容易忽略的点：里程碑的责任人要写进表里。原料的里程碑只有时间，没有责任人。六个节点分别由谁推进、谁判定，必须在表里体现，否则到了 7 月 14 日行程没确认，所有人都觉得是别人的事。常见做法是在里程碑表右侧加两列——“责任人”和“判定人”，责任人负责推进，判定人负责签字，两个角色不能是同一个人，这是最低限度的相互制约。

3.2 验收标准的四层判定：内容、后勤、客户反馈、费用

评价标准这一段的作用，是把“项目成功”这个模糊概念拆成几条能逐条打勾的条件。原料里的四条其实写得相当扎实：CTO 在考察人员之列且如期成行、考察期间内容零失误、后勤失误不超过 1 次、客户有明确正面反馈且支持后续项目实施、费用不超预算。这四条覆盖了内容、后勤、客户、成本四个维度，结构是对的，需要补的是每一层的判定证据。

“后勤失误不超过 1 次”这条特别值得展开，因为它示范了怎么把定性描述变成可计数条件。前提是先把“失误”定义清楚：车辆晚点超过 15 分钟算一次，签证材料出错导致改签算一次，酒店房型与确认单不符算一次，参观样板点时设备无法演示算一次。定义写进任务书，验收时就不会出现“这算什么失误”的争论。没有定义的“顺利”，验收阶段必然变成玄学。

内容零失误这一条，靠的是提前评审。议程、汇报材料、样板点演示脚本，在考察开始前三天完成一次全流程走查，走查记录本身就是验收证据。我一般会要求走查时按分钟级排一遍，从接机到送机，每个环节谁在场、谁主讲、超时怎么办，全写下来。这套东西看着繁琐，但它能把“内容失误”挡在发生之前，而不是事后统计。

3.3 假定与约束：写下来的是免死金牌，也是紧箍咒

这两块经常被混为一谈，实际是两个完全不同的东西。假定是“我们认为会成立、但没把握的前提”，它可被证伪，一旦不成立，项目范围要变更；约束是“不可谈判的边界”，它不需要论证，只需要遵守。分不清这两者，项目中途就会陷入两种困境：把假定当约束，客户一变卦整个项目停摆；把约束当假定，预算超了还在往里填。

原料里的三条假定写得太粗。“假定客户能成行”这句话，等于没写——客户当然可能不成行，问题是不成行的时候怎么办。合格的假定要带触发条件和备选动作：客户 CTO 若在 7 月下旬有其他出访安排，则启用 8 月上旬备选时间窗，备选窗口需在 7 月 15 日前确认。这样写，假定才真正起到免死金牌的作用——不是推卸责任，是提前约定变更路径。

三条约束倒是写得具体。“车程半小时以内的五星级酒店”“至少一位对等级别的高层接待”，这种带数字和级别的约束是可执行的，接待经理拿着这句话就能去订酒店、去约高层日程，不需要反复请示。约束最怕写成“接待规格要体现重视”，这种话除了增加沟通成本没有任何作用。

还有一类常被漏掉的约束：客户方的时间窗口。原料里写“考察必须在 7 月底之前完成”，这是己方约束，客户方那边有没有约束？比如客户高层夏季休假、当地节假日、客户方季度结算期，这些不写进去，排期时就会撞墙。我的习惯是在约束段末尾加一行“客户侧时间限制”，哪怕写“暂无已知限制”，也比空着强。

4. 干系人表：一张表决定出了事找谁

干系人表是整份任务书里最容易被当成附属品的一段，很多人直接照抄组织架构，把部门、职务填一遍就交差。这张表的真正用途不是记录谁参与了这个项目，而是回答三个问题：这件事谁拍板、谁执行、谁会被影响。原料里的表有姓名、类别、部门、职务四列，类别还做了下拉菜单，这个设计思路是对的，下拉菜单能防止自由填写导致后续统计失效。缺的是影响力和关注点两列，而这两列恰恰是导出沟通计划的关键。

4.1 六类角色与职责边界

原料里出现的角色可以归成六类：项目赞助人、项目经理、客户经理、技术接口人、供应链接口人、接待经理。这六类角色在一个客户考察项目里各管一段，边界模糊就会互相推诿。

这张表里最容易被忽略的是“判定权”这一列。干系人表如果只写谁参与，不写谁判定，验收阶段就会出现“大家都觉得完成了，但没人签字”的局面。我的做法是每个里程碑、每条验收标准都指定一个判定人，判定人必须在干系人表里有对应角色。这张表和里程碑表是互相咬合的，咬不上就说明有人被漏掉了。

4.2 干系人表的填法与维护节奏

除了原料里的四列，建议补三列：影响力（高/中/低）、关注点（一句话）、沟通频率（日/周/里程碑/月）。影响力不写“重要”这种词，只写高、中、低三档，方便后续分类；关注点写这个人最在意什么，比如客户 CTO 关注的是供货稳定性，技术接口人关注的是版本管理流程，接待经理关注的是行程不能出岔子；沟通频率按人定，不按项目定。

下拉菜单在 Word 里用“开发工具—内容控件—下拉列表”实现，在 Excel 里用数据验证。这个细节看着小，作用不小：类别字段如果能自由填写，十个人能填出十二种写法，“项目赞助人”“赞助人”“Sponsor”“发起人”混在一起，后面想做筛选统计基本没戏。原料里特意标注了“类别（加下拉菜单）”，说明这个坑是踩过的。

维护节奏上，干系人表不是填一次就完事。立项时出初版，每个里程碑完成后更新一次，人员变更时立刻更新并留痕。更新不是改完就覆盖，建议在文件末尾留一个变更记录小表，写清日期、变更内容、变更人。人走了、岗位调了、对接人换了，这张表如果还是三个月前的版本，出了事照样找不到人。

4.3 从干系人表导出沟通计划

干系人表填完，沟通计划就是一道推导题。按影响力和关注点分四类处理：高影响高关注的人，每周一次当面或电话同步；高影响低关注的人，只在里程碑节点汇报，且每次汇报必须带结论和需要他决策的事项；低影响高关注的人，进周报抄送名单；低影响低关注的人，月度简报即可。

客户 CTO 这类角色是典型的高影响低关注，很多人会犯两个方向的错：要么天天发进度，把人烦到不回消息；要么从头到尾不沟通，考察当天才第一次露面。正确做法是里程碑节点汇报，每次不超过一页纸，第一句写结论，第二句写需要他做什么，剩下的才是背景。这个习惯坚持下来，关键时刻要资源会顺畅很多。

5. 避坑：这五处填错，任务书等于没写

任务书这东西，写对了是项目护栏，写错了是心理安慰。下面五条是我在不同项目里反复见到的翻车现场，每条都按“现象—原因—解决”拆开，对着改一遍，能省掉执行期一半的口水。

第一条：目标写成口号。现象是任务书里写着“提升客户满意度”“增强客户信心”，验收时谁也说不清达到没有。原因很简单，写的人把“目的”和“目标”当成了一个东西，目的可以虚，目标必须实。解决办法是给每个目标加三样东西：时间点、交付物、判定证据。“增强信心”改成“考察结束后 10 个工作日内取得客户书面正面反馈”，立刻就能验收。改的时候有个自检办法：把目标那句话念给一个没参与项目的人听，问他“你怎么知道做到了”，他答得出来才算过关。

第二条：里程碑写成动作。现象是里程碑表里全是“启动”“推进”“完成”“启程”这类词，到期无法判断是否完成。原因是填表时按时间顺序回忆要做什么事，而不是按成果倒推要交什么东西。解决办法是把每个里程碑的名词化——动作换成成果，“递交邀请函”换成“邀请函签收记录”，“考察结束”换成“考察纪要与行动项清单”。换完再检查一遍：这份成果现在存在吗？不存在的话，谁在什么时候能把它做出来？

第三条：验收标准不可判定。现象是验收标准写着“客户满意”“过程顺利”“无重大问题”，验收会上各说各话。原因是把感受当标准。解决办法是每条标准都配一个证据形式和判定人，证据形式必须是第三方能查证的东西——邮件、纪要、签字单、系统记录。“无重大问题”改成“议程执行偏差为零，后勤失误计数不超过 1 次，失误定义见附表”，争议空间立刻消失。这一条和第 3 章的验收表是同一套逻辑，写标准的时候顺手把证据列出来，验收时就不用临时找。

第四条：假定和约束混用。现象是项目中途客户改期，整个计划停摆，因为任务书里写的是“客户必须按时成行”。原因是把假定当成了约束，假定不成立应该触发变更，不是项目失败。解决办法是给每条假定加触发条件和备选动作，“客户不能成行”对应“启用备选时间窗，窗口在 X 日前确认”。反过来，约束也不能写成假定，“预算不超过 20 万”是约束，不能写成“希望控制在预算内”，语气一软，超支就有了借口。

第五条：干系人表照抄组织架构。现象是表里人名部门职务一应俱全，真出了事还是找不到人。原因是填表时想的是“谁跟这个项目有关系”，而不是“这件事谁拍板、谁执行、谁被影响”。解决办法是按职能倒推：每个里程碑谁推进、谁判定；每条验收标准谁提供证据；客户侧谁确认行程、谁给反馈。倒推完再和现有名单对一遍，缺的人补上，多余的人删掉。表里的人数不是越多越好，八到十二个人是比较舒服的规模，再多就失去焦点。

这五条有个共同点：都不是格式问题，是判断标准问题。格式错了好改，判断标准错了，整份文件就是一张好看的废纸。

6. 把模板变成可复用资产：裁剪规则与立项前自检

模板用一次是文档，用十次就得变成资产。我的做法是给它配两样东西：一份裁剪规则和一份立项前自检清单。裁剪规则解决“不同项目怎么用同一份模板”的问题——客户考察类项目必须保留全部六段，交付类项目可以弱化接待相关字段但要加强里程碑和验收，内部改进类项目可以砍掉客户干系人但必须保留假定与约束。下面这张表是我自己用的裁剪口径，供参考。

自检清单我一般压到八问，立项评审前逐条过：项目名称能不能看出交付物；编号在共享盘里是否唯一；背景里的问题有没有量化；目标是否同时具备时间、交付物、预算；每个里程碑是否有成果和判定人；每条验收标准是否有证据形式；每条假定是否有触发条件和备选动作；干系人表里每个角色是否有判定权。八问里任何一条答不上来，就先别开会评审，回去补完再说。

归档命名也值得定个规矩。我的习惯是“项目编号_文档类型_版本号_日期”，比如 T250701_项目策划任务书_V1.0_20250708.docx，执行期变更用 V1.1、V1.2 递增，项目结项后整个目录打成压缩包，跟验收材料放一起。这套规矩看着死板，但它救过我一次——两年前的一个考察项目，客户半年后回头质疑当时的议程安排，我从归档包里三分钟翻出 V1.0 版本和对应的议程执行记录，事情当场说清。从那以后我每次立项都强制走一遍裁剪规则和八问自检，宁可前期多花两小时，也不想在中途花两周去解释“当时到底怎么定的”。希望帮到你。

本文还有配套的精品资源，点击获取