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

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

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

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

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

面對這些困惑，有些公司只需雇傭其中一種角色，希望他們能找出每個人做了什么。這可能導致關(guān)于角色之間差異的爭論。另外，我看到了一個滑稽的場景：一個團隊有產(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ù)科學項目是否和構(gòu)建摩天大樓一樣？

不不不，它們并不一樣。

目的不是手段

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

我離題了。

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

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

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

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

到處都是不確定因素

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

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

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

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

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

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

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

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

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

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

是不是想起來了？好吧，敏捷過程并沒有敏捷宣言本身那么可怕，它有一個大寫的「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ā)生，然后眼看著最后期限到來，人們都開始加班。很明顯，這是關(guān)于創(chuàng)造性思維的。

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

• 如果你發(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)

雷峰網(wǎng)版權(quán)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。