大数据项目管理：从规划到实现

数据项目的风险管理

｜

47

3.2.4

　外部团队风险

除了与项目团队相关的风险之外，在与一个或多个外部团队沟通时也存在风险。如果这些

外部团队开发的组件或系统对项目团队至关重要，或者反过来，项目团队的工作对外部团

队至关重要，那么这种风险就尤为明显。如果你的成功直接与另一个团队挂钩，那么就要

保持警觉和尊重。明确责任和需求有助于实现这一目标。此外，在设计需要与外部系统发

生交互的软件时，要清晰地定义接口并将它们文档化。

本章及第

4

章都会详细讨论接口。

3.2.5

　需求风险

在讨论过团队风险和技术风险之后，接下来讨论需求风险。这种风险具有不同的表现形

式。其中一种是定义不明的需求，这意味着后续需要进行调整，而这些调整会引入新的

风险。另一种是团队之前未曾遇到过的需求，例如服务等级协定（

service level agreement

，

SLA

）和延迟指标。

明确地定义功能性需求有助于降低这些风险。如果将功能性需求视为非技术性的合约，就

可以有效地让项目保持在正轨上。本章稍后将讨论其他可用于降低需求风险的方法。

将需求分解为更易于管理的工作块是降低需求风险的另一种方法。举个例子，有个客户向本

书的一位作者展示了一份上百页的系统组件需求文档。这份文档来自一家咨询公司，用来帮

助客户实现解决方案。事实证明，咨询公司的做法失败了。这份需求文档采用的方法有点好

高骛远，导致客户不堪重负，不知道该从哪里着手。尽管文档记录了他们的需求，却仍然无

助于确定切实可行的开发时间表以及需求和任务的优先级。最后，这份文档被弃用了。

在弃用这份需求文档之后 ...