在IT行業混了十幾年，從事項目管理（早管理項目中的一部分業務模塊，算是個team leader吧）也有七八年了吧，這十幾年差不多也是中國軟件行業飛速發展的十幾年，軟件項目的規模與管理等，也較早期有了質的變化，但總體來說，我對國內的軟件項目還是比較失望的，優期是國內的企業，自己帶過的項目、公司同事帶過的項目、身邊朋友帶過的項目、客戶實施的其他項目，很少有可以按照軟件工程的思想去實施項目的，項目的質量、時間執行情況等到后都會大打折扣，后寫起項目總結時，總能寫出一大堆的項目管理過程的改善建議，下次再執行時，又總能出現新的改善建議，看上去似乎每次也都不太一樣，但大能有規律可循。以下我根據自己在項目管理中的體會，談談自己對國內軟件項目管理的一些想法，望各位輕拍~~~
軟件項目管理的問題源頭
在軟件剛開始興起的時候，國內的軟件企業，優期是中小型軟件企業，通常都有這樣一種現象，幾乎沒有哪家企業在成立時，先投入大量技術研發力量的，也是說很少企業是先進行產品研發的，多是先擁有一個或幾個有需求的客戶，然后給客戶做項目化的開發，有的甚至于項目完成后，軟件系統也不會在加以完善了，多是客戶提新需求過來時，再進行完善。如果接到下一個項目，則在老系統基礎上進行修改，以滿足新客戶的需求，如此幾個項目下來之后，同一套軟件系統便會出現多個版本，由于企業本身技術力量的不足，必然會走向無標準成型軟件系統的路子上。后同一個企業的同一個軟件系統，便會出現很多個標準，從而導致在每一次的軟件項目實施過程中，都沒有一個穩定成熟的軟件產品，但卻走著實施產品的方式，以此來壓縮項目實施周期，從而為項目實施過程增加了風險。
另外，部分相對成熟的企業，在初期的項目實施完成后，慢慢的感覺到，純項目化實施的成本越來越大，也意識到以產品帶動項目實施的重要性，因此便開始投入產品研發，但我們來看看他們的產品是怎么研發出來的，首先產品經理通常都來至于企業內部的項目經理，帶過一兩個項目，與一兩個客戶接觸過，沒有什么市場經驗，更談不上市場洞察力和市場需求分析能力了，并且在做產品前，也沒有進行過市場需求調研（這里說的是市場需求，并不是特指一兩個客戶的需求，市場需求是指產品所面向的整個市場的需求情況，并且是未來若干年內的需求），他們完全是基于已完成的項目基礎上，對項目產出物的不足之處的完善，通常會根據產品經理或架構師的個人理解，對軟件產品預留一些擴展而已。這樣的產品自然會存在很多的不足，一兩個客戶怎么能代表整個行業的需求呢，把項目產品物加以完善而形成產品，本身伸縮性有限，怎么能應對市場多種需求的變化呢，帶過一兩個項目的產品經理，他的視野又能有多開闊呢，這些問題必須會導致產品本身并沒有什么市場競爭力，同時也會項目實施留下了不可回避的擴展風險。
國內企業有個特點，是在付錢后，狠不點馬上能用上系統，根本不去考慮項目的實施周期問題，客戶總覺得我已經付了，你應該馬上把東西給我，這是里所當然的。跟客戶談過工時的人，請問你們有沒有遇到過哪個客戶跟你說，這么點時間你們實施來的急嗎，會不會時間太短了，要不要多點時間，對不起，這么多年來我沒有見過一個客戶這么問過我。其實一家企業從有需求進行招標開始，到終的項目上線，周期還是非常長的，但我們回想一下，這么長的時間，項目招標以及產品初步交付到終上線的過程用了多少時間。所以在項目立項到上線、甚至上線后的一段時間內，項目組的人都會拼命的趕進度、加班、加人等等，但終還是感覺時間不夠用，甚至于不能按計劃上線。
上面我從產品質量問題以及項目實施周期的不合理性方面，分析了下國內軟件項目管理的源頭上所存在的問題，這為后期的項目實施過程帶來了不可逾越的困難。后面我會陸續的對以上兩點再做詳細的分析，敬請關注！
我們都知道，項目是否可以結束，是要由驗收情況來決定的，在國內的中小型企業的項目中，對于項目驗收這塊存在著很多模糊的情況，是導致項目驗收過程不能順利進行、甚至于無法進行驗收的首要問題。
我問個問題，項目驗收的標準是什么？大家都會說是需求確認書，那再問一下，需求確認書的標準又是什么？沒錯，是項目合同。項目合同才是項目驗收標準的首先依據，而在國內軟件項目合同中，基本都存在著很多的問題，這些項目合同大多都描述了合同的金額、項目名稱、交付物、幾個關鍵時間點，對于項目實施的范圍有些也會有所描述，但都比較簡單模糊。另外一點，對于有些項目經理，有可能連項目合同中僅有的部分項目邊界描述也沒有機會看到，這樣必然會導致軟件項目后期驗收中的問題。
因此，在簽定項目合同時，應該考慮一下項目驗收的問題，為項目驗收界定一個明確的范圍，比如說項目所涉及到的部門、所需要解決的業務清單、所需要達到的目標、交付物的交付標準與規范等，并且把項目驗收計劃書作為合同的附件、以后做項目驗收時，僅以此驗收計劃書為基準，這樣可以有效的避免因在項目過程中無限擴大邊界而導致的項目無法完成驗收的問題。
在項目合同期明確的驗收標準之后，在需求階段，應以項目合同為基礎、驗收計劃書為指導依據進行需求確認，如果有必要，可以在需求確認階段修訂驗收計劃書，這樣也可以保證項目邊界與合同不會有太多的出入。
在保證了項目驗收計劃書的質量之后，后期進行項目驗收時，不會出現這個沒實現、那個也沒實現的問題（如果真有沒實現，那可能真是實施的問題，忘記實現了），因為有法可依了，同時項目經理在準備項目驗收時，也可以提前參照一下驗收計劃書，以免有未達到目標的部分出現，也可提前把問題解決，為項目驗收掃清障礙。
在軟件項目中（其他類項目也是一樣），項目經理的作用至關重要。平均算下來，一個項目的成敗、完成質量大約有60%的因素取決于項目經理（也是說一個很差的項目經理，至少有60%的項目實施失敗或完成質量低下）。目前，在國內的軟件項目中，項目經理主要有以下幾種類型：
1、掛名項目經理
這種情況主要出現在面向客戶的時候，由于企業自身項目經理的素質較低，拿不出手，或者是為表示對客戶的“重視”（注意，這里只是在官場上的重視），公司選用高層領導擔任項目經理，其并不會參與項目過程的實質性工作。此類項目經理因為是掛名，不參與實質性工作，所以對項目過程的影響比較小，可以說是可有可無，所以對能力方面也沒有什么要求。
2、實施類項目經理
此類項目經理主要負責對客戶的項目實施，一般公司擁有自己產品的時候，會設立實施類項目經理，這類項目經理通常技術水平一般，業務能力較強。實施類項目經理通常出生于項目實施工程師、咨詢顧問。所以一般業務能力會比較強，但問題是可能管理能力和技術能力會跟不上，優期是技術能力，因為軟件項目中或多或少的都會涉及到客戶化的開發，由于技術能力的欠缺可能會導致對方案、工時方面的判斷失誤。
3、技術研發類項目經理
此類項目經理多為客戶化開發或公司內部的項目經理，主要是帶領團隊從事技術研發工作，本身技術能力較強。該類項目經理通常出生于技術工程師，所以技術能力一般較強，但問題是管理能力不足、業務能力欠缺、優其是技術出生的管理者往往太追求完美或因專注于某項技術而忽略整個項目的管理。
4、全能性項目經理
此類項目經理比較“利害”了，什么事都能干，可一人兼做商務、技術架構、業務咨詢等，通常此類項目經理在小型企業的小型項目中比較多見。此類項目經理通常出生于技術，因為在很多個中小型企業做過，所以練了一人身兼多職的能力。看似比較“全能”，其實各項能力均不夠專業化，也是大家說的什么都會，但什么都不精。這類項目經理特別適合中小型企業的中小型項目，他們可以在資源嚴重不足的情況下，完全通過個人的能力完成一個小型項目。這種項目的失敗率也比較高，項目經理頂不住，項目必然失敗。所以全能型項目經理在稍大些項目中，也很難看到。
為了更好的進行軟件項目管理，實質上應該只有實施類項目經理和技術研發類項目經理才能算的上是真正意義上的項目經理，才能擔當軟件項目經理一職，才能管好項目。這兩種類型的項目經理，在其自身能力方面，應該各具特色，其中必備的能力素質如下：
1、團隊管理能力；
2、溝通協調能力；
3、控制能力；
4、執行能力；
5、解決問題的能力；
6、責任心；
7、對于實施類項目經理，必須具備業務能力（可以不熟悉項目所涉及到的全部業務，但必須熟悉一種以上，并且必須熟悉各業務間的耦合）；
8、對于技術研發類項目經理，必須具備很強的技術研發能力（可以是項目所涉及到的一種或多種技術）。
除了以上所描述的項目經理必備能力素質以外，項目經理還必須要有項目上所必須的特殊化技能，如對國外客戶時應具備與客戶溝通的語言技能等。
項目經理如果存在以下問題，可能會直接或間接的導致項目的失敗：
1、實施類項目經理不熟悉項目中的業務；
2、技術研發類項目經理不具備技術研發能力；
3、太專注于某一方面，而忽略整個項目的其他方面；
4、太強調自己的領導地位，讓下屬對其失去親和力；
5、過問太多細節，表現出對下屬的不信任；
6、做事太過謹慎，當斷不斷；
7、表達能力差，不能用簡短的語言描述清楚一件事情；
8、事事追求完美者。
另外，在國內的軟件項目中，項目經理本身的職責權利還沒有達到真正意義上的權利，在項目中的很多事情項目經理不能自己做主，如項目實施方法論、項目中的部分關鍵時間點，甚至于部分項目資源的分配方式等。這也會制約部分有實際能力的項目經理的能力發揮。因此企業在任命項目經理時，除了要選配具備項目經理素質的人才之外，還應提供一定的職權空間。
在軟件項目中，通常情況下都會分成以下幾個階段，項目立項、需求調研、需求分析、需求確認、功能設計、設計確認、功能開發、測試、實施推廣、試運行、項目驗收。這是比較詳細的分法，還有一種比較大的分法，如下所示：
1、需求階段：包括有需求調研、需求分析、需求確認；
2、設計開發階段：功能設計、設計確認、功能開發、測試；
3、實施階段：實施推廣、試運行、項目驗收；
從上面可以看到，可把項目階段統分為三個大的階段，從這三個大階段方面，我們來分析下各階段的重要性，這里所說的重要性是站上項目風險和控制難易成度的角度來考慮的。
首先來說說需求階段，需求階段的目的是為了了解清楚用戶現在的情況和未來的一些想法，項目需求人員要通過各種方法把用戶了解清楚，并轉化為自己的理解，在這個階段通常會存在以下幾方面的問題：
A、怎么樣讓用戶把他們的現狀完整、準確的描述給你；
因為對于企業來說，都是分工合作的，每一個人都只會熟悉自己的業務部分，即使對于上層管理者，他們所了解的是大方向上面的東西，對于細節了解不夠，所以在需求調研時，想準確、完整的了解到用戶現狀是非常困難的一件事，優期是各業務間的耦合部分，你有時會覺得找不到一個人可以說清楚這中間是如何銜接的。
B、現狀中的問題無人可以承擔
在經過一段時間的現狀調研之后，你會發現這家企業中存在著各中各樣的問題管理上的問題、或業務操作上的問題，這時你可能是為了要把現狀陳清，所以希望能有個人出來說，是的，這塊是有問題，這實際上也是一件很困難的事， 因為誰也不想承認自己的錯誤。
C、流程再造后無人愿意定案
在進行完現狀調研之后，必然會進行必須流程再造，對于新流程的應用，必須會涉及到原來職責、職能的變更，對于這樣的變更必然是要經過相關管理層人員的決策，這是一個長期而又慢長的過程，一般管理者都不會輕易的去改變現有的管理模式，所以這給需求確認階段帶來了不少的困難。
其次來分析下設計開發階段，該階段是建立在完成需求階段的工作基礎之上的，需求階段的成果直接決定了設計開發階段的工作。在該階段的主要問題表現為以下幾個方面：
A、開發過程中，用戶提出的需求變更
在開發過程中，讓人痛苦的莫過與此了，誰也不想辛苦設計開發出的東西，剛完成被用戶否定了。
B、開發出的東西與設計的東西不一致
通常因為開發人員對于需求或設計的理解不夠，會導致開發出的東西和設計不輔，從而不得不進行修改程序。
C、開發出的東西有一堆BUG
這是在正常不過的事情了，所以才需要測試啊。
后來說說實施階段吧，在經歷前面的需求和設計開發階段后，總算可以拿出東西給客戶看了，實施階段往往并沒有想象中的那么順利，在該階段主要有以下問題影響的實施進度。
A、用戶進行系統驗證時發現自己看到跟當初想象的不一樣
這個每個項目經理都會有體驗吧，不管前期做了多少次變更，總規有那么些節點跟用戶想的不一樣。
B、上了系統后，用戶不知道怎么做業務了
系統都是按照用戶的要求進行設計的，即使有些流程跟以前不太一樣，但也是通過用戶確認認可了的，但在新的系統上，用戶是不知道該怎么做業務了。
C、有些人始終停留在老的操作模式上，不愿意改變
在實施推廣階段我們總會遇到一部分人，不管你怎么說，他總是堅持自己的想法，有的可能真的是不知道怎么改變，而有的也會是因為各種原因不愿意去改變，他們不改變你永遠無法完成系統的實施。
實施項目實質上也可以看成是一種投資，站在投資的角度來考慮，投資分析重要的一點是前期的準備工作，真正的投資實施過程并不特別難，因為你只要按照前期計劃的去做可以了。所以說在軟件項目中， 需求階段是為重要的，其次應該是實施推廣階段，后才是設計開發階段，為什么要這么說呢，可從以下幾個方面來分析。
A、需求階段的目的是為了搞清楚后面的工作該怎么做的，如果你都不知道用戶的現狀是什么樣的，都不知道用戶想要什么樣的的東西，那后面的設計和開發出的東西可以說不可能滿足客戶的要求，也必然會經歷一次又不一次需求變更，即使到了實施推廣階段你也一樣無法進行推廣，因為跟他們現在的業務完全不輔，你讓人家怎么去用。
B、需求階段因為是與客戶進行交流互動的過程，因為你對客戶的不了解（如果你了解，可能不需要調研了），所以交流上會存在各種困難，有個事情，你甚至不知道該找誰去問。了解客戶的現狀還需要客戶在時間和人員上的配合，改造他的流程，也需要相對領導的審批，這些都可能不是調研人員所能控制的，難道你想讓客戶停止現在的業務來配合你，這不可能；難道你想讓客戶的領導不要出差、不要開會，來給你簽字確認，那更不可能。
所以需求階段有很多因素是你不能控制的，所以是有風險的，所以是困難的。
C、設計開發階段其實并沒有想象中的那么困難，假如說你已經知道了你要做一個什么的東西，你對的你團隊又很了解，你應該可以控制他們，可以安排他們，那么接下來你要做的是安排一步步的去實現可以了，如果有難度那可能是人力資源不夠吧，那也沒關系，你還可以安排加班呢，如果還不行，那你應該提出來了，即使是簡單的實現工作，算上加班，你現在的人手也不夠，那只能增加人手或延長時間了。
這里你不要說中間可能會存在很多技術上的問題，或者進行二次開發時的一些切入點問題，這些我認為不是關鍵性的問題，作為一個項目團隊，如果連一些技術問題都解決不了，還怎么去實施項目呢，再說現在對于業務功能的實現也不局限于一種技術，為什么你一定要選一個你實現不了的技術呢。
所以說設計開發階段應該更多是量化性的工作，并且是可控制的，所以說風險應該也是小的。
D、實施推廣階段，因為在需求階段不管如何做，總規會存在一些需求變更的情況，其中在實施推廣時表現的也為強烈，并且實施推廣階段要涉及到用戶業務操作方式的變化，所以說需要一些時間給用戶進行轉換與適應。另外在實施推廣階段中，因為所涉及到都是客戶人員，有些時候還會是客戶的客戶，所以在應用推廣時，會存在很大的障礙，主要還是業務切換上面的問題。
綜上所述，在項目管理的三大階段中，需求階段為重要，也重困難，其次是實施推廣階段，設計開發階段應該是容易的，因此我們在項目總的時間分配上，應根據各階段的具體情況來制定時間計劃。在通常情況下，應該三個階段所有時間比例想近才對，你不要介意前期花太多的時間去做需求，那是值得。對于設計開發階段的時間可以壓縮的話，可盡量壓縮，把時間留給需求和實施推廣階段，不要把太多的時間花在內部上，而應該花在客戶身上，不可控的才是風險，可控的算不上什么風險。
