数据科学项目和建设性项目是不同的
对于外行来说，「Jira」只是一个项目管理工具，在科技公司中几乎无处不在。它最初是为管理软件开发项目而构建的，后来自然而然地被应用到数据科学项目中。我想说，尽管 Jira 可能是一个很好的工具，但数据科学项目是特别的！
管理数据科学项目会引起大量热烈的讨论或大量的争论。一方面，默认的立场是，由于数据科学家通常都在技术部门工作，因此他们应该像专业的软件开发人员一样进行管理。另一方面，有一种观点认为，由于数据科学家通常有研究背景，他们应该被当作研究人员对待，并给予自由支配权「以便保持创造力」。
这两种方法都不完全管用。然而，后一种方法的风险对于前者来说更为明显：你让这些数据科学家自我管理，他们可能会变得自由散漫，根本不做任何事情。所以我想把这周的帖子花在前一种方法的讨论上：为什么数据科学家如此抗拒软件开发人员和管理人员认为理所当然的管理方式？
首先，我应该声明我是项目管理的忠实信徒。正如管弦乐队需要指挥一样，一个团队也需要一个具有协调能力的人。一个问题是，人们对如何称呼他们没有达成广泛的共识。在微软，这些人都被称为程序经理，在其他地方他们被称为项目经理。我还见过产品经理甚至是商业分析师扮演这个角色。
面对这些困惑，有些公司只需雇佣其中一种角色，希望他们能找出每个人做了什么。这可能导致关于角色之间差异的争论。另外，我看到了一个滑稽的场景：一个团队有产品经理、程序经理、业务分析师和项目经理，他们都在管理两个糟糕的数据科学家。在这种情况下，我们是否可以责怪这两位数据科学家对四位管理者创建的流程产生了抵触？毕竟，真正工作人是谁？
因此，也许数据科学家对流程的不满的原因是流程被破坏，而不是数据科学家被毁掉了。
无论如何，在任何项目中，项目经理都必须展示进度。数据科学的东西很复杂。所以，也许我们只是分配任务，然后汇总显示完成了多少任务的图表。我们甚至可以制作图表显示谁做了什么！高级管理层想看到的就是这些。
这里用到了 Jira。
现在，Jira 做得很好，这没什么问题。然而，世界上有一种心态是「我们在完成任务，因此我们在交付」。这是错误的。真的，这真的错了。Jira 鼓励这种心态，因为它把事情分解成了一个个需要勾选的任务。
让我们来分析一下在完成任务和交付有用的东西之间的区别。乍一看这可能有悖常理。当然，项目管理的一个基本原则是，你把一件大事，分解成许多可预见的小事，然后通过完成这些小事来完成整个项目。换言之，你把你的项目分成若干个任务，然后逐一勾选这些任务。甚至还有一个很好理解的、政府批准的系统来实现这一点，叫做 Prince2。在 Prince2 系统中，许多人都为拥有各种听起来很花哨的功能而高兴。天哪，如果我在建摩天大楼，我会用这个系统，比如为伦敦奥运会做准备工作，对吧？
所以，现在问题变成了：数据科学项目是否和构建摩天大楼一样？
不不不，它们并不一样。
目的不是手段
第一个区别是最终目标。摩天大楼工程的目标是建造一件艺术品。利用这件艺术品的商业目标，即出租办公室、酒店、公寓等等，反正它们会为你赚很多钱。你可以把每一层楼都想象成你口袋里的钱就够了。
我离题了。
关键是，作为一个谦虚的工程师，你可以继续建造这座该死的摩天大楼，而不用太担心商业方面的事情。
然而，数据科学家并非如此。你的工作不是建立一个作品就万事大吉，而是为了更好地改善一个正在进行的业务流程。让我举一个具体的例子：你的工作不是建立一个预测订阅流失的模型，而是能在实际上减少订阅流失。预测模型可能有用，也可能没有用。你耸耸肩说，「我只是做了一个模型，这是你让我这么做的」是没有用的。
所以，你要改进这个业务流程。你从哪里开始？目标数据是多少？好吧，你可能会想到很多事情。邮件提醒？个性化推荐？产品折扣？
在这一点上，作为一个数据科学家，你注意到两件事。首先，数据科学研究只是你工作的一小部分，所以你最好和其他人一起工作。其次，你不知道什么会起作用，什么不会起作用。
到处都是不确定因素
这里我们来谈谈数据科学项目和构建摩天大楼之间的第二个区别。你的摩天大楼是在一个基本上可以预测的环境中建造的，用基本上可以预测的材料来进行或多或少的固定设计。在这个世界上，把这些基本上可预测的结果分解成基本上可预测的子任务并按自己的方式处理是完全合理的。
在许多数据科学项目中，这些都不适用。环境总是在变化，因为高级管理人员似乎一直在改变主意。一个数据科学家的材料就是他们所使用的技术，所以基本上不可能预测什么能起作用，什么不能起作用。你不知道与产品相关的功能会有什么不同。邮件提醒？推荐文章？折扣？所以，提出一个固定的设计是不可能的——谁知道顾客会有什么反应呢？
你所能做的就是尽快地做实验。然后用你的实验结果来决定下一步要做什么，然后收集下一组结果等等。换句话说，你需要迭代。
现在你知道了，陈词滥调是有原因的。
如今，由于 MVP 运动，每个人在口头上都支持迭代。然而，我很少看到这种影响完全融入到一个组织的工作中。如果你真的支持迭代，那么一旦你完成了第一个任务，你就必须根据你发现的东西来调整接下来的任务。
换句话说，你的计划毫无用处。
列出你要做的事情的清单可能会让你感到轻松一点。然而，你不应该欺骗自己，以为列出的清单会与你最终要做的事情有任何关系。如果它们与你最终的工作无关，那又有什么用？
这就是 Jira 心态的问题。如果你按计划使用这个工具，你会花一生的时间去移除清单、更换清单、取消清单——只是因为你的任务总是会随着你所学到的东西而改变。问题不在于 Jira 本身，而是因为你认为世界是可预测的，可以被组织成一个任务列表。
Jira 很敏捷，但敏捷是为了迭代，所以你错了！
敏捷软件开发的 12 条原则（https://agilemanifesto.org/principles.html）是我一遍又一遍地提到的文档之一，它们表达得如此优雅以至于根本不需要再次总结。
是不是想起来了？好吧，敏捷过程并没有敏捷宣言本身那么可怕，它有一个大写的「A」。事实上，敏捷宣言的作者之一甚至否认了敏捷过程。所以从现在开始，我将使用小 a 来指代与敏捷宣言一致的过程，而大 A 则指代公司推动数据科学家的各种过程。
这些过程指什么？好吧，它们可能极其复杂，令人费解，涉及到故事，史诗，仪式等等。然而，虽然意图可能不同，但最后我只看到 A 作为任务集合被勾选出来。对我来说，这就是「Jira 心态」，它更接近 Prince2，而不是敏捷宣言。
那么，数据科学项目应该如何管理呢？
好吧，这个问题可以再写一篇文章了！以下是数据科学 PM 需要考虑的一个简短清单：
- 项目经理的很大一部分工作是把活动任务分解出来，并确保项目团队有一个明确的目标。99%的任务都应该涉及到具体的数字。
- 一旦确定了这个数字，就必须对项目进行时间限制。这并不是说在一段时间后停止项目，更像是「我们会在某一天有某个会议，在会议上必须展示实际的成果数据」。然后你可能就开始咬指甲了，因为在初期似乎什么都没发生，然后眼看着最后期限到来，人们都开始加班。很明显，这是关于创造性思维的。
- 计划是无用的，但计划是必要的。你将不得不对项目如何迭代到进行一些最好的预测。好吧，你不知道会发生什么，但你可以想想你需要发送电子邮件吗？如果需要，那最好提前和客户关系管理团队谈谈。
- 如果你发现自己需要鞭打别人来完成任务，那么事情就严重出错了。
最后一点，我对项目经理有点刻薄。它们是很容易达成的目标，而数据科学方面的东西还是新的。在未来，我们将回到数据科学家和项目经理应该如何一起工作的问题上，但现在可以认为项目经理有两种类型。有些人并没有真正了解正在发生的事情，他们试图将所有事情都强制纳入他们已经熟悉的项目管理方法中。这些人基本上都是会给项目带来消极的影响。
via：https://towardsdatascience.com/the-jira-mindset-is-damaging-your-data-science-team-66efc46aaa47
