數(shù)據(jù)科學項目和建設性項目是不同的

對于外行來說，「Jira」只是一個項目管理工具，在科技公司中幾乎無處不在。它最初是為管理軟件開發(fā)項目而構建的，后來自然而然地被應用到數(shù)據(jù)科學項目中。我想說，盡管 Jira 可能是一個很好的工具，但數(shù)據(jù)科學項目是特別的！

管理數(shù)據(jù)科學項目會引起大量熱烈的討論或大量的爭論。一方面，默認的立場是，由于數(shù)據(jù)科學家通常都在技術部門工作，因此他們應該像專業(yè)的軟件開發(fā)人員一樣進行管理。另一方面，有一種觀點認為，由于數(shù)據(jù)科學家通常有研究背景，他們應該被當作研究人員對待，并給予自由支配權「以便保持創(chuàng)造力」。

這兩種方法都不完全管用。然而，后一種方法的風險對于前者來說更為明顯：你讓這些數(shù)據(jù)科學家自我管理，他們可能會變得自由散漫，根本不做任何事情。所以我想把這周的帖子花在前一種方法的討論上：為什么數(shù)據(jù)科學家如此抗拒軟件開發(fā)人員和管理人員認為理所當然的管理方式？

首先，我應該聲明我是項目管理的忠實信徒。正如管弦樂隊需要指揮一樣，一個團隊也需要一個具有協(xié)調(diào)能力的人。一個問題是，人們對如何稱呼他們沒有達成廣泛的共識。在微軟，這些人都被稱為程序經(jīng)理，在其他地方他們被稱為項目經(jīng)理。我還見過產(chǎn)品經(jīng)理甚至是商業(yè)分析師扮演這個角色。

面對這些困惑，有些公司只需雇傭其中一種角色，希望他們能找出每個人做了什么。這可能導致關于角色之間差異的爭論。另外，我看到了一個滑稽的場景：一個團隊有產(chǎn)品經(jīng)理、程序經(jīng)理、業(yè)務分析師和項目經(jīng)理，他們都在管理兩個糟糕的數(shù)據(jù)科學家。在這種情況下，我們是否可以責怪這兩位數(shù)據(jù)科學家對四位管理者創(chuàng)建的流程產(chǎn)生了抵觸？畢竟，真正工作人是誰？

因此，也許數(shù)據(jù)科學家對流程的不滿的原因是流程被破壞，而不是數(shù)據(jù)科學家被毀掉了。

無論如何，在任何項目中，項目經(jīng)理都必須展示進度。數(shù)據(jù)科學的東西很復雜。所以，也許我們只是分配任務，然后匯總顯示完成了多少任務的圖表。我們甚至可以制作圖表顯示誰做了什么！高級管理層想看到的就是這些。

這里用到了 Jira。

現(xiàn)在，Jira 做得很好，這沒什么問題。然而，世界上有一種心態(tài)是「我們在完成任務，因此我們在交付」。這是錯誤的。真的，這真的錯了。Jira 鼓勵這種心態(tài)，因為它把事情分解成了一個個需要勾選的任務。

讓我們來分析一下在完成任務和交付有用的東西之間的區(qū)別。乍一看這可能有悖常理。當然，項目管理的一個基本原則是，你把一件大事，分解成許多可預見的小事，然后通過完成這些小事來完成整個項目。換言之，你把你的項目分成若干個任務，然后逐一勾選這些任務。甚至還有一個很好理解的、政府批準的系統(tǒng)來實現(xiàn)這一點，叫做 Prince2。在 Prince2 系統(tǒng)中，許多人都為擁有各種聽起來很花哨的功能而高興。天哪，如果我在建摩天大樓，我會用這個系統(tǒng)，比如為倫敦奧運會做準備工作，對吧？

所以，現(xiàn)在問題變成了：數(shù)據(jù)科學項目是否和構建摩天大樓一樣？

不不不，它們并不一樣。

目的不是手段

第一個區(qū)別是最終目標。摩天大樓工程的目標是建造一件藝術品。利用這件藝術品的商業(yè)目標，即出租辦公室、酒店、公寓等等，反正它們會為你賺很多錢。你可以把每一層樓都想象成你口袋里的錢就夠了。

我離題了。

關鍵是，作為一個謙虛的工程師，你可以繼續(xù)建造這座該死的摩天大樓，而不用太擔心商業(yè)方面的事情。

然而，數(shù)據(jù)科學家并非如此。你的工作不是建立一個作品就萬事大吉，而是為了更好地改善一個正在進行的業(yè)務流程。讓我舉一個具體的例子：你的工作不是建立一個預測訂閱流失的模型，而是能在實際上減少訂閱流失。預測模型可能有用，也可能沒有用。你聳聳肩說，「我只是做了一個模型，這是你讓我這么做的」是沒有用的。

所以，你要改進這個業(yè)務流程。你從哪里開始？目標數(shù)據(jù)是多少？好吧，你可能會想到很多事情。郵件提醒？個性化推薦？產(chǎn)品折扣？

在這一點上，作為一個數(shù)據(jù)科學家，你注意到兩件事。首先，數(shù)據(jù)科學研究只是你工作的一小部分，所以你最好和其他人一起工作。其次，你不知道什么會起作用，什么不會起作用。

到處都是不確定因素

這里我們來談談數(shù)據(jù)科學項目和構建摩天大樓之間的第二個區(qū)別。你的摩天大樓是在一個基本上可以預測的環(huán)境中建造的，用基本上可以預測的材料來進行或多或少的固定設計。在這個世界上，把這些基本上可預測的結果分解成基本上可預測的子任務并按自己的方式處理是完全合理的。

在許多數(shù)據(jù)科學項目中，這些都不適用。環(huán)境總是在變化，因為高級管理人員似乎一直在改變主意。一個數(shù)據(jù)科學家的材料就是他們所使用的技術，所以基本上不可能預測什么能起作用，什么不能起作用。你不知道與產(chǎn)品相關的功能會有什么不同。郵件提醒？推薦文章？折扣？所以，提出一個固定的設計是不可能的——誰知道顧客會有什么反應呢？

你所能做的就是盡快地做實驗。然后用你的實驗結果來決定下一步要做什么，然后收集下一組結果等等。換句話說，你需要迭代。

現(xiàn)在你知道了，陳詞濫調(diào)是有原因的。

如今，由于 MVP 運動，每個人在口頭上都支持迭代。然而，我很少看到這種影響完全融入到一個組織的工作中。如果你真的支持迭代，那么一旦你完成了第一個任務，你就必須根據(jù)你發(fā)現(xiàn)的東西來調(diào)整接下來的任務。

換句話說，你的計劃毫無用處。

列出你要做的事情的清單可能會讓你感到輕松一點。然而，你不應該欺騙自己，以為列出的清單會與你最終要做的事情有任何關系。如果它們與你最終的工作無關，那又有什么用？

這就是 Jira 心態(tài)的問題。如果你按計劃使用這個工具，你會花一生的時間去移除清單、更換清單、取消清單——只是因為你的任務總是會隨著你所學到的東西而改變。問題不在于 Jira 本身，而是因為你認為世界是可預測的，可以被組織成一個任務列表。

Jira 很敏捷，但敏捷是為了迭代，所以你錯了！

敏捷軟件開發(fā)的 12 條原則（https://agilemanifesto.org/principles.html）是我一遍又一遍地提到的文檔之一，它們表達得如此優(yōu)雅以至于根本不需要再次總結。

是不是想起來了？好吧，敏捷過程并沒有敏捷宣言本身那么可怕，它有一個大寫的「A」。事實上，敏捷宣言的作者之一甚至否認了敏捷過程。所以從現(xiàn)在開始，我將使用小 a 來指代與敏捷宣言一致的過程，而大 A 則指代公司推動數(shù)據(jù)科學家的各種過程。

這些過程指什么？好吧，它們可能極其復雜，令人費解，涉及到故事，史詩，儀式等等。然而，雖然意圖可能不同，但最后我只看到 A 作為任務集合被勾選出來。對我來說，這就是「Jira 心態(tài)」，它更接近 Prince2，而不是敏捷宣言。

那么，數(shù)據(jù)科學項目應該如何管理呢？

好吧，這個問題可以再寫一篇文章了！以下是數(shù)據(jù)科學 PM 需要考慮的一個簡短清單：

• 項目經(jīng)理的很大一部分工作是把活動任務分解出來，并確保項目團隊有一個明確的目標。99%的任務都應該涉及到具體的數(shù)字。

• 一旦確定了這個數(shù)字，就必須對項目進行時間限制。這并不是說在一段時間后停止項目，更像是「我們會在某一天有某個會議，在會議上必須展示實際的成果數(shù)據(jù)」。然后你可能就開始咬指甲了，因為在初期似乎什么都沒發(fā)生，然后眼看著最后期限到來，人們都開始加班。很明顯，這是關于創(chuàng)造性思維的。

• 計劃是無用的，但計劃是必要的。你將不得不對項目如何迭代到進行一些最好的預測。好吧，你不知道會發(fā)生什么，但你可以想想你需要發(fā)送電子郵件嗎？如果需要，那最好提前和客戶關系管理團隊談談。

• 如果你發(fā)現(xiàn)自己需要鞭打別人來完成任務，那么事情就嚴重出錯了。

最后一點，我對項目經(jīng)理有點刻薄。它們是很容易達成的目標，而數(shù)據(jù)科學方面的東西還是新的。在未來，我們將回到數(shù)據(jù)科學家和項目經(jīng)理應該如何一起工作的問題上，但現(xiàn)在可以認為項目經(jīng)理有兩種類型。有些人并沒有真正了解正在發(fā)生的事情，他們試圖將所有事情都強制納入他們已經(jīng)熟悉的項目管理方法中。這些人基本上都是會給項目帶來消極的影響。

via：https://towardsdatascience.com/the-jira-mindset-is-damaging-your-data-science-team-66efc46aaa47

雷鋒網(wǎng)雷鋒網(wǎng)雷鋒網(wǎng)