《我的專案筆記 #21》搞懂規格書，讓你的團隊再也不用通靈 — HeroMi

前幾天在網路的聊天群中，看到又有工程師們在抱怨PM，抱怨什麼呢？不外乎就是規格文件寫得太簡陋，重要的資訊都沒有提供，工程師就頻頻抱怨需要「通靈」，才知道文件到底在寫什麼。

這讓我想到大三的時候，有一門課教授的是專案管理，那時候老師要同學們去找企業實際執行一個專案，在大四的時候進行成果發表。當時，老師要求每組都必須提交一份「專案文件」，其中，老師有提醒要將執行專案的每個畫面，都必須要有規格說明。現在回頭想想，當時的「專案文件」其實指的就是「規格書」，然後亂做一通，不過誰沒有過去呢。

然後，在出社會的第一份工作中，除了畫些人物設定、做做動畫，花了更多的時間其實在寫規格文件，當時有一個專案，除了規劃遊戲的畫面及操作，還需要提供工具的規格文件給外包廠商進行製作。那時也是懵懵懂懂的，好在當時有一位資深的工程師，有提供一個範本，那時才第一次的見識到，原來所謂的「規格書」，需要做很多的功能說明。實際和工程師溝通時，還是遇到一些阻礙，總是覺得我說得很清楚，但是好像沒人聽得懂。

之後，有一次和廠商的開會中，不經意的看到某國外大廠要求的規格書範本，又讓自己長了見識。原來規格書還需要很多看起來是流程圖的東西。

心裡覺得，一份規格書要準備的內容還真不少。

正當以為已經理解一份規格書的內容時，沒過多久，隔壁的技術主管跑來說，「廣三，這個專案的資料庫設計，也要麻煩你了。」，心想「資料庫？這也是要我設計嗎？學生時是有學過，但是要規劃資料庫，實在是令人恐懼。」。不過，也讓我知道，原來一份規格書，還需要資料庫的規劃。

在接下來的職涯中，和越來越多的工程師交手後，也慢慢的悟出，一份規格書需要的內容是那些。

其實，會看規格書的人，不是只有工程師而已，而是整個團隊都會參照這份規格書來進行開發。另外，你的需求方，像是老闆、客戶、還有其他單位的同事，也是有機會看這份規格書的，如下圖。

也因為如此，看這份規格書的人實在是太多了，於是對規格書的需求就越來越多，相對的，規格書也就變成一個相當重要的工具。因為，「開發都會依循這份規格書的內容去執行。」

那每個人想看的是什麼？

客戶想看的，是這個產品做出來長怎樣，起碼要能想像，符不符合想像，很多時候客戶對於自己的需求是無法想像的，我們要做的就是將它具現化，起碼在確認需求階段就可以讓客戶知道大概長怎樣，減少打掉重做的機會。

老闆想看的，是這個產品做出來後，能不能替公司帶來價值，有沒有賺錢的地方，有沒有考慮到會員儲值、消費的地方，而我們要做的，就是要讓老闆知道，這些賺錢的功能，我們都有考慮進去。

其他單位想看的，例如營運單位，他們要的就是有沒有地方可以看到營收分析、會員人數統計、消費分析…等，各種數據指標，而我們要做的，就是規劃這些商業數據分析的後台報表，讓這些單位知道，我們也都有考慮進去了。

設計師想看的，是這個產品總共有多少畫面，大概長怎樣，不要讓我自己想像，有沒有具體的範本或參考依據，而我們要做的，就是提供清楚的畫面需求，有哪些圖片需求、按鈕配置，或是一些特效演出。

前端工程師想看的，是這個產品的畫面的交互關係是什麼，操作邏輯是什麼，怎麼切換畫面，而我們要做的，就是提供每個畫面的關聯，描述每個按鈕點下去會發生什麼事。

後端工程師想看的，是這個產品的畫面要那些資料，要怎麼提供，怎麼計算，還有每個按鈕點下去後，要怎麼處理，而我們要做的，就是這些資料的規則、計算公式，還有就是每個功能的判斷流程、規則，還有邏輯。

IT人員想看的，是這個產品的系統架構大概長怎樣，要怎麼去規劃各項服務、系統配置，還有資料庫的設計，而我們要做的，就是提供整個產品的系統功能規劃，讓IT人員可以去進行規劃。

天啊，一份規格書居然包含這麼多的項目，有畫面、有流程、有規則，還有各種資料及邏輯。在之前的文章提到的「循序圖」，其實就是用來協助說明「流程」的一種工具而已。

一份產品的規格書，其實在動手撰寫之前，要先想一下，會看這份產品規格書的人有哪些？而不是拿到需求後，就開始著手撰寫，這樣很容易陷入「見樹不見林」的狀況，到頭來，你寫的很辛苦，但是客戶及團隊卻通通不買單。

舉例來說：

設計師想看到的產品畫面，其實主要是希望知道產品的畫面配置，文字、圖表、按鈕的大概位置，如下圖，當然有些設計師甚至會希望提供尺寸，但是這部分可以和設計師溝通，是否可以由設計的專業出發，進行尺寸的最佳配置。

那前端工程師想知道的是甚麼？

其實最主要的項目就兩個，畫面與畫面之前的關聯，以及API的串接，至於什麼是「API」，可以參考先前的文章《搞懂前端與後端，成為工程師的神隊友》，裡面有一些說明。

如下圖，前端工程師想知道的是點擊「立即登入」後，會切換到哪一個頁面，或是會呼叫哪支API，而這個範例中，就會去呼叫「登入的API」，然後將API需要的參數傳給後端。

那後端工程師要知道的東西是什麼呢？

主要會想知道流程、規則，符合條件會怎樣，不符合條件又會怎樣。

例如，點擊「立即登入」後，要進行的流程判斷，大概是像下圖的東西。首先會檢查AAA，符合就繼續往下，不符合就顯示提示訊息，告知使用者錯誤的回饋；然後繼續檢查BBB，直到全部的條件都符合後，就完成登入的檢查，並進行畫面的切換。

另外，下圖的內容，也是前端工程師會需要知道的，因為「顯示提示訊息」，通常都是由後端提供給前端，再由前端進行顯示，也就是說，這份文件裡面，有相當多的部分，會是「團隊成員需要共同確認」的內容，並非單一成員確認即可。

有沒有覺得一份規格書要寫的內容居然這麼多？其實，規格書的精神不在於是不是真的要能寫出這些東西，而是它是一個用來進行資訊同步與確認的工具。不然，我們討論一個規格，最後我說的是A，但是你理解的是a，這樣的討論就完全失去意義了。只要能達到溝通的目的，這樣的規格書是用word、excel、PPT，還是其他專門用來寫文件的工具，甚至是白板，其實都可以。而我自己後來最常使用撰寫文件的工具，就屬PPT和Axure了。

今天大概說明了一些關於規格書，可能會需要具備的內容，接下來會一一介紹其他相關的內容，希望可以幫助在開發過程中，和你的開發團隊可以好好的溝通。

搞懂規格書，讓你的團隊再也不用通靈。

若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。

🔗前往分析連結

---

歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi

《歡迎加我LINE，一起破局未來》

*本站所有文章未經授權，請勿任意利用、引用、轉載，但是歡迎按讚、訂閱、分享。