IT 项目失败的概率比任何其他类型都更高——通常是因为范围不清晰、遗漏了依赖项或沟通薄弱。使用 Trupeer，你可以从免费的 IT 项目计划模板开始，先节省数小时的规划时间；再用你的 品牌识别 进行定制；最后把计划转化为视频更新，让技术与业务相关方保持一致。

什么是 IT 项目计划，以及为什么通用模板会失效

项目计划是一份文件，用来说明将交付什么、何时交付、由谁交付，以及要让这些发生必须满足什么条件。所有在该搜索中排名的模板都会给你这些内容，通常以任务清单的形式呈现：包含开始日期、结束日期、负责人以及甘特条。

任务清单本身并不是问题。问题在于你填写它的顺序。

通用模板从你的工作开始。列出任务、估算持续时间、安排顺序、添加负责人，然后结束日期就会落在最底部。依赖项会在之后才被添加到某一列里，作为备注。

IT 项目很少因为这些估算不准确而延期。它们延期是因为有些事情在计划之外突然出现，而且无法争辩：覆盖上线周的变更冻结、排队长达六周的安全审查、供应商的实施顾问被预订到季度末、许可证在替换准备就绪前就要续期、一次审计会把环境锁定一个月。

这些都不是风险。风险是可能发生的事情。它们在你开始规划的那一天就已经存在，而且只要有人在第一周问起，就都能被提前知晓。

因此，这个模板会颠倒顺序。你先画出那些无法移动的日期。然后弄清楚剩余窗口到底有多宽。接着把工作安排进这个窗口。任务清单仍然存在，只是不再是你写下的第一件事。

如何在 Trupeer 中自定义此模板

步骤 1：打开模板（Templates）部分

从主导航进入 Templates（模板）部分。

步骤 2：选择并打开模板

点击任意你想要处理的模板以将其打开。

步骤 3：展开模板视图

如有需要，展开模板视图以清晰查看完整布局和细节。

步骤 4：编辑模板

点击 Edit（编辑）开始修改所选模板。

在编辑器中，你可以：

• 添加新的章节

• 定义或更新格式规则

• 添加徽标并调整其位置及相关设置

步骤 5：保存你的自定义模板

完成所有必要更改后，点击 Save（保存），将更新后的模板存为你自己的版本。

步骤 6：预览并微调模板

当你想查看自定义模板的效果时，打开 Preview（预览）。

在预览界面中，如有需要，你还可以继续直接进行调整，确保模板呈现得完全符合你的预期。

使用 IT 项目计划模板，你可以：

• 节省规划时间：跳过空白页面，直接使用为 IT 计划打造的结构。

• 管理技术复杂度：内置架构、依赖项与风险等章节。

• 保持品牌一致：使用 Trupeer 的品牌套件应用你的徽标、字体与配色。

• 让业务与 IT 保持一致：把技术计划转换为业务相关方能理解的视频更新。

• 跨项目实现标准化：每个 IT 计划都使用同一模板。

• 触达全球团队：一键把计划与更新翻译为 65+ 种语言。

不可变项，以及在哪里找到它们

不可变项是由不向项目汇报的人设定的任何日期或持续时间。你无法在项目内部对它进行协商；而且如果发现得太晚，它就会从约束变成危机。

下面是第一周要用到的清单。请让每位负责人回答两个问题：你的日期是什么？你的提前期是多少？

其中有两项值得特别关注，因为它们最常被忽略。合同中的通知期是位于续约日期之前的不可变日期，这意味着真正的截止时间比日程表上的更早。还有，源系统中的数据质量是唯一无法通过查表得知规模的不可变项。你必须亲自去测量，因此对源数据进行画像应当属于第一周，而不是迁移阶段。

在你估算任何内容之前，把这些都画在同一个日历上。你要找的是“空档”的形状。非常常见的情况是，这个空档比项目持续时间要窄得多，而关于范围的坦诚沟通发生在第二周，而不是第七个月。

计划中要写什么

当不可变项都画出来后，计划本身有十二个章节。复制这些标题，并按此顺序填写。

1. 概要。一句话：会发生哪些变化、对谁产生影响，以及之后哪些不再成立。

2. 结果与成功标准。可衡量，并注明日期。至少包含一个关于被替换对象的标准，例如：在指定日期前，旧系统没有流量且没有许可证成本。以上线为终点的计划，会导致公司为两个系统付费。

3. 约束日历。把上表中的不可变项填好，并用通俗的文字把由此得到的交付窗口写成一个日期范围。

4. 范围。三份清单：包含（in）、不包含（out）以及延期（deferred）。延期清单才是最有用的，因为当范围被削减时，范围就会进入这里；这样就能避免同一场关于范围的讨论反复发生四次。

5. 阶段与里程碑。里程碑是有可观察答案的事件，例如“安全审查通过”或“首家门店上线”，而不是“设计阶段完成”。

6. 工作分解。任务、负责人、估算、顺序。这是其他所有模板都会从这里开始的部分。

7. 依赖项。把内部与外部拆开。每一个外部依赖都要在对方组织中指定到具体人员，并写明对方已同意的日期，而不是你假设的日期。

8. 环境与数据。有哪些环境、每个环境里有哪些数据、测试中如何保护生产数据，以及源数据画像的结果。

9. 切换与回滚。切换的逐小时顺序、你停止的决策点、由谁做出该决定，以及如何返回。把它写成可执行的流程，这正是 方法与程序模板 应该放置的内容。

10. 带触发条件的风险。不是“可能性与影响”的网格。每个风险都要有一个可观察的触发条件，以及一旦看到触发条件就会执行的动作。“12 月 5 日前供应商顾问未确认”就是触发条件。“供应商可能会迟到”则不是。

11. 沟通、培训与采用。谁在何时被告知什么，以及在第 1 天用户需要能够完成哪些事情。

12. 治理与收尾。谁做决定、谁升级、决策记录长什么样，以及在什么条件下项目被宣布完成并交付给运行团队。

一个完整示例，以及它花了多少钱

Ashmore Retail：84 家门店、3 个配送中心。该公司在 2 月启动计划，准备在所有三个 DC 中替换仓库管理系统。历时九个月，计划在 11 月中旬上线。启动会的资料中描述为“能轻松领先于高峰期”。

在那次启动会当天，存在两个不可变项。两者都已发布，但都不在计划里。

第一个是变更冻结。零售运营每年 1 月都会发布，并从 11 月 1 日运行到 1 月 15 日，覆盖高峰交易期。在这 11 周内，任何类型的生产变更都不会进入。

第二个是旧合同。它在 12 月 31 日续约，再延长 12 个月，金额为 186,000 英镑，并且需要提前 90 天通知，这使得真正的截止时间变成了 10 月 2 日。

项目在春季期间按计划推进。安全审查用时四周，对应声明的 SLA 为两周。供应商的实施顾问直到 10 月才可用，因为他们在 7 月才被要求介入。两次延期都通过把上线从 11 月中旬推迟到 11 月下旬来吸收，但没人提出警示，因为没人查看冻结日历。

冻结问题在 9 月初的一次变更咨询委员会会议中被发现。11 月无法上线，下一个可行窗口在 1 月 16 日打开。

这让他们必须在 10 月 2 日前做出一个选择：对旧合同发出通知，并从 1 月 1 日开始运行——在整个业务依赖的系统上不提供支持；或者让合同续约，并为一年付费，而他们原本计划在 11 月关闭该系统。

他们选择续约。新系统于 3 月 4 日上线。旧合同在其 52 周期限中被使用了九周，也就是相当于 186,000 英镑账单中的约 32,000 英镑价值。大约 154,000 英镑买到的是什么都没有。

具有启发意义的是：项目从来没有“迟到”，也就是人们通常所说的那种迟到。工作以合理的标准、合理的节奏完成。出问题的是：窗口比任何人画出来的都窄了六周，而定义窗口的两个日期在项目存在之前就已经写在已发布的日历和已签署的合同里。

如果在 2 月就画出约束日历，顺序会显而易见：在 11 月 1 日之前上线，倒推回一场真正为六周的四周安全审查、一条为期六周的采购路径，以及需要提前一个季度通知的顾问——这意味着供应商合同必须在 4 月中旬签署。但他们在 7 月才签。项目并不需要跑得更快；它需要在更早的 11 周前就启动那些不可变的依赖项。

五种 IT 项目形态，以及哪些章节承担关键权重

在这个搜索中，常见的是包含 20 个 IT 项目模板的列表，覆盖从 ITSM 实施到基础设施升级，再到建立 PMO 等所有内容。实际上，它们会归并为五种形态，而形态会告诉你，上面哪些章节值得写得更细。

替换（Replacement）。把正在运行的系统替换为另一个系统。包括 WMS、ERP、ITSM 工具、呼叫中心平台、HR 系统。第 3、9 和 2 章承担关键权重，因为难点在于窗口、切换以及证明旧系统确实已关闭。

实施（Implementation）。没有前任系统的全新内容。包括 SLA 管理、IT 治理与合规项目、资产管理、知识管理。第 11 和 2 章承担关键权重，因为在此之前没有任何东西被“打坏”，所以只有采用（adoption）才能让它真正落地。我们的 数字采用实施指南 会对此讲得更深入。

迁移或原地升级（Migration or upgrade in place）。同一系统，但版本更新、主机更换或区域迁移。包括虚拟化、整合、云迁移、数据库升级。第 8 和 9 章承担关键权重，因为回滚才是整个游戏的核心。

构建（Build）。软件开发与流程自动化。第 4 章承担关键权重，因为范围是会移动的变量，而验收标准则决定了它不会悄悄地继续移动。

项目计划与保障（Programme and assurance）。建立 PMO、IT 审计、组合管理、风险管理、安全合规。第 12 章承担关键权重，因为交付物是证据与签字确认，而不是一个可运行的系统；里程碑则是由其他人设定的评审日期。

如果你的项目无法清晰地归入以上任一类，通常意味着：其实是两个项目被起了同一个名字。

一天内搭建计划

上午：画出不可变项。把这两个问题发给表格中的每位负责人，先追问供应商与安全相关的答案，因为它们的“尾巴”最长；并把你拿到的每一个日期都放到同一个日历里。用一句话写出由此得到的窗口。

下午：写出第 1、2 和 4 章，然后写里程碑。把详细的工作分解留给交付团队在这一周内填写。只要窗口与范围达成一致，计划就立刻有用；而在里面塞进四百行内容并不会让它更有用。

在每次治理会议上，都要用窗口来复核计划。值得只问一个问题的不是“我们进度是否正常”，而是“有没有任何不可变项发生了移动”。冻结会被延长、审计会被重新安排、供应商会失去顾问。这些变化会以一种“延期的任务”从未做到的方式重塑计划。

该删掉什么

每个任务的甘特图不应该出现在计划文件中。它应该放在你用来排程的任何工具里；把它重复到文档中会产生两个在两周内就会互相不一致的版本。

带分值的完整风险登记表也不应该放在这里。保留那些带触发条件与日期的风险，其余的放到登记表里。

关于如何开展工作的详细流程应当放在 IT SOP 中，而你已经搭建了什么的描述应当放在 IT documentation 中，而不是计划里。把交接给运行团队这件事做得足够充分，正是 知识交接 SOP 的用途。

什么时候该停止使用文档，改用软件

在争论计划的阶段，文档是正确的容器——这通常发生在最初的一个月。等到同时满足三件事时，它就不再是正确的容器：上线的任务超过约三十个、超过四个人在更新状态、并且任务之间的依赖关系开始每周变化。

到那时，把工作分解迁移到排程软件中，并保留文档用于第 1 到 5 章以及第 12 章——这些部分会被那些永远不会打开工具的人阅读。文档保存的是一致意见。工具保存的是排程。

把计划变成交付团队真正会遵循的内容

计划会在启动会和指导委员会会议上被阅读。切换运行手册会在凌晨两点被某个不在任何会议现场的人阅读。

Trupeer AI 会把屏幕录制转化为可记录的流程，因此第 9 章中的切换步骤以及第 11 章中的第 1 天任务，会变成对你真实系统的演练，而不是用段落去描述它们。只要把顺序记录一次，你就能在你的 知识库 中获得一步一步的指南、一段视频和一份文档，并且使用你自己的品牌风格。

记录它。给它上品牌。翻译它。用 Trupeer 来实现它。

对于第 11 章中的采用工作，变更管理 和 培训视频 覆盖推广侧；而 文档 会把计划、运行手册和交接材料放在一起。设置说明在 文档模板设置指南 中。

常见问题解答

Excel 里有免费的 IT 项目计划模板吗？

没有以文件形式提供给你，而且这笔交易值得说清楚。Excel 确实是第 6 章工作分解的更好容器，因为日期、依赖项与汇总都属于单元格。你需要自己用列来搭建这张表：任务、负责人、开始、结束、依赖项、状态以及不可变项标记。把第 1 到 5 章、第 9 章和第 12 章保留为文档，因为这些内容需要用文字来讨论，而没有人会在电子表格里协商范围。

有 Word 版本吗，还是可以免费下载 Word 文档？

上面这套十二章节结构是为直接复制到 Word 或 Google Docs 而写的。粘贴标题、保留编号，并按给定顺序填写。没有门槛式下载，这也意味着你和结构之间没有表单。

有 PDF 版本吗？

把章节粘贴到你的编辑器中，在计划达成一致后导出为 PDF。把计划在签字确认时冻结为 PDF 很有价值；在此之前保持可编辑也很有价值，所以在合适的时刻导出你自己的副本，比从一个固定文件开始更好。

启动会用的 PPT 版本有吗？

这套资料是另一份不同用途的文档。通常用六页就够：结果、由你的约束日历确定的交付窗口、范围的纳入与排除、里程碑、已命名的外部依赖项，以及谁来决定什么。不要把工作分解放进资料里。没有人会在投影仪上认真阅读甘特条。

我可以免费下载安装吗？

结构、不可变项表格以及完整示例都是免费的，并且不受限制。使用它们、编辑它们，并以你自己的名义把它们放进你的模板库。

项目交付计划和项目计划是一样的吗？

足够接近，以至于这种区分很少能真正发挥作用。若组织将两者分开，项目计划会覆盖项目的完整生命周期，包括商业案例与收尾；而交付计划只覆盖构建与发布部分。如果你的治理要求两者都要，那么写上面那份计划，并把第 5 到 9 章当作交付计划。

我还需要单独的项目管理报告模板吗？

需要，而且要比你想象的短得多。重复计划的状态报告在一个月内就会被忽略。汇报四件事：有没有任何不可变项发生了移动、窗口是否仍然足够宽、你今天需要这个小组做出什么决策，以及自上次以来风险清单中触发了哪些变化。

IT 项目计划需要写得多详细？

详细到让新加入者能知道接下来会发生什么，并且仅此而已。实践中，对于一个九个月的项目，计划文档大约八到十五页，其中大部分是第 8 和 9 章。如果文档比切换运行手册还长，说明比例不对。

计划应该多久更新一次？

第 6 和 7 章每周都会变化，并且应该放在你们团队已经在使用的工作位置上。第 1 到 5 章应当很少变动，而对它们的每一次修改都需要有人审批。如果你的范围章节每周都在悄悄被编辑，那你并没有计划，你只有一份日记。