寫到這邊，在回顧一下在建立SPEC相內容一些小Tips，這些Tips讓整個產品開發運作，加強運作順遂。

• 在寫規則的時候，要注意判斷是依據這一個規則，所需要的幾個決策面判斷，由上而下、由大到小、重要到不重要順序做排列，這樣可讓工程人員先進行做一個規劃，並且讓使用者體驗上可以了解那一些是核心功能。

• 在講解規格時，不會真的有人馬上就記得SPEC是什麼？直到真正實作，才會開始記憶，所以要有一個心理準備要時時的跟相關人員，不斷重複說明相關規格。

• 時程管理，將把整個專案最終的時間點拉出來，將所有的功能和事項，全部放進去之後，它就是一個最主要的時程，但是會因為開發進度做事情內容的調整，原則上也是要符合這些主要的功能規劃以及MVP的核心功能。

• 敏捷開發，可能規劃100個功能，但是需要挑出核心的主要功能，作為MVP的執行方向，當MVP做完之後，再考量說哪一些功能是對於整個服務上面有用的直接效益的功能。

• MVP怎麼挑？MVP怎麼挑的方式其實最簡單的方式，就是那一些功能是可以讓產品獲利的服務，那這就是最主要的核心項目。

• 如果開發的產品有跨平台（APP, WEB)，功能開發發布機制，可以採用不用送審的平台先進行功能發布(Web, API)，先行Release運行及測試；APP(iOS, Google)的原生性APP需被平台審查，後面一點開發完release。

• 版本控制

  • 迭代iteration：註記每次版本的更迭項目。

  • 編年史Chronicle：註記重大時間軸及Milestone。

• 交付時的過程一定會遇到很多不同面向的人的討論包括工程師測試人員或者是業務人員這些面向他們都會有當下都會有不同的聲音或者是會有此相反的意見，那這時候要做的方式就是把產品的主軸拿回來排階段性的去更迭不同的項目，回到當下這一個功能這個產品在現在所需要解決的問題或者是在未來的半年可解決什麼樣的問題？這一個解決方式來做拉回的動作。

• 那當然一定會有遇到衝突的時候那衝突的時候還是回到如何去讓事情繼續運作下去避免讓事情無法往下走，這時候PM的態度就會變得非常的重要要包容所有的負面情緒，但還是要堅定地讓事情往下走。

Take away

產品規格目的是讓工程團隊，可以理解該功能，因此內容要設想閱讀者，不是24小時參與整個討論，要如何讓該類使用者，在閱讀時減少疑惑，也就減少了討論時間。

團隊開發總是一定會遇到很磨合狀況，當有將要發生劇烈討論或變化之前，需要先預想出最好和最壞的解決方式，以能讓專案運行。