敏捷方法近年來獲得廣泛歡迎，因其能快速交付產品並適應變化的需求。然而，並非所有專案都具備可行性，因此在決定是否繼續進行專案時，做出明智決策至關重要。結合「進/不進」檢查清單與加權評分方法，可為評估敏捷專案的可行性提供一個框架。本文將探討「進/不進」檢查清單的重要性，以及加權評分方法如何協助做出明智決策。
為何需要敏捷專案的「進/不進」檢查清單
可行性研究是敏捷專案開發過程中的關鍵環節。這些研究旨在評估所提議專案的實際可行性，並判斷專案在範圍、預算和時程方面是否可行。可行性研究中的一個關鍵組成部分是「進/不進」檢查清單，用於決定專案是否應啟動、暫停或終止。本文將探討在敏捷專案可行性研究中使用「進/不進」檢查清單的前後流程。
可行性研究之前
在開始可行性研究之前，必須清楚了解專案的目標、範圍以及利害關係人的需求。專案的可行性研究通常包括評估專案的技術、財務、營運及市場可行性。制定詳細的可行性研究計畫，並讓所有相關利害關係人參與其中，至關重要。
「進/不進」檢查清單是可行性研究期間不可或缺的工具。它列出了專案得以繼續進行所必須達成的標準。這些標準通常包括技術可行性、財務可行性、市場需求以及資源可取得性。「進/不進」檢查清單有助於確保所有關鍵因素均被考量，並在繼續前評估專案成功的潛力。
可行性研究之後
可行性研究完成後，將使用「進/不進」檢查清單來決定專案是否應啟動、暫停或終止。若專案符合清單中列出的所有標準，則視為具備可行性，可繼續進行。若專案未能達成任何一項標準，則可能需要暫停或終止專案，直到問題解決為止。
「進/不進」檢查清單是一項極具價值的工具，可確保在專案繼續前對其可行性進行全面評估。它有助於識別可能影響專案成功的潛在風險與問題。透過使用此清單，利害關係人可做出更明智的決策，判斷是否應繼續進行專案。
使用「進/不進」檢查清單的好處
在敏捷專案的可行性研究中使用「進/不進」檢查清單具有多項好處，包括：
- 明確標準：檢查清單提供專案得以繼續所必須達成的明確標準。這確保所有利害關係人對專案目標及成功標準有清晰的理解。
- 風險管理：檢查清單有助於識別可能影響專案成功的潛在風險與問題。這使利害關係人能在專案啟動前採取適當措施來降低風險。
- 明智決策：檢查清單有助於利害關係人做出是否繼續專案的明智決策。透過根據明確標準評估專案的可行性，利害關係人能更清楚地判斷專案成功的潛力。
範例
以下是敏捷專案可行性研究中「進/不進」檢查清單可能包含的一些項目範例：
- 技術可行性：
- 開發專案所需的技術是否可取得？
- 專案是否能在既定的技術限制內完成開發？
- 開發團隊是否具備完成專案所需的技能與專業知識？
- 財務可行性：
- 專案是否具備財務可行性？
- 預估預算是否與專案目標和宗旨相符？
- 是否存在可能影響專案可行性的潛在超支情況？
- 市場需求：
- 市場上是否對此專案有需求？
- 市場上是否已有類似專案存在？
- 專案是否符合當前的市場趨勢與需求？
- 資源可取得性：
- 專案所需的資源是否可用？
- 在現有的資源下，專案是否能在給定的時程內完成？
- 是否存在可能影響專案可行性的潛在資源限制？
如果專案符合「進退決策清單」中列出的所有標準，便可進入下一開發階段。若未能符合任何一項標準，專案可能需要暫停或停止，直到問題解決為止。
實際案例
根據此進退決策清單，專案似乎具有可行性，可進入下一開發階段。然而，開發團隊需密切監控專案，以確保其在既定限制內進行，並及時處理任何潛在問題。
在「是」與「否」欄位中，您可以標示專案是否符合標準。在「備註」欄位中，您可以針對每一項標準提供額外資訊或註解，例如需要解決的潛在問題或疑慮。
以下是一個適用於敏捷專案可行性研究的進退決策清單表格範本：
| 標準 | 是 | 否 | 備註 |
|---|---|---|---|
| 技術可行性 | |||
| 開發專案所需的技術是否可用？ | 是 | 公司具有開發網路應用程式之經驗，且熟悉專案所需的技術架構。 | |
| 專案是否能在既定的技術限制內開發？ | 是 | 專案的技術需求在開發團隊的能力範圍內。 | |
| 開發團隊是否具備完成專案所需的技能與專業知識？ | 是 | 團隊具備開發類似專案的經驗，並具備完成專案所需的技能。 | |
| 財務可行性 | |||
| 專案是否具財務可行性？ | 是 | 專案預期收入將超過開發成本。 | |
| 預估預算是否與專案目標一致？ | 是 | 專案預算符合公司的財務資源與目標。 | |
| 是否存在可能影響專案可行性的潛在超支情況？ | 沒有 | 開發團隊已識別出潛在的成本超支問題，並採取了措施加以緩解。 | |
| 市場需求 | |||
| 市場上是否對此項目有需求？ | 是 | 市場研究顯示，小型企業有對專案管理工具的需求。 | |
| 市場上是否已有類似的項目？ | 是 | 市場上已有幾種專案管理工具，但沒有任何一種是專門針對小型企業需求而設計的。 | |
| 此項目是否符合當前的市場趨勢與需求？ | 是 | 此項目符合當前對雲端軟體解決方案的市場趨勢與需求。 | |
| 資源可用性 | |||
| 專案所需的資源是否可取得？ | 是 | 專案所需的硬體、軟體及其他資源皆可取得。 | |
| 在現有資源下，專案是否能在指定時程內完成？ | 是 | 專案的時程是現實且可在現有資源下達成的。 | |
| 是否有任何潛在的資源限制可能影響專案的可行性？ | 沒有 | 開發團隊已識別出潛在的資源限制，並採取措施加以緩解。 |
使用此表格範本可協助您記錄決策過程，並提供明確的紀錄，說明專案為何被批准繼續或中止。
進退決策清單的簡單評分
在此範例中，符合專案需求的每一項標準給予1分，部分符合的標準則給予0.5分。最終得分為各項標準得分的總和，若得分超過某一門檻（例如8/11），則判定專案可行。
| 標準 | 是 | 沒有 | 得分 | 評論 |
|---|---|---|---|---|
| 技術可行性 | ||||
| 開發項目所需的技術是否可用？ | 是 | 1 | 公司有開發基於網絡應用程式經驗，並熟悉項目所需的技術架構。 | |
| 項目是否能在給定的技術限制內開發？ | 是 | 1 | 項目的技術需求在開發團隊的能力範圍內。 | |
| 開發團隊是否具備完成項目所需的技能和專業知識？ | 是 | 1 | 團隊有開發類似項目的經驗，並具備完成項目所需的技能。 | |
| 財務可行性 | ||||
| 項目是否具有財務可行性？ | 是 | 1 | 項目預計收入將超過開發成本。 | |
| 預估預算是否與項目的目標和宗旨相符？ | 是 | 1 | 項目的預算與公司的財務資源和目標一致。 | |
| 是否存在可能影響項目可行性的成本超支？ | 沒有 | 1 | 開發團隊已識別出潛在的成本超支，並採取措施加以減輕。 | |
| 市場需求 | ||||
| 市場上是否存在對該項目的需求？ | 是 | 1 | 市場研究顯示，小型企業需要一款專案管理工具。 | |
| 市場上是否已有類似的項目可供使用？ | 是 | 0.5 | 市面上已有幾款專案管理工具，但沒有任何一款是專門針對小型企業需求設計的。 | |
| 這個項目是否符合當前的市場趨勢與需求？ | 是 | 1 | 此項目符合當前對雲端軟體解決方案的市場趨勢與需求。 | |
| 資源可用性 | ||||
| 專案所需的資源是否可取得？ | 是 | 1 | 專案所需的硬體、軟體及其他資源皆可取得。 | |
| 在現有資源下，專案是否能在指定時程內完成？ | 是 | 1 | 專案的時程安排現實且可在現有資源下達成。 | |
| 是否存在可能影響專案可行性的資源限制？ | 沒有 | 1 | 開發團隊已識別出潛在的資源限制，並採取措施加以緩解。 | |
| 總計 | 9.5/11 |
然而，必須注意的是，為每一項標準賦予分數可能具有主觀性，未必能準確反映專案的可行性。在使用評分系統評估專案可行性時，必須考慮每個專案的背景與獨特特徵。
帶有通過/不通過清單的加權價值評分系統
評分系統與加權值是通過/不通過清單的重要組成部分，它們提供了一種基於預設標準來量化評估專案可行性的方法。
評分系統根據每一項標準是否達成，為清單中的每一項標準分配「是」或「否」的值。例如，與技術可行性相關的標準可能會詢問開發專案所需的技術是否可取得。若技術可取得，該標準的答案為「是」；若不可取得，則答案為「否」。
一旦每一項標準被評估並賦分，加權值便會發揮作用。每一項標準都會被賦予一個權重，代表該標準在整體專案可行性評估中的相對重要性。權重通常以百分比表示，所有權重總和為100%。
範例
以下是一個帶有權重值的進退檢查清單範例：
| 標準 | 權重 | 是 | 否 | 分數 | 評論 |
|---|---|---|---|---|---|
| 技術可行性 | 40% | ||||
| 開發專案所需的技術是否可用？ | 20% | 是 | 0.2 | 公司有開發基於網路應用程式的經驗，且熟悉專案所需的技術架構。 | |
| 專案是否能在既定的技術限制內開發？ | 10% | 是 | 0.1 | 專案的技術需求在開發團隊的能力範圍內。 | |
| 開發團隊是否具備完成專案所需的技能與專業知識？ | 10% | 是 | 0.1 | 團隊有開發類似專案的經驗，並具備完成專案所需的技能。 | |
| 財務可行性 | 30% | ||||
| 專案是否具備財務可行性？ | 20% | 是 | 0.2 | 項目預計的收入預期將超過開發成本。 | |
| 預計的預算是否與項目的目標和宗旨一致？ | 5% | 是 | 0.05 | 項目的預算與公司的財務資源和目標一致。 | |
| 是否存在可能影響項目可行性的潛在超支情況？ | 5% | 否 | 0.05 | 開發團隊已識別出潛在的超支情況，並已採取措施加以減輕。 | |
| 市場需求 | 20% | ||||
| 市場上是否存在對此項目的需求？ | 10% | 是 | 0.1 | 市場研究顯示，小型企業有對專案管理工具的需求。 | |
| 市場上是否已有類似的項目？ | 5% | 是 | 0.025 | 市場上有幾種專案管理工具，但沒有任何一種是專門針對小型企業需求而設計的。 | |
| 此項目是否與當前的市場趨勢和需求一致？ | 5% | 是 | 0.025 | 此項目符合當前對雲端軟體解決方案的市場趨勢和需求。 | |
| 資源可用性 | 10% | ||||
| 專案所需的資源是否可用？ | 5% | 是 | 0.05 | 專案所需的硬體、軟體及其他資源皆已備妥。 | |
| 在現有的資源下，專案是否能在給定的時程內完成？ | 3% | 是 | 0.03 | 專案的時程是現實且可在現有資源下達成的。 | |
| 是否存在可能影響專案可行性的潛在資源限制？ | 2% | 沒有 | 0.02 | 開發團隊已識別出潛在的資源限制，並採取措施加以緩解。 | |
| 總計 | 100% | 0.605 |
在此範例中，每一項評估標準的權重是根據專案的具體需求與優先順序而定。最終得分是透過將每一項標準的分數乘以其權重，再將所有加權分數相加而得出。最終得分是根據清單中評估的各項標準，對專案可行性所做出的量化衡量。
值得注意的是，每一項標準所分配的權重具有主觀性，可能因專案的具體情境而異。因此，與相關利害關係人及領域專家討論，以確定每一項標準的適當權重，至關重要。
一旦計算出最終得分，即可作為進行「準許／不準許」決策的依據。例如，若最終得分超過預先設定的門檻，專案可能獲准繼續進行；反之，若得分低於門檻，專案可能被判定為不可行而放棄。
總而言之，透過為不同評估標準分配不同的權重，加權評分系統可提供更細膩且具情境特性的專案可行性評估。結合「準許／不準許」清單與加權評分系統，可成為決策是否推動敏捷專案的有力工具。
總結
「準許／不準許」清單是評估敏捷專案可行性的一項實用工具。透過為清單中的每一項標準賦予權重，可進行更細膩且具情境特性的評估。評分系統根據每一項標準是否達成，賦予「是」或「否」的評分，而加權值則代表該標準在整體評估中的相對重要性。一旦計算出每一項標準的加權分數，最終得分即為所有加權分數的總和。此最終得分是專案可行性的一項量化衡量，可用作決策是否推動敏捷專案的依據。透過「準許／不準許」清單與加權評分方法，組織可做出更明智的決策，並提高專案成功的機率。