昨天在〈將產品負責人與團隊經營者分開〉有聊到，假設有成員身兼需求提出和經營管理團隊的職責，很容易因為不對等的關係，導致將過量的工作強塞到團隊身上，團隊也難以抵抗。然而，就算是只有負責產品的職責，也很容易因為整體組織帶來的壓力，導致團隊不得不硬吞下來。「某某客戶說有這個功能就會買我們的服務」、「這個 Bug 會讓公司流失掉多少客戶」等等，若是產品負責人夾帶著如此似乎動搖公司營收的理由，要求開發團隊限期內完成，那開發團隊就像被整個公司霸凌一樣，不得不勉強答應。但是有經驗的你我都知道，長期這樣壓榨開發團隊的情況，最後產出的產品通常都會不穩定、甚至到不能用。

所以，在討論待辦清單時，必須讓團隊與產品負責人處於對等的關係，讓團隊有權拒絕產品負責人無理的要求，讓產能與品質能夠維持穩定。這種拒絕的權利，會迫使產品負責人作出抉擇，到底什麼需求是急迫的、什麼需求其實無關緊要、甚至有什麼需求只是來自於外部的幹話。產品負責人會不得不扛起自己的職責，研究產品到底該怎麼發展，哪些功能是必要的、哪些功能只是噱頭但沒有也可以，暸解哪些 Bug 是會造成大量使用者不滿的、或是造成產品崩潰的，有些 Bug 是有辦法繞過的、或是其實會踩到這個 Bug 的使用者數量很少。當產品負責人暸解這些資訊後，才有辦法擬出需求的優先順序，讓團隊在維持一定的產能下，逐一滿足。

在擬出優先順序後，產品負責人就可以開始和開發團隊協商，並詢問那些需求的成本。比如說這個禮拜如果要做 A 的話，只能再塞個 B、C，但是不做 A 的話，就可以做 B、C、D、E、Ｆ。於是在與開發團隊估算成本之後，兩者協商最近一次開發週期要做哪些事情，而且是以開發團隊有高信心水準下能夠完成清單的所有需求，也就是在沒有遇到意外或是額外的插入事件時，可以全部完成。在這時候，開發團隊就等於在向產品負責人做出承諾，所以在評估時千萬不要勉強，寧願留點餘力而不要硬扛，提早做完還可以把時間做點還技術債的事，但若是發現做不完，可能就會逼迫自己熬夜、欠下技術債，這樣都會讓未來的產能降低。

專業的程式設計師就應該重視承諾，不對做不到的事情作出承諾，一旦作出承諾就一定要完成。因為倘若失信了，就會破壞兩方的信任感，導致關係惡化。這部分是有可能產生蝴蝶效應的，單純沒完成某項需求的這件事，不只事沒完成對產品負責人的承諾，而會有更多的傷害。當開發團隊失信了，那麼可能也會導致產品負責人基於相信開發團隊，而對組織其他人或是產品使用者作出承諾也失信了，造成組織信譽受損等。而當開發團隊不值得信賴時，在產品的長期規劃就會出現困境，產品負責人很難對組織交代出一個明確的計畫，整體的氣氛就會呈現低麋與不安。

所以，規劃是要經過協商有一個很重要的目的，就是要培養雙方的信任感。藉由團隊有權利拒絕無理的要求，換取能對產品負責人承諾答應下來的需求一定會做到，而產品負責在要求開發團隊做出承諾外，也要承諾不會在這份清單完成期間，隨意插單（肆意的新增要完成的項目）。如果真的有插單的必要，就必須再開啟一次協商討論，看插入某項需求後，要把哪個需求從清單上清除，而不會在原本的負荷下再增加負擔，而是以交換的方式進行。

然而，在協商時難免會遇到兩方出現衝突或是討論失焦的情況，這時候作為第三方、擔負經營團隊角色的成員，就需要以客觀的角色協助兩方順利交流、溝通，並透過一些會議技巧去主持協商過程了。