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。
保持今年優異的表現，提升今年不足的方面，開始執行可以優化的工作，停止與關鍵指標無關的工作。