全文共4276字，预计学习时长13分钟

来源：Pexels

并不是所有问题都有深刻且明确的解答，数据科学界特别如此。

讨论数据科学家应该具备的辅助技能时，项目管理是常常被提及的软技能加分项。但是很少有关于如何将项目管理技能应用于数据科学的专门教程，相关的建议往往也很浅显。

无论任何时候提及这个问题，标准答案总是“只要去阅读已有的项目管理资源”。

笔者曾在一个牵涉几百万美元的公司级项目中担任项目经理，可以告诉你一些经验之谈。项目管理并非制定计划并逐一划去计划表上的事项。亲身参与过数据科学项目就会知道，由于难以预见的情况，计划常常不能如期完成。事情总比想象中耗时更久，种种问题也会不期而至。事实上，Daniel Kahnerman和Amos Tversky创造了“计划错觉”这个词，用以形容人们低估完成任务所需时间的倾向。

项目管理希望解决人类交付的不可靠性。这就是为什么笔者希望给出基于有效项目管理技巧的可行建议，而不是一系列昂贵的工具软件，或者一个讨论CRISP-DM流程每一步用时的粗略大纲。

为什么要使用项目管理工具？

项目管理者用于监督和报告项目进度的工具种类繁多，这些工具看起来似乎只是增加了工作量，使得项目经理的薪酬更加合理，但事实并非如此！使用这些工具，不仅可以维持和高级管理层的沟通，也能帮助项目经理和其他项目参与者记录假设和项目依赖关系。

灵活软件开发宣言提到，应该总是重视人和交流多于过程和工具。相应地，在数据科学项目中，应该重视解决商业问题多于夸夸其谈。尽管你可以论证项目管理工具并非必需，但它们将对系统性地解决和思考问题产生令人惊讶的助益。

正如灵活软件开发宣言所述，这些工具的使用和规范应该视项目规模而定。所以，如果你只是在为丰富简历而进行一个周末即可完成的数据科学项目，就没有必要设计一个花哨的甘特图。但是如果要在搭建项目的过程中时时牢记假设，建立一个RAID日志（包含风险，假设，问题，依赖惯性）可能很有必要。即使在项目结束之后，它也将帮助你在几个月或几年后验证自己的假设。在接下来的阅读过程中，牢记可以，也应当按照需求来选择工具。

数据科学项目管理的工具种类

来源：Pexels

你的项目管理工具包中有什么？

1. 有条理地思考问题：RAID日志——RAID即风险，假设，问题和依赖关系。提到项目管理工具，第一个想到的可能不是RAID日志，但笔者认为它们是最重要的。无论项目大小，笔者都建议创建一个RAID日志。无论处理什么问题，都需要假设来构想解决方案。在收集数据时，可能会遭遇扰乱计划的风险。在列出所需步骤时，依赖关系有助于安排步骤的执行顺序。将这些内容记录下来，就是全面了解项目而不致对其毫无头绪的关键。

2. 理清待办事项——WBS工作分解结构。这其实就是待办事项清单的时髦说法。数据科学过程框架——比如CRISP-DM，KDD和OSEMN——总结了数据科学项目中的步骤，然而将这些框架应用于具体问题非常重要。比如，在OSEMN框架（获取，清洗，探索，建模和解读）中，需要执行什么样的清洗工作？计划使用的是哪一个模型，如果这个模型无法工作，备选项又是什么？如果是在进行团队合作，WBS甚至能帮助你将任务分配到个人。

3. 规划每个任务或阶段的顺序和时长：甘特图——甘特图结合了RAID日志中的依赖关系和WBS中的任务，有助于计划任务的时间和顺序。它可以相当详细（和WBS上的每个任务相对应），也可以十分简略，仅仅与高级过程相对应。高级甘特图通常被称为“路线图”，它是与高级管理层沟通的最佳方式之一。

RAID日志

创建RAID日志是反映商业问题，并评估数据科学问题能否解决商业问题的方法，它也能帮助保持与其他项目参与者之间的联系以解决问题。

假设表格的示例。在techno-pm.com发现更多示例和模板。

考虑业务问题

笔者建议在了解商业问题后首先记录项目的风险，假设和依赖项，尝试将商业问题转变为数据科学问题，然后考虑如何解决。这自然会导致问题和假设的提出，可以记录这些问题并回顾。

假设

假设通常是一些不言自明的事情，它使人产生一个项目比事实上更加容易的错觉。假设可能关于多个方面，包括：

1. 数据：数据科学家常常在此马失前蹄——特别是考虑到数据清洗通常占数据科学家工作量的80％。可能会对数据做出的假设包括：期望的数据格式，数据有哪些有用的特征，数据是否具有普遍性，某些特征是否能用于代表另一特征等。

2. 模型：所有模型都有各自的假设。例如，K-Means聚类假设聚类内的方差本质上是球形的，并且聚类的大小相同。没有空值是另一个可能的必须条件，这可能要求在WBS中加入一步估算。记录下这些假设和违反假设之处对于确保完全理解模型的利弊十分重要（并在WBS中记录满足假设所需的必要步骤）。

3. 工作流或数据流水线：尽管倾向于不考虑模型部署后的变化，但是如果将来发生变化，那么记录有关工作流的假设就非常重要。例如，最初可能假设地理位置只能分为市或州，但是将来数据流水线可能会更改为获取经纬度，并导致生产模型的调整。

依赖关系

依赖关系可能是数据科学项目遵循的自然顺序，例如在尝试建模之前先完成数据清洗。依赖关系还可以表明某些团队需要交付给其他团队的成果，例如数据工程师向数据分析师或机器学习团队提供的干净数据文件。通过记录依赖关系可以了解某个项目延迟的原因，而不是将其简单归咎于最后一个经手该项目的团队。

风险

风险可能难以区分，并且常常与其他RAID日志项混淆。假设和依赖关系有助于了解风险所在。风险通常是实际问题的征兆（实际上，如果意识到了风险，可以用一个新的问题来代替它）。

问题

仅在项目开始后才需要记录问题。那么为什么要这样做呢？项目管理不仅涉及项目规划，还涉及后续的管理和文档记录。当下看来似乎是在浪费时间，但是像任何好的做法（代码中的* ahem *注释）一样，将来它会带来回报。了解过往项目中遇到的问题（尤其是对于不经常更改数据基础结构的公司），可能有助于防止低估潜在的工作量，准确地估计项目时间轴和效益！

项目参与者之间的联系

最佳做法是让不同参与者定期在RAID日志上签名。如果这看起来过于繁琐，检查所有的新项目或更改就可以使所有参与者了解情况并承担责任。这样IT和商业利益相关者可以轻松确认假设或风险，他们的意见将帮助你保持正确的前进方向。

工作分解结构（WBS）

一个包含项目时长预期的WBS示例。在pmwares.com可以找到更多使用微软产品创建WBS的信息。

WBS把项目从主要交付内容分解为越来越小的部分，直至各个任务级别。列出各个子任务有很多好处：

思考您需要做什么

由于对解决实际问题的过度热心，任务可能被低估，导致为其分配的时间不足。或者，更糟糕的是，简单但不可或缺的步骤可能被跳过（检查和估算缺失值！标准化数值特征！一键编码类型变量！），模型结果表明的基本特征转换问题可能被忽略。通过强迫自己将高级数据科学项目的各个阶段分解为一个个子任务，就可以形成标准且可重用的方法。

这一做法最大的优点是，WBS可以在将来的项目中反复重用。又遇到一个可以使用聚类解决的问题？只需找出上一个聚类项目中已经列好了步骤和事项的WBS！

估计每一步的时长

WBS是计算项目所需用时的好办法。每个任务已经列出，添加耗时估算就变得十分简单。与估计高级别任务的时间线（例如，数据清洗需要2天）不同，如果发现一项任务非必需或者违反了模型的假设，这表明该任务不太适合您的数据，并且可以立即确定节省的时间。

由于人们不擅长估算事情需要花费的时间，借鉴历史记录是一个好办法。如果在过去的项目中曾经记录过每个任务的实际耗时，则可以更好地预测未来项目的时间。

识别依赖关系

尽管某些任务之间的依赖关系很明显（如在使用机器学习模型处理特征之前需要先估算空值），但还有其他更微妙的依赖关系。尤其是数据科学过程可以在特征工程和建模步骤中迭代时，仔细考虑任务之间的依赖关系有助于高效地规划模型流水线。

例如，可能想对刚刚经过标准化处理的特征使用线性回归模型，然后再回头看看各种变换如何影响模型结果。因此，尽管两次迭代可能都依赖于线性回归，但可能仅需对第二次迭代应用对数转换。记录任务的顺序和任务间依赖关系有助于创建可重复使用的干净流水线。

甘特图

甘特图是获取WBS并将其直观表示的一种方法。通常，任务沿竖直轴列出，时间沿水平轴延伸，每个水平横条显示一个任务的时间跨度。任务也可以分为工作流组，特别是在项目规模较大且涉及跨组织的多个职能部门的情况下。

一个高级甘特图，也可称为“路线图”。图片来源：如何在powerpoint中创建甘特图

确定时间跨度级别

如果是独自完成项目，可以跳过下面这个项目管理工具。但是如果是在团队合作中，笔者认为高级“路线图”非常有用。笔者认为，视觉学习者比人们想象的更多。或者至少，当事情以图片形式呈现能使人们更快地理解。这就是为什么像路线图这样显示项目进展情况的图表（尤其是在长期项目中）可以缓解高级管理层的担忧并保持他们的投资。

牵涉大型组织中多个团队的项目适于在较低的任务级别创建甘特图。不过这种情况下通常会有专门的项目经理负责监督和管理项目。