作者wt (Time to Change!)
標題Re: [請益] 一份好的設計規劃應該怎麼寫
時間2023-03-10 17:51:59
把自己想成,今天coding這個動作由其他人完成。
在這樣條件下你要怎麼做?
團隊合作時,文件是用來溝通
自己做時,文件是用來釐清思路跟回憶。
這兩者的文件資訊密度跟內容就會不同。
====
如果是團隊合作,通常會走下面這樣。
這個只能算是 MRD (Market Requirements Document)
用商業語言描述需求項目。
簡單說法就是,業務、行銷都看得懂,寫得出來。
你需要是PRD (Product Requirements Docuement)
用技術語言描述相關規格細節。
你說的需求變更可能就是這塊沒講清楚。事後就會一直改。
例如說付款
接受那些方式?
信用卡:接受哪幾家信用卡?
信用卡:用哪些方式串? 跟誰串? ===>連帶延伸到網路功能,走無線還是有線
硬幣:接受哪幾款硬幣?
上面每個都是文字描述,但就需要技術經驗跟概念。
有經驗的工程師就能推估出要怎麼做,給出更細的Design Document。
以上提供參考。
※ 引述《icetofux ()》之銘言:
: 我目前從事販賣機的軟體開發,需求主幹很簡單:
: 1.用戶選定商品、檢查商品庫存。
: 2.提示付款、依據使用者付款方式檢查付款是否成功。
: 3.投放商品。
: 4.控管存放庫的溫度。
: 主幹的描述跟流程圖可以很快的寫出來,但問題在於細節的實施,比方說步驟2.,付款方式百百種,而且常常開發到一半就需要增減某種付款方式;又比方步驟4.,不同商品可能有不同的控管邏輯。
: 只要遇到需求變更,就得修改文件重畫流程圖,導致後來我也養成便宜行事的壞習慣,先把程式寫完,出版後再來按code寫規劃文件。
: 雖然目前也沒遇到什麼太大的問題,但違背了先畫流程圖跟寫規格書的原則,心裡總是留一根刺。
: 想向各位先進請教,像這種情形有沒有什麼好的建議或改善方向呢?
: 謝謝。
--
※ 發信站: 批踢踢實業坊(ptt-web.org.tw), 來自: 61.230.192.176 (臺灣)
※ 文章網址: https://ptt-web.org.tw/Soft_Job/M.1678441921.A.AC0
推 Belieeve: 推 謝謝分享 03/10 21:05
→ h920032: 寫PRD是PM的工作 這就是為什麼PM必須要懂技術 03/11 00:07
→ viper9709: 推 03/11 00:08
推 geniusturtle: 推 03/11 01:27