在敏捷的框架中，PO(Product Owner)依照項目的價值，負責決定開發項目的優先順序，也因此許多直接與商業掛勾的需求自然就佔到優先順位，而偏技術的優化就會在權衡之下往後移。

Devops 的精神中，除了跨越開發跟維運的界線，更是讓產品在功能、穩定跟效率之間都取得平衡，而不只是挹注所有的精力在開發新功能上。

所以在 PM 角色中，當提到及決定項目的優先順序時，要考慮的還有技術債的調整項目，當這些項目會影響到產品交付的 Lead Time、系統崩潰後回復正常的時間，這些項目的重要性就可以被標記出來。

其中一個可以客觀顯現優先開發技術債的數據，就是昨天提到的 DORA 指標。

完成這個項目，是否縮短了工程師 commit 程式碼後到正式上線的時間？或者是縮短服務恢復的時間？DORA 指標就是一個 PM 可以說服利益關係人的有力資訊。

取得利害關係人的共識後，PM 在規劃產品撰寫 user story 時，常常只會圍繞功能使用情境規劃開發範圍。但同樣的，在 Devops 的精神加入後，關於系統穩定、安全性的 user story 也變得重要（特別是金融相關的產品）。在盤點需求的前期，就將相關項目標記出來，也避免到最後一刻產品要上線前，才發現重大議題。

另外一個可以跟團隊培養共同默契的方式，就是在工作項目規劃的時候，將 15%-20% 時間讓工程師固定來修技術債，優化開發及維運流程。這樣就像定期保養系統，讓工程師有餘韻可以將優化項目排入時程內，讓技術債跟功能開發不互相打架。