進行專案開發的時候，你會常覺得，規格明明都有寫在文件上，可是為什麼做出來的都和說的不一樣嗎？明明都有說，可是做出來的卻總是東漏西漏，做出來的功能就是不完整嗎？你知道為什麼工程師常常會覺得PM寫的文件，就是寫得很不好嗎？那你知道如何撰寫產品規格書嗎？
曾經有一次的版本更新，發生了這樣的狀況。還記得那時候是QA測試後的BUG分派會議。
QA：「這次上版的功能，好像不完整，有些功能沒有完成，那這些沒完成的功能就先指派給PM，再麻煩PM確認一下這個部分是誰要負責修正。」
PM：「請問是那部分的功能？」
QA：「其實也沒有甚麼啦，小問題而已，就是會員登入的時候，規格書上有說要檢查帳號長度，但是實際上好像沒有檢查到。」
PM：「這個我記得開會的時候我有說，有要檢查帳號的字元長度阿？是漏掉了嗎？請問，負責做這個項目的工程師是哪位？」
前端工程師：「疑？這是我要阻擋嗎？不是後端要做檢查？」
後端工程師：「長度不是前端擋掉就可以了嗎？為什麼要後端檢查？」
QA：「沒關係，我先將這個BUG分派給PM，後續再看看是誰要負責處理。」
這樣的場景，熟不熟悉？是不是覺得昨天自己的團隊就發生過了…。
其實，在剛進入軟體開發這一行的時候，這種狀況基本上不太會出現，因為當年的工程師都是全端工程師，也就是工程師自己負責前端與後端，一個人把自己負責的系統功能做完。
這種狀況，大概是在前端與後端分離的開發模式後，就一直不斷的發生。不過這也是沒辦法的事情，在現在普遍流行專業分工的狀況下，讓前端與後端工程師，各自在自己的領域發揮，確實比較容易有「1+1>2」機會，只是，現況往往是「1+1<2」。
為什麼會這樣呢？
就用上一篇的文章《我的專案筆記 #21》搞懂規格書，讓你的團隊再也不用通靈 中的「登入頁面」來說明，如下圖。
想想看，平常常見到的登入文件，大概會長怎樣？應該是像下面這張圖這樣吧。
這樣的規格書已經算是很清楚在描述「規格」，起碼還圖文並茂。還看過更多的規格文件僅僅寫了一句話「會員可登入系統並可登出系統。」，然後就沒了…。
坦白說，年輕時的我，也是這樣寫規格書的，還寫了好幾年…。
第一次的蛻變：和日本製作人協作開發網頁遊戲
在遊戲O子時期的最後一個專案項目，是和一位日本的遊戲製作人，合作開發網頁遊戲，也第一次正式接觸到日本的規格文件。剛入行寫規格書的時候，那時候被灌輸的觀念，是以寫「書」的方式去寫，但是其實在理解上，非常的不直覺。但是，日本來的規格書，僅僅做了一點改變，我就覺得超有感。如下圖：
大家感覺看看，這樣的呈現有沒有甚麼不同？是不是有把畫面和規則連結起來了？而且更容易閱讀。不再是寫書的方式撰寫，而是用區塊的方式呈現，都是一樣的文字描述，可是卻更容易理解，是不是很神奇。
第二次的蛻變：和中國的專案負責人合作在地化改版
這次負責的專案，是要將一款日文的遊戲，做在地化的改版，其實就是做中文化改版，但是不是只有翻譯，在系統面還是有小幅度的調整。
那這次的改變是什麼？
其實是流程圖上的呈現，以上面的登入流程來說，常見的登入流程應該是如下圖這樣，對吧。
這樣的流程圖看起來好像沒甚麼問題，如果我們仔細思考一下，輸入的驗證碼不是4位數，而是3位數，或是1位數，甚至不輸入驗證碼，那會發生什麼事？
所以，進階一點的流程圖應該會長這樣，如下圖。
這樣的流程圖，看起來是不是更加完整一點？
這位中國的專案負責人看到這樣的流程圖就問了我一個問題，哪些的檢查在「Client」，哪些在「Server」，當下覺得，如果想知道的話，那我就標註起來給你看，一點也不難，呈現就像下面這張圖。當時這位中國的專案負責人只有簡單的說：「這樣就比較清楚Client和Server各自要處理的部分是哪些。」直到多年後，才意會到這樣的思維，大大的提升我和工程師溝通的能力。
第三次蛻變：和循序圖的方式整合
還記得在之前的文章中有提到的「循序圖」，他的基本概念如下圖。
那，「循序圖」的觀念要怎麼整合呢？
其實就是取用他將「參與者、前端、後端、資料庫」這些實體分開的概念，具體呈現就會像下圖這樣。
這樣是不是又更加的清楚一些了。有清楚的介面的設計圖，加上容易閱讀的規格說明，再加上清楚的流程圖，這樣的規格書就完美了嗎？
不不不，因為這樣還是少了一味。
為什麼？
想想看，當你看到「顯示提示訊息」時，會是怎樣的畫面呈現？是下圖的A還是B？
圖A和圖B都是很常見的顯示方式，尤其是在登入的時候。這兩種做法沒有誰對誰錯，只有在執行的時候，「有沒有好好說清楚」，不然很有可能你想像的可能是圖B，但是做出來的時候卻是圖A，然後又是一陣爭論。設計師說：「你又沒有講!!」，PM回說：「你也沒有問阿!!」。所以在撰寫的文件的時候，也務必要定義清楚「提示訊息的樣式」。
那那那，這樣的規格書，應該就完美了吧!?
如果選圖A的提示訊息的朋友，其實還有一個小陷阱。尤其是現在都用手機的時代，更需要特別小心。那就是「關閉提示訊息」的時機，點擊「確認」後關閉提示訊息，應該沒有什麼爭議。但是，就是這個但是，如果點擊的是「黑色半透明遮罩」的區塊呢？請問這個「提示訊息」需不需要關閉？有些產品會關閉，有些不會關閉，這個時候一樣會出現「我覺得要關閉，你覺得不用關閉。」的狀況。
其實，規格書為什麼叫做規格書，就是盡量要把大家對於「規格」的認知拉到同一個點上，盡可以能的降低「我想A，你卻想著B。」的狀況。只是，中文就是這麼有趣…
就像網路上常看到的笑話：
冬天：能穿多少穿多少；
夏天：能穿多少穿多少。
請問，如果只看「能穿多少穿多少」，不就有兩種意思嗎？
沒有前後文，怎麼理解呢？這時候就真的只能靠「通靈」了…。
回到一開始提到的那個案例，其實很多時候我們都會習慣說「我規則都寫在文件上了，你有沒有看？」。
但是，實際上，工程師應該都是有看的，只是，有沒有意識到那個項目原來是我要負責的，這才是重點。尤其是現在高度分工的狀況下，大家都看同一本規格書、參與同一場會議，可是卻都用自己的想像，去決定哪些項目是我該做的，哪些是別人該做的。這樣，就算同步100次，還是有可能會漏掉某些項目。
最後想告訴大家，很多時候，你以為規格寫得很清楚，其實團隊根本就不清楚。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
*本站所有文章未經授權，請勿任意利用、引用、轉載，但是歡迎按讚、訂閱、分享。
留言