---

在Blue，我们花了很多时间思考项目管理。这对我们所做的事情以及我们交付给客户的成功至关重要。如果没有对项目管理的扎实理解，我们怎么可能构建项目管理软件？

每当我们开始一个新项目，无论是新功能、后端工程升级、市场营销活动还是招聘活动，我们都会先分析项目本身以及它是如何运行的。因此，凭借丰富的经验和见解，我们决定开始正式化一些项目管理的基本原则。

虽然使用更非正式、个人的直觉来导航项目是常见的（且可以接受的），但这显然不是一种可扩展的方法——而且并非没有缺陷。

项目

让我们先定义一下项目。

项目是一个临时的努力，具有明确的开始和结束，以产生独特的产品、服务或结果。这是大多数人对项目的看法。但还有一些其他更正式的项目特性需要考虑：

• 项目有有限的资源（时间、金钱、人员）；
• 项目是为了实现特定目标而进行的；
• 项目有明确的范围（因此有明确的事情是它不会做的）；
• 项目受到不确定性和风险的影响。

现在我们对项目有了更好的理解，我们可以继续讨论基本原则——项目成功所需的核心构建块。这些包括：

• 项目经理；
• 一个目标；
• 一份待完成事项清单——这通常被称为计划；
• 指定某人负责每项任务；
• 每项任务的时间表；
• 一种沟通策略，定期更新和会议的节奏，以及信息存储位置的计划。

我们发现这些内容通常适用于所有项目，如果做得好，可以消除项目中99%的所有问题。

项目经理

项目所需的第一件事是有一个人负责成功完成它。这似乎是一个显而易见的陈述，但值得强调。

这个人就是项目经理。他们负责确保项目目标的实现，并确保项目按时、在预算内并达到所需的质量标准完成。通常，我们中的许多人在没有经过培训的情况下成为事实上的项目经理。如果你是这样的人，那么你很幸运，我们为此写了一本指南！

值得考虑的是项目经理应该做什么和不应该做什么。毕竟，他们承担着很大的责任，必须认真对待这一责任。

项目管理通常会占用项目预算的相当一部分——通常在2%到10%之间，具体取决于项目的风险程度。风险越高，项目管理所需的工作就越多，以确保事情保持在正轨上，项目不会失败。

作为一名经理，项目经理应该专注于如何通过他人实现目标。他们需要确保项目团队有效，并且他们朝着共同目标和谐地合作。项目经理是那个需要确保每个人都在做他们的工作，并且做得好的。

项目经理还负责与项目利益相关者沟通，并及时向他们更新项目进展。

就像我们在领导者的优先级中讨论的那样，项目经理应该始终关注约束点。如果让利益相关者批准某件事情花费了太多时间，那么他们需要高度关注获得这种承诺。他们需要不断问自己：“是什么阻碍我们完成项目目标，如何尽快解决这个问题？”

在某种程度上，项目管理与沟通是同义词。将详细的想法写下来是项目经理的一项宝贵技能，因为这大大减少了所需会议的数量——团队成员可以自助获取所需的信息。

目标

项目的另一个核心构建块是项目需要一个明确且可衡量的目标。一旦项目完成，查看结果并知道项目是否达成了目标或失败应该是微不足道的。

目标应该公布，以便每个团队成员都能访问。这一点很重要，因为这意味着决策可以分散和去中心化，因为每个团队成员可以查看他们工作的小部分，并将其与项目的总体目标联系起来。然后，如果存在不一致，他们可以提出问题，或在项目的小范围内调整他们的方法，以更好地服务于更大的目标。

项目的目标应该是SMART的：

• 具体的。 项目通常有听起来更像使命或愿景声明的高层目标。一个糟糕的目标示例是“改善客户支持”。这不够具体。诸如“我们计划在第四季度结束前在30分钟内回复90%的客户”这样的目标要具体得多。
• 可衡量的。 当你设定具体目标时，通常会同时解决衡量问题，因为这样就容易评估目标是否达成。
• 可实现的。 目标只有在可以实现的情况下才有意义。但这并不是创造简单目标的借口。一个好的目标应该有一定的挑战性——足够具有挑战性以便能够实现，但又不是不可能或极不可能的。
• 相关的。 这听起来可能非常显而易见，但你会惊讶于这种情况发生的频率。项目目标应该能够通过执行项目来实现。你不能设定那些无法由执行具体项目工作的项目团队控制的目标。例如，在一家公司的制造部门工作的团队可能无法影响客户的店内购物体验。
• 有时间限制的。 好的目标需要附加某种时间限制。这可能很困难，尤其是在现代软件项目中，待完成的工作并不总是明确的，因此时间表可能非常难以估计。有时你可能会偏差很大，这并不是任何人的具体过错。尽管如此，设定时间表可以确保项目的整体范围保持在某些界限内。如果你有一个月的时间来解决一个问题，而不是一年，你会提出非常不同的解决方案。

目标必须反复向所有团队成员传达：他们应该（比喻地）厌倦项目经理不断讨论目标。一些实时（或尽可能接近实时）的仪表板跟踪进展也可以确保每个人都朝着目标对齐，并知道项目的进展情况。

待完成事项清单

我们强烈建议将计划称为“待完成事项清单”，因为这使规划过程不再神秘。

计划通常是猜测，但它们仍然是有价值的。这是因为规划过程本身有助于阐明我们知道什么以及我们尚不知道什么。

不计划就计划失败。

计划的本质是获取从项目开始到成功完成的所有步骤的详细清单。一些行动将需要先前步骤的完成，因此你可能会得到一系列相互关联的任务，通常称为依赖关系。其他行动可以并行进行，并且不会相互阻塞。

项目经理应该始终关注阻碍其他行动的最重要的行动，因为这定义了项目的关键路径。也就是说，项目可以完成的最短时间，如果所有依赖关系都排成一行。

从项目的两端进行计划工作可以极大地帮助建立有效的计划。这意味着你从开始到结束，但你也从结束开始，向后工作以了解完成项目和实现目标所需的内容。

这个反向规划过程的最后部分通常会揭示遗漏的任务。

但是，规划过程并未完成，直到我们了解每个任务的责任人以及每个任务完成所需的时间。

这些点应该同时涵盖，因为它们是紧密相关的。你不能在不涉及了解该任务具体情况的专家的情况下创建工作估算，即使如此，你仍然需要关注你的资源。个人很少能够有效地同时处理多项任务，因此你需要了解项目计划是否可能存在瓶颈。这是指一个人无法完成所有分配的任务，因为他们根本没有足够的时间。

指定某人负责每项任务

项目中的每个任务都需要有一个特定的个人负责完成该任务。如果你发现需要多个人负责同一任务，通常是因为你没有将任务细分到足够的层次。

例如，在许多行业中，会有设计和建造阶段；这可能是在制造、建筑甚至软件中。你应该将其细分，以便可以分配设计师的具体任务和建造者的具体任务。你会发现这两个学科之间通常会有反复的交流，这一点你可以考虑进去。一个示例可能如下所示：

1. 设计阶段1由设计师完成
2. 可行性检查1由建造者完成
3. 设计阶段2由设计师完成
4. 可行性检查2由建造者完成
5. 高级利益相关者审核
6. 设计最终确定由设计师完成
7. 建造者进行最终检查
8. 利益相关者批准

这显示了不同参与方之间的现实上下波动，而不是将“设计阶段”单独分配给设计团队直到设计阶段完成。

每项任务的时间表

这可能是创建计划中最具挑战性的部分——我们如何测量每项任务将花费多长时间？如前所述，时间表不应自上而下，而应自下而上。这意味着每个项目由将要执行工作的人员（或至少是一个了解情况的同事）进行估算，并将所有这些估算加总并计算成一个整体时间表。

也就是说，在进行详细估算之前，拥有一个整体的高层时间表是有帮助的，因为估算某件事情需要多长时间和决定解决任务的具体方法本质上是相同的。

因此，如果一个项目有宽松的高层时间表，那么各个专家可以将其纳入他们的估算中，并尝试优化长期解决方案，而不是为了确保时间表的达成而走捷径。如果项目的时间表紧迫，那么每个专家都知道他们可能需要做出权衡。

在创建项目计划时，常常被忽视的一件事是，利益相关者需要审查进展并确认需要考虑的决策。最好的方法是查看以前的项目，这些项目包括相同的利益相关者，并了解他们提供反馈的典型周转时间。

这里的另一个危险是，如果与关键利益相关者的月度指导委员会会议中，某个项目交付物无法及时提交，那么会发生什么？项目会暂停到下个月利益相关者再次会面，还是会在月度指导委员会之间处理并批准（或反馈）？

沟通策略

当出现这样的情况时，它们确认了项目内沟通方式的重要性。

通常，问题不是策略不好，而是根本没有策略。因此，沟通渠道以非正式和临时的方式开放，“足够好”成为标准。

这样做的问题在于事情并不总是按计划进行。人员变动，知识丢失，随着项目规模的扩大，越来越多的人加入，沟通开销可能迅速膨胀。

因此，显然，工具本身并不是那么重要；事实是，当你超过一个非琐碎人数（比如10人）时，团队合作变得越来越困难。

这是因为团队沟通并不会随着团队人数的增加而线性扩展。

例如，如果你有一个2人的团队，那么就有一个沟通线程（在这两个人之间）。再加入一个人；现在你有三个沟通线程。因此，尽管团队规模增加了50%，但沟通线程却增加了300%。

让我们看看这个增长的情况：

• 2名团队成员 = 1个沟通线程
• 3名团队成员 = 3个沟通线程
• 5名团队成员 = 10个沟通线程
• 8名团队成员 = 28个沟通线程
• 10名团队成员 = 45个沟通线程
• 15名团队成员 = 105个沟通线程
• 20名团队成员 = 190个沟通线程
• 30名团队成员 = 435个沟通线程
• 50名团队成员 = 1,225个沟通线程
• 100名团队成员 = 4,950个沟通线程

这可以用以下公式表示：

n(n-1)/2

其中 n 是需要参与项目的人数。

如你所见，随着团队规模的增加，这个数字呈指数增长。如果你有一个10人的团队，需要管理45个潜在的沟通线程。但如果你有一个50人的团队，则有1,225个潜在的沟通线程——这多了27倍！如果你有一个100人的团队，则有4,950个可能的沟通线程——这多了110倍！

值得注意的是，这不仅是大团队的问题，而是任何团队中个体不在同一地点的问题。这是因为可能的沟通线程数量并不受团队成员的物理接近程度的限制。

例如，你有一个10人的团队，但他们都位于世界的不同地方。在这种情况下，仍然有45个潜在的沟通线程需要管理——即使团队成员并不在物理上接近。

而且情况可能更糟。上述计算假设只有一种沟通方式。如果我们想考虑不同的沟通方式，我们将不得不以以下方式重写公式：

n(n-1)/2

其中 n 是沟通渠道的数量。

让我们重新计算上述沟通线程的数量，但这次假设 n 包含：

• 电子邮件
• 群聊
• 个人聊天
• 项目管理系统中的评论
• 电话
• 文档中的笔记/评论

将数字代入，我们得到：

• 2名团队成员 = 6个沟通线程
• 3名团队成员 = 18个沟通线程
• 5名团队成员 = 60个沟通线程
• 8名团队成员 = 168个沟通线程
• 10名团队成员 = 270个沟通线程
• 15名团队成员 = 630个沟通线程
• 20名团队成员 = 1,140个沟通线程
• 30名团队成员 = 2,610个沟通线程
• 50名团队成员 = 7,350个沟通线程
• 100名团队成员 = 29,700个沟通线程

沟通线程数量增长的速度令人担忧——如果远程工作更容易实现那些在现实生活中不切实际的大型会议，那么这就是一把双刃剑。

因此，简而言之，制定策略对于避免即使是相对较少的团队成员也可能发生的沟通爆炸至关重要。

虽然“沟通策略”的概念听起来复杂而宏伟，但并不一定如此。关键是设定一些原则，明确主要沟通渠道，并可能告诉人们不该做什么。

一些基本原则需要考虑：

• 保持信息开放。 假设所有信息在几个月/几年后都需要易于查找和共享。确保项目团队中的每个人都能访问所有所需信息，并注意以此为基础命名文件和文档。
• 倾向于清晰。 想象一下，有新成员加入项目团队。清晰简洁地记录信息，以确保他们能够轻松理解关键决策。
• 保持会议记录。 确保所有重要会议都有记录，并且易于查找。

在沟通渠道方面，越少越好。我们建议将其减少到以下几项：

• 项目管理软件用于进行任务特定的讨论。
• 会议（面对面或远程）有会议记录和一个地方可以找到所有项目会议记录。
• 文档：这可以是Google Docs中的评论和讨论，或允许评论的特定工具（即Figma用于UX设计）。

将group chat添加到此列表也是可以接受的——但必须小心管理，因为它可能变成一个没有明确目标或议程的巨大全天（和每天！）会议。

项目经理需要明确设定这些规则，并成为如何协作的榜样，同时偶尔使用“棍子”（比喻，不是字面意义上的！）来促使项目团队成员正确沟通。

最后思考

无论一个人的专业水平如何，退一步从基础层面看待一个主题或过程总是有价值的。因此，在深入探讨项目管理主题时，我们识别出了成功执行项目所需的关键基本原则。

每个项目都应该有一个项目经理：他们确保项目有明确的目标，这些目标被分解为完成最终目标所需的任务。项目经理接着需要为每个任务分配一名团队成员。团队可以共同确定每个待办事项和整个项目的时间表。

通常，似乎理所当然的事情可能会引发问题，而不是那些往往受到更多关注的高级主题——例如沟通。这就是为什么在项目团队内部和外部与利益相关者之间应该有一个明确的沟通策略。

项目管理是一个复杂的主题，因此这绝不是一个详尽的指南。仍然有一些我们在这个初步概述中没有涵盖的因素需要考虑，例如预算、解决选项之间冲突的方法，以及在项目中委派的程度。