原創不易，求分享、求一鍵三連
前段時間有個粉絲問了一個問題：
小釵你好，我十分喜歡技術，但真的轉到工程團隊後又十分困惑：工作沒人評價也沒人push！
做得好沒人誇獎，做得差沒人批評，工作自由，幾個月不產出也沒人問，這樣下去感覺得廢啊...
很好的問題，該同學從業務團隊轉崗至工程團隊後難以適應，表面原因是該同學自己找不到技術創新點，甚至也不太“自律”，所以慢慢“隨波逐流”了。
其實這裡進一步原因是：對於業務團隊，上層有大量運營、產品天天抓破腦子想需求，所以業務團隊目標性會很強，時間節點要求也會很高，業務技術多是解決執行問題，在思考方面的壓力會很小；但技術工程團隊負責的是技術基建，他的業務方多是技術Leader們和自己，技術基建工作涉及到大量的技術選題和真實難題發現，這需要大量資訊輸入與獨立思考，而多數人並不擅長資訊輸入與思考，自然也很難做出令大家受益的技術服務了...
因為工程團隊其實是服務於技術團隊的，他代表了技術團隊的創新能力，做得好可以提升技術負責人的影響力，做得不好便是技術負責人的後花園，基建工作多數情況和產品業務沒有直接關係，所以很少有業務方會認可技術基建，他們會覺得這是一群“閒人”...
所以，問題的本質是團隊應該在技術基建投入多少資源。
技術基建
業務需求解決的是公司戰略問題；技術基建解決的是技術團隊在公司的地位問題，兩個定位完全不在一個量級，所以業務投入一定會遠大於技術基建。
如果技術基建結果能直接加速業務迭代效率，那麼這個就是好的基建、業務方認可的基建，否則都是在扯犢子。
關於什麼是好的技術基建，什麼是不好的技術基建？結合這些年的工作經歷，給一些例子：
Hybrid框架
很多年前的App全部是Native，隨著業務發展，NA迭代速度慢，釋出痛苦、使用者不更新等問題一再暴露。
這個情況下，Hybrid框架應運而生，一套程式碼三端執行，開發效率槓槓的，於是後續的業務多使用Hybrid開發。
這個Hybrid框架就是非常成功的技術基建，他極大的提高了業務迭代效率。
Hybrid框架導致了一大波紅利，技術人陶醉其中持續繡花，後續也產生了很多進階版本，但每次版本進階，技術人就想做一次系統升級，這會導致極大的耗損。
活動運營平臺
APP體系興起後，對應的營銷活動必不可少，這些活動就像髒水一樣又多又急，如果全部開發多少技術也不夠，為了解決這個問題，活動運營平臺應運而生，讓運營同事自己拖拽完成活動釋出：
活動運營平臺的出現，極大的方便了運營同學，同時也釋放了技術團隊，這是好的技術基建。
活動平臺的出現在公司帶來了一些紅利，於是各個部門爭相效仿都想做一套差異化的平臺，資源投入不小，差異化效果寥寥，這種重複造輪子行為，是一種資源浪費。
重構
一個系統因為年久失修導致事故不斷，業務方怨聲載道，這會影響技術團隊的口碑，所以團隊會做業務重構，這種因為穩定性而發生的少數資源投入，業務團隊也是贊成的；
但業務重構是無止境的，程式碼重構可以一優再優，如果長時間的重構投入，最終影響了迭代速度，那就不是好的技術基建了。
產品體驗
還有一類的技術投入旨在提供更好的產品體驗，這種技術基建正常情況都不會遭到反對，但如果是花大力氣將體驗從99分做到100分，業務方就不會買單了，ROI太低。
好的基建
所以，業務方眼中的好基建無非三種：
- 提升了迭代效率；
- 提升了產品體驗；
- 提升了系統穩定性；
如果一個技術基建的結果與這些無關，那麼在業務方的眼裡都是技術負責人在自嗨，這種自嗨包括那種想要提升迭代效率，但是沒有成功的技術專案。
在技術人的眼裡，評價標準還會額外加一條：自己技術實力是否得到進步，這條標準甚至會優先順序最高，因為這跟他的工資直接掛鉤...
技術人的矛盾
技術部存在的本質工作是完成產品的實現，因此技術負責人會承擔來自業務方莫大的壓力，因為技術團隊需要一個未來、需要一個口碑，所以基建投入是必不可少的；但如果大量資源投入又沒有產出，那他就要揹負藏人的惡名，這導致了幾個結果：
- 技術Leader對於基建的態度很矛盾；
- 做基建被業務方看不起，不做基建被技術和業務方一起看不起；
- 業務開發覺得工程團隊無所事事，是個黑盒；
- 工程團隊覺得業務開發技術平平，只是工具人；
- 因為工程團隊事實上在給技術Leader打工，所以還不得不給不錯的績效，這又會引起一些人的不滿；
總之是不做不行，做多了不行，做了沒效果更不行！
就是因為如此種種原因，工程基建失敗了可以大事化小小事化了，工程基建成功了又要適當包裝大勢宣傳。
失敗沒成本，成功重獎勵，一進一退之間技術氛圍倒是好了，甚至會被渲染為工程師文化，但這造成了很惡劣的結果：不計成本的重複造輪子，這背後的資源浪費是驚人的。
基建的投入問題
“念念不忘，必有迴響”，資源在哪裡，哪裡就會發展，如果技術團隊想要有所發展，基本的資源投入是必不可少的。就這幾年心得：
低於團隊資源20%的技術基建投入是可接受的，10%左右的技術基建是比較合理的，小於5%的技術基建投入是沒有希望的...
舉個例子，Devopts、質效平臺、資料採集、資料監控......這些系統有沒有用，當然有用！但如果技術團隊一年的成本是一個億，請回答以下問題：
- 你願不願意用兩千萬去買上述系統？
- 兩千萬花了，上述系統是不是就好用了？
就我來看，首先是不值得買，其次是未必做得好，如果有成熟的系統，建議直接採買；如果沒有成熟的系統，也要酌情開發。
在某些時候，還會有些特例，會導致技術基建投入超過20%，這多半是上層業務出了問題，技術團隊無事可做，不得已自己找事做，這是非常危險的訊號。
結語
最後回到文章之初的問題，該同學所處工程團隊現在一定屬於“失控狀態”，這裡有可能的原因是：
該工程部遊離在業務邊緣，並不解決業務問題，另一方面技術Leader沒有提供明確的技術選題，也沒有提供足夠的資訊輸入，只是任由工程團隊野蠻生長，就造成了工程部“無所事事”的情況。
如果沒想清楚工程部存在的價值，大可將他們先回歸到業務部門，在想清楚後再重新組建，作為技術Leader要有個認知：
技術創新帶來的業務增量 > 技術基建帶來的效率提升 >= 技術基建帶來的穩定性、效能提升 >>> 技術基建帶來的自我滿足
如果要藏人做技術創新，那就想辦法做ROI最高的那個吧...
好了，今天的分享就到這，喜歡的同學可以四連支援：
想要更多交流可以加我微信：