<input id="ohw05"></input>
  • <table id="ohw05"><menu id="ohw05"></menu></table>
  • <var id="ohw05"></var>
  • <code id="ohw05"><cite id="ohw05"></cite></code>
    <label id="ohw05"></label>
    <var id="ohw05"></var>
  • 技術管理進階——把控基建與業務的比例和節奏

    原創不易,求分享、求一鍵三連

    前段時間有個粉絲問了一個問題:

    小釵你好,我十分喜歡技術,但真的轉到工程團隊后又十分困惑:工作沒人評價也沒人push!

    做得好沒人夸獎,做得差沒人批評,工作自由,幾個月不產出也沒人問,這樣下去感覺得廢啊...

    很好的問題,該同學從業務團隊轉崗至工程團隊后難以適應,表面原因是該同學自己找不到技術創新點,甚至也不太“自律”,所以慢慢“隨波逐流”了。

    其實這里進一步原因是:對于業務團隊,上層有大量運營、產品天天抓破腦子想需求,所以業務團隊目標性會很強,時間節點要求也會很高,業務技術多是解決執行問題,在思考方面的壓力會很小;但技術工程團隊負責的是技術基建,他的業務方多是技術Leader們和自己,技術基建工作涉及到大量的技術選題和真實難題發現,這需要大量信息輸入與獨立思考,而多數人并不擅長信息輸入與思考,自然也很難做出令大家受益的技術服務了...

    因為工程團隊其實是服務于技術團隊的,他代表了技術團隊的創新能力,做得好可以提升技術負責人的影響力,做得不好便是技術負責人的后花園,基建工作多數情況和產品業務沒有直接關系,所以很少有業務方會認可技術基建,他們會覺得這是一群“閑人”...

    所以,問題的本質是團隊應該在技術基建投入多少資源

    技術基建

    業務需求解決的是公司戰略問題;技術基建解決的是技術團隊在公司的地位問題,兩個定位完全不在一個量級,所以業務投入一定會遠大于技術基建

    如果技術基建結果能直接加速業務迭代效率,那么這個就是好的基建、業務方認可的基建,否則都是在扯犢子。

    關于什么是好的技術基建,什么是不好的技術基建?結合這些年的工作經歷,給一些例子:

    Hybrid框架

    很多年前的App全部是Native,隨著業務發展,NA迭代速度慢,發布痛苦、用戶不更新等問題一再暴露。

    這個情況下,Hybrid框架應運而生,一套代碼三端運行,開發效率杠杠的,于是后續的業務多使用Hybrid開發。

    這個Hybrid框架就是非常成功的技術基建,他極大的提高了業務迭代效率。

    Hybrid框架導致了一大波紅利,技術人陶醉其中持續繡花,后續也產生了很多進階版本,但每次版本進階,技術人就想做一次系統升級,這會導致極大的耗損。

    活動運營平臺

    APP體系興起后,對應的營銷活動必不可少,這些活動就像臟水一樣又多又急,如果全部開發多少技術也不夠,為了解決這個問題,活動運營平臺應運而生,讓運營同事自己拖拽完成活動發布:

    活動運營平臺的出現,極大的方便了運營同學,同時也釋放了技術團隊,這是好的技術基建。

    活動平臺的出現在公司帶來了一些紅利,于是各個部門爭相效仿都想做一套差異化的平臺,資源投入不小,差異化效果寥寥,這種重復造輪子行為,是一種資源浪費。

    重構

    一個系統因為年久失修導致事故不斷,業務方怨聲載道,這會影響技術團隊的口碑,所以團隊會做業務重構,這種因為穩定性而發生的少數資源投入,業務團隊也是贊成的;

    但業務重構是無止境的,代碼重構可以一優再優,如果長時間的重構投入,最終影響了迭代速度,那就不是好的技術基建了。

    產品體驗

    還有一類的技術投入旨在提供更好的產品體驗,這種技術基建正常情況都不會遭到反對,但如果是花大力氣將體驗從99分做到100分,業務方就不會買單了,ROI太低。

    好的基建

    所以,業務方眼中的好基建無非三種:

    1. 提升了迭代效率
    2. 提升了產品體驗;
    3. 提升了系統穩定性;

    如果一個技術基建的結果與這些無關,那么在業務方的眼里都是技術負責人在自嗨,這種自嗨包括那種想要提升迭代效率,但是沒有成功的技術項目。

    在技術人的眼里,評價標準還會額外加一條:自己技術實力是否得到進步,這條標準甚至會優先級最高,因為這跟他的工資直接掛鉤...

    技術人的矛盾

    技術部存在的本質工作是完成產品的實現,因此技術負責人會承擔來自業務方莫大的壓力,因為技術團隊需要一個未來、需要一個口碑,所以基建投入是必不可少的;但如果大量資源投入又沒有產出,那他就要背負藏人的惡名,這導致了幾個結果:

    1. 技術Leader對于基建的態度很矛盾;
    2. 做基建被業務方看不起,不做基建被技術和業務方一起看不起;
    3. 業務開發覺得工程團隊無所事事,是個黑盒;
    4. 工程團隊覺得業務開發技術平平,只是工具人;
    5. 因為工程團隊事實上在給技術Leader打工,所以還不得不給不錯的績效,這又會引起一些人的不滿;

    總之是不做不行,做多了不行,做了沒效果更不行!

    就是因為如此種種原因,工程基建失敗了可以大事化小小事化了,工程基建成功了又要適當包裝大勢宣傳。

    失敗沒成本,成功重獎勵,一進一退之間技術氛圍倒是好了,甚至會被渲染為工程師文化,但這造成了很惡劣的結果:不計成本的重復造輪子,這背后的資源浪費是驚人的。

    基建的投入問題

    “念念不忘,必有回響”,資源在哪里,哪里就會發展,如果技術團隊想要有所發展,基本的資源投入是必不可少的。就這幾年心得:

    低于團隊資源20%的技術基建投入是可接受的,10%左右的技術基建是比較合理的,小于5%的技術基建投入是沒有希望的...

    舉個例子,Devopts、質效平臺、數據采集、數據監控......這些系統有沒有用,當然有用!但如果技術團隊一年的成本是一個億,請回答以下問題:

    1. 你愿不愿意用兩千萬去買上述系統?
    2. 兩千萬花了,上述系統是不是就好用了?

    就我來看,首先是不值得買,其次是未必做得好,如果有成熟的系統,建議直接采買;如果沒有成熟的系統,也要酌情開發。

    在某些時候,還會有些特例,會導致技術基建投入超過20%,這多半是上層業務出了問題,技術團隊無事可做,不得已自己找事做,這是非常危險的信號。

    結語

    最后回到文章之初的問題,該同學所處工程團隊現在一定屬于“失控狀態”,這里有可能的原因是:

    該工程部游離在業務邊緣,并不解決業務問題,另一方面技術Leader沒有提供明確的技術選題,也沒有提供足夠的信息輸入,只是任由工程團隊野蠻生長,就造成了工程部“無所事事”的情況。

    如果沒想清楚工程部存在的價值,大可將他們先回歸到業務部門,在想清楚后再重新組建,作為技術Leader要有個認知:

    技術創新帶來的業務增量 > 技術基建帶來的效率提升 >= 技術基建帶來的穩定性、性能提升 >>> 技術基建帶來的自我滿足

    如果要藏人做技術創新,那就想辦法做ROI最高的那個吧...

    好了,今天的分享就到這,喜歡的同學可以四連支持:

    想要更多交流可以加我微信:

    : 

    posted on 2022-06-15 17:03  葉小釵  閱讀(1651)  評論(17編輯  收藏  舉報

    国产美女a做受大片观看