作為乙個演算法技術人員，學習了產品和開發的一些概念，例如mvp(minimum viable product）和敏捷開發的小步快跑。
最近在思考乙個問題，為什麼演算法研發和上線總是那麼漫長，那麼不敏捷？
首先，演算法研發，尤其是機器學習演算法應用研發主要分為這幾個部分： 方案，資料，和模型；
那麼，演算法應用的研發，也就自然而然要涉及到對接：
到這裡基本上可以看出來，為什麼演算法研發專案的週期都這麼長，基本可以總結為以下幾個原因：
以上這些問題自然不能盡如人意全部避免，但是我認為通過一些組織上的、方法上的改進，一定程度上也能減輕一些成本，提公升一些演算法研發效率做到更加敏捷：
首先是演算法研發人員應該多參與原始需求討論，真正理解業務方的真實訴求，甚至從技術可行性上引導業務方的產品模式和方案。
其次，研發鏈路這個問題需要演算法團隊從組織架構上，對團隊內部的能力進行拓展，不能完全沉迷演算法原型驗證。要從兩個維度進行拓展，第乙個是資料開發能力，指的是演算法人員應該有一些關鍵資料提前預設和埋點意識，指導資料生產和儲備，不能完全依賴於資料開發工程師做通用資料開發滿足所有需求。第二個是，演算法研發團隊內部需要具有基礎的資料etl和抽取能力，盡量縮短資料準備週期和資料溝通成本，不僅是在開發預演階段的資料獲取，同時也是上線或者灰度後的資料抽取和分析能力。
再有，演算法資料模型的交付不是終點。需要跟蹤開發的進展，把控開發的資料準備，特徵處理等問題，對自己的模型最終業務表現負責，而不是離線結果負責（然後互相甩鍋）。 當然，這個問題本身沒有這麼簡單，還涉及到例如專案主導權的問題，其中乙個重點就是，一般而言，專案主導者對於整個專案的跟蹤和交付都具有責任感而參與者則略弱。 所以這個問題的解決方案可能還包括任務邊界的區分，和主導權的問題（本不該這麼複雜o(╯□╰)o）
更高效的字串匹配演算法 shift and
在接觸這個演算法之前，一直覺得kmp巧奪天工，利用next陣列的遞推，實現對於模式串任一子串最大相同前字尾的找尋，繼而在匹配目標串的過程中，一旦遇到失配情況，可以令 匹配起始下標 進行合理範圍內最大的跳躍，從而將匹配整體複雜度從o nm 降為o m n a b c a bc.a b c a bk可從...
《高效程式設計師45個習慣》 敏捷開發有感
高效程式設計師的45個習慣 敏捷開發修煉之道 standing on shoulders of giants 站在巨人的肩膀上 2014年9 月20日星期六 h該書一共用了兩天時間通讀完，簡單的翻看其中的道理，把其中有用的好的道理和哲理摘錄和用自己的話說出來，引以為用。希望對看過該文的人有所幫助。在...
幸福的團隊更高效 管理者你知道嗎？
幸福的團隊更高效管理者你知道嗎？幾個志同道合的夥伴 乙個讓人感到舒服又佩服的上司 乙個團結協作的團隊，又會給人帶去多少幸福感 有句話就說 做什麼事其實不重要，跟誰在一起做事才重要。而這一切，幸福或不幸福，都是發生在組織中，組織和 管理者是 始作俑者 因此，組織不能 無為而治 放任自流，而是要為和諧的...