為什麼是雜談ㄋ，因為這幾天我太忙了QQ 只好分享一個過去的PM小故事

順便也當成範例來跟大家講講，裡面的前PM到底犯了什麼錯，導致最後大家7pupu

故事是這樣的：有一位前PM初期跟案主討論需求後，給了報價單跟初始規格書也簽了合約，後續案主開始討論開發細節，開始加東西，案主給了一份許願清單，前PM拿到後接了沒有回應，也沒有跟案主討論哪些可以做哪些有問題，但到底要做什麼還是要有個眉目，開發團隊的規格認知跟案主的規格認知不一致，前PM還搞消失導致最後無法結案，最後開發團隊找到我幫忙進場救火

來，歡迎大家可以先花個十秒吐槽一下，想想可能造成的問題有哪些，案主的認知是什麼? 開發團隊的認知是什麼? 再繼續往下看其中出了什麼問題

最大的問題：規格書不明

好啦，我知道你想說前PM溝通很爛沒講清楚又搞消失，對啦也沒錯拉：DDD

大家可能會說，啊有初始規格書也有修正規格書，哪有不明?

當然是因為溝通不明所以導致規格書認定不明阿

這點大概是最淺而易見的問題點了，其實在這整個專案中規格書都不明，初始規格書是一個大的開發框架，PM如果在簽約後才收到案主的許願清單，應該要回去對照初始規格書討論，如果是沒討論到的，就跟案主討論清楚，如果是有討論到的，就去對功能，該拒絕的去拒絕，該追加報價的去報價

絕對不是就放著，沒有答應但也沒有不答應，變成薛丁格ㄉ許願清單

拜託~對案主來說也超困擾的好嗎? 後來開發團隊給了修正規格書，PM也沒有去跟案主確認：我們就做這份修正規格書後，但這份規格書沒辦法包含許願清單的所有項目喔
導致後續案主的認知是：我們要做全部許願清單的功能，而開發團隊的認知是：我們只做修正規格書的功能

那後續解法呢?

當然是去吵架R：D

沒有啦我是說”協商”，在中間來回跟案主討論那些薛丁格ㄉ地方，那我們雙方各退讓一步好嗎? 修正規格書跟許願清單需求有落差不明的部分，不要全做，但也不要全不做，我們來討論看看做個兩成怎麼樣? 剩下三成我們找免費套件幫你解決，雖然不是最漂亮，但至少有功能可以用

大guy 4這樣啦，也跟大家聊一下在我們第一次正面交戰吵架後，案主態度踩蠻硬的，希望還是全做，那怎麼辦呢? 如果還有時間的話，可以用緩兵政策，我們先就修正規格書跟許願清單中，需求重疊有共識的地方先交付，交付後順個毛讓案主也好交代後，我們再來繼續談，剩下有落差的地方之後怎麼做：D