Writing suggestion of request for proposal: Difference between revisions

From LemonWiki共筆
Jump to navigation Jump to search
mNo edit summary
Tags: Mobile edit Mobile web edit
 
(31 intermediate revisions by the same user not shown)
Line 1: Line 1:
怎麼避免這樣寫 RFP (Request For Proposal) 需求建議書
避免這樣寫 RFP (Request For Proposal) 需求建議書 (又稱需求規格書、SPEC)


== 原則 ==
原則: 功能規格的文字，需要可以準確作為驗收或交付的項目。例如
原則: 功能規格的文字，需要可以準確作為驗收或交付的項目。例如
* (1) 將模糊的大功能，展開為子項功能。
* (2) 將模糊文字，改成可以操作的功能文字。


* '''細分大功能為子項功能'''：將模糊的大功能，展開為子項功能。一個項目（一句話）只處理一件事情、一項功能。例如：登陸頁包含那些功能模組、視覺設計、數據追蹤、顧客聯繫表單
* '''可交付與驗收'''：將模糊描述，改成可以具體操作與驗收的功能文字。
* '''明確負責人'''：具體說明誰要負責這件項目，例如網站前期分析，是由業主負責、還是接案單位負責。
* '''避免過度承諾'''：避免承諾無法實現的功能，以免導致無法驗收或預算估計失誤。
* '''避免過早限定技術解決方案'''：例如規格需完成購物車推薦系統，規格書也許可以提到數種演算法，但是不限定只使用已知的演算法。
* '''問題導向的規格定義'''：檢視規格與原本的問題情境的對應，是否規格有解決原本問題，但避免造成過度設計 (over design)
* '''保留根據測試調整的彈性'''：如果合約可行的話，保留功能規格可依據使用測試結果再調整的彈性。如果無法採用敏捷合約（Agile Contracting），而是傳統的瀑布流開發方式，還是可以透過合約方式保留開發有限度的彈性。
== 範例建議 ==
範例1:  <strike>IE 必須死</strike> 不支援 IE
範例1:  <strike>IE 必須死</strike> 不支援 IE
* 建議: 原因 IE 對於 HTML5 支援度不佳，用字建議改成「支援哪個功能，哪個版本的瀏覽器」
* 建議: 因為 IE 對於 HTML5 支援度不佳，但是儘管是其他瀏覽器支援度也有差異，可參考 [https://html5test.com/ HTML5test - How well does your browser support HTML5?]。用字建議改成「支援哪個功能，哪個版本的瀏覽器」


範例2:  支援 HTML5 的新版瀏覽器 C, F ... 等
範例2:  支援 HTML5 的新版瀏覽器 C, F ... 等
Line 12: Line 20:


範例3: 後台資料庫填報要符合RWD精神，讓老人家使用 (來源: AMOS 推坑賴群祖)
範例3: 後台資料庫填報要符合RWD精神，讓老人家使用 (來源: AMOS 推坑賴群祖)
* 建議: (1) 「RWD精神」、「老人家使用」的用字過於模糊，無法驗收 (2) RWD 建議改成可以準確作為驗收的項目，例如參考 [[https://wiki.planetoid.info/index.php/Research_surveys#.E5.85.A8.E7.90.83.E7.80.8F.E8.A6.BD.E5.99.A8.E3.80.81.E4.BD.9C.E6.A5.AD.E7.B3.BB.E7.B5.B1.E3.80.81.E8.9E.A2.E5.B9.95.E8.A7.A3.E6.9E.90.E5.BA.A6.E3.80.81.E6.90.9C.E5.B0.8B.E5.BC.95.E6.93.8E.E5.B8.82.E5.8D.A0.E7.8E.87.E7.B5.B1.E8.A8.88.E8.A1.A8 | 全球瀏覽器、作業系統、螢幕解析度、搜尋引擎市占率統計表]]，研究哪些是目前是市佔率高的裝置或者是專案需求，再改成「支援哪個螢幕尺寸的哪種行動裝置」 (3) 關於字體大小、按鈕大小等設計，需求端可以再與廠商溝通確認細節，釐清「老人家使用」的需求。
* 建議:  
** (1) 符合 「RWD精神」、「老人家使用」的用字過於模糊，不是功能規格文字，連帶造成日後無法驗收。RWD 建議改成可以準確作為驗收的項目，例如參考 [[Research_surveys#.E5.85.A8.E7.90.83.E7.80.8F.E8.A6.BD.E5.99.A8.E3.80.81.E4.BD.9C.E6.A5.AD.E7.B3.BB.E7.B5.B1.E3.80.81.E8.9E.A2.E5.B9.95.E8.A7.A3.E6.9E.90.E5.BA.A6.E3.80.81.E6.90.9C.E5.B0.8B.E5.BC.95.E6.93.8E.E5.B8.82.E5.8D.A0.E7.8E.87.E7.B5.B1.E8.A8.88.E8.A1.A8 | 全球瀏覽器、作業系統、螢幕解析度、搜尋引擎市占率統計表]]，研究哪些是目前是市佔率高的裝置或者是專案需求，再改成「支援哪個螢幕尺寸的哪種行動裝置」  
** (2) 釐清「老人家使用」的需求：需求端可以再與廠商溝通確認關於字體大小、按鈕大小、內容版面等設計細節，


範例4: 網站資料分析要具備機器學習功能
範例4: 網站資料分析要具備機器學習功能
* 建議: 因為機器學習包含預測、分類、分群等領域，建議展開為子項功能，才能收斂日後交付的功能範圍。
* 建議: 因為機器學習包含預測、分類、分群等領域，建議展開為子項功能，才能收斂為日後交付的功能範圍。
 
範例5: 資訊圖表提供匯出功能、下載功能
* 建議: 匯出或下載什麼的檔案格式，例如 CSV, PNG 檔案？以 CSV 檔案格式為例，資料來源與資料輸出的欄位可以進一步定義。
 
== 相關資料 ==
相關資料
 
* [https://legacy.gitbook.com/book/masonwu1762/bakerystorespec/details 軟體需求與功能規格書-以線上糕餅網站為例 · GitBook]
* [http://www.gaya.org.tw/journal/m2/2-main1.htm gaya/佛教圖書館館訊/第二期/圖書館自動化之路－－經由建議需求書 RFP]「因為 RFP與日後合約的內容有相當密切的關係（甚至，國外有些 RFP的範本，中間有一段落就是要求廠商的建議書中要提供合約的草約），所以，撰寫 RFP需要花相當的心思，小心謹慎，力求文字清楚嚴謹，儘量用量化、具體的數據與敘述，避免有模稜兩可或者任何彈性釋意的空間或機會。 」
* [https://vide.tw/10136 產品經理 PM 第 3 講：如何開始一個改版專案] {{access | date=2018-08-17}}
* [https://ithelp.ithome.com.tw/questions/10201095?sc=nl.daily RFP怎麼寫 - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天] {{access | date=2020-11-16}}
* [https://www.facebook.com/sokingwang/posts/4999931386686026 需求方不是故意的，只是大家都沒經驗] (2021). 王彥博 {{access | date=2021-12-05}}
 
* [https://m.facebook.com/story.php?story_fbid=5402800853065742&id=100000076418866 王彥博 - ▋教導實習生寫需求文件，才發現我是個很 GY 的人 ... | Facebook] 1.  有沒有在需求建議書裡面過度承諾 2.  寫下來的文字語句，有沒有明確的指向性 3.  一行一述，一句話只講一件事情，不要多重條件子句
 
* [https://www.facebook.com/sokingwang/posts/pfbid07Ay7UFZxRzeZidYP2sNwCgSYBrAYJisefgJUYjaqL1uZdFRvQgxM7bteQr8q3pQbl 王彥博 - ▋8個產品設計文件 PRD 的 SPEC 書寫原則小技巧 ▋ ⠀⠀ 你曾經寫過所謂的「規格文件」要提供給開發人員實作嗎？... | Facebook]
 
相關概念
 
* [http://terms.naer.edu.tw/detail/1314560/ Operational Definition - 操作定義] (Operational Definition)
* [[Software acceptance test plan]] (使用者驗收測試)
 
相關討論
 
* [https://ithelp.ithome.com.tw/questions/10191107 如何一次把軟體需求講清楚 - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天] {{access | date=2018-10-17}}
 
{{Template:Build a website in Mandarin}}


[[Category:WebDesign]]
[[Category:Design]]

Latest revision as of 16:33, 12 February 2024

避免這樣寫 RFP (Request For Proposal) 需求建議書 (又稱需求規格書、SPEC)

原則[edit]

原則: 功能規格的文字，需要可以準確作為驗收或交付的項目。例如

  • 細分大功能為子項功能：將模糊的大功能，展開為子項功能。一個項目（一句話）只處理一件事情、一項功能。例如：登陸頁包含那些功能模組、視覺設計、數據追蹤、顧客聯繫表單
  • 可交付與驗收：將模糊描述，改成可以具體操作與驗收的功能文字。
  • 明確負責人：具體說明誰要負責這件項目，例如網站前期分析，是由業主負責、還是接案單位負責。
  • 避免過度承諾：避免承諾無法實現的功能，以免導致無法驗收或預算估計失誤。
  • 避免過早限定技術解決方案：例如規格需完成購物車推薦系統，規格書也許可以提到數種演算法，但是不限定只使用已知的演算法。
  • 問題導向的規格定義：檢視規格與原本的問題情境的對應，是否規格有解決原本問題，但避免造成過度設計 (over design)
  • 保留根據測試調整的彈性：如果合約可行的話，保留功能規格可依據使用測試結果再調整的彈性。如果無法採用敏捷合約（Agile Contracting），而是傳統的瀑布流開發方式，還是可以透過合約方式保留開發有限度的彈性。

範例建議[edit]

範例1: IE 必須死 不支援 IE

範例2: 支援 HTML5 的新版瀏覽器 C, F ... 等

  • 建議: 由於瀏覽器版本一直更新，無法確定最新版本是否會出問題。建議確認哪個版本瀏覽器是沒有問題後，將用字改成「支援哪個版本以上的瀏覽器」

範例3: 後台資料庫填報要符合RWD精神，讓老人家使用 (來源: AMOS 推坑賴群祖)

  • 建議:
    • (1) 符合 「RWD精神」、「老人家使用」的用字過於模糊，不是功能規格文字，連帶造成日後無法驗收。RWD 建議改成可以準確作為驗收的項目，例如參考 全球瀏覽器、作業系統、螢幕解析度、搜尋引擎市占率統計表，研究哪些是目前是市佔率高的裝置或者是專案需求，再改成「支援哪個螢幕尺寸的哪種行動裝置」
    • (2) 釐清「老人家使用」的需求：需求端可以再與廠商溝通確認關於字體大小、按鈕大小、內容版面等設計細節，

範例4: 網站資料分析要具備機器學習功能

  • 建議: 因為機器學習包含預測、分類、分群等領域，建議展開為子項功能，才能收斂為日後交付的功能範圍。

範例5: 資訊圖表提供匯出功能、下載功能

  • 建議: 匯出或下載什麼的檔案格式，例如 CSV, PNG 檔案？以 CSV 檔案格式為例，資料來源與資料輸出的欄位可以進一步定義。

相關資料[edit]

相關資料

相關概念

相關討論

網站設計和開發流程
Retrieved from "https://wiki.planetoid.info/index.php?title=Writing_suggestion_of_request_for_proposal&oldid=24433"