如何為項目定價和管理範圍蔓延
已發表: 2022-03-10我相信您已經閱讀過不切實際的文章，這些文章表明存在一些科學的定價方法，可以神奇地讓您創建準確的報價。 您可能還被引導相信應該不惜一切代價避免範圍蔓延，但在現實世界中，它總是會發生。
現在是我們停止玩這種荒謬遊戲的時候了，開始以一種不像賭博的方式來運行項目，而更像是遵循一個穩健可靠的流程。
我誇大其詞了嗎？ 可能，但讓我們看看數字項目經常出錯的地方。
我們項目過程的問題
根據我的經驗，任何行業的大多數組織都以大致相同的方式運行項目：
- 管理人員要求完成一個項目。 不幸的是，這個請求通常缺乏可交付成果的細節，而且往往只有模糊的目標。
- 一個利益相關者委員會被召集來詳細定義項目並決定範圍。
- 然後將詳細的範圍提交給將要構建它的團隊，並要求他們估計需要多長時間和成本。
- 項目按規範交付，強調按時交付並在預算範圍內。 結果，範圍蔓延成為敵人。
- 項目已交付，每個人都繼續執行任務列表中的下一個項目。
這種方法遠非理想，尤其是對於數字項目。 數字化為我們提供了前所未有的關於用戶行為的反饋，並使實施變更相對容易（與實體產品相比）。 然而，一旦確定了範圍並提供了報價，項目就會被鎖定，隨著項目的進展，每個人都不願意做出改變。
然而，不可避免地，範圍最終會發生變化，主要是因為利益相關者對將要構建的內容有不同的解釋，或者因為他們在項目中期意識到關鍵要素是錯誤的。
事實上，範圍蔓延並沒有錯。 在您了解更多信息時保持靈活性和適應能力是創建出色數字服務的基礎。 問題不在於範圍蔓延，而在於我們運行項目的方式。
不幸的是，由於已就截止日期和成本達成一致，我們試圖在這些限制內交付這些更改，從而導致偷工減料。
並不是說時間表和成本首先是準確的。 數字項目很複雜，通常需要專家和利益相關者一起工作。 因此，眾所周知，它們很難準確估計。
我已經閱讀了許多文章，這些文章提出了準確估計的方法。 然而，它們在現實世界中幾乎在所有情況下都是不切實際的，主要是因為它們太耗時而無法應用。 對項目進行估算取決於直覺、經驗和有根據的猜測！
任何曾在該領域工作過的人都會告訴你，大多數估計都是虛構的。 我們通常不知道足夠的前期知識，甚至無法確定正確的解決方案是什麼或用戶可能如何響應它。 因此，不可能預先準確估計整個項目。
不幸的是，當項目不可避免地錯過最後期限並超出預算時，這種模糊性通常會導致不公平地分配責任。
幸運的是，有一種方法可以提供準確的估算，並管理涉及更改運行項目的範圍蔓延。 秘訣在於將項目分成更小的塊。 這種方法避免了承擔大型和復雜的項目。
將項目分解為一系列較小的參與
在這一點上我需要清楚。 我並不是說雄心勃勃的工作計劃是錯誤的。 我在大量網站和龐大的工作計劃上為大客戶工作。 然而，我很少將這些參與視為一個單一的大型項目。 相反，我將它們分解為更易於管理的項目，我一次只限定一個。
當客戶找我要進行數字項目（無論大小）時，我通常將其分為四個階段，按以下順序發生：
- 發現，
- Α，
- 最小可行產品，
- 持續迭代和優化。
每個階段都是具有明確可交付成果的單獨參與。 因此，我不承諾整個項目，而只承諾第一階段。 這使得估計和管理範圍蔓延變得容易得多。
例如，您只需要定義下一階段的範圍。 這使您可以更好地管理範圍蔓延，因為您可以在定義下一個階段時適應它，一旦前一個階段完成。
您不是在估算整個工作計劃，而是在估算該計劃中的下一個項目。 此外，您可以使用前一階段來幫助您更準確地進行估算。
每個階段都有助於定義和估計下一個階段，從發現開始。
1. 發現
在發現階段，我與利益相關者一起驗證項目。 根據項目的整體規模，這可能只是幾次會議，也可能是整個工作計劃。
通常它包括以下元素：
- 進行用戶研究；
- 分析競爭；
- 確定關鍵績效指標；
- 定義成功的樣子；
- 理解約束；
- 整理利益相關者的意見。
這個想法是，發現階段將為項目提供更明智的定義，包括用戶需求、業務目標以及需要創建的內容。
最重要的是，它將驗證項目將交付所需的價值。
然後，我們可以使用此可交付成果來定義和估計 alpha 階段所需的工作。 這樣做可以使我們的估計更加準確，並根據我們所學的內容調整範圍。
2.阿爾法
Alpha 階段是我們定義數字服務（無論是 Web 應用程序還是網站）如何工作並確保用戶在使用它時獲得積極體驗的地方。
這通常是通過創建原型來完成的。 在較小的項目中，這可能只是一些設計模型。 在較大的項目中，它可能是人們可以試用的功能原型。
無論如何，我們的想法是可視化您正在構建的數字服務。
我們這樣做有三個原因。
- 首先，可視化將確保所有利益相關者對您正在創建的內容有一個共同的願景。 一個文檔可以用許多不同的方式來解釋，但是用原型來做這件事要困難得多。
- 其次，原型將更容易識別任何可能被忽視的東西，因此當解決成本更高時，避免範圍進一步蔓延。
- 最後，如果我們有一些有形的東西，我們可以與用戶一起測試它，以確保它符合目的，然後再花錢建造真實的東西。
如果測試不佳，我們在下一階段之前仍有空間進行調整，而不會破壞預算或打亂時間表。
與發現階段一樣，我們可以使用 alpha 來估計下一階段所需的工作。 對需要構建的內容進行可視化可以使所有相關利益相關者更容易估計所需的工作。 他們可以看到他們被要求建造什麼。
此外，我們可以利用從測試 alpha 中吸取的教訓來調整我們將要創建的內容，再次為範圍的更改創造空間，而不會破壞項目。
一旦我們有了 alpha，我們就可以自信地進入構建，知道我們將創建正確的東西，並且用戶會積極響應它。
3. 最小可行產品
我曾經將這個階段稱為“構建”。 但是，我發現利益相關者將完成構建與完成項目聯繫在一起。 實際上，數字服務永遠不會完成，因為它們需要不斷迭代以確保它們盡可能有效。
為了避免這個問題，我開始把這個階段稱為最小可行產品（MVP）。 在這個階段，我們構建並啟動了數字服務的初始版本。
通過將其稱為最小可行產品，我們強調將有一個發布後的迭代。 這為我們提供了一種處理範圍蔓延和意外複雜性的方法，方法是將其推遲到發布後。 這確保了項目保持在軌道上並保持其勢頭。
在構建過程中不可避免地，我們會將一些東西擱置到發布後。 然後，這些元素成為定義我們最後階段的基礎，使我們能夠對發布後的優化做出初步估計。
4. 持續迭代和優化
發布後階段處理我們在 MVP 中沒有解決的功能、複雜性和其他問題。 在這一點上，這個改進列表相對容易確定，並且可以以合理的準確度進行估計。
然而，除了這項工作之外，還應該有一個持續的監控、迭代和測試過程，以進一步完善數字服務的有效性。
根據數字服務的規模和復雜性估算您承擔的工作量。 您的估算還應與項目其餘部分的投資成正比。
通過將您的項目分解為這四個階段並分別完成每個階段，您將消除我們在使用傳統項目管理方法時面臨的許多挑戰。
為什麼分解項目有效
以這種方式分解項目有四個顯著的好處：
- 每個階段都有更好的定義。
因為上一階段的可交付成果定義了每個階段，這意味著有一個清晰的方向願景。 這有助於利益相關者了解事情的發展方向，並避免以後出現令人討厭的意外。 - 項目估算更準確。
例如，您不必猜測交付一個具有大量未知數的重要而模糊的項目需要多長時間，您只需估計下一階段並根據前一階段的可交付成果進行估算。 - 它帶來更好的數字服務。
由於項目創意已經過用戶驗證和測試，因此您可以更有信心最終產品符合目的。 它還允許在階段之間調整範圍和功能，以確保您提供可能的最佳結果。 - 這是一種風險較小的方法。
委託數字服務的公司不需要預先承諾整個項目。 如果發現階段未能驗證項目的可行性，則可以將其丟棄，損失很小。 同樣，如果 alpha 原型沒有在用戶中很好地測試，它可以在價格變得太貴之前進行調整。
如果第一次使用外部供應商，最後一點是令人放心的。 與其在不知道他們是否可以交付的情況下為大型項目簽約代理，客戶可以讓他們參與發現階段，看看他們是什麼樣的。 如果他們很好，他們可以繼續與他們合作。 如果沒有，他們可以將調查結果帶到另一個機構，而不會丟失任何東西。
如果您經營一家代理機構或者是一名自由職業者，您可能會認為這聽起來是個壞主意。 可以理解的是，您更願意為整個項目註冊一個客戶。 但是，我通過這種方法避免了許多競爭性投標，因為客戶不覺得他們在這麼小的初始投資上承擔風險。 此外，他們不覺得有必要與不同的供應商交談，因為如果他們不喜歡我，他們可以很容易地轉換。
此外，使用這種分階段的方法將使您的下一個固定價格項目的範圍界定和定價變得更加容易。 當然，它不會神奇地提供估計或防止範圍蔓延。 但是，這將使估算更易於管理，因為您一次只確定一個部分的範圍。 它還將允許您使用範圍蔓延，而不是試圖抑制它。
因此，我的建議是，無論您是在內部還是外部工作，在大型或小型站點上工作，都不要試圖在不將項目分解為階段的情況下對項目進行估計和確定範圍。 相反，一次解決一個階段，並用你學到的知識來通知下一個階段。 如果你這樣做了，你的估計會更準確，有根據你所學的內容進行調整的空間，並且會發現項目管理更簡單。