自己團隊所提出的需求是指性能優化、技術棧升級、架構調整等需求，偏向於技術範疇。
要推動這類需求，除了自己團隊的努力之外，還需要一些外在的輔助因素。
一、時機
對於我們自己團隊內部就能消化的需求，主要的問題就是人員，只要人員充足，那麼就能慢慢推進。
而對於那些需要跨團隊協作的需要，那麼就需要在合適的時機推進。
1）大方向
這個需求是符合公司大方向的，這樣才能得到足夠的重視和適當的資源。
例如公司今年提倡開源節流，正好我們團隊有一臺老舊服務器，計劃遷移到另一個雲服務上，預計可以節省多少錢。
那臺服務器運維也不太好維護，還沒發佈系統，遷移後就有統一的發佈平臺，維護代碼也方便。
2）上級認可
這個需求的價值可以獲得上級的認可，例如公司在快速發展期間，前後端項目是整合在一起的。
由於界限模糊，經常出現講不清楚的情況，導致人員之間出現爭議，順勢就提出了前後端分離，也得到了上級的同意。
不過執行週期很長，這是一個長期的需求，並且依賴服務端的人員要充足，還得有檔期。
3）優先級
這個需求的優先級是否可以被拔高，符合大方向以及上級認可的需求多了，很多可能就是重要而不緊急，那最多也就給箇中的優先級。
得不到強有力的推進，往往就會一直被擱置拖着。例如將一個熱榜頁面從 jQuery 改造成 Vue。
自己團隊的功能早就完成了，但是 QA 一直沒有資源，然後最近遇到一個契機，那就是熱榜的接口出現了大量慢響應。
而這個慢響應正是我們組的核心指標，需要竭盡全力解決的，於是順勢將接口改造，由我們組做轉發改成直接調用服務端的接口，即前後端分離。
此時，也有理由強勢的讓 QA 出人來支持此需求，一個拖了幾個月的需求，在一週之內就被完成了。
二、人和
人和分爲兩個方面，第一個是對外，第二個是對內。
1）對外
第一個對外針對的是協作團隊，或其他部門的人。
首先可以明確，這些需求的受益人基本上都是我們團隊自己，讓其他團隊參與都是在增加他們的工作量。
也就是說，對於那些中低等級的需求，協作團隊是有可能拒絕買你的賬，或者就一直推脫着。
爲了能讓他們配合，除了上述所說的時機之外，還需要利用點軟技能。
讓他們心理上願意配合，和強制讓他們配合，肯定是選前者最佳，不要讓他們有怨氣，爲了做到這點，日常工作中，得多多積累人氣。
例如之前有個性能優化需要客戶端做改造，有點工作量。
由於之前在他們有難的時候，我們組沒有磨磨唧唧，直接伸出了援手，所以這次也爽快的答應了。
一些需要業務方配合的工作，他們也會積極響應。
因爲日常他們有問題向我們團隊詢問時，都能得到有效而及時的答案，若是需要其他組的人查，我們也會告訴他們找誰，秉承事事到我爲止。
我一直希望我們團隊中的成員對於別人的疑問都能給予有價值的反饋，回答都是肯定句，而不是模棱兩可的話術。
2）對內
第二個對內針對的是團隊成員，即自己組的人。
首先就是要想推進需求，必須得有人，2021 年的時候，人員不足，只能疲於應付各類業務需求，完全沒有時間搞其他需求。
2022 年的時候，不僅我們組加人了，其他團隊也加了充足的人員，此時才能展開我們想要推進的工作。
團隊成員的意向也非常關鍵，他們是否認可這個團隊需求。需要塑造一種開放的團隊氛圍，要所有成員都能暢所欲言。
若他們反對，可提出改進方案或者拿出他所設計的方案，大家再討論，在內部達成一致後，再開工，有點攘外必先安內的意思。
還有就是需求是否科學，即符合當前團隊所能承載的能力，以及有較高的 ROI。
例如之前有成員提出集中人力和資源去研發低代碼，但是考慮到公司的業務特點，目前還並不需要，但可以做些簡化，提升工作效率。