作者 | donnyhuang

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

一、運營需求是什么

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

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

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

二、客戶訴求和現(xiàn)實差距

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

就如同大家在工作中經(jīng)常遇到這樣的場景：需要數(shù)據(jù)的時候發(fā)現(xiàn)沒有上報，要等埋點幾個月發(fā)布。

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

比如運營同學突然腦洞一開：“ XXX策略，可以讓我們業(yè)務增長XXX倍，看看能否明天上線?！?研發(fā)只能說：“需求已經(jīng)排滿了，你和xxx pk一下，看能否排進下個月迭代?！?/p>

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

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

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

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

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

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

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

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

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

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

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

四、穩(wěn)才是第一位

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

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

確實，我們通過FMEA梳理出來，發(fā)現(xiàn)配置這個東西，風險無處不在。

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

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

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

五、突破機會怎么找

整體的要求就是快、準、穩(wěn)，下圖是我們團隊梳理的運營支持研發(fā)全景圖。同樣也是針對提出的快準穩(wěn)三個愿景作出的一些梳理部署吧，上層是我們支撐的業(yè)務板塊，底下是我們?yōu)榱藢崿F(xiàn)快準穩(wěn)，需要沉淀的基礎(chǔ)能力。

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

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

那么，這些也是我們運營研發(fā)技術(shù)上持續(xù)突破的機會！

六、結(jié)語

以上就是運營開發(fā)在技術(shù)上持續(xù)突破的實踐經(jīng)驗。

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