一、日常問題
1）需求的討價還價
做最大的努力，維護自己團隊成員的開發利益。
產品和運營會根據他們的業務來提出需求，從他們的角度來說，這些需求無可厚非。
不過，他們提出的需求，在實現時有些改動會比較複雜。那麼就需要與他們協商。
協商的目的不是砍需求，而是用一種更合適的方式實現，既能滿足他們的需求，也能最小化的變動代碼。
一般會先了解下需求的背景，他們爲什麼要這個需求。例如有個標籤需求，產品想將標籤的狀態和另一個審覈系統的狀態有所關聯，那麼她希望將標籤在審覈中的每一步都能提醒到標籤列表中。爲此還畫了張狀態流轉的表格。
我們在分析後發現，其實狀態可以精簡到3種，至於其他審覈相關的狀態，若業務有需要，可以從歷史審覈中去查找。並且運營其實也不需要了解審覈的細節，只需要一個結果就可以了。
這個需求和更改後，改造成本就比較低了。大家都得到了滿意的結果。
上述是與業務之間的討價還價，經常性的，在與技術部的其他組協作時，也會涉及需求實現的討價還價。核心就是明晰職責邊界，減少開發成本。
例如有個專題頁的評論功能，產品希望能和審覈系統打通，還有評論的功能可以和客戶端中的評論功能一致。
如果自己實現一套評論功能，那着實要有很大的開發量，關鍵是否能做到複用。既然現在有一套評論，那直接沿用，成本是最低的。所以就需要讓服務端介入，提供評論的接口，我們來做專題頁與現有評論的關聯。
未來，與評論相關的活動頁或專題頁都能對接這套系統，這樣對於我們組來說，實現成本也是最低的。
有時候在QA驗收時，他們也會提出一些需求意見，這些意見會讓用戶體驗更好。我們在收到這些意見後，需要自己做權衡。
首先要去核對需求文檔，看看是否有這一條。這步很關鍵，因爲漏了需求，那就明顯是我們的問題了。如果沒有，那可以作爲一種依據。
然後就是出於性能和可維護性的考慮了，如果改動比較簡單，那順手做下，皆大歡喜。
反之，若改動巨大，那就要和產品明確潛在的風險，以免釀成線上事故。
2）各類兜底
人員離職和成員休假，都是團隊內會正常發生的事情。
人不在，公司業務還是照常在運營的，所以或多或少還是有需求要處理的。
對於那些不緊急的需求，可以等到招到合適的人或休假回來再處理。
對於那些比較緊急的需求，就要着手安排解決，但是小團隊的人員比較少，每個人手上都會有固定的業務在處理，可能就無法騰開手處理太多別人的需求。
那就需要由我來處理了，將這些需求兜底。
其實在日常，各類突發事件、比較難纏的遺留問題、團隊協作制訂方案等等，總之那些比較難搞的人和事，都得需要我去臨時兜底處理。
所以我的時間比較碎，無法去處理比較大的緊急需求。
二、工作優化
1）想的多點
公司APP的版本做了一次比較大的升級，我們這邊後臺有個配套的功能，也要跟着升級。
而這次升級，會比較考驗電腦的性能，所以在正式放開之前，讓公司內的相關人員都動手操作了一下，看看結果。
雖然想到了全職員工的電腦，但是忘記了兼職人員的電腦。於是，在放開前的兩天，急急忙忙的適配優化兼職人員的電腦。
之所以自己沒有想到，是有幾個原因的。
- 第一，是自己並沒有完全參與這次升級，只是旁聽，具體的執行由團隊的另一名成員完成。
- 第二，不曾覺得我們這邊有什麼會影響發版的點，所以也就沒有特別重視。
- 第三，過於依賴測試團隊，以爲只要他們能把關好頁面質量，就沒有其他問題了。
- 第四，團隊成員經驗尚淺，有些事情我還得幫襯一下，而這次放的太開，自己偷懶了。
所以的話，技術部重要的事情，只要與我們相關，我都得心裏有數，必要的時候，需要深入參與，避免再次有遺漏。
2）QA資源不夠
現在公司的 QA 主要在處理 APP 版本和重要活動，對於其他不緊急的需求經常沒有人測試。
這些不緊急的需求就包括我們組自己推進的基建工作，技術棧升級，用戶體驗優化的功能。
一般用戶體驗優化的改動都比較小，也不會影響營收，那麼就會先讓業務方在預發環境驗收，沒問題的話，就直接上線了。
但其實有時候還是會有問題的，例如之前讓運維給靜態頁面配CDN，但是他配的參數有問題，自己也只是粗略測試，上線後影響好多頁面無法訪問，妥妥的事故。
大部分的基建工作（例如前端監控、BFF、低代碼等）都會創建新頁面，並且也不影響業務，所以經常都是直接上線的。
不過問題也是有的，例如前端監控的參數採集一開始沒走異步隊列，就直接把服務器給搞垮了，又妥妥的一次事故。
不過好在，這些事故都不會影響線上業務，若會影響線上業務，例如充值，那就要好好斟酌了。
技術棧升級就比較謹慎了，因爲網頁中的體驗要保持一致，若有問題，那麼就會有投訴。
但也不能等 QA 釋放資源，所以我們會先和業務方拉個羣，將升級後的頁面先交由他們來驗收，驗收週期可以長點，多多發現問題。
再給到 QA 的時候，他們的問題也能少點，測試也能順利點。
3）2022 年終述職
今年的年終獎計算公司又玩出了新花樣，在 360 評測的基礎上，又加了個述職環節。
讓各個組彙報下今年的成果，包括年度工作回顧、年度工作成果、團隊成果與公司的核心價值的關聯以及團隊年度 KISS 評價。
好在今年我們組寫了許多工作文檔，我讓組員都去列舉自己今年完成的工作，標註重點，以及個人簡單的總結。
我在自己寫出第一版後，就讓組內成員閱讀，然後再提出補充意見，大家陸陸續續提出了 10 多條意見，讓文檔更爲完善。
工作回顧就是列舉今年的重點項目，寫出選擇原因、成功、覆盤和學習與成長，我列舉了兩個項目，都用數字來描述它們的重要性。
例如榜單活動，列舉了此類活動佔比，成果就是 BUG 數和用戶滿意度評分，在覆盤中重點描述了優化過程，以及經驗總結。
例如組件化與抽象化思維的推廣，還有研發活動工具，縮短上線時間，壓縮上線步驟，解放生產力等。
在工作成果中，列舉了本組的北極星指標和關鍵指標，並詳細描述了優化前後的數據對比。
公司的核心價值是營收，日活，社交數據，用戶體驗等，我們組的價值是業務支撐和用戶體驗。
除此之外，還希望在更深入的理解業務的同時，能借助自身的技術背景，主動發掘一些能提升用戶體驗、營收等公司核心價值的點。
KISS 評價包括 4 部分，K-Keep、I-Improve、S-Start 和 S-Stop。
保持今年優異的表現，提升今年不足的方面，開始執行可以優化的工作，停止與關鍵指標無關的工作。