作者bachelorwhc (積積陰陰德)
看板Soft_Job
標題Re: [請益]如何有效減少與PM對於規格認知上的差異
時間Thu Jan 12 09:15:50 2023
1. 規格會不會變 跟 應不應該寫規格 是兩碼子事
規格肯定會變，沒有不變的，但應不應該寫規格就看公司文化
有兩派說法：
a. 規格是產品擁有者跟開發者的依據
b. 產品迭代快，產品目前的行為就是規格
實作會錯、test會錯、規格也有可能會錯，只要是人就會犯錯，所以
板友說這是看團隊，不無道理
2. 回到人會犯錯，規格有時會變成政治工具的一種
因為說到底，如果你的公司是犯錯就要究責的文化，那責任出在誰身上，那就很重要
此時規格的目的不再是為了完成產品
3. 規格不好寫
只要規格是用自然語言寫成的，就有可能會造成誤解
(我相信大家不可能沒遇過一群人對同一句話有兩種以上不同解釋的狀況)
精準的規格，有些產業可能隨便寫下來就是一兩千頁，然後賣你個五六萬
光是名詞解釋就能分成一冊單售
當然你們公司的商業邏輯可能複雜程度不是什麼業界標準等級的，可以參考
domain driven的叢書，但我試過，台灣大部分是推不起來:)
如果規格的目的是在避免犯錯或降低溝通的成本，但又不想寫規格，那不如
由開發人員主動設想所有「可能會出錯」、「模糊不清」的腳本或狀況
這些edge case的設想往往需要判斷與經驗、對系統的了解
我的經驗是大部分是非工程師的人往往不會去想這些，作為開發者的我有必要
在看到他們描述行為時，就盡量釐清我能想到的狀況
當你有了這些case或腳本，你就能夠建立測試
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.216.78.140 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1673486154.A.9C5.html
1F：推 black209: 推 01/12 10:32
2F：→ loadingN: 太長了 簡單說就是團隊如何有效協作 01/12 11:17
3F：→ DrTech: 推二樓，簡單就是團隊怎麼協作，遇到問題怎麼互動達成目的 01/12 12:15
4F：→ DrTech: 才是重點。不然規格再怎麼寫清處都沒用。 01/12 12:15
5F：→ TAKADO: 文件跟規格不是萬能，一樣的文件給不同人開發還是有可能產 01/12 13:37
6F：→ TAKADO: 出完全不一樣的實作。實務上只能PG、SA跟PM一直持續溝通跟 01/12 13:37
7F：→ TAKADO: 追蹤，不要都自掃門前雪，自己覺得做完列出來的專案工作項 01/12 13:37
8F：→ TAKADO: 目就覺得沒事了。 01/12 13:37
9F：推 tsairay: 個人經驗是,有些交辦規格的上游是故意寫的模糊的 01/12 13:46
10F：→ tsairay: 這樣他們才好凹作更多,如果項目清清楚楚就是10個項目 01/12 13:47
11F：→ tsairay: 他就沒辦法叫你作第11項,所以他們都會寫的故意模糊 01/12 13:48
12F：→ tsairay: 這樣就能一直追加 01/12 13:48
13F：→ tsairay: 一些外包或是招標有打合約的案子規格就能寫得清清楚楚 01/12 13:50
14F：→ tsairay: 不用打合約的規格就一直修改,要不要作而已 01/12 13:53
15F：→ jej: 原po的答案就是成為通靈王就可以了 01/12 18:42
16F：推 gary861226: ㄜ...那請問DB欄位名稱還不清楚就要前端人員先開發正 01/12 21:39
17F：→ gary861226: 常嗎？input name叫我先丟去google翻譯成英文，等DB 01/12 21:39
18F：→ gary861226: 規格確認了再回頭改 01/12 21:40
19F：推 c80352: 改名稱小事吧 雖然很煩沒錯 但不用動到邏輯我覺得 OK 01/13 01:37
20F：推 TAKADO: Clean Architecture 的概念參考一下，DB UI都可以後面再決 01/13 13:09
21F：→ TAKADO: 定就好。 01/13 13:09
22F：推 Nitricacid: db欄位沒開跟你前端有什麼關係...接口做個欄位轉換而 01/22 09:15
23F：→ Nitricacid: 已 如果是要隕石開發又要追求效能就塊陶 01/22 09:15