在軟體專案中，通常情況下都會分成以下幾個階段，專案立項、需求調研、需求分析、需求確認、功能設計、設計確認、功能開發、測試、實施推廣、試執行、專案驗收。這是比較詳細的分法，還有一種比較大的分法，如下所示：
1、需求階段：包括有需求調研、需求分析、需求確認；
2、設計開發階段：功能設計、設計確認、功能開發、測試；
3、實施階段：實施推廣、試執行、專案驗收；
從上面可以看到，可把專案階段統分為三個大的階段，從這三個大階段方面，我們來分析下各階段的重要性，這裡所說的重要性是站上專案風險和控制難易成度的角度來考慮的。
首先來說說需求階段，需求階段的目的是為了了解清楚使用者現在的情況和未來的一些想法，專案需求人員要通過各種方法把使用者了解清楚，並轉化為自己的理解，在這個階段通常會存在以下幾方面的問題：
a、怎麼樣讓使用者把他們的現狀完整、準確的描述給你；
因為對於企業來說，都是分工合作的，每乙個人都只會熟悉自己的業務部分，即使對於上層管理者，他們所了解的是大方向上面的東西，對於細節了解不夠，所以在需求調研時，想準確、完整的了解到使用者現狀是非常困難的一件事，優期是各業務間的耦合部分，你有時會覺得找不到乙個人可以說清楚這中間是如何銜接的。
b、現狀中的問題無人可以承擔
在經過一段時間的現狀調研之後，你會發現這家企業中存在著各中各樣的問題管理上的問題、或業務操作上的問題，這時你可能是為了要把現狀陳清，所以希望能有個人出來說，是的，這塊是有問題，這實際上也是一件很困難的事， 因為誰也不想承認自己的錯誤。
c、流程再造後無人願意定案
在進行完現狀調研之後，必然會進行必須流程再造，對於新流程的應用，必須會涉及到原來職責、職能的變更，對於這樣的變更必然是要經過相關管理層人員的決策，這是乙個長期而又慢長的過程，一般管理者都不會輕易的去改變現有的管理模式，所以這給需求確認階段帶來了不少的困難。
其次來分析下設計開發階段，該階段是建立在完成需求階段的工作基礎之上的，需求階段的成果直接決定了設計開發階段的工作。在該階段的主要問題表現為以下幾個方面：
a、開發過程中，使用者提出的需求變更
在開發過程中，最讓人痛苦的莫過與此了，誰也不想辛苦設計開發出的東西，剛完成就被使用者否定了。
b、開發出的東西與設計的東西不一致
通常因為開發人員對於需求或設計的理解不夠，會導致開發出的東西和設計不輔，從而不得不進行修改程式。
c、開發出的東西有一堆bug
這是在正常不過的事情了，所以才需要測試啊。
最後來說說實施階段吧，在經歷前面的需求和設計開發階段後，總算可以拿出東西給客戶看了，實施階段往往並沒有想象中的那麼順利，在該階段主要有以下問題影響的實施進度。
a、使用者進行系統驗證時發現自己看到跟當初想象的不一樣
這個每個專案經理都會有體驗吧，不管前期做了多少次變更，總規有那麼些節點跟使用者想的不一樣。
b、上了系統後，使用者不知道怎麼做業務了
系統都是按照使用者的要求進行設計的，即使有些流程跟以前不太一樣，但也是通過使用者確認認可了的，但在新的系統上，使用者就是不知道該怎麼做業務了。
c、有些人始終停留在老的操作模式上，不願意改變
在實施推廣階段我們總會遇到一部分人，不管你怎麼說，他總是堅持自己的想法，有的可能真的是不知道怎麼改變，而有的也會是因為各種原因不願意去改變，他們不改變你就永遠無法完成系統的實施。
實施專案實質上也可以看成是一種投資，站在投資的角度來考慮，投資分析最重要的一點是前期的準備工作，真正的投資實施過程並不特別難，因為你只要按照前期計畫的去做就可以了。所以說在軟體專案中， 需求階段是最為重要的，其次應該是實施推廣階段，最後才是設計開發階段，為什麼要這麼說呢，可從以下幾個方面來分析。
a、需求階段的目的是為了搞清楚後面的工作該怎麼做的，如果你都不知道使用者的現狀是什麼樣的，都不知道使用者想要什麼樣的的東西，那後面的設計和開發出的東西可以說不可能滿足客戶的要求，也必然會經歷一次又不一次需求變更，即使到了實施推廣階段你也一樣無法進行推廣，因為跟他們現在的業務完全不輔，你讓人家怎麼去用。
b、需求階段因為是與客戶進行交流互動的過程，因為你對客戶的不了解（如果你了解，可能就不需要調研了），所以交流上會存在各種困難，有個事情，你甚至不知道該找誰去問。了解客戶的現狀還需要客戶在時間和人員上的配合，改造他的流程，也需要相對領導的審批，這些都可能不是調研人員所能控制的，難道你想讓客戶停止現在的業務來配合你，這不可能；難道你想讓客戶的領導不要出差、不要開會，來給你簽字確認，那更不可能。
所以需求階段有很多因素是你不能控制的，所以是有風險的，所以是最困難的。
c、設計開發階段其實並沒有想象中的那麼困難，假如說你已經知道了你要做乙個什麼的東西，你對的你團隊又很了解，你應該可以控制他們，可以安排他們，那麼接下來你要做的就是安排一步步的去實現就可以了，如果有難度那可能就是人力資源不夠吧，那也沒關係，你還可以安排加班呢，如果還不行，那你就應該提出來了，即使是簡單的實現工作，算上加班，你現在的人手也不夠，那只能增加人手或延長時間了。
這裡你不要說中間可能會存在很多技術上的問題，或者進行二次開發時的一些切入點問題，這些我認為不是關鍵性的問題，作為乙個專案團隊，如果連一些技術問題都解決不了，還怎麼去實施專案呢，再說現在對於業務功能的實現也不侷限於一種技術，為什麼你一定要選乙個你實現不了的技術呢。
所以說設計開發階段應該更多是量化性的工作，並且是可控制的，所以說風險應該也是最小的。
d、實施推廣階段，因為在需求階段不管如何做，總規會存在一些需求變更的情況，其中在實施推廣時表現的也最為強烈，並且實施推廣階段要涉及到使用者業務操作方式的變化，所以說需要一些時間給使用者進行轉換與適應。另外在實施推廣階段中，因為所涉及到都是客戶人員，有些時候還會是客戶的客戶，所以在應用推廣時，會存在很大的障礙，主要還是業務切換上面的問題。
綜上所述，在專案管理的三大階段中，需求階段最為重要，也重困難，其次是實施推廣階段，設計開發階段應該是最容易的，因此我們在專案總的時間分配上，應根據各階段的具體情況來制定時間計畫。在通常情況下，應該三個階段所有時間比例想近才對，你不要介意前期花太多的時間去做需求，那絕對是值得。對於設計開發階段的時間可以壓縮的話，可盡量壓縮，把時間留給需求和實施推廣階段，不要把太多的時間花在內部上，而應該花在客戶身上，不可控的才是風險，可控的算不上什麼風險。
對於各個階段具體快如何控制，需求階段如何來做好需求，後面我會陸續進行分析，盡請期待……
軟體專案管理隨談（1） 軟體專案管理的問題源頭
在it行業混了十幾年，從事專案管理 最早管理專案中的一部分業務模組，算是個team leader吧 也有七八年了吧，這十幾年差不多也是中國軟體行業飛速發展的十幾年，軟體專案的規模與管理等，也較早期有了質的變化，但總體來說，我對國內的軟體專案還是比較失望的，優期是國內的企業，自己帶過的專案 公司同事帶...
也談軟體專案管理
今天得空看了看osgeo上的gdal開發資源。開源專案的管理也比商業專案完善的多，大的軟體專案真不是幾個牛人就能搞出來的，除非做的是一次性的專案。管理在大型專案開發中的作用怎麼強調都不為過，我們基本上都是做的不夠。冗長的 簡短的文件，大多數專案離開原班開發者後就成了雞肋，離開 加入新人都是超級費勁的...
軟體專案管理（4）
軟體專案管理 4 軟體專案啟動階段的知識與管理 軟體專案啟動即專案的籌備 規劃與準備階段，是軟體專案實施的前期工作。軟體專案啟動由兩個重要的工作階段構成 一是專案的立項，而是專案的全面計畫。立項階段完成的主要工作有 1 立項建議書 2 可行性分析報告 3 確定專案任務書 4 組建專案團隊 專案計畫制...