機器學習項目為什麼未實現敏捷開發

1. 敏捷開發，這種做法在我們公司的研發部門公司在運行；

2. MVP（最小可行性產品），小步快跑，這個做法在我們的產品PM團隊在試行。

而我帶領的機器學習演算法團隊還是在按部就班的在進行著：確定目標-準備數據-訓練模型-優化模型-API開發-上線-效果評估的的全流程中，並沒有體現出一丁點的敏捷開發和MVP的意味。最近一段時間也在思考：是否我們的演算法團隊也能實現，敏捷開發或者MVP呢？

時至今日，還是沒有找到很好的突破點，在此把我的思考過程發佈於各位分享，看一下其他的大拿們能夠點醒我。

實質上，敏捷開發的和MVP是為了適應互聯網中兩個思路：一個是分散式開發，替代過去的瀑布式項目管理，快速迭代開發，並快速糾正錯誤；二是快速試錯，測試市場的反應，看一下產品的定位是否與你預期的一致，小而美，如果有效果了再快速擴大範圍。不管是哪種方法，都體現了"快"的思想。

而我們現在做的機器學習項目，是基於業務的智能化的實現方式，和業務本身穩定性是息息相關的，照理說我們沒有必要追求又好又快，這是個慢工出細活的事；舉個例子，如果你是新興業務，那麼你的數據累積量不夠，你做的模型可參考性不夠，你的模型也很難做准；如果你是成熟的業務，你的數據累計量就足夠了，機器學習的威力就更大一些，你可以把模型做的更准，可以持續的進行優化。但在很多特定的場景下，如果你項目拖得時間太長，那麼對業務的幫助也就越小，他們沒有足夠的耐心等你一年、半年來獲得成效，因為他們很多項目都是需要很快速的取得效果的，但是我們的很多演算法項目並不能決定一個項目的成敗，只能作為一個輔助手段來進行實施，所以從這點上要求我們需要更快速的相應號召，儘快的把演算法做出來上線並持續的優化使得對業務的幫助最大化。

最近統計了一下我們之前實施的演算法累項目，發現我們的流程實在是有點漫長，讓整個項目的執行過程有點太過於拖沓，我們需要太長的時間。我們的有些演算法項目從開始立項到正式上線這整個周期，長的有過一年，中的半年，短的也要兩到三個月的時間，所以我想要scrum是不可能的事情。上線之後又有一些線上的問題，模型迭代或者修bug，首先定位問題，然後開發、測試到再次上線，又大半個月過去了，這一整套流程下來，模型起到的作用，影響業務的效果就大打折扣，有時候時機就失去了。所以我最近都在思考，為什麼我們會這麼慢，為什麼我們不能快一點？

針對這個問題，我覺得我們現在的做法有些地方可以進行優化：

1、首先，部門結構可以做一些微調，我們的組織結構是：演算法隸屬於團隊A，ETL工程師和API團隊隸屬於團隊B，開發團隊隸屬於團隊C，產品團隊隸屬於D，業務團隊隸屬於團隊F，測試團隊隸屬於E。我不知道有多少公司是跟我們一樣的組織結構，我挺贊同專業的人做專業的事情，可是這樣的團隊組織結構會導致出現一些潛在的問題：

• 太多的團隊合作，一個演算法項目需要協調ABCDEF團隊；跨團隊合作最大的問題是溝通問題和資源優先順序問題。溝通的問題只需要一個強大的項目Owner就可以了，他既當項目經理也又做其他的角色，這個角色總可以找人擔當，問題不大；第二個問題就比較難了，大家都有自己的事情，如果此類型的項目多了，那麼其他團隊想要達到快速響應就很難了，我們經常會把BCDE團隊集合在一起，討論一下大家都比較空閑的時間，然後進行排期，如此幾次，甚是勞心傷神，進行緩慢；有時候還不得不拉上各team的高級領導們進行協調，溝通；

• 演算法項目的上線需要產品團隊和業務團隊保持好相關的溝通，演算法團隊夾在中間，和業務偏離有點遠，又無法直接對接開發團隊，所以導致中間資源損耗，總是覺得上線個東西很辛苦；
• 項目的責任人不清晰，沒有一個明確的說法說：由哪個團隊主導，所以會出現一些扯皮的事情；

以上列出了一些目前碰到的問題，那麼對於其他公司的啟發是：

• 首先從團隊A（演算法團隊）上進行優化，一個好的演算法團隊應該有自治能力，即有API的開發能力和數據開發的能力，這個在有些公司就是硬性要求的，我們目前還沒有。我們假想一下，如果演算法團隊內部有能力封裝API，那麼開發團隊只要調用API就上線模型了，同事因為從模型到API開發都是在演算法內部團隊內流轉的，那麼實現Scrum就有可能了。
• 我覺得以後演算法模型應用的趨勢是類似這種微服務自治的方式，我們提供相應的API，供各調用方使用，在不同的場景使用，這樣可以大大的提高代碼復用、模型復用、減少很多重複工作；
• 另外在演算法團隊的職能上看，如果要讓演算法發揮更大的價值，那麼演算法團隊應該獨立於業務和技術，應該是介於這兩個之間，演算法與技術和業務的結合就更緊密一些；根據不同的階段，演算法團隊和這兩個團隊的關係是不同的，在前期和業務結合的更好一些，後期上線和技術結合的更緊密些；
• 明確約定演算法主導的項目有演算法團隊的人主導，對其考核KPI，對結果負責，這樣才能讓演算法起到更大的作用；
• 造成目前的一個問題還有一個原因是大數據平台數據的不可持續性，因為業務變化導致數據的變化太多，表結構變化了、建新表了、廢棄舊錶了、新增欄位了等等煩心的事情。基於hadoop平台的數據應用流程，我覺得可以做一些微調，就是以前開發團隊只管寫代碼，生產數據；我覺得可以多邁一步，開發團隊既生產數據，也負責把D+1的數據導入到hadoop集群。這樣做的話：

1. 保持了線上數據與hadoop歷史數據的一致性，開發團隊會保證數據生產的有效性，其他團隊的人可以暢通無阻的使用這些數據，這樣就可以讓每個人都是數據的消費者。

2. 減少了數據團隊和開發團隊的多次交流和溝通，其他的任何團隊，比如產品、業務的人可以直接取到生產上的D+1的數據進行加工，數據倉庫工程師的人員可以全力去做下游的倉庫建設工作。基於hadoop平台，各個團隊都可以接觸到非敏感性的數據，進行相關的數據分析工作。這樣可以減少單純查詢數據的ETL工程師的人員，實現了很多的數據查詢自治。養著這麼多的數據查詢工程師的人員，對他個人是沒有成長空間的，工作又沒有挑戰性，很容易使得人員流失；
3. 根據數據侵染和大環境的發展趨勢，以後的方向是大部分的開發和業務人員都是數據分析箇中高手，他們能輕鬆的接觸到數據，又能至少做些簡單的分析工作。比如產品經理，如果你都不知道你的產品的表現怎麼樣，你怎麼去進行優化，業務都不知道自己的KPI的數據是什麼，還怎麼做業務。

以上就是我的一些思考，最後我想說的是，我對敏捷的思考有個漏洞，為什麼我非要上線才知道效果呢？實際上做過演算法的人都知道，演算法模型大部分在Offline的時候都會有相應的評估指標，比如RMSE，auc，Recall，Precision，NDCG@，MAP...，所以我們能事先評估出來。但在實踐中，我們發現這種Offline評估的效果總是和真實上線後不是完全match的，在線上的模型受到的干擾很多，甚至會出現模型影響模型自身的情況，所以我們看實際效果的時候都是以線上的為準，因此才有以上說的重視線上效果的一些思考。

推薦閱讀：