作者 | donnyhuang

?運營開發為什么會存在呢？“肯定是因為有運營嘛，有運營需求，需要開發完成這些需求，所以我們才存在?！?那么，真的是這樣的嗎？

一、運營需求是什么

這個話題首先要先分析：運營是干啥的？一個運營需求的生命周期是什么樣的呢？通常來講分三步：評估決策-落地-效果反饋，然后迭代改進。跟我們精益研發的價值循環有點像。

在這個過程中客戶對我們有兩個比較大的訴求，一個是運營工具，第二個就是數據，希望通過運營工具能快速落地他的想法，而不是需求提出要一兩個月才能驗證，這樣就談不上快速迭代。

另外就是希望一上線就要能看到數據反饋，能通過數據精確制導他們策略制定、評估更好的方案，精確制導。

二、客戶訴求和現實差距

但理想和現實還是有差距的，我們過去在運營效率上還遠遠不夠。

就如同大家在工作中經常遇到這樣的場景：需要數據的時候發現沒有上報，要等埋點幾個月發布。

運營落地也是如此，大家有沒有很熟悉這樣的場景：

比如運營同學突然腦洞一開：“ XXX策略，可以讓我們業務增長XXX倍，看看能否明天上線。” 研發只能說：“需求已經排滿了，你和xxx pk一下，看能否排進下個月迭代。”

三、反思：運營研發是要思考如何不斷的提高運營效能

所以反思一下，上面下的定義不對，我們存在的意義，是要完成運營需求，但又不止是完成運營需求，而是思考如何不斷的提高運營效能。

甚至比較理想的是運營不再需要給我們提需求了，想要的時候就有了，因為如果走需求評審、排期、開發這種模式，代碼寫的再快都很難達到。

團隊其實在有些場景上實際也有了初步探索，比如我們現在正在做的無埋點上報，目的就是不用提需求就獲得數據，開發也不用埋點，想要的時候開啟就有。

又例如工具落地，之前行業個性化返傭，落地一個政策，要找人要數據，定排期，再開發，一兩個月才完成一個政策，最后還算錯了，搞出故障。

現在我們對需求分類梳理，抽先出核心公式，實現標準化、模式化、配置化，完全產品自助就搞定了，而且會有比較軟的風險管控措施，可以防止算錯。比如，我們還做了通用的風控模型，每個政策起手可以防刷返傭。

當然這些還遠遠不夠，目前可能只是解決了某些環節某些場景的問題。比如數據這塊，除了上報，搭建數據倉庫，數據應用、數據分析的效能提升也要不斷加強。

例如，上次幫一個同學review代碼，發現半年一共上傳不到1000行代碼，我很震驚，半年上傳的代碼這么少？后來問了才知道平時比較多的是幫產品臨時分析，代碼都沒有沉淀，所以當時就給他們提了要求，要把這些分析需求盤點分類，模板化，沉淀下來，后面就不用老是來臨時分析了。

同樣，運營活動類的需求也是一樣，不能一兩個月才落地，特別今年涉資的業務都要求接入審計，防止資金風險，研發資源投入上需要增加，更加需要關注效率的提升。

另外還有一類需求，現在還有管控流程線上化的需求，比如人臉的設備管控，之前因為沒有這些能力，很多流程是人肉跑的，但業務不可能停下等系統慢慢完善，導致系統建設跟不上業務發展，有很多債務，比如設備類型數據對不上，設備sn亂碼等等。

這些工具也是可以抽象沉淀的，基于一個原則“”能標準化的標準化，實在個性化的可以分類分場景來模式化，實在全新場景的通過原子組件和框架實現低代碼快速搭建系統”。總之新的管控場景要起手做好，不能再踩之前的坑了。

四、穩才是第一位

但是，做到這樣是不是就夠了呢？剛才講的都是怎么快，其實最重要的是要穩，不要搞出問題，運營往往涉及資金或者其他資源，出了問題，影響是非常惡劣的。

例如，經?？吹揭驗榕渲靡l的各種問題，有些直接導致出現重大事故。我們現在發配置特別擔驚受怕，擔心手一抖就導致重大事故，我們也在探索怎么通過更好的辦法預防配置的風險發生。

確實，我們通過FMEA梳理出來，發現配置這個東西，風險無處不在。

但總結起來歸根到底就是太靈活，也分析了歷史上出現過的大部分故障的原因，大部分是因為配置太靈活。

• 可配置的內容太靈活，所以也非常容易配錯；
• 配置發到線上的流程太靈活，跟代碼不一樣，沒經過測試驗證也可以發到線上；
• 使用配置太靈活，覺得啥都用配置最好，覺得可配置就是牛逼；

因此需要思考在控制靈活性的前提下提高效率。

五、突破機會怎么找

整體的要求就是快、準、穩，下圖是我們團隊梳理的運營支持研發全景圖。同樣也是針對提出的快準穩三個愿景作出的一些梳理部署吧，上層是我們支撐的業務板塊，底下是我們為了實現快準穩，需要沉淀的基礎能力。

我最近在維護這個圖的時候發現個很有意思的事情，我看到上層是不大穩定的，有一些我們之前做的運營工具，比如收銀員激勵、智慧推薦什么的，因為市場環境和監管要求的變化，已經不存在的，但底層的東西是相對比較穩定，而且需要不斷的做深做細，才能真正不斷的提高運營效率。

例如，一個上報，之前從來沒有想過背后有這么多技術難點和挑戰，例如配置，之前做了一個可以快速生成配置頁面的能力，覺得已經很牛逼了，現在發現，除了把頁面作出來，還要考慮配置安全性，怎么防止配錯，怎么防止自己的服務掛了影響上游，都是更深入的問題，需要想辦法突破。

那么，這些也是我們運營研發技術上持續突破的機會！

六、結語

以上就是運營開發在技術上持續突破的實踐經驗。

最后，新年之際，給大家送上一副春聯，祝愿大家無論工作和生活都能持續突破！