前端資源化的問題如何破局？

　　阿里妹導讀：本次分享是打算從我個人的實踐和思考中，提出在某些工作過程中，可以改善甚至避免資源化問題的例子和大家探討。

　　 背景

　　年初我們大團隊層面有過一次對現有問題的調研及總結，其中大家提的最多的就是前端資源化問題，擺在了所有問題的第一位。

　　本次分享是打算從我個人的實踐和思考中，提出在某些工作過程中，可以改善甚至避免資源化問題的例子和大家探討。也想拋磚引玉，引起大家對這個問題的再次重視，能在後續有更多的討論和發聲。

　　 資源化探究

　　前端資源化在某種程度上表達了前端人在業務中的主動性差、參與感弱、存在感不足、價值體現不夠，合作起來往往被需求方牽著鼻子走等等現狀，是前端人對自身在業務中的真實角色定位和影響力問題的綜合反映。

　　對於大部分程式設計師群體來說，處理因資源化帶來的情緒管理危機是要比處理技術問題更加困難的，所以這也是迫切需要認識並解決資源化的重要原因。

　　但每個人參與業務的角度和背景不同，對前端資源化也會有不同的看法，也的確不好一概而談。但也有些經驗豐富的同學已經給過總結，我們可以參考一下他們的觀點，梳理出來大概就是這樣的：

　　在絕大多數業務目標中，PD是產品系統能力的主導者，後端是從底層到上層產品系統能力的實現者，而前端負責的是與使用者互動的更上層，作為前端當然要懂產品，但因為崗位分工的側重點不同，對整體系統的瞭解程度不如後端和PD也是正常的。

　　因此前端起的多數是橫向的資源作用，能在資源上不拖累專案進展就是絕大部分業務方對前端的要求，偏資源化是共性問題，需要正視前端作為資源的事實。

　　那麼，難道前端就只能是資源了？

　　 如何解資源化

　　業務支撐角度前端做不到主導位置，迴避不了資源化的問題，但是我們可以主導其它可以帶來額外業務價值的事項，即業務增值。

　　大家也都能認可作為前端我們的價值：前端在業務增值中能發揮出PD、後端崗位所不具備的、前端崗位所獨有的橫向優勢和使用者視角優勢。

　　關於這一點，TL們也給過我們很多思路和目標，讓大家從體驗、從效能，讓我們從使用者視角出發去看自己的業務中有哪些真實使用者，去看去分析這些使用者有哪些待解可解的關鍵問題。

　　很多時候我們能看到這些事情，也著手去做這些事情。但或是眼高手低，事情想得很多，卻最終沒有實操性或因為各種原因中途放棄。又或是很順利，天如人願事情努力做完了，但仍然沒有改善資源化的問題。

　　大家有沒想過這裡面的問題是什麼？我認為可能會是這些原因：

　　1.用愛發電

　　在沒有被專案組足夠關注的情況下自行投入，OKR都難以對齊；

　　2.習慣自閉環

　　為避免拉通、協同等成本，自己既當軍師又當小兵，不同崗位間交流不足，專案組未必能感知，更不要說有多少人能多認同；

　　3.預算不足

　　對成本、風險、協同資源等預算問題在前期考慮不足，中期難以持續；

　　這裡大家可以檢查下自己設定的與業務增值相關的OKR，看看是不是有一些專案組無感知也不關注的事項？這已經可以復現出一個岌岌可危的所謂前端主導的業務增值專案了。那根本的問題出在哪呢？我的觀點列出來供大家參考：

　　1.業務增值，做事的驅動力是從哪裡來的？

　　拋去用愛發電的理由，那是什麼驅使我去做的？技術驅動？體驗驅動？又或是自己已經具備了產品或運營能力想去跨界多邁出一步？

　　技術驅動可以做的事：效能、延續性、可用性、穩定性等等；

　　體驗驅動可以做的事：使用者運營、自服務、互動效率、互動體驗等等；

　　2.誰能認可我做這件事？價值體現在哪裡？

　　若他認可了我做的這件事，那麼誰來認可他的所謂認可？這件事的價值是否能夠互相印證？有人說只要TL認可我做這件事我就做，但我理解的是TL認可這件事更多是因為所在業務認可，是你透過在業務中的重要程度說服了TL，認可並不是憑空出現的。

　　3.誰願意和我一起去做這件事？有沒可能實現更多價值？

　　若他願意和我一起做這件事，那反過來他的驅動力從哪來？他需要我 / 我能夠幫助他做哪些事？這些事的價值在哪？

　　這三個問題想通後，我們起碼知道主導這件事情背後的驅動力是什麼，有怎樣的價值，以及共事成員的驅動力及其價值。那麼我們再做事情就不再是自閉環獨狼這一條路了，可以抱團去產生影響力，去反向管理專案組，為我們設定目標或貼近目標。

　　你會發現從這一刻起自己不再是一個資源化的角色，反過來成為專案的發起者和領導者了。而同時也會發現專案合作者們或多或少都可能會有一些資源化的影子在，就好像資源化的你我一樣。

　　這裡可能會有個誤區，這個是在做專案PM嗎？當然不是的，這個是在完全的主導一件事，你自己是專案的主導者，而PM更多是專案的管理員，是一個執行角色，這兩者還是非常不同的。

　　前端作為一個專案發起者、領導者和專案管理者，需要考慮到更多籌備拉通的事情，所以有一些特別需要做以及避免做的事情，我簡單梳理了一下，這也包括一些TL們的看法：

　　需要做的事

　　1.對事：對業務足夠了解，瞭解自己堅持的核心價值點。能吸收不同角色視角的輸入，如何求同存異，結合自己的思考。但也不隨波逐流，不能別人說啥就是啥，沒有自己的堅持，讓人不信任。

　　2.對人：需要了解每個人對協同邊界的考慮、每個人對價值的衡量，他們在堅持什麼目標和價值，在意的是什麼，甚至還要當有人動搖的時候，如何給予他們信心，當期望值過高時，如何幫助他們降低期望等等。

　　避免做的事

　　1.避免樹立高期望目標，過度放大自己或隊友的能量，讓所有人都很累，沒有持續性，用一錘子買賣換一地雞毛；

　　2.避免為了做自己覺得正確的事燃燒自己，逼迫自己或隊友，等大家做了犧牲之後，事情又變成了爛攤子；

　　3.避免讓參與者用愛發電，寶貴的時間裡大家都有自己想實現的價值，用愛發電意味著很容易放棄、不靠譜；

　　接下來是一個例項，這是我今年做的一個的重點專案，在這個專案中甚至能感受到專案進行過程中，前端與後端在主導和資源的換位，以及運營與PD在業務輸入輸出的換位，這些非常明顯的變化。

　　 例項：體驗驅動的定價配置改版

　　分析體驗問題

　　做體驗絕不是簡單的事，對體驗的改進是一件有計劃、有方案的非常具有前端專業性的事情。

　　從重要性來說，體驗改進是針對所有使用者的，而功能迭代往往是針對某些特定使用者的，特別是成熟產品後續就更少有針對所有使用者做的功能迭代。

　　但實際做體驗有多難？一旦涉及到橫向協同就會非常多的阻礙：

　　與產品功能的迭代相比，體驗改進難與具體業務目標掛鉤，與業務的關聯程度低，結果難以衡量，難以出現在垂直於業務的PD、後端的OKR中被執行，這樣只有前端和UED在用愛發電，不可持續。

　　長此以往，前端越來越偏資源，做的事情都不是大家的重點。大家對於體驗的感知也只是浮於摳摳文案改改佈局這種表面問題上，這讓體驗改進無法有效影響業務和拿到產出，這是發生在每個前端身上非常殘酷的現實，也是大家都在困擾的事情。

　　如果這麼去設定OKR去做這個專案，是很難能拿到結果的。我相信大家都會有和我一樣的感受，所以結合之前提到的種種思考，我們需要去推動專案組，其中去推動做體驗最佳化的難點是：

　　1.產品功能迭代是絕大多數PD工作的重點，他們在意體驗，但是缺少強有力理由爭取高優先順序去驅動他們做體驗；

　　2.後端通常有厚重的底層積累，他們對穩定性和成本更關心，很難爭取後端為了體驗去調整功能；

　　3.目標認知不匹配，功能需求的落地對於PD、後端是重要的業務結果，其設定的OKR可以完全對齊業務上下游。而對前端來說只是日常支撐，做得好只是本職，在真正工作中體現不出競爭力。

　　綜上來看，以上問題不解決，體驗治理遙遙無期。

　　解決問題思路

　　面對這些問題，我的思路化成具體步驟如下：

　　Step 1. 找目標、定目標；

　　可主導體驗內容類建設的崗位，去推後端、PD以產品功能為主要工作職責的崗位，不如去推動運營、UED這些橫向的角色，更容易找到相同的價值目標從而影響其它角色。

　　原因是運營角色相比PD，在業務中離使用者更近，他偏向使用者也在意體驗。如果業務中沒有運營，那麼前端或者UED必須有一個要跨職能協同，至少在專案中做好對客分析角色。

　　他們的需求除了來源於一部分頂層規劃外，大部分都是自身或相關係統的使用者訴求，產出結果可以由使用者滿意度來衡量，而使用者滿意度通常又是工單量、諮詢量這些直觀的指標，比較好量化。

　　Step 2. 拆分工作，明確主導位置

　　目標確定後，需要把主導角色明確出來，在過程中也順帶將風險攤開來：

　　體驗驅動類的工作，可由前端、UED、運營去主導；

　　產品功能類的工作，需要由後端、產品去主導；

　　為什麼這麼做？主導權不是功利，而是為了達成業務目標所需要的不同崗位職責，作用是負業務責任和把控執行方向，去做拆分可以讓相應優勢的角色負起應有的責任。

　　這裡會讓後端或PD產生不適感，因為體驗驅動這部分工作，可能在慣用使用產品功能去解決問題的同學眼中，認為解決不了具體問題，面臨這種質疑，這裡建議我們也至少需要做到兩點：

　　1. 給出充分的調研資料去證實：

　　我們在這次改版中找了能代表不同場景的多位使用者參與到體驗改版的過程管理中，他們留下的體驗感想是非常重要的，既能夠說服大家，也能夠給我們信心和動力。

　　2. 給予PD及後端功能最佳化相關的輸入：

　　我們在改版中分析了很多工單，暴露了很多使用者視角對功能問題的反饋，這些作為體驗改版中的產出，也能為第二波功能類最佳化的工作提供非常有價值的輸入；

　　Step 3. 做好專案管理，降低專案風險：

　　我的建議是，在橫向崗位主導的體驗最佳化專案中，不能強依賴後端開發做高成本投入，否則容易出現：

　　“後端同學搞某個更重要產品功能去了，暫時沒時間投入，這個要不先放一放吧？”

　　原因很簡單也非常能夠理解，資源總是容易流失到更加重要的專案中，橫向推動的專案管理一但出現風險，可能就直接面臨失敗，一但失敗後續再想發起就沒這麼容易了。

　　好不容易拉起來的隊伍，重新建立信任關係、應對各方挑戰的成本太高。

　　 小結

　　在這個專案中，我給自己的要求是除了專案產生的業務價值外，還要讓每個參與的角色都有自己堅持的信念以及想要的收益，寧願不做也要拒絕用愛發電：

　　對於UED，透過這個專案可以找到他從開始就一直在堅持的設計價值，而且這個專案提供了資料和目標支撐，讓他的堅持更加有說服力；

　　對於運營，可以透過這個專案讓他走得更遠做得更多，完全可以達到甚至超越由PD推進的產品功能改進所產生的業務價值，這對於運營和PD在同一個團隊良性競爭的現狀來說，這也是他所需要的；

　　對於前端，我們透過這個專案可以找到前端驅動專案組增值業務的可複用的通用方法論，增強在專案中前端的參與感、存在感。可以經歷整個從籌備到拉通實施的過程，跨過專案領導者和管理者門檻，更進一步成為其它專案的發起者、領導者和管理者。