2020-03-09 16:56:00 讀芯術

全文共3996字，預計學習時長

12分鐘

對於外行來說，“Jira”是一個項目管理工具，在科技公司之外幾乎無處不在。

它最初是為了管理軟件開發項目而構建的，自然會被重新應用到數據科學項目中。

儘管Jira可能是一個很好的工具，但數據科學項目是不同的！

數據科學項目和建築項目是不同的

管理數據科學項目會引起許多激烈的討論（對於樂觀主義者而言）或大量的爭論（對於悲觀主義者而言）[1]。

一方面，由於數據科學家通常在技術部門工作，因此應該像管理專業的軟件開發人員一樣管理他們，這是默認的情況。另一方面，有一種觀點認為，因為數據科學家通常都有研究背景，所以應該像對待研究人員一樣對待他們，並應賦予他們“創造”的自由。

這兩種管理方式都不合適。

然而，後一種方式在管理類型上風險更大:給這些數據科學家自由，他們就會感到無關緊要，根本不做任何事情。所以本文著重討論前一種方式的錯誤之處。

為什麼數據科學家如此抵制軟件開發人員和管理人員認為理所當然的流程呢？

首先，筆者是某種項目管理的忠實信徒。正如管絃樂隊需要一個指揮[2]，一個團隊也需要一個可以進行協調的人。問題是，對於如何稱呼這些人，並沒有達成廣泛的一致意見。在微軟，他們都被稱為Program Managers（程序經理）。其他地方會稱他們為Project Managers（項目經理）。有的產品經理也負責這方面的事務，甚至商業分析師也做過類似的工作。

面對這些困惑，有些公司（在這裡不會說出具體的名字）只需每個職位僱一個人，並希望他們自己能弄清楚誰為自己做了什麼。這可能會導致關於不同角色之間差異的惡意爭論。此外，這也取決於思考者還是試探者的定位[3]，在這樣的團隊中，一個產品經理，一個程序經理，一個業務分析師和一個項目經理都在管理兩個可憐的數據科學家，這個景象又滑稽又悲慘。現在能責怪那兩位數據科學家對四位經理創建的流程產生牴觸情緒嗎？畢竟，有誰在真正地工作呢 [4]？

所以也許數據科學家對流程不滿可能預示著流程的崩潰，而不是數據科學家的崩潰。

現在，本文中把所有負責協調角色的人統稱為“PM”。如果一名數據科學家不確定PM是指誰，就可以認為他們就是團隊的樂隊指揮，即他們站在最前面，揮舞著手臂，做著奇怪的表情。

無論如何，在任何項目中，一個PM必須呈現任務進度。數據科學很複雜。所以，也許只是給團隊成員分配任務，然後把燃盡圖放在一起，顯示完成了多少任務。甚至可以製作圖表顯示誰做了什麼！高級管理人員很吃那一套。這是一個很棒的工具，它讓所有這些事情變得非常非常容易，所以就用它吧…

那麼就用Jira吧。

現在，Jira做得很好，並沒有出現錯誤。然而，有一種思維模式認為，“我們正在完成任務，也就是說我們正在交付任務”。這是錯誤的。Jira鼓勵這種思維方式，因為它把世界組織成了需要勾選完成的任務。

來研究一下完成任務和交付有用的東西之間的區別。乍一看可能有悖常理。當然，項目管理的一個基本原則就是，把一件大事，分解成許多可預測的小事，然後通過這些小事來完成。換句話說，把大事分解成任務，然後把這些任務一個一個地完成。有一個很好理解，政府批准的系統來做這件事，叫做Prince2（關於敏捷，稍後討論）。大量的人因為在這個Prince2系統中擁有各種花哨的發聲資格而歡欣鼓舞。如果在建一座摩天大樓時用這個系統，那麼它就能用在倫敦奧運會上了，對吧？

於是問題就變成了:數據科學項目就像摩天大樓項目嗎？

當然不是，接下來會進行解釋。

目的不是手段

第一個區別是最終目標。摩天大樓項目的目標是建造一個人工製品。使用這些人工製品就是商業目標，即出租辦公室、酒店、公寓、或任何一樣被層層令人眼花繚亂的金融騙局抽象化的東西。這些騙局一直延伸到提供養老金的基金。別想每一層都能分到多少錢了。

跑題了。

關鍵是，作為一個卑微的工程師，可以繼續建造這座該死的摩天大樓，而不必太擔心商業方面。

作為一個卑微的數據科學家，就沒有這種好事了。工作不是建立一個人工製品，而是改變一個正在進行的業務流程，使之變得更好。舉一個具體的例子：工作不是建立一個預測訂閱流失的模型，而是減少實際的訂閱流失。一個預測模型可能有用，也可能沒用。聳聳肩說“我只是做了個模型，因為你就是這麼說的”，是沒有用的。

要改進這個業務流程，從哪裡開始，什麼能改變這些數字的走向？數據科學家可能會想出一大堆東西。提醒郵件？個性化推薦？產品折扣？

此時，作為一名數據科學家，會注意到兩件事。首先，數據科學在想做的事情中只佔很小的一部分，所以最好和其他人一起合作。其次，數據科學家根本不知道什麼有用，什麼沒用。

不確定性無處不在

這裡來談談數據科學項目和摩天大樓之間的第二個區別。摩天大樓是在一個基本可以預測的環境中建造的，使用基本可以預測的材料，根據基本上固定的設計。在這裡，把這些基本可以預測的結果分解成基本可以預測的子任務，然後通過自己的方式來完成它們是完全合理的。

在許多數據科學項目中，這些都不適用。環境總是在變化，因為高級管理人員似乎在不斷改變他們的想法。數據科學家的材料相當於他們所使用的技術，基本上不可能預先預測哪些有用哪些不有用。不知道哪一個產品的特性會帶來哪些不同。提醒郵件？推送文章？打折？所以想出一個固定的設計是不可能的，因為誰知道客戶會有什麼反應呢？

能做的只有實驗，儘可能快地實驗。然後使用實驗的結果來決定下一步要做什麼實驗，然後收集下一組結果，依此類推。換句話說，需要迭代。

因此，不要嫌囉嗦。

現在，因為MVP (Model-View-Presenter) 運動規則，所有人都只有口頭功夫，而不真正去迭代。然而，一個公司的工作中很少充分考慮到這些影響。如果這樣做，一旦完成了第一個任務，將不得不根據發現的任何東西改變下面的任務。

換言之，計劃將失效。

現在，列出一個要做的事情的清單，可能會是一點安慰。然而，不應該自欺欺人地認為這個清單與最終要做的事情有任何關係。如果上面的內容與最終要做的事情無關，那就再想想這一點。

這就是Jira思維的問題所在。如果按照預期使用這個工具，將要一直去刪除、更改、去除某些標籤的優先權——僅僅是因為任務總是會根據學到的東西而改變。問題不在於Jira本身，而在於一種想法，即人們能在一個可被列成任務清單的可預測的世界中進行操作。

但是敏捷（Agile）是關於迭代的。而且Jira就是敏捷，所以錯了！

不是這樣的。

敏捷（Agile，大寫A）軟件開發的12條原則是非常棒的。這是筆者反覆提及的。而且，它們表達得很委婉，沒有進行總結。點擊此處進行了解[5]。

印象不錯吧？好吧，敏捷（Agile，大寫A）的流程並沒有敏捷宣言本身那麼棒。事實上，敏捷宣言的一位作者已經否認了敏捷流程。因此，從現在開始，筆者將使用agile（小a）這個詞來指代與敏捷宣言一致的流程，而Agile（大A）則指代公司推給數據科學家完成的各種流程。

這些流程是什麼？它們可能很複雜，令人費解，涉及到文學故事、史詩、儀式和尖峰輻射的術語。然而，儘管意圖可能不同，筆者最終只看到過敏捷（Agile）被做為需要打勾的任務的集合。這就是“Jira思維”，它更接近Prince2，而不是敏捷宣言。

那麼數據科學項目應該如何管理呢？

這才是本文的主題！這裡有一個簡短的列表，供數據科學的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] 可見敏捷宣言早期的輝煌。