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