最近看大家都在做總結，技術文章寫到一半，乾脆我也還是先總結一下吧。從哪裡開始呢，先從小釵大師“看手相”開始吧（美女看手相嗎，我們聊聊管理玄學？），下圖是做的測試結果

小釵大師解卦：

“完美超過18分算是強屬性 所以你有鞭策大家幹活的屬性，而你又是個實幹家，所以很多事喜歡自己下場幹，並且你是強屬性完美者，所以交給你的事情往往能做得很徹底，但會比較固執。 你的轉折點可能是做leader後，推進者屬性會讓你不停的讓專案組按照你的時間點和目標前進，但你又是個完美主義者，可能會要求組員按你的標準來，在一些小問題上糾結，最後容易大家都不開心。”

大師果然是大師，在基於對我的瞭解和“命相”上給出了一些結論，還是很中肯的，對自我認知有很大借鑑意義。

今年由於公司調整，來到了新團隊。回顧這半年多做的事情。大部分產出，都是支援基建提效，或者利用技術方案優化業務。參與過一些業務迭代開發、也擔任過幾個業務迭代的技術owner角色。還作為技術owner承接了一個公司重要專案，時間緊、壓力大、捱罵多、加班程度突破個人歷史最高峰。

基建方面

熟悉了公司devops流程和一部分實現原理，統一優化了前端專案和node服務在釋出系統中apollo配置的整合。

持續迭代的前端監控，解決了公司業務中traceId導致的使用者體驗問題、發現和解決了很多線上反饋或者沒有發現的bug，還發現了能在風控能力上有一定作為，實現了一些監控。系統本身做了優化和提升，提高了查詢效能、節省了儲存空間、豐富了問題追蹤視角。

承接了前端委員會提出的路由控制的問題，設計和開發了前端路由重定向系統，解決連結地址或者生成的二維碼地址傳送給客戶或者三方之後是能修改的問題，對公司內部系統相互訪問同樣適用。同時能夠統計訪問記錄，用以確定對外連結使用情況。也支援短連結功能，縮短地址長度。設計方案在前期還是做的很完善，系統穩定執行中，接入業務也在逐漸增長。下個迭代會和公司泳道完美融合。

和後端同事，合作開發了公共資料圖表平臺，一個內部配置化快速生成圖表的平臺，不需要建立業務程式碼倉庫，也無需發版。通過ETL把業務資料匯入到分析型資料庫，做內部管理臺使用的資料視覺化圖表和表格展示，開發速度快，資料查詢速度快，是一個提效產出的平臺，並且支援嵌入到任何管理臺。目前已經接入了幾個業務統計圖表和供應鏈資料相關的表格。

解決開源工具Jaeger崩潰問題，開發GRPC本地工具WEB版等。

在新團隊之後負責公司的NODE技術相關的建設，公司服務端是使用的GO，因此前端團隊在使用NODE的原則主要是做一些工具或者獨立服務於大前端開發的提效專案。不做業務介面、不做BFF層，避免一個業務介面週期中出現GO和NODE服務相互呼叫的情況（以前有存在這樣的專案，現在已經被GO重構掉了）。

NODE方面，主要是設計開發和技術支援了幾個獨立服務專案，統一了技術選型和開發約定。團隊內部通過開發迭代，拉入了很多前端同學參與進來，前期設計要求比較嚴格，需要經歷需求分析、技術調研，技術評審。整個任務分配比較細，也不會佔用大家太多時間，邊做邊培訓的方式，帶大家學習技術和理解方案設計。總體來說，也是因為有需求和問題需要解決，我們才會介入做相關事情，並不會為了發展技術而發展技術，大家的精力也大都在業務上。

業務方面

有做幾個業務迭代，也做過幾次業務技術owner，都中規中矩吧。有個小程式短視訊優化的需求，大致就是模仿微博短視訊的互動方案做優化迭代，發現滾動條很死板做了一個技術優化方案： JS進度條順滑版實現。平時比較關注自己小組負責的C端核心業務，排查和協助解決了很多線上問題。偶爾也會接到產品技術方案的調研，協助產品分析相關的業務資料等等的事情，經過一些拉扯，對業務的執行情況也有了一定了解。

在業務投入上，顯得比較弱，也有部分原因是這半年多裡，組織調整我換過4個小組，加上最後要說的CEO駕駛艙專案，佔用了我兩個多月的全部精力。

CEO駕駛艙專案

重點說下這個專案的情況吧（專案情況可以通過這篇部落格瞭解：【開源】數字化轉型實操——非要度量效能，從《一分鐘日報》開始）。專案產品就是技術老大葉小釵，最初是在內部群裡說了，需要幾個開發同事做他的專案，對技術有要求。我自己剛好也沒有特別多的業務忙，就第一個報名了，然後就被指定為技術owner了。最初就是開局一張圖，產品原型、具體細節啥的都沒有，講了下需求，給了個三週的時間，就讓先做了。當時實際並沒有在認知上對齊，畢竟小釵和老闆拉扯了一兩個月才想清楚的需求，一張圖說一個小時就讓我們開發了。公司需要解決問題，必須要趕時間，才能趕上一些重要節點。總之還是挺難的，要在規定時間內完成，當時業務也是特別忙，想調動多一點人力都幾乎沒有。中途還有很多實現細節的討論和拉扯，也出現過幾次需求變動。

因為並非是一個非常清楚的產品需求設計，作為owner我也必然會介入更多的思考才能跑通功能並且認可合理性。前期在保障完成核心功能和認知沒有完全對齊的情況下，我是希望能砍一些功能和實現方式。就出現了很多對剛的場景。但小釵是大領導，不像平時和產品溝通，我幾乎是被全方面碾壓，當然這個事情本身也是受限於能力差異與認知差異。

一方面我要思考的更多，一方面我也是全力在開發，時間緊張，工作強度大，加上休息略微不足。我站在我對產品的理解上，希望能給大家減少點開發負擔也同時減少一些不合理的需求。我和小x討論的過程中出現了很多分歧，在自我經過思考後得出了對應的結論，本身比較堅持。但實際上有時候是資訊理解偏差加上自我思維固化導致的，其實自己也不一定就是對的（有時候也是對的）。在自我已經基於分析得出了結論之後，就會很固執，也沒有完全帶入到對方的思維中。這次專案經過了很多拉扯對剛，自己因為固執也捱罵不少，有時候罵了還是剛，還捱罵，當然大部分時候確實是我的問題。

固執會增加很多內耗，也是罵挨多了，就比較有意識的去注意這一點，後面會盡可能多的去站在對方的角度傾聽和思考，有時候聽了也不完全覺得對，但是能理解對方的立場。級別又比對方低，就還是聽大哥的吧！通過很多輪拉扯，認知慢慢也開始對齊了起來，專案也彙報的比較順利，自己也認可了自我的固執不正確，所以後面捱罵的就少了些。

現在想想當時也是很有意思，我每次極力的和小釵對剛，然後剛不下去之後，我就轉身問服務端負責的同事，結果他都是認為小釵現在非常需要這些功能，我們必須完全支援他，爭辯是沒有意義的，其他同事默默吃瓜。最後我都是低頭認慫，繼續幹吧。在這種壓力下，還是比較容易激發出人身上的問題的，經過這個專案我現在也是非常認同我很固執了，我會時常提醒自己很固執這個事情，希望慢慢能改掉這方面的問題（但常常還是很容易會覺得我是對的）。妥協也是一種減少內耗的方式，留一些時間來認證，而不是一定立刻要爭個輸贏（但我有這方面爭奪的強屬性，可怕～）。

生活方面，這次專案封閉式開發，小釵想著大家太辛苦了每天都讓點好吃的外賣（可報銷），飲料隨時供奉（不報銷、花了我不少錢）。生活費超標了不少，經常向我家領導申請多給點錢，異地戀很多年，好不容易到我現在這邊來上班了，剛好就遇到我在做這個專案，每天看不到我人，感覺還是異地一樣。小夥伴們也是相愛相殺到最後相互同情、互相鼓勵，體會到了團隊的樂趣和團結。

今年的詞條

多變

部門調整、四處坐客，不停調整找到適合自己做的事情。

基建

發現問題、提出方案、推動和協助解決問題、收穫成績。

堅持

堅持積極主動抗事、堅持技術學習、有價值的事情堅持做下去。

固執

唉，還真是個問題～