接管“疯人院”

引言

这并不是一篇真正意义上针对项目经理这个想法的檄文，而是探讨可以通过哪些自动化工具、方法论和文化实践的改变，使得软件团队能够在没有人工监督的情况下运作，或者至少是仅以一名团队成员的次要职责来承担监督职能。

请注意，这仅适用于您处理的是**内部**软件开发团队的情况，因为外包/合同制运营涉及两个目标不同的方¹。

背景

如果您在 Google（或 Bing）上搜索“项目经理做什么？”，在浏览了大约前三页的抱怨和博客文章链接后，您会发现以下基本轮廓

典型职责包括

• 商定项目目标
• 代表客户或组织的利益
• 提供项目管理方面的建议
• 组织参与项目的各种专业人士
• 确保质量标准得到满足
• 使用 IT 系统跟踪人员和进度
• 监督会计、成本和账单

这是一个相当长的列表，但通过逐一审视，我想提出一些自动化或消除这些职责的方法。

1. 商定项目目标

需要有人规划并商定项目目标，通常还需要一个已签署且不可更改的规范，这是过去遗留下来的做法。在那个时代，项目的付费方对什么可能实现以及成本如何没有现实的概念。项目目标会规划出一系列可在可用预算内实现的现实目标。

然而，在大多数行业，尤其是在拥有内部软件开发职能的公司中，客户/利益相关者拥有丰富的过往项目经验和行业信息，可以自行确定什么可行以及应投入多少预算。事实上，很多情况下，他们已经在任何开发团队或项目经理参与之前，就已经制定了成本效益分析，甚至向高层管理人员提出了项目建议。

因此，项目目标应在项目成为“软件项目”之前就达成一致。

2. 代表客户或组织的利益

如果一个项目是由业务部门和开发团队共同向高层管理人员提出的，那么业务部门和开发团队的利益将大致一致，这降低了需要有人代表组织利益的需求。

为了确保项目目标与业务之间的这种持续一致性，需要重新思考项目的融资方式。企业不应在开始时就商定一个端到端的总预算，而应提供一笔足够的“启动资金”预算，以支持第一个版本上线生产，后续的资金将根据项目的实际收益而定。这种达尔文式的项目管理方法也能确保最成功的项目获得所需的预算，并在小规模的失败演变成大规模的失败之前将其扼杀。

3. 提供项目管理方面的建议

在这个角色中，项目经理是业务部门和开发团队之间的边界或接口。他们提供状态更新和可交付成果的预测，并确保业务部门随时了解项目的进展。通常，这涉及到收集团队关于已关闭缺陷、已实现功能以及预计完成时间的信息，并将这些信息以幻灯片演示文稿或仪表板的形式呈现，供定期审查。

有大量的工具可以提供这种“幻灯片演示文稿”的实时视图，并将其公开，以便业务部门可以随时跟踪项目——其中最流行的有 JIRA 和 Team Foundation Server。使用燃尽图和看板视图也可以比任何团队成员的民意调查提供更真实的进度和完成时间估计，最重要的是，这些都可以在不干扰开发工作本身的情况下完成。

4. 组织参与项目的各种专业人士

这与上一条有关。真正“专业”的人员应该有自律能力，当一个团队运作良好时，团队内部的动态会将团队的每一位成员都引导到正确的轨道上。

当一切都在公开透明的环境中进行时（通过公开燃尽图、质量指标和看板），所需的外部组织工作量就会完全消失。

5. 确保质量标准得到满足

在此标题下，有两个不同类别的质量标准：代码质量和应用程序测试状态。

代码质量是指确保源代码本身易于理解和维护，并遵循“最佳实践”指南。这种最佳实践的具体细节因语言而异（何时释放对象、变量的作用域），也因团队而异（命名约定、将代码元素映射到源代码文件等）。

应用程序测试状态是指确保所有进入生产环境的代码都经过测试。这从最低层次的开发人员为其代码编写单元测试，一直到最高层次的用户验收测试。

同样，这也是一个已经开发了许多软件工具的领域。

6. 使用 IT 系统跟踪人员和进度

这在第 3、4 和 5 条中已经讨论过。关键信息是“发布的仪表板”。

7. 监督会计、成本和账单

如果项目采用“启动资金 + 回报价值百分比”的模式进行融资，那么降低成本将成为项目团队关注的重点，同时，业务部门也内置了防范成本超支和“僵尸项目”的保护机制。

历史

• 2015年9月23日 - 初步想法

脚注

¹ 是的——它们确实不同。这就是为什么会有合同，以及为什么资金会附带条件地转移。