在it行業混了十幾年，從事專案管理（最早管理專案中的一部分業務模組，算是個team leader吧）也有七八年了吧，這十幾年差不多也是中國軟體行業飛速發展的十幾年，軟體專案的規模與管理等，也較早期有了質的變化，但總體來說，我對國內的軟體專案還是比較失望的，優期是國內的企業，自己帶過的專案、公司同事帶過的專案、身邊朋友帶過的專案、客戶實施的其他專案，很少有可以按照軟體工程的思想去實施專案的，專案的質量、時間執**況等到最後都會大打折扣，最後寫起專案總結時，總能寫出一大堆的專案管理過程的改善建議，下次再執行時，又總能出現新的改善建議，看上去似乎每次也都不太一樣，但大能有規律可循。以下我根據自己在專案管理中的體會，談談自己對國內軟體專案管理的一些想法，望各位輕拍~~~
軟體專案管理的問題源頭
在軟體剛開始興起的時候，國內的軟體企業，優期是中小型軟體企業，通常都有這樣一種現象，幾乎沒有哪家企業在成立時，先投入大量技術研發力量的，也就是說很少企業是先進行產品研發的，多是先擁有乙個或幾個有需求的客戶，然後給客戶做專案化的開發，有的甚至於專案完成後，軟體系統也就不會在加以完善了，最多是客戶提新需求過來時，再進行完善。如果接到下乙個專案，則在老系統基礎上進行修改，以滿足新客戶的需求，如此幾個專案下來之後，同一套軟體系統便會出現多個版本，由於企業本身技術力量的不足，必然會走向無標準成型軟體系統的路子上。最後同乙個企業的同乙個軟體系統，便會出現很多個標準，從而導致在每一次的軟體專案實施過程中，都沒有乙個穩定成熟的軟體產品，但卻走著實施產品的方式，以此來壓縮專案實施週期，從而為專案實施過程增加了風險。
另外，部分相對成熟的企業，在初期的專案實施完成後，慢慢的感覺到，純專案化實施的成本越來越大，也意識到以產品帶動專案實施的重要性，因此便開始投入產品研發，但我們來看看他們的產品是怎麼研發出來的，首先產品經理通常都來至於企業內部的專案經理，帶過一兩個專案，與一兩個客戶接觸過，沒有什麼市場經驗，更談不上市場洞察力和市場需求分析能力了，並且在做產品前，也沒有進行過市場需求調研（這裡說的是市場需求，並不是特指一兩個客戶的需求，市場需求是指產品所面向的整個市場的需求情況，並且是未來若干年內的需求），他們完全是基於已完成的專案基礎上，對專案產出物的不足之處的完善，通常會根據產品經理或架構師的個人理解，對軟體產品預留一些擴充套件而已。這樣的產品自然會存在很多的不足，一兩個客戶怎麼能代表整個行業的需求呢，把專案產品物加以完善而形成產品，本身伸縮性有限，怎麼能應對市場多種需求的變化呢，帶過一兩個專案的產品經理，他的視野又能有多開闊呢，這些問題必須會導致產品本身並沒有什麼市場競爭力，同時也會專案實施留下了不可迴避的擴充套件風險。
國內企業有個特點，就是在付錢後，狠不點馬上就能用上系統，根本不去考慮專案的實施週期問題，客戶總覺得我已經付了首款，你就應該馬上把東西給我，這是裡所當然的。跟客戶談過工時的人，請問你們有沒有遇到過哪個客戶跟你說，這麼點時間你們實施來的急嗎，會不會時間太短了，要不要多點時間，對不起，這麼多年來我沒有見過乙個客戶這麼問過我。其實一家企業從有需求進行招標開始，到最終的專案上線，週期還是非常長的，但我們回想一下，這麼長的時間，專案招標以及產品初步交付到最終上線的過程用了多少時間。所以在專案立項到上線、甚至上線後的一段時間內，專案組的人都會拼命的趕進度、加班、加人等等，但最終還是感覺時間不夠用，甚至於不能按計畫上線。
也談軟體專案管理
今天得空看了看osgeo上的gdal開發資源。開源專案的管理也比商業專案完善的多，大的軟體專案真不是幾個牛人就能搞出來的，除非做的是一次性的專案。管理在大型專案開發中的作用怎麼強調都不為過，我們基本上都是做的不夠。冗長的 簡短的文件，大多數專案離開原班開發者後就成了雞肋，離開 加入新人都是超級費勁的...
軟體專案管理 三 軟體專案範圍管理
專案範圍對專案的影響是決定性的，它確定了軟體專案工作內容的多少。有效的範圍管理可以保證專案只做必須做的事情，避免範圍蔓延和做無用功，同時也避免不清晰的需求所導致的嚴重的系統缺陷 需求獲取工作的任務就是收集專案干係人的需求資訊，為定義專案的範圍奠定基礎。需求獲取工作只能通過使用者與開發人員之間進行高度...
軟體專案管理 作業1
1 描述專案 專案管理和軟體專案管理的概念。專案 是一次性 創造性的活動。專案管理 就是在專案活動中運用專門的知識 技能 工具和方法，使專案達到預期目標的過程，是以專案作為管理物件，通過乙個臨時性的 專門的柔性組織，對專案進行計畫 組織 執行和控制，並在時間 成本 效能 質量等方面達到預期目標的一種...