軟件開發項目從頭到尾都會是一個挑戰。在一開始，我們不喜歡花時間去好好地進行計劃，而且我們假定已經了解了客戶的需要，因而匆匆地去制定商業需求。初我們覺得設計工作很有意思，但后來我們發現技術環境比我們想象的要更加復雜，并因此而感到頭疼。編碼工作之后，我們還要做測試工作，時間長了會變得很無聊。后，我們只想著要做完這個可恨的項目，但是這里還有一個任務—實現。
實現經常又被稱作部署，對于這個專欄來講，兩個詞匯的意思是一樣的。要實現一個應用軟件沒有一個單一的途徑，它取決于你的項目和解決方案的特性。一些實現工作像在說“我們現在活著”一樣的容易。當解決方案是全新的而你正在對即將成型的生產環境進行開發和測試時，這種類型的實現可以起作用。這種情況下，實現工作處于這樣的狀態：頭解決方案還處于開發狀態，而第二天它應用于生產。
另一個極端是項目本身是實現工作。例如，你也許有一個應用軟件需要在全世界范圍內你的分公司中進行部署，這會花上數月的時間來完成并要求包括有計劃，分析，設計等的一個完整的生存周期。
當你考慮到要進行實現時，你總是應該首先了解其中所涉及的復雜性。如果實現工作相對的簡單，那沒有必要制定詳細的實現過程。因此在這個專欄中，我將關注于當你面對復雜的實現要求時要考慮的策略。
早作計劃
項目管理之中的很多的例子都與早期計劃有關系。事實上，如果你的開發人員對花上這么多時間進行計劃的需要提出疑問，你可以指出計劃的目的之一是確定實現工作的復雜性。如果實現工作非常龐大，你在開始要在分析階段中創建一個實現策略。這個文件將描述實現工作的整體方法途徑，范圍，假定和風險等等。你可以在這里做出一些關于實現工作如何進行的基本決策。例如，你可以決定在實現過程中是否要進行平行測試，或是在一個特定的階段中系統是否要關閉。
下一次你要考慮到實現工作是在設計階段。這里你將創建一個較低級別的實現計劃。如果你創建一個初始策略文件，實現計劃將會加入很多詳細內容。如果你沒有創建策略文件，你需要從更高的層次上理解你想要完成什么，但然后你很快地跳入了計劃細節之中了。實現計劃用來設置實現工作的整體時間進度，確定誰將進行這方面的工作，列出所涉及的公司組織，估計工作量和持續時間等的參數。如果實現工作涉及到新的處理過程，你需要解決如何對用戶進行培訓和誰來進行培訓的問題。如果實現工作需要發生在多個位置之上，你需要對整體的順序給出描述。要注意實現計劃提供了可以與你的出資人和項目團隊共享的詳細信息，這一點是很重要的。然而，它還沒有到達實際工作計劃的級別。
建構實現工作計劃
到目前為止，我們已經完成了實現策略（在分析階段）和實現計劃（在設計階段）。然而，我們仍要為部署工作實際地去建構工作計劃行動。這應當在建構階段完成。在這一點上，你已經經歷了從高到底的級別，因此你剩下的工作是去實際地定義行動，從屬，時間和負責人員等等。
當你確實到達了實現階段的時候，你已經準備好了一個工作計劃，而且你能夠確信它可以完成你的需要，因為你已經有了從高到底的計劃。
溝通永遠是關鍵
在進行計劃之外，實現工作的另一個關鍵元素是溝通（這里，我們談到的還是一個復雜的實現工作，如果不是這樣，你也許只需將解決方案投入生產過程之中并對你的所做給出解釋可以解決問題和客戶的抱怨）。如果你采取一個與前面所描述的類似的方法，那么你一直都在進行溝通。實現策略意在從一個客戶的觀點關注于處理過程，而且在進行之前應該得到他們的許可。實現計劃應該貫徹給所涉及的所有人，你只需要不斷地進行信息的溝通并確保每個人對實現工作做好準備。
如果你沒有準備實現策略和計劃，你仍然需要盡可能早地與人進行溝通。舉個例子，我的經驗顯示，在開發人員和基礎架構人員之間有著一種天生的摩擦點，這是因為實現工作的具體細節沒有得到溝通，或是進行溝通的時候已經太遲了。有多少次你看到一個團隊準備好要實現一個客戶機—服務器應用軟件，但是發現他們需要讓工作站支持團隊在桌面上安裝這個應用軟件？當然，如果由于缺乏溝通導致支持團隊沒有做好準備，他們是不會高興的。其它的摩擦點包括當部署應用軟件或是出現重大改變時沒有能夠給出事先的警告，因為他們可能要接聽很多來自用戶的電話。第三點是開發團隊在發現服務器環境需要變動時為時已晚。再一次，如果這個需要在實現工作開始之前得到溝通，通常不會造成麻煩。
計劃和溝通帶動成功的實現工作
在這個專欄中，我們從一個方法論的角度上來看待實現工作。關鍵點在于早期計劃并經常溝通，以防意外發生。即使是復雜的實現工作也可以通過從頭到腳的計劃和良好的溝通得以成功地管理。另一方面，即使是簡單的實現工作也可能被糟糕的計劃和溝通所破壞。在這個系列的下一篇文章之中，我們將看一看實現工作的詳細內容和需要考慮并注意的地方。
