Threadser.net
數據
關鍵字
功能建議
Blog
Following
Threads
Change language
登入
串文
串文鏈結
2024-11-17 01:01
▎需求管理,專案管理的關鍵角色 一個專案或需求的交付內通常會分為 functional requirement 及 non-functional requirement,用冰山來比喻的話,前者就像是海平面上可以看到的冰山,通常是指系統應該做什麼,基本是由具體的功能、行為、權限組成。而後者就是冰山下隱藏的那部分,不常被人所知,但是至關重要的系統應該如何運作,會專注在於效能、擴展性、維護性、安全性等。 以圖片上傳為例:功能性需求是「用戶能上傳圖片到雲端」,而非功能性需求則包含效能、穩定性等指標,例如「檔案需在5秒內完成上傳,支持每秒200次請求並保持穩定性」。 (如果有在做系統設計面試練習或有其實作經驗的話大概會非常熟悉後者) 從這個角度切入就可以發現,開發完成功能性需求相對容易,但若商業需求需要非功能性需求的支持,則應在需求規劃階段進行評估。即便初期未能明確確定,開發過程中也需要持續檢視,確保交付我們的交付結果滿足需求,避免徒勞無功,白肝一場。
讚
4
回覆
1
轉發
作者
Chin 🥑 logs about SWE
a.chin.logs
粉絲
3,873
串文
146+
讚
回覆
轉發
24小時粉絲增長
發文前
3,735
發文後24小時
3,735
變化
0 (0.00%)
互動率
(讚 + 回覆 + 轉發) / 粉絲數
0.13%
回覆 (BETA)
最先回覆的內容
發文後
用戶
內容
幾秒內
Chin 🥑 logs about SWE
a.chin.logs
▎在管理需求的路上,該怎麼做比較好呢? 在平衡交付與品質的過程中,權衡優先序就是個重要的課題。推薦一個在工作上我常運用的方法論 —— Moscow Principal,透過分析需求中歸納 Must-have, Should-have, Could-have, Won’t-have 幫助平衡交付與品質。 以工程師的 terminology 來說,即是避免 over-engineering 的藝術。如何在面對需求的時候識別背後的未能確認的的 specification,並在時間的推移過程保持自己的設計或實作能被動態的調整及滿足當下的需求。(題外話,這也是軟體之所以為軟體的 mindset,因為我們適應改變,所以我們才夠軟,當然我知道有些不同的論點,但是這是我喜歡軟體的其中一個原因。)