有時候我們在執行專案的時候會遇到一個狀況，工程師實作的東西跟預期的不一致，因此能夠正確傳達需求是一個重要的技巧。原本我認為應該就是規格說明清楚就沒問題了，實際上事情卻沒有這麼單純。
識別角色
要能正確地說明規格，需要先了解現在我們討論的對象是怎樣的角色。像是專案經理、技術主管或者是負責實作的工程師。
之前有遇過客戶每次給我們的都是 MRD（Market Requirements Document，市場需求文件）因此讓我們的 PM（Project Manager，專案經理）需要花非常多時間了解系統上的需求，再跟工程師傳達。然而，經過這樣一連串的轉述，有非常多訊息都已經消失。實際上，對負責實作工程師來說比較有幫助的是描述需求跟規格的 PRD（Product Requirement Document，產品需求文件）也就是說，我們卡住的原因是因為需要反覆的從客戶提供的「市場需求」反推「產品」的樣貌，然而這些資訊大部分對工程師來說可能是一種雜訊。
備註：因為客戶自己有專案經理，因此合約中我們的專案經理主要負責時程方面的控管，需求由客戶自己的專案經理處理。
定義產品規格
跟「市場需求」會描述在市場上的需要不同，「產品需求」是根據這些市場的需要，定義一個產品應該具備怎樣的規格。其中一種撰寫方式，就是先以功能面向進行大分類，然後再撰寫 User Story（使用者故事）來描述情境。
在製作的階段，我認為會需要由負責撰寫規格的產品經理或專案經理跟技術主管協作，在確認市場、技術限制跟成本的前提下去描述，這樣的文件不是去限制程式該怎麼寫，而是如同測試去動開發是什麼這篇文章中提到的 BDD（行為驅動開發）用「預期的操作行為」來去定義。
有了這樣的文件，負責實作的工程師就能清楚的依據在什麼情況（When）做了什麼事情（Given）然後得到怎樣的結果（Then）去設定測試，接下來只要將實現的功能符合這個定義即可。
減少溝通成本
假設我們沒辦法很好的提供資訊，那麼就會呈現前面所提到的狀況。需要經過不同人的彙整，然後再傳達給其他人。然而因為資訊非常多，因此會變得無法逐步地縮限範圍直到一個工程師可以理解的範圍，最後就變的需要投入大量的溝通來了解實現的方式。
以一個軟體開發團隊來看，必定會有資深跟資淺等不同程度的工程師，每個人能考量到跟處理的範圍是不同的，為了能夠讓比較不熟練的同事能夠專注在正確的小單元工作，清楚描述的文件就變得非常重要。
單純一篇文章似乎沒辦法完整的說明，我認為在專案團隊中過度溝通（Over-Communication）是一個增進團隊協作品質的方式，同時減少溝通成本也是一個重要的方向，兩者也不衝突。前者是讓團隊成員理解在做什麼，後者是減少理解的成本，因此正確傳達規格給工程師就變得非常重要。
封面圖片使用 Unsplash 上 Joppe Spaa 的作品，有想聽的主題可以透過匿名問卷告訴我，想了解專業的技術主題可以到弦而時習之找找靈感。
