就確定項目范圍而言，要考慮到到一些關鍵因素，但也有一些額外的因素可能會使每個利益相關者的生活變得更簡單，并有助于避免范圍蔓延。首先，在規劃階段制定一個范圍管理計劃，明確規劃項目的范圍將如何定義，驗證和管理。然后確保你對利益相關者的真實需求和期望有充分的了解，特別是牽涉到貴公司的可用資源、局限性、優勢、流程、技術/工具和文化等方面的需求和期望。通常，因為在這一步沒有分配足夠的時間和精力，范圍蔓延后來變成了一個痛苦的現實。

 

在網絡和本地應用程序開發公司The Silverlogic，首席運營官Cristina Escalante在確定項目范圍時分享了他們考慮的一些事項。Escalante說：“我們的客戶主要是小企業、初創公司和企業，他們希望從零開始創造最小可執行產品(minimal viable product，MVP)，而且常常預算有限。你可以想象得到，知道什么時候說“停止”是一個MVP和一個完整的應用程序之間的區別。我們花時間與利益相關者一起確定他們想要解決的問題，編寫關于MVP的主要和次要功能特性的用戶故事。另外，我們在紙上或在Sketch或WireframeSketcher等軟件上制作了一些初步的線框。”

 

用戶體驗和互動戰略咨詢公司Garofalo Studios的首席顧問Frank Garofalo說，就確定范圍的要素和因素而言，“我們已經接受了敏捷/混合項目方法，這使得我們可以定義關鍵目標，同時提供能適應不斷變化的業務需求的靈活性。”

 

公司意識到將敏捷等最相關的方法用于項目的好處，并采用軟件收集和構建需求、記錄、存儲并與多個利益相關者共享項目范圍信息。這些都是有助于減輕工作難度的工具。

 

 

一般而言，范圍文檔的目的是讓所有項目參與者和利益相關者隨時訪問他們始終可以參考的活文檔，以減少版本控制問題并減少圍繞客戶和團隊需求、期望、可用資源、時間表、質量方面和其它相關細節的混淆。

 

Escalante告訴首席信息官何時需要與利益相關者進行文檔記錄和共享，他說：“我們與利益相關者以及使用Google Sheets和InVision的開發團隊分享這些故事和線框。”之后，她表示：“開發團隊就什么樣的用戶故事應該被分裂或合并給出反饋，并指出整體流程或邏輯上的差距，利益相關者將故事按優先順序排列”，經過幾次迭代，“更重要的故事和經常被遺忘但卻是必需的故事浮到頂端。”

 

在Garofalo Studios，“項目范圍記錄在任務訂單文檔中，項目范圍包括關鍵目標/任務的定義，變更管理和時間表(以月為單位)。在這個時間表內，然后用一個為期兩周的時間來跟蹤實現關鍵目標的進展”，Garofalo這樣說道。他已經確定這些方法已經幫他們成功地“建立了利益相關者批準的記錄的目標，同時提供了在項目流程中接受變化的靈活性”。

 

Escalante說：對于像Silverlogic這樣的公司來說，他們的“策略在我們的敏捷/ Scrum工作流程中運作良好”，她說：“這使得開發團隊和利益相關者能夠快速地對故事展開協作，相互更新每個故事的評估和批復，發送互動線框進行評審。”

 

 

Escalante分享了其中一個她將考慮改變的事情，她說：“Google Sheets的癥結之一是，不是每個人都能流暢地使用表格，并且表格很難在移動設備上使用。”她告訴我們說：“如果我們有時間和/或資源，我們希望制作一個表格(Sheets)應用程序來改進用戶故事管理系統的用戶界面。”

 

在Garofalo，與之前的方法(如瀑布)相比，它“已經采取了一種文化變革和教育過程來向利益相關者解釋這種方法。在真正的敏捷形式中，我們的過程不斷被評估和發展”，Garofalo這樣分享道。

 

在我看來，雖然沒有一個“正確的方法”或“合適的地方”來記錄項目范圍，但有些公司已經成功地使用開源的項目管理軟件進行協作，而另一些公司通過旨在滿足其特殊和唯一需求的專用軟件取得了更大的成功。在項目的整個生命周期內具有足夠的且易于訪問(最好是電子/在線)文檔可以顯著地減少范圍蔓延。這個文檔應該在規劃階段與所有利益相關者分享，以確保每個人都了解他們的職責，并從一開始就步調一致且內部流程和方法有助于解決一些繁重的工作。

 

版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。