隨著計算能力的飛躍和深度神經網絡的發展，數據科學，無論在國外還是國內，都是最近幾年高科技領域的一個熱點。很多公司和互聯網企業都急切地涌入到這一波熱潮中。但是成功的產品卻并不多。大多數集中于創業企業的數據科學/機器學習項目都沒能實現最初都愿景，有的不了了之，有的難以兌現價值，并且有相當多的項目只是拿來做融資的噱頭。這里總結一下基于數據科學的項目和產品中一些常見問題
項目和產品不夠明確?
初始的討論就缺乏可行性，可操作性，或者有一些項目本來就不需要是一個數據科學的項目。這里考驗的是一個產品經理或者公司執行者的視野和能力。我曾經在一個電商公司工作過一段時間，當時成立data science團隊是受到投資人的推動，于是急匆匆招兵買馬架起了隊伍。在具體討論項目和產品時候，CEO只給出來了一個“簡單”的目標，把用戶平均消費額提高10%。市場部原封不動的將這個目標傳遞到了DS團隊，沒有任何具體的方案和建議，沒有具體的對接人，沒有指定的產品經理或者項目經理。帶著其他部門一廂情愿的理解，DS團隊開始了研發，然后就是一團糟：數據模型做出來之后沒有任何現實意義，單純對于用戶的聚類卻不能給出銷售行為具體指導。面對更復雜的分析和活動，市場部既沒有條件來實現，IT部門也沒法支持。最后只剩下一堆PPT，和一些描述性的結論，并沒有具體的產品。?
CEO的動機非常清晰：提升銷售額。但是這在商業上是一個極其龐大和復雜的課題，并沒有一個簡單的解決方案。這種項目或產品，一開始的定位就缺乏具體性和可行性。一個好的產品經理，應該將其具體化到小的課題以及可行的解決方案：比如如何通過優化優惠券的發放來提高用戶單位訂單，如何優化新品推薦短消息的內容等。確立了具體的靶點之后，再協調各部門共同開展項目，而非依賴于單一部門。一個好的CTO更不能自絕于DS之外。在互聯網時代的項目中，幾乎每一個都是跨部門多功能的。保證所有參與方之間明確產品的功能和定位，是進入項目開發前必須的一步，雖然很耗費精力，但是磨刀不誤砍柴工。?
Data Scientists 缺乏研發軟件產品的能力?
數據科學家這個職位聽起來很sexy，很吸引人。可惜這并不是一個“科學家”。可以這么講，一個好的data scientist需要的是一個科學家和一個工程師的集合。市場上有兩類典型的“數據科學家”：一類是學習軟件工程出身，可能干過程序員，對寫程序比較輕車熟路。然后自學了一些網上的課程，就開始做DS了。他們科學研究相對弱一些，可能按部就班做工作更多一些。另一類是研究生出身，寫過論文或者接觸過科學研究，比較擅長讀文獻，看教科書，推導公式做習題。但是缺少軟件開發的經驗。主要是缺少在軟件項目團隊中合作的經歷。就我看來，這兩種DS都有缺陷，都需要改進。這里主要說第二類問題，缺少軟件開發背景的DS?
五年前，我曾經在一個飲食行業的獨角獸企業DS團隊中工作過。當時的團隊有3個博士，2個碩士，大家在一起很喜歡聊最近的研究論文，數學和統計學上的一些問題和簡介。整個團隊里面每個人很聰明，工作也很有熱情，大家每個人主導一個項目，每周討論非常活躍。但是這樣一個團隊，一年時間里幾乎一事無成，拿不出來被認可的產品。究其原因，團隊里面的研究氣氛濃郁，卻缺少將模型轉化成產品的能力。 Google有一篇關于數據項目的文章的觀點很有代表性：建立數據和工作流程比做一個預測模型本身更重要。當時的團隊就是陷入了一個誤區，做出來的模型越來越復雜，數據流卻從來沒有理清楚，從來不了解如何設計軟件的架構，沒有CI/CD，沒有測試和運維。一個在軟件工程看來很直接明了的需求，卻始終無法實現。?
用比較糙的話來總結：這些DS可以稱為“偽數據科學家”。大家追逐炫酷的模型的同時，不應忘記一個企業一個項目追求的根本是商業價值，體現在一個軟件產品的客戶價值上。一個項目背后的模型可以是簡單的邏輯回歸，甚至是rule-based，但是不能缺少良好的軟件設計和實現。盡管這對于一個沒有軟件開發背景的純研究出身的人來說比較苛刻，但是現實就是這樣。我可以接受你模型做的不夠完美，但是能交付產品。我不能接受一個完美的模型和PPT作為最終產品，除非我們做的生意只是套投資人的錢而已。 在組建團隊的時候，也一定要把這點作為重要考量，即團隊中至少要有一個軟件開發經驗充足的數據科學家。?
與工程師團隊無法有效合作?
通常在一個cross-functional的項目中，軟件工程師是必不可少的。這時候就需要DS和工程師有效合作，共同開發產品。現實中，這樣的合作常常是問題百出。常見的問題有：?
1. 工作模式不同
對于研究型的學者來說，從事的工作都是全新的，而且通常很難。這類的工作很難預估或者事前計劃。而對于傳統的軟件開發而言，以scrum為代表的敏捷開發非常流行。這兩者其實并不能很好的統一，或者說本質上不應該試圖統一。我曾經在的項目中就經常遇到這類問題，建模組需要一些數據來驗證一個新的想法（或者模型），而相應的數據工程師團隊要求必須在每周二sprint會議之前提要求，否則要推到下一個sprint。如此一來二去，整個項目進展緩慢。這源于一些團隊對于敏捷開發的理解過于局限，過于拘泥形式。應該明白的是，敏捷開發不是形式而是思想。
2. 對于以數據科學為中心的項目理解不同
很多工程師還是基于以前軟件開發的經驗，在與DS的合作中沒能認識到半科研半工程項目的特殊性，過分專注于代碼本身。比如，很多時候，DS項目就是一個不斷試錯的過程，重復驗證了多個可行性之后才有可能找到一個最理想的方案。這需要快速試錯，prototyping，而非過分糾結于最終產品。這一過程沒有辦法預知，也難以做到測試驅動。與項目利益方的不斷互動，可能使得整個項目可能永遠就是在不斷的交付一個又一個MVP。這不妨礙成為一個成功的DS項目，但是卻有別于傳統的軟件開發目標。?
3. Teamwork
一個專業的工程師，到底是應該對別人代碼中的問題牙呲必究還是應該適可而止？這個問題沒有標準的答案， 主要取決于整個項目的目標和企業利益。現實中常常見到DS的代碼不盡人意，而又不愿意花大力氣改進，畢竟沒有事情是完美的。個人認為最好的辦法就是項目經理必須明確到底項目最重要的目標和底線，各方認同這一底線，從實際出發，避免DS團隊的過度工程化。?
缺乏創新能力?
一個良好的DS團隊不能只會實用現成的軟件包開訓練模型，不能只分析數據，而應該具有獨立開發新算法新模型的能力。也許目前的項目并不需要這些過的工作，但是整個團隊應該保持至少20%的時間和資源用來做原創性的研發工作。比如研究一些最新的理論進展，follow一些論文，組織學習小組系統地學習新知識，積極參加相關的會議。這些講起來容易，其實做起來很難，因為項目經常會安排很滿，難以給予足夠的時間來做充實團隊，或者做一些技術儲備。?
總結?
很多企業都在構建數據科學團隊和相關的項目，但是又經常抱怨投入產出比低下。一個成功的產品需要不僅僅優秀的DS團隊，還需要決策層和相關部門對于數據科學的理解和配合。本質上，數據科學是軟件開發而非科學研究，是對人類既有流程和工作效率的優化而非替代。尋找一個優秀的數據項目經理，遠比尋找一個優秀的數據科學家難。
