商業持續運營管理/商業持續運營管理/專案管理

第3章：定義IT專案

概述

許多專案都是以探索者的原則進行管理：“讓我們行動起來，看看會發生什麼。”雖然這種方法可能令人興奮，特別是在凌晨兩點臨近里程碑交付期限的時候，但它很少能產生客戶想要的東西。定義專案就是找出客戶想要的東西。指出為了滿足客戶，你需要確定什麼才能做到這一點，這似乎是令人反感的初級問題，但是，客戶的需求往往在實施階段才最終明朗。那時候就太晚了。

你可能會好奇為什麼很多專案一開始沒有明確定義最終產品，但更有效的問題是，什麼指標會告訴你你的專案可能沒有關注客戶需求？有一些指標。

你的團隊（包括你自己）有一種“以前做過”的態度。因此，你可能會被誤導，以為因為你瞭解應用程式（比如庫存），所以你瞭解客戶的需求，而且沒有必要浪費寶貴的時間去問一些愚蠢的問題。

當你和你的團隊解決問題時，你專注於技術解決方案而不是客戶需求。如果你要以客戶為中心，那麼你和你團隊討論的所有問題都必須透過考慮什麼對客戶最好來解決，而不是依賴於技術上的創造力。

專案在一開始就匆忙進行。你面臨著幾乎不可能完成的期限，以及夜間和週末工作的迫切性。如果是這樣，你將被施加壓力去“繼續”，去儘快生產出一些東西——任何東西——你會認為放慢速度與客戶交談是阻礙職業發展的行為。

你的客戶或你的管理層（或你）認為，計算機系統專案中唯一有價值的產品是程式碼，其他一切都只是序言——成本高昂、耗時且價值有限。如果是這樣，任何延遲“真正”工作開始的行動都是浪費的，不受歡迎的。

如果這些條件中的任何一個成立，那麼你就擁有了一些力量，這些力量使你偏離了打好必要基礎的工作。針對這些力量的對策是堅持儘可能清晰明瞭地定義專案的必要要求。

對交付成果的清晰定義，還有一個新出現的威脅。許多專案現在圍繞某種形式的迭代開發進行結構化，其中準備原型、進行審查，並逐步完善，直到原型演變成最終系統。在這種系統開發方法中，原型通常用於識別業務規則和程式，這會導致人們傾向於忽略定義需求的必要性，因為“隨著原型的演變，它們會變得清晰。”如果你聽到這種論點，指出迭代開發是達到期望結果的一種方式，但結果仍然需要定義。事實上，這種專案方法更需要對最終目標有更清晰的定義。

為了定義一個專案，你必須定義、記錄並獲得客戶對兩件事的認可：交付成果和範圍。這些內容將在本章後面討論。

然而，定義專案不僅僅是定義交付成果和範圍。你還需要定義如何進行專案。具體來說，你需要建立以下內容：

如何管理對範圍的變更請求

客戶將如何稽核和批准交付成果

對於開發專案，專案將採用哪種方法

這些是第3章的主題。最後有一個清單，可以幫助你確保你和客戶在專案的重要問題上達成一致。