全文共3996字，预计学习时长12分钟

来源：Pexels

对于外行来说，“Jira”是一个项目管理工具，在科技公司之外几乎无处不在。

它最初是为了管理软件开发项目而构建的，自然会被重新应用到数据科学项目中。

尽管Jira可能是一个很好的工具，但数据科学项目是不同的！

数据科学项目和建筑项目是不同的

管理数据科学项目会引起许多激烈的讨论（对于乐观主义者而言）或大量的争论（对于悲观主义者而言）[1]。

一方面，由于数据科学家通常在技术部门工作，因此应该像管理专业的软件开发人员一样管理他们，这是默认的情况。另一方面，有一种观点认为，因为数据科学家通常都有研究背景，所以应该像对待研究人员一样对待他们，并应赋予他们“创造”的自由。

这两种管理方式都不合适。

然而，后一种方式在管理类型上风险更大:给这些数据科学家自由，他们就会感到无关紧要，根本不做任何事情。所以本文着重讨论前一种方式的错误之处。

为什么数据科学家如此抵制软件开发人员和管理人员认为理所当然的流程呢？

首先，笔者是某种项目管理的忠实信徒。正如管弦乐队需要一个指挥[2]，一个团队也需要一个可以进行协调的人。问题是，对于如何称呼这些人，并没有达成广泛的一致意见。在微软，他们都被称为Program Managers（程序经理）。其他地方会称他们为Project Managers（项目经理）。有的产品经理也负责这方面的事务，甚至商业分析师也做过类似的工作。

面对这些困惑，有些公司（在这里不会说出具体的名字）只需每个职位雇一个人，并希望他们自己能弄清楚谁为自己做了什么。这可能会导致关于不同角色之间差异的恶意争论。此外，这也取决于思考者还是试探者的定位[3]，在这样的团队中，一个产品经理，一个程序经理，一个业务分析师和一个项目经理都在管理两个可怜的数据科学家，这个景象又滑稽又悲惨。现在能责怪那两位数据科学家对四位经理创建的流程产生抵触情绪吗？毕竟，有谁在真正地工作呢 [4]？

所以也许数据科学家对流程不满可能预示着流程的崩溃，而不是数据科学家的崩溃。

现在，本文中把所有负责协调角色的人统称为“PM”。如果一名数据科学家不确定PM是指谁，就可以认为他们就是团队的乐队指挥，即他们站在最前面，挥舞着手臂，做着奇怪的表情。

无论如何，在任何项目中，一个PM必须呈现任务进度。数据科学很复杂。所以，也许只是给团队成员分配任务，然后把燃尽图放在一起，显示完成了多少任务。甚至可以制作图表显示谁做了什么！高级管理人员很吃那一套。这是一个很棒的工具，它让所有这些事情变得非常非常容易，所以就用它吧…

那么就用Jira吧。

现在，Jira做得很好，并没有出现错误。然而，有一种思维模式认为，“我们正在完成任务，也就是说我们正在交付任务”。这是错误的。Jira鼓励这种思维方式，因为它把世界组织成了需要勾选完成的任务。

来研究一下完成任务和交付有用的东西之间的区别。乍一看可能有悖常理。当然，项目管理的一个基本原则就是，把一件大事，分解成许多可预测的小事，然后通过这些小事来完成。换句话说，把大事分解成任务，然后把这些任务一个一个地完成。有一个很好理解，政府批准的系统来做这件事，叫做Prince2（关于敏捷，稍后讨论）。大量的人因为在这个Prince2系统中拥有各种花哨的发声资格而欢欣鼓舞。如果在建一座摩天大楼时用这个系统，那么它就能用在伦敦奥运会上了，对吧？

于是问题就变成了:数据科学项目就像摩天大楼项目吗？

当然不是，接下来会进行解释。

来源：Pexels

目的不是手段

第一个区别是最终目标。摩天大楼项目的目标是建造一个人工制品。使用这些人工制品就是商业目标，即出租办公室、酒店、公寓、或任何一样被层层令人眼花缭乱的金融骗局抽象化的东西。这些骗局一直延伸到提供养老金的基金。别想每一层都能分到多少钱了。

跑题了。

关键是，作为一个卑微的工程师，可以继续建造这座该死的摩天大楼，而不必太担心商业方面。

作为一个卑微的数据科学家，就没有这种好事了。工作不是建立一个人工制品，而是改变一个正在进行的业务流程，使之变得更好。举一个具体的例子：工作不是建立一个预测订阅流失的模型，而是减少实际的订阅流失。一个预测模型可能有用，也可能没用。耸耸肩说“我只是做了个模型，因为你就是这么说的”，是没有用的。

要改进这个业务流程，从哪里开始，什么能改变这些数字的走向？数据科学家可能会想出一大堆东西。提醒邮件？个性化推荐？产品折扣？

此时，作为一名数据科学家，会注意到两件事。首先，数据科学在想做的事情中只占很小的一部分，所以最好和其他人一起合作。其次，数据科学家根本不知道什么有用，什么没用。

不确定性无处不在

这里来谈谈数据科学项目和摩天大楼之间的第二个区别。摩天大楼是在一个基本可以预测的环境中建造的，使用基本可以预测的材料，根据基本上固定的设计。在这里，把这些基本可以预测的结果分解成基本可以预测的子任务，然后通过自己的方式来完成它们是完全合理的。

在许多数据科学项目中，这些都不适用。环境总是在变化，因为高级管理人员似乎在不断改变他们的想法。数据科学家的材料相当于他们所使用的技术，基本上不可能预先预测哪些有用哪些不有用。不知道哪一个产品的特性会带来哪些不同。提醒邮件？推送文章？打折？所以想出一个固定的设计是不可能的，因为谁知道客户会有什么反应呢？

能做的只有实验，尽可能快地实验。然后使用实验的结果来决定下一步要做什么实验，然后收集下一组结果，依此类推。换句话说，需要迭代。

因此，不要嫌啰嗦。

现在，因为MVP (Model-View-Presenter) 运动规则，所有人都只有口头功夫，而不真正去迭代。然而，一个公司的工作中很少充分考虑到这些影响。如果这样做，一旦完成了第一个任务，将不得不根据发现的任何东西改变下面的任务。

换言之，计划将失效。

现在，列出一个要做的事情的清单，可能会是一点安慰。然而，不应该自欺欺人地认为这个清单与最终要做的事情有任何关系。如果上面的内容与最终要做的事情无关，那就再想想这一点。

这就是Jira思维的问题所在。如果按照预期使用这个工具，将要一直去删除、更改、去除某些标签的优先权——仅仅是因为任务总是会根据学到的东西而改变。问题不在于Jira本身，而在于一种想法，即人们能在一个可被列成任务清单的可预测的世界中进行操作。

但是敏捷（agile）是关于迭代的。而且Jira就是敏捷，所以错了！

不是这样的。

敏捷（Agile，大写A）软件开发的12条原则是非常棒的。这是笔者反复提及的。而且，它们表达得很委婉，没有进行总结。点击此处进行了解[5]。

印象不错吧？好吧，敏捷（Agile，大写A）的流程并没有敏捷宣言本身那么棒。事实上，敏捷宣言的一位作者已经否认了敏捷流程。因此，从现在开始，笔者将使用agile（小a）这个词来指代与敏捷宣言一致的流程，而Agile（大A）则指代公司推给数据科学家完成的各种流程。

这些流程是什么？它们可能很复杂，令人费解，涉及到文学故事、史诗、仪式和尖峰辐射的术语。然而，尽管意图可能不同，笔者最终只看到过敏捷（Agile）被做为需要打勾的任务的集合。这就是“Jira思维”，它更接近Prince2，而不是敏捷宣言。

那么数据科学项目应该如何管理呢？

来源：Pexels

这才是本文的主题！这里有一个简短的列表，供数据科学的PM们思考:

1. PM的工作很大一部分是把不确定的部分“拿出来”，并确保项目团队有一个明确的目标要交付。99%的时间应该用来处理一个数字。

2. 一旦确定了这一数字，项目就必须有时间限制。这并不是说过了一段时间就会停止，更像是“我们在这个日期会举行一次大型会议，在会议上必须展现数字的改善”。然后就不得不紧张起来，因为一开始似乎什么都没发生，然后看着人们在最后期限到来时熬夜工作，显然，与创造性思维有关。

3. 计划虽无用，但有必要。必须对事情可能会迭代到哪里进行一些最佳猜测。好吧，不确定会发生什么，但是会考虑发邮件吗？那么最好提前和CRM（客户关系管理）团队谈谈。

4. 大概就这些。如果自己鞭策别人去完成任务，那就说明出了严重的问题。

最后，本文对项目经理有些刻薄。他们很容易成为攻击的对象，而且数据科学在这方面没什么经验。接下来将回到数据科学家和项目经理未来应如何合作的问题上。现在来谈谈项目经理的两种类型。有些人并不真正了解目前的情况，他们试图将所有的事情都生搬硬套到他们所学过的项目管理方法中。这些人基本上是一个项目的净负值，企业无法承受净负值。

另一种在科技公司中很常见，但在科技公司之外可能更少见，他们基本上都是价值不菲的。如果公司中碰巧有一个，也许应该考虑如何不惜一切代价留住他们！

注释：

[1] 例子参阅O’Reilly的 敏捷数据科学2.0。

[2] 每条规则都有例外。参考Persimfans 乐团。

[3] “我经常说，而且经常认为，这个世界对思考的人来说是喜剧，对感受的人来说是悲剧——这是为什么德谟克利特笑而赫拉克利特哭。”——霍勒斯·沃波尔，《写给霍勒斯·曼爵士的信（1769年12月31日）》

[4] 参阅David Graeber的B******t Jobs。

[5] 可见敏捷宣言早期的辉煌。

留言点赞关注

我们一起分享AI学习与发展的干货

如转载，请后台留言，遵守转载规范