其實做乙個專案經理真不是乙個好的職業，它需要太多的千錘百鍊才能修煉出來。這不僅需要反覆經歷「失敗-總結-再失敗」的輪迴，而且需要有一顆無比堅強的心，能夠在無數次經歷無比艱難並且令人沮喪的時刻而能堅持不懈、毫不氣餒。乙個專案經理就像一位將軍。將軍百戰死，而專案經理呢，經歷無數專案以後沉澱下來的，更多的是疲憊與滄桑。
但凡乙個好的專案經理都是要經過一次又一次專案失敗的教訓，似乎只有失敗才能留給他們更深刻的教訓與更巨大的提公升。當然，這種失敗可大可小。即使一些專案最終是成功了，也只是結果的成功，而專案進行過程中的失誤，以及因此帶來的成本的提高，過程的曲折，同樣是一種失敗。專案管理之難，作專案經理之難可見一斑。
專案管理之難，其真正的難處就在於，要將其做好，需要注意的地方實在太多。任何乙個方面沒有做好，都會造成專案的失敗。文章之初提出的軟體開發的風險，實質就是軟體需求的風險，在專案管理中就是需求管理。需求管理的失敗是大多數專案失敗的根本原因，這其中包括需求理解的準確性、需求變更的管理，等等。這篇文章討論迭代式開發，就是給大家需求管理帶來一種思路。
而另乙個非常重要的方面就是專案進度管理。當專案計畫制訂出來以後，就必須按照專案計畫進行，任何的專案延期都會是一種巨大的風險。如何避免專案延期，是專案成功的關鍵因素。作為專案經理，如何避免專案延期呢？那就是在專案進行的任何時刻都要清楚地知道「where you are」，讓使用者清楚地知道「where you are」。
where you are，對於我們來說就是專案進行到什麼程度了。我們要隨時問我們這個問題，隨**估專案進度的偏差，及時進行調整，才可能使專案如期交付。如何做到這一點呢？我們制訂了詳細的專案計畫，計畫中將每一項工作的進行時間都制訂出來。這個計畫就是我們的航標，將計畫與進度比較，就可以隨時清楚專案進度的偏差。同時，製作burn-down table，隨時關注還有多少工作沒有完成，還剩多少時間，就可以從另乙個角度直觀地認識專案的進度。
當需求發生變更時，必然造成工作量的增加。重新調整我們的專案計畫，就如同重新調整我們的航線。這還包括重新調整我們的人員、我們的分工，以及我們的工期，使其符合實際情況。然後我們就可以按照新的航線前進了（以往很多專案的失敗，正是因為發生變更以後還是按照原有的航線前進，其風險可想而知）。
完成專案計畫修改的同時，不要忘了我們的burn-down table。我們要重新評估我們的剩餘工作量和剩餘時間，繪製到當前的時間上。只有這樣，我們才能隨時知道「where you are」，才能有效地監控專案程序。
那麼，為什麼要讓使用者清楚地知道「where you are」呢？乙個軟體專案的進行其實不光是我們自己的事情，也是客戶的事情。專案一旦進行，其實客戶與我們是綁在一根樹上的螞蚱。讓客戶知道我們的進度，能增加客戶對我們的信任感；讓客戶知道我們的難處，會讓客戶與我們共同想辦法去解決問題，去規避專案風險。這樣做，其實對大家都有好處，何樂而不為呢？
所以，迭代式開發對有效避免軟體開發的風險，作用是巨大的。但問題是，如何在專案中實際運用起來，挑戰也是巨大的，很多難題需要解決，我們只有不斷上下而求索，總結、總結、再總結••••••
[url=一次迭代式開發的研究：軟體開發的風險[/url]
[url=一次迭代式開發的研究：什麼是迭代式開發[/url]
[url=一次迭代式開發的研究：怎樣進行迭代式開發[/url]
[url=一次迭代式開發的研究：迭代開發從這裡開始[/url]
[url=一次迭代式開發的研究：準確的工作量評估[/url]
[url=一次迭代式開發的研究：功能的優先順序評估[/url]
[url=一次迭代式開發的研究：乙個迭代式專案計畫[/url]
[url=一次迭代式開發的研究：開始真正的工作[/url]
[url=一次迭代式開發的研究：從容應對需求變更[/url]
[url=一次迭代式開發的研究：需求變更的關鍵步驟[/url]
[url=一次迭代式開發的研究：where you are[/url]
[b]（全文終）[/b]
一次迭代式開發的研究 怎樣進行迭代式開發
前面我們提到了迭代式開發的巨大優勢，它可以降低我們軟體開發的巨大風險，它可以使我們把握使用者的真正需求，它可以使我們從錯誤與偏差中及時糾正過來，那麼我們應該如何進行迭代式開發呢？要回答這個問題，我們首先要弄清迭代式開發與傳統的瀑布式開發的差別在 b 1.需求分析的差別 b 與傳統的軟體開發一樣，迭代...
一次迭代式開發的研究8 開始真正的工作
我們經過以上一系列的分析，工作量評估與優先順序評估，制訂出乙個迭代式的專案計畫，再經過一系統使用者確認與公司評審以後，終於可以開始我們真正的開發工作。其實，迭代式開發的執行過程，也就是製作和不斷去關注與評估專案進度表的過程。因此，當專案進入執行開發過程時，專案經理應當首先製作專案進度表。現在我們看看...
一次迭代式開發的研究10 需求變更的關鍵步驟
前面我們提到了需求變更。當客戶提出了需求變更，經過與我們的需求人員的詳細討論與分析，最後確定下來了變更內容和修改方案。但這時草率地開始進行設計和開發是不正確的，它將成為專案後期的乙個巨大的風險，一顆定時zhadan，為什麼呢？我們來詳細分析分析。每當發生需求變更的時候，不管是大是小，專案的許多因素都...