工程師們需要建立自提需求清單

平常在開發上，RD 們可能會產生除 PM/PO 需求之外，自己注意到或想做之事，例如：

某些 RD 導向的需求，PM 會不太理解其對 Project 的幫助（例如程式語言的版本升級，短期對專案不會有助益)，有的則是 RD 自己對 Project 的新想法，想要增加某些功能時，這時 RD 們就會傾向先自行開單紀錄。

然而 RD 們的自提單號優先度往往很低，常常開了放在那邊長灰塵，一忙起來大家就忘記有這個需求。
雖然鼓勵團隊成員自行開單(再通知 PM 排後續開發時間），但每個人開了自己的單號，很容易產生重複開單或者沒有統一單號管理的問題。

具體做法建議

在任務發單系統建立一張主票、母票或主任務為「某某 Team 自提需求清單」
若有自提需求，請大家建立自提需求後，將該單連結或關聯進「某某 Team 自提需求清單」成為子單。
呈上，這樣 Web Team Lead、PM 們統一檢視此單號即可。亦可避免成員間重複開單或開過單但其他人沒注意到。
Web Team 成員都是此單號協作者。
母單號或主任務單號的主要被 assign 者，是能負責管理的人，而子單號由他分配誰發處裡。
- 開單人不一定是實作人，例如團隊成員 A 開了一張 Node.js 要升版的任務，難道後續處理就是他嗎？不對，因為團隊成員 A 可能那幾個 Sprint 很忙，所以主管可以分配給團隊成員 B 在閒暇時幫忙處理。

這點很重要。

事實上，主管或 PM 們不能把產品功能、專案的迭代或修技術債、下水道工程都撇給下屬。因為這張自提需求清單等於是下屬工程師們的百寶袋了，把一些問題或解法提前開票並寫上解法。

並且自提需求清單同時也會是團隊的備忘錄，如果主管沒有意識到，那就不會是「團隊的備忘錄」。主管如果沒意識到，那誰是團隊的頭？文化的推動和產品的改善，始終需要管理職小小小的推動，如果管理職對這張票放著不理，那只會帶來負面效果。

人都會有惰性，並且我始終認為沒有人會自願無償多做事情。光是團隊成員能注意到某些問題並更新自提需求清單、開票其實就已經是很棒的行為。

在 Sprint 週期中，如果有成員提早開發完畢，應該是由主管或前面說的「能負責管理的人，而子單號由他分配誰發處裡」來分配這些自提需求任務。

否則大家一直開票，沒人要處理，那團隊或產品不會更好，並且有一點很重要：

發現問題的人不一定有解決問題的時間或能力，但這不代表他發現的問題沒有意義。

不能因為有人建立了這個清單，主管就不理了，如果主管沒有協助分配，那只會導致在意的人很在意，不在意的不在意，既然誰在乎誰痛苦，那最後乾脆大家都不要開票不要處理了，我東西做完就等下班就好了不是嗎？所以我認為自提需求的核心仍然是在主事人（主管或 PM）身上。

所以這個清單也會是主管和團隊應該要約定好，三不五時拿出來審視的公同目標。