20年前，項目管理的應用僅限於美國國防部的承包商和建築公司。如今，項目管理的基本思想已被廣範應用於國防，建築，製藥，化工，電信，軟件開發，銀行，廣告，會計，司法，政府和聯合國等領域和機構。這些機構已經意識到了項目管理和生產率之間的緊密關係，及其在當今商業環境中的至關重要性。
一項調查表明，大約70%的軟件開發項目超出了估算的時間，大型項目平均超出計劃交付時間20%至50%，90%以上的軟件項目開發費用超出預算，並且項目越大，超出項目計劃的程度越高。因此，軟件開發迫切需要進行項目管理。但是，軟件開發不同於其他產品的製造，軟件的整個過程都是設計過程（沒有製造過程）；另外，軟件開發不需要使用大量的物質資源，而主要是人力資源；並且，軟件開發的產品只是程序代碼和技術文件，並沒有其他的物質結果。基於上述特點，軟件項目管理與其他項目管理相比，有很大的獨特性。
第一章 小型軟件公司的特點
俗話說，聚沙成塔，沒有在金字塔地層下大量的小型的甚至是作坊型的小軟件公司，就不可能有大型的特大型的軟件公司。現在，無論是大學的教程，還是書本，講的軟件工程管理都是針對大中型軟件公司的，連網絡上也很少有針對小型軟件公司的項目管理文章。小型的軟件公司只有實行軟件項目管理，才能生存和發展，才能向大中型軟件公司邁進，才能使軟件產業更加繁榮！
一個企業的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把別人的經驗生搬硬套到自己身上，可能會適得其反。同樣，管理一個軟件項目也一樣，大項目和小項目的方式不完全一樣。但從另一個角度來看，項目的大與小並沒有本質的區別，很多方法是共通的。本文的目的是從作者的經驗來談談小型軟件公司的項目管理。
小型軟件公司相對與大中型軟件公司而言，有以下的特點：
1、項目負責人一般也是公司的老闆,對軟件工程有一定的瞭解，但不全面，相對而言，對市場的瞭解較爲透徹或對技術很精通；
2、項目功能相對較少 ，涉及面相對較狹窄；
3、開發人員較少，人員結構簡單 ；
4、開發週期較短 ，少則兩三個月，多則一到兩年。
總的而言，大中型軟件公司，軟件開發主要分爲六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。軟件公司將軟件配置管理、軟件質量管理、軟件風險管理及開發人員管理四方面內容導入軟件開發的整個階段。小型軟件公司的軟件開發同樣分爲六個階段，但比較模糊，側重點也不一樣；至於軟件配置管理、軟件質量管理、軟件風險管理及開發人員管理四方面內容則比較少。
大中型軟件公司開發軟件就如八股文一樣：總體規劃、項目立項、需求分析、系統分析、系統設計、編碼實現、項目測試、文檔製作（八股文：破題、承題、起講、入手、起股、中股、後股、束股），一切都按部就班。小型軟件公司開發軟件就是寫現代文：不拘泥於形式，但同樣符合規則！！
爲了符合小型軟件公司的管理特點，本文將小型軟件公司的項目管理分爲三個部分：
編碼前的管理、編碼的管理、編碼後的管理。
第二章 編碼前的管理
無論是項目，管理都必須在以人爲本的前提下進行。以人爲本，指的不只是軟件開發人員這一部分。這裏的人主要指的是一些與項目有利害關係的一些人，即項目干係人(stakeholders)，一般包括客戶或者用戶、項目團隊、項公司的管理層等一些主要的利害關係者。 一個項目能否成功，很大程度上取決於能不能分清楚這些項目利害關係者各自對項目的影響，不能利用好這些人力資源，溝通協調好他們之間的關係。
一、 管理方式的改變
在土木工程的項目管理中，成本主要分爲三部分：人員工資等費用、管理費用、材料費用。其中人員工資等費用、管理費用隨着經濟的發展所佔的比重越來越大。土木工程的項目管理爲了降低人員工資費用、管理費用，採取了這樣一條措施：儘量縮短工期，節假日以項目爲準，平時週末不放假，項目完成在不補放。
很明顯，在軟件開發不需要使用大量的物質資源，而主要是人力資源，人員工資費用佔軟件開發成本的大頭。要減低人員工資費用，我們不能削減員工工資，更不能削減必要的人員，提高軟件開發人員的效率纔是根本。進行軟件開發有這樣的一個特點：你放下的時間越長，你要重新理清前面的關係需要的時間越長，構思連續性也不好。很多小問題，也是因爲中間間隔的時間太長，開發人員忽略導致的。現在，一般的軟件公司，特別是大中型軟件公司，都實行這樣的制度：星期一到五，朝九晚五上班；星期六、星期天放假。這樣，這個軟件開發都給打斷了，連續性很差，效率很低。
經過對土木工程的項目管理的對比吸收，以及結合目前的軟件公司的管理現狀，本公司實行以下的管理制度：
對於開發週期在兩三個月以內的小項目：週末也要上班，只在月末才放兩天假。等整個項目完成後，再把以前沒有放的假期補放。例如，一個項目從三月一號開始開發，五月三十一號完成。在這期間，三月底放假兩天，四月底放假兩天。因爲從三月份到五月份的公衆假期有：27天，但前面有放了四天假，理論上可以給軟件開發人員放23天的有薪假期。但實際操作時給放了半個月的假。
對於開發週期比較長的項目，跟小項目類似，每月放兩天的假期，但長假不是在項目完成後放，而是每隔半年放一次，時間爲一個月。
這樣的管理可以在一定程度上提高開發人員的效率，又可以避免長時間因爲沒放假，使開發人員感到枯燥，情緒低落，動力不夠，壓力過大的情況。當然在實際操作時，開發人員因爲自身的原因需要偶爾放的假，都會盡量滿足。
本來，爲了更好的提高效率，我公司還把白天的工作制度作了一些調整。一般進行軟件開發，特別時編寫代碼的人員都有這樣的體會：晚上的效率特別高。這是有原因的，晚上所受外界的干擾最少，人的精神特別容易集中，思路特別清晰。爲此，我公司實行了以下制度：開發人員統一居住，下午兩點到六點工作，晚上八點到十二點工作。實行這樣的制度，開發人員的效率得到很大的提高。但是，由於種種的原因，此制度不能實施下去。
二、 項目風險的估計
前面說到，小型軟件公司的項目經理往往是老闆本人，有很強的風險意識。但在這裏還是要着重說說軟件工程的風險管理，因爲項目經理認識的風險大多侷限在商業風險（銷售問題等）中，對風險的理解很片面。
軟件風險是指軟件開發過程中及軟件產品本身可能造成的傷害或損失。風險關注未來的事情，這意味着，風險涉及選擇及選擇本身包含的不確定性，在軟件開發過程及軟件產品都要面臨各種決策的選擇。風險是介於確定性和不確定性之間的狀態，是處於無知和完整知識之間的狀態。另一方面，風險將涉及思想、觀念、行爲、地點等因素的改變。根據風險內容，我們可以將風險分爲項目風險（成本提高，時間延長等）、技術風險（技術不成熟等）、商業風險（銷售問題等）、戰略風險（公司的經營戰略發生了變化）、管理風險（公司管理人員是否成熟等）、預算風險（預算是否準確等）等。
另外，我們還可以將風險分爲已知風險（如員工離職等）、可預報風險（從以往經驗得出可能有風險的）和不可預知風險。
例如，在一些訂單開發的軟件中，存在着很大的商業風險。林子大了，什麼鳥都有。客戶多了，需要就不同，客戶相關的風險出現的概率就不一樣。一些人只知道他們需要什麼；而另一些人知道他們不需要什麼。一些客戶希望進行詳細的討論，而另客戶則滿足於模糊的承諾。客戶有不同的個性。一些人喜歡享受客戶的身份，而另一些人則根本不喜歡作爲客戶。一些人會高興地接受幾乎任何交付的產品，並能充分利用一個不好的產品；而另一些人則會對質量差的產品猛烈抨擊。一些人會對質量好的產品表示讚賞；而另一些人則不管怎樣都抱怨不休。客戶和供應商之間也有各種不同的通信方式。一些人非常熟悉產品及生產廠商；而另一些人則可能素未謀面，僅僅通過信件來往和電話與生產廠商溝通。一個“不好的”客戶可能會對一個軟件項目組能否在預算內完成項目產生很大的影響。對於項目管理者而言，不好的客戶是對項目計劃的巨大威脅和實際的風險。
對於大多數軟件項目而言，風險因素——性能、成本、支持、進度，也代表了風險參考水平值。即，對於性能下降、成本超支、支持困難、或進度延遲，都有一個水平值的要求，超過它就會導致項目被迫停止。如果風險的組合所產生的問題引起一個或多個參考水平值被超過，則工作將會停止。在軟件風險分析中，風險參考水平值存在一個點，稱爲參考點或臨界點，在這個點上，決定繼續進行該項目或終止它（問題太多）都是可以接受的。下圖以圖形方式表示了這種情況。如果風險的組合產生問題導致成本超支及進度延遲，則會有一個水平值,即圖中的曲線，當超過它時會引起項目終止。
三、 項目進度成本效益的估計
其實，這也是項目風險有着緊密聯繫，是項目風險發生的一大因素之一。爲此，需要做到以下幾步：
1、在制定項目計劃時，必須進行項目的需求分析，明確項目的需求。
在的需求分析階段，往往存在着這樣的誤區：在項目的需求分析階段，開發方與客戶方在各種的問題的基本輪廓上達成一致即可，具體細節可以在以後填充。因爲無論開始時有多麼細緻，以後對需求的修改幾乎是必然的。當然這樣做是有原因的：在具體實際中由於種種原因客戶方很難在需求分析階段全面而準確地描述所有問題。隨着開發進度的推進，往往會有一些需求的改變。但是這樣做，由於需求階段對問題的描述不夠細緻，導致後來預算超出或者時間進度達不到要求。
正確的做法是：在項目需求分析階段，雙方必須全面地儘可能細緻地討論項目的應用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準。並且，在需求分析結束以後，雙方還要建立可以直接聯繫的渠道，以儘早地對需求變動問題進行溝通。並在項目需求分析完成後，和客戶明確項目的哪些部分可以在日後的進度中能修改，修改的限度，哪些不能修改。例如，應用背景、功能要求方面應該是在需求分析階段確定，日後不能做修改。而性能、界面及接口等可以在日後作有限度的修改。
2、制定項目計劃：
有人這樣說計劃的，“計劃，計劃，紙上畫畫，牆上掛掛，計劃不如變化！”。計劃很容易成爲空話，特別是在軟件工程中，影響計劃的因素太多，計劃就形同虛設了！但是，軟件進行項目管理的目的就是綜合各種因素，制定合理的計劃，並通過計劃的實施，使其規範化，從而提高項目的效益，提高人員效率，降低項目的成本。
制定項目計劃首先對項目進行估算，粗算出項目的總體進度。然後進行精化：確定概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段等階段的具體要求、完成時間、投入人力物力，並確定幾個關鍵階段。這些關鍵階段的要求進度必須在指定日期之前完成。最後做出項目進度表，列出在每個階段的難點要點，要注意的問題。，並將需要分析階段的內容和項目計劃、進度表整理成文檔，分發到相關人員手上。
3、充分考慮影響項目計劃的因素，並做出相應的措施。
影響因素可以分爲主觀因素和客觀因素。客觀因素有客戶相關風險，外部環境的影響，停電，機器損壞，不能上網等原因。客觀因素在一定程度上可以轉變爲主觀因素。主觀因素有：人的因素、技術因素，資源因素。人的因素，本項目是否有足夠的人手，投入本項目的每一個成員有沒有要兼顧其他事情、項目，人員的流動、休假甚至是離職，這些對本項目的計劃有多大的影響，並對此作處相應的不久措施。技術因素，本項目是否涉及到技術問題，所佔比例是多少，以前是否有個類似的問題，新技術對本項目人員而言，新到什麼程度，解決需要的技術問題。要注意，盲目追求新技術，也會影響項目的進度，甚至拖垮整個項目，成爲技術先烈。還有一個技術問題是，本項目的人員，對要實施的軟件的行業背景的熟悉程度。根據這些因素決定是否對本項目的人員進行培訓！！資源因素，項目經費是否充足，軟件配置，硬件配置是否及時充足。總的來說，可以把影響項目的計劃劃分爲A—災難的 B－嚴重的 C－輕微的 D－可忽略的，對相應的等級作處相應的應變措施。
4 、根據計劃估算出成本。計劃一旦確定，就可以通過人力資源成本、日常辦公費用、軟硬件的損耗等算出本項目的成本。
四、 項目的立項：
只要經過管理方式的考慮，風險的評估，項目進度成本效益的衡量，再綜合其他方方面面的因素，做出決定，是否立項。
第三章 編碼的管理
在這裏首先要聲明一點的是，雖然在這裏並沒有着重強調系統設計，但系統設計是軟件工程管理的很重要的一部分。這裏，項目確定計劃就包含了系統設計。
在以前，甚至是在現在，也有相當大的一部分人是這樣認爲的：軟件程序主要由代碼組成，因此編碼階段是整個軟件項目的最重要的階段，應該給與大量的時間，並且集中主要的資源。
其實，與以前相比，由於軟件的規模和複雜度的增加，以及半自動化軟件代碼開發平臺的出現，現代軟件項目管理的中心發生了轉移--不是着重編碼階段，而是着重系統總體/詳細設計階段。一般說來，在現代軟件項目管理中各種資源的合理分配比例是：項目論證、風險評估階段3%，項目需求分析階段8%，系統總體/詳細設計階段45%，編碼階段10%，系統測試階段34%。
但是，如果軟件項目沒有實施好的話，頻繁地對軟件進行修改、甚至重做，編碼階段就會耗費大量地時間，在整個軟件工程所佔地時間比例也大大增加。很多軟件工程，不能按計劃完成就是因爲編碼階段的問題太多了。
編碼階段，要成功，就必須牢記一條：能做到少修改，不重做，力爭一次成功！！
在編碼階段，只要不是原則性的錯誤，儘量不要推倒前面所做的一切，重新做，畢竟以前做的時候也是考慮了方方面面的因素的，現在出現的問題只是在某方面考慮不周而已，一切都作廢，太浪費了。還有，要是數據庫字段已存在，除非萬不得已，千萬不要修改數據庫字段，能可添加字段。因爲已經存在的字段，很有可能已被軟件開發小組的其他成員在使用，不要因爲你的修改而令其他人也要跟你做相應的修改。最後，軟件界面的修改要慎重，界面的修改很容易使你忽略修改相應的內容，造成軟件大問題沒有，小問題一大堆。
要想做到不修改，不重做，很不容易，要考慮的因素很多。
首先從軟件的角度來說吧:
對於專用軟件，很多時候，一般用戶對於軟件要完成哪些功能已經有了一個比較清楚的輪廓，而且往往在開發合同中已經大致地規定了。但是，開發合同上規定的只是一個大概的框架，用戶心目中的產品究竟是什麼樣子，有時不要說開發人員不知道，連用戶本人也不知道。所以很多時候，都是到了開發工作的後期才發現開發人員的理解和用戶的要求有一些誤解，那麼必然造成時間上的浪費。
對於通用軟件，很多時候是到了開發工作的後期才發現某方面的功能不足，或要添加新功能等等。
在小型軟件公司中，由於開發人員少，這樣意味着不同人員的程序之間交互、接口相對少一些。開發週期短意味着往往是同樣的幾個人從頭到尾負責一個項目。這兩者都讓人容易犯些錯誤。往往是幾個人碰一下頭，討論一下最基本的數據結構、函數接口便分頭去做自己的工作了，沒有一份較正式的文檔。當有的人會對討論出的接口、結構理解有偏差(應該承認人是會犯錯誤的)，一個誤解可能造成以後的返工。
其次從管理的角度來說吧:
1、 有效的團隊組織。
提高團隊組織的工作績效，提高組員的團隊精神。這非常有利團隊有效，有序的工作。有效的團隊建設，這是管理的重要內容。
2、 小組成員的溝通、協調。
溝通，也許在各行各業都已提到了一個相當重要的位置。在一、二十年前，也許您會經常聽到某位大俠單獨完成了某種創舉，成了人們崇拜的對象。可今天，這種大俠，已經很難有生存空間了。取而代之的是，某軍團，又攻克了一座什麼樣的寶壘。這樣，溝通，可以說已經變得無比的重要。在軟件業，溝通可以說是快速學習和掌握新知識，達到技術上的更高層次的最佳途徑。 小組員的溝通，可以很好的加強團隊組織的凝聚力。可能更好的讓項目良性的進行。而培養這種氣氛，形成有效的溝通，這也是項目管理的基本內容。協調幾個人的工作比自己完成一段編碼更重要。如果小組成員在協調上出了漏洞，可能導致很大的問題，所以項目負責人必須隨時監控各開發人員的工作，包括內容是否與要求發生偏差，進度是否滯後等等。
最後從測試的角度來說吧。
傳統觀點認爲，測試是在編碼後的工作。其實，測試和編碼是兩個密不可分的階段，交叉進行的，測試在編碼後期進行的較多！！主要有兩方面:
1、 不經過單元測試而直接進入系統測試;
造成這一現象的原因是每個模塊相對比較簡單，但是爲了測試一個模塊需要建立一些測試環境。例如，爲了測試一個函數是否正確，應該用一些測試數據去調用該函數，需要編寫一些測試數據。但很多開發人員嫌麻煩，覺得反正其他模塊也很快出來了，直接用真正的數據來運行幾次就行了。殊不知，一旦直接進入系統測試，發現運行結果不正確後需要一步步查找。不但耗費了大量的查找時間，而且後面的模塊已完成了，修改前面的模塊又會影響後面的模塊，使的修改的難度增加，修改後導致新的錯誤產生的概率增大，另外，每個人的潛意識都不想否定自己，這種情況下很難真正去修改。還有由於這種測試不完全，真正運行系統，當調用某模塊時，可能大部分時候都是正常數據，極少出現邊界情況，可能某些邊界情況容易被忽視，很久之後才被發現。但是如果對每個模塊進行單元測試時都進行一下邊界測試，就會很容易消除一些隱患。真可謂欲速則不達也！
2、 如果在項目人員配置中設置了專門的測試人員，編碼人員會認爲軟件所有的內部測試工作全部應該由測試人員完成。
衆所周知：軟件程序測試可以分爲“白盒法”和“黑盒法”兩種方式。由於使用“白盒法”對測試人員各方面素質的種種要求，在進行程序測試時測試人員總是最優先使用“黑盒法”。他們的工作方式往往是先對程序進行“黑盒法”測試；如果測試沒有通過，不得已這才考慮對程序代碼進行“白盒法”測試。顯然，這種對“白盒法”有意無意的“逃避”，對軟件的可靠性和穩定性構成了威脅，造成在編碼後期，甚至是在試運行或運行階段需要進行大量的修改。如何解決這個問題？一方面需要提高對測試人員的要求，另一方面也需要程序員完成部分的“白盒法”測試（實際上，程序員往往也是進行“白盒法”測試的最佳人選）。
在代碼階段，除了要想做到不修改，不重做外，還需要對軟件的質量進度等進行控制，必須做到以下幾點：
1、 定期召開項目工作會議，向項目開發人員及時瞭解項目進展情況及存在的主要問題。一旦發現問題，管 理人員應迅速查明原因，儘快採取措施，爭取在儘可能小的範圍內解決問題。
2、 在軟件開發過程中，請專家和用戶按照里程碑評審階段性的成果，判定開發進度 是否與軟件項目定義的里程碑保持一致，開始時間是否與計劃時間一致。
第四章 編碼後的管理
編碼完成後，就是軟件實行試運行、運行階段，並生成相應的版本，並進行相應的備份。這個工作很重要，特別是版本生成備份，很容易出錯。筆者在曾經犯過這樣的錯：給了老版本給用戶；把爲甲做的版本給了用戶乙；備份時把以前有用的版本覆蓋了等等，不一而足。要避免犯這些錯誤，就必須要在每次生成不同的版本或者備份時，都要建立相應的文章。在文檔中，儘可能詳實地記錄本版本或備份的時間、目的，特別是和其他版本的不同之處。寫的越詳實，出錯的概率越
一項調查表明，大約70%的軟件開發項目超出了估算的時間，大型項目平均超出計劃交付時間20%至50%，90%以上的軟件項目開發費用超出預算，並且項目越大，超出項目計劃的程度越高。因此，軟件開發迫切需要進行項目管理。但是，軟件開發不同於其他產品的製造，軟件的整個過程都是設計過程（沒有製造過程）；另外，軟件開發不需要使用大量的物質資源，而主要是人力資源；並且，軟件開發的產品只是程序代碼和技術文件，並沒有其他的物質結果。基於上述特點，軟件項目管理與其他項目管理相比，有很大的獨特性。
第一章 小型軟件公司的特點
俗話說，聚沙成塔，沒有在金字塔地層下大量的小型的甚至是作坊型的小軟件公司，就不可能有大型的特大型的軟件公司。現在，無論是大學的教程，還是書本，講的軟件工程管理都是針對大中型軟件公司的，連網絡上也很少有針對小型軟件公司的項目管理文章。小型的軟件公司只有實行軟件項目管理，才能生存和發展，才能向大中型軟件公司邁進，才能使軟件產業更加繁榮！
一個企業的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把別人的經驗生搬硬套到自己身上，可能會適得其反。同樣，管理一個軟件項目也一樣，大項目和小項目的方式不完全一樣。但從另一個角度來看，項目的大與小並沒有本質的區別，很多方法是共通的。本文的目的是從作者的經驗來談談小型軟件公司的項目管理。
小型軟件公司相對與大中型軟件公司而言，有以下的特點：
1、項目負責人一般也是公司的老闆,對軟件工程有一定的瞭解，但不全面，相對而言，對市場的瞭解較爲透徹或對技術很精通；
2、項目功能相對較少 ，涉及面相對較狹窄；
3、開發人員較少，人員結構簡單 ；
4、開發週期較短 ，少則兩三個月，多則一到兩年。
總的而言，大中型軟件公司，軟件開發主要分爲六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。軟件公司將軟件配置管理、軟件質量管理、軟件風險管理及開發人員管理四方面內容導入軟件開發的整個階段。小型軟件公司的軟件開發同樣分爲六個階段，但比較模糊，側重點也不一樣；至於軟件配置管理、軟件質量管理、軟件風險管理及開發人員管理四方面內容則比較少。
大中型軟件公司開發軟件就如八股文一樣：總體規劃、項目立項、需求分析、系統分析、系統設計、編碼實現、項目測試、文檔製作（八股文：破題、承題、起講、入手、起股、中股、後股、束股），一切都按部就班。小型軟件公司開發軟件就是寫現代文：不拘泥於形式，但同樣符合規則！！
爲了符合小型軟件公司的管理特點，本文將小型軟件公司的項目管理分爲三個部分：
編碼前的管理、編碼的管理、編碼後的管理。
第二章 編碼前的管理
無論是項目，管理都必須在以人爲本的前提下進行。以人爲本，指的不只是軟件開發人員這一部分。這裏的人主要指的是一些與項目有利害關係的一些人，即項目干係人(stakeholders)，一般包括客戶或者用戶、項目團隊、項公司的管理層等一些主要的利害關係者。 一個項目能否成功，很大程度上取決於能不能分清楚這些項目利害關係者各自對項目的影響，不能利用好這些人力資源，溝通協調好他們之間的關係。
一、 管理方式的改變
在土木工程的項目管理中，成本主要分爲三部分：人員工資等費用、管理費用、材料費用。其中人員工資等費用、管理費用隨着經濟的發展所佔的比重越來越大。土木工程的項目管理爲了降低人員工資費用、管理費用，採取了這樣一條措施：儘量縮短工期，節假日以項目爲準，平時週末不放假，項目完成在不補放。
很明顯，在軟件開發不需要使用大量的物質資源，而主要是人力資源，人員工資費用佔軟件開發成本的大頭。要減低人員工資費用，我們不能削減員工工資，更不能削減必要的人員，提高軟件開發人員的效率纔是根本。進行軟件開發有這樣的一個特點：你放下的時間越長，你要重新理清前面的關係需要的時間越長，構思連續性也不好。很多小問題，也是因爲中間間隔的時間太長，開發人員忽略導致的。現在，一般的軟件公司，特別是大中型軟件公司，都實行這樣的制度：星期一到五，朝九晚五上班；星期六、星期天放假。這樣，這個軟件開發都給打斷了，連續性很差，效率很低。
經過對土木工程的項目管理的對比吸收，以及結合目前的軟件公司的管理現狀，本公司實行以下的管理制度：
對於開發週期在兩三個月以內的小項目：週末也要上班，只在月末才放兩天假。等整個項目完成後，再把以前沒有放的假期補放。例如，一個項目從三月一號開始開發，五月三十一號完成。在這期間，三月底放假兩天，四月底放假兩天。因爲從三月份到五月份的公衆假期有：27天，但前面有放了四天假，理論上可以給軟件開發人員放23天的有薪假期。但實際操作時給放了半個月的假。
對於開發週期比較長的項目，跟小項目類似，每月放兩天的假期，但長假不是在項目完成後放，而是每隔半年放一次，時間爲一個月。
這樣的管理可以在一定程度上提高開發人員的效率，又可以避免長時間因爲沒放假，使開發人員感到枯燥，情緒低落，動力不夠，壓力過大的情況。當然在實際操作時，開發人員因爲自身的原因需要偶爾放的假，都會盡量滿足。
本來，爲了更好的提高效率，我公司還把白天的工作制度作了一些調整。一般進行軟件開發，特別時編寫代碼的人員都有這樣的體會：晚上的效率特別高。這是有原因的，晚上所受外界的干擾最少，人的精神特別容易集中，思路特別清晰。爲此，我公司實行了以下制度：開發人員統一居住，下午兩點到六點工作，晚上八點到十二點工作。實行這樣的制度，開發人員的效率得到很大的提高。但是，由於種種的原因，此制度不能實施下去。
二、 項目風險的估計
前面說到，小型軟件公司的項目經理往往是老闆本人，有很強的風險意識。但在這裏還是要着重說說軟件工程的風險管理，因爲項目經理認識的風險大多侷限在商業風險（銷售問題等）中，對風險的理解很片面。
軟件風險是指軟件開發過程中及軟件產品本身可能造成的傷害或損失。風險關注未來的事情，這意味着，風險涉及選擇及選擇本身包含的不確定性，在軟件開發過程及軟件產品都要面臨各種決策的選擇。風險是介於確定性和不確定性之間的狀態，是處於無知和完整知識之間的狀態。另一方面，風險將涉及思想、觀念、行爲、地點等因素的改變。根據風險內容，我們可以將風險分爲項目風險（成本提高，時間延長等）、技術風險（技術不成熟等）、商業風險（銷售問題等）、戰略風險（公司的經營戰略發生了變化）、管理風險（公司管理人員是否成熟等）、預算風險（預算是否準確等）等。
另外，我們還可以將風險分爲已知風險（如員工離職等）、可預報風險（從以往經驗得出可能有風險的）和不可預知風險。
例如，在一些訂單開發的軟件中，存在着很大的商業風險。林子大了，什麼鳥都有。客戶多了，需要就不同，客戶相關的風險出現的概率就不一樣。一些人只知道他們需要什麼；而另一些人知道他們不需要什麼。一些客戶希望進行詳細的討論，而另客戶則滿足於模糊的承諾。客戶有不同的個性。一些人喜歡享受客戶的身份，而另一些人則根本不喜歡作爲客戶。一些人會高興地接受幾乎任何交付的產品，並能充分利用一個不好的產品；而另一些人則會對質量差的產品猛烈抨擊。一些人會對質量好的產品表示讚賞；而另一些人則不管怎樣都抱怨不休。客戶和供應商之間也有各種不同的通信方式。一些人非常熟悉產品及生產廠商；而另一些人則可能素未謀面，僅僅通過信件來往和電話與生產廠商溝通。一個“不好的”客戶可能會對一個軟件項目組能否在預算內完成項目產生很大的影響。對於項目管理者而言，不好的客戶是對項目計劃的巨大威脅和實際的風險。
對於大多數軟件項目而言，風險因素——性能、成本、支持、進度，也代表了風險參考水平值。即，對於性能下降、成本超支、支持困難、或進度延遲，都有一個水平值的要求，超過它就會導致項目被迫停止。如果風險的組合所產生的問題引起一個或多個參考水平值被超過，則工作將會停止。在軟件風險分析中，風險參考水平值存在一個點，稱爲參考點或臨界點，在這個點上，決定繼續進行該項目或終止它（問題太多）都是可以接受的。下圖以圖形方式表示了這種情況。如果風險的組合產生問題導致成本超支及進度延遲，則會有一個水平值,即圖中的曲線，當超過它時會引起項目終止。
三、 項目進度成本效益的估計
其實，這也是項目風險有着緊密聯繫，是項目風險發生的一大因素之一。爲此，需要做到以下幾步：
1、在制定項目計劃時，必須進行項目的需求分析，明確項目的需求。
在的需求分析階段，往往存在着這樣的誤區：在項目的需求分析階段，開發方與客戶方在各種的問題的基本輪廓上達成一致即可，具體細節可以在以後填充。因爲無論開始時有多麼細緻，以後對需求的修改幾乎是必然的。當然這樣做是有原因的：在具體實際中由於種種原因客戶方很難在需求分析階段全面而準確地描述所有問題。隨着開發進度的推進，往往會有一些需求的改變。但是這樣做，由於需求階段對問題的描述不夠細緻，導致後來預算超出或者時間進度達不到要求。
正確的做法是：在項目需求分析階段，雙方必須全面地儘可能細緻地討論項目的應用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準。並且，在需求分析結束以後，雙方還要建立可以直接聯繫的渠道，以儘早地對需求變動問題進行溝通。並在項目需求分析完成後，和客戶明確項目的哪些部分可以在日後的進度中能修改，修改的限度，哪些不能修改。例如，應用背景、功能要求方面應該是在需求分析階段確定，日後不能做修改。而性能、界面及接口等可以在日後作有限度的修改。
2、制定項目計劃：
有人這樣說計劃的，“計劃，計劃，紙上畫畫，牆上掛掛，計劃不如變化！”。計劃很容易成爲空話，特別是在軟件工程中，影響計劃的因素太多，計劃就形同虛設了！但是，軟件進行項目管理的目的就是綜合各種因素，制定合理的計劃，並通過計劃的實施，使其規範化，從而提高項目的效益，提高人員效率，降低項目的成本。
制定項目計劃首先對項目進行估算，粗算出項目的總體進度。然後進行精化：確定概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段等階段的具體要求、完成時間、投入人力物力，並確定幾個關鍵階段。這些關鍵階段的要求進度必須在指定日期之前完成。最後做出項目進度表，列出在每個階段的難點要點，要注意的問題。，並將需要分析階段的內容和項目計劃、進度表整理成文檔，分發到相關人員手上。
3、充分考慮影響項目計劃的因素，並做出相應的措施。
影響因素可以分爲主觀因素和客觀因素。客觀因素有客戶相關風險，外部環境的影響，停電，機器損壞，不能上網等原因。客觀因素在一定程度上可以轉變爲主觀因素。主觀因素有：人的因素、技術因素，資源因素。人的因素，本項目是否有足夠的人手，投入本項目的每一個成員有沒有要兼顧其他事情、項目，人員的流動、休假甚至是離職，這些對本項目的計劃有多大的影響，並對此作處相應的不久措施。技術因素，本項目是否涉及到技術問題，所佔比例是多少，以前是否有個類似的問題，新技術對本項目人員而言，新到什麼程度，解決需要的技術問題。要注意，盲目追求新技術，也會影響項目的進度，甚至拖垮整個項目，成爲技術先烈。還有一個技術問題是，本項目的人員，對要實施的軟件的行業背景的熟悉程度。根據這些因素決定是否對本項目的人員進行培訓！！資源因素，項目經費是否充足，軟件配置，硬件配置是否及時充足。總的來說，可以把影響項目的計劃劃分爲A—災難的 B－嚴重的 C－輕微的 D－可忽略的，對相應的等級作處相應的應變措施。
4 、根據計劃估算出成本。計劃一旦確定，就可以通過人力資源成本、日常辦公費用、軟硬件的損耗等算出本項目的成本。
四、 項目的立項：
只要經過管理方式的考慮，風險的評估，項目進度成本效益的衡量，再綜合其他方方面面的因素，做出決定，是否立項。
第三章 編碼的管理
在這裏首先要聲明一點的是，雖然在這裏並沒有着重強調系統設計，但系統設計是軟件工程管理的很重要的一部分。這裏，項目確定計劃就包含了系統設計。
在以前，甚至是在現在，也有相當大的一部分人是這樣認爲的：軟件程序主要由代碼組成，因此編碼階段是整個軟件項目的最重要的階段，應該給與大量的時間，並且集中主要的資源。
其實，與以前相比，由於軟件的規模和複雜度的增加，以及半自動化軟件代碼開發平臺的出現，現代軟件項目管理的中心發生了轉移--不是着重編碼階段，而是着重系統總體/詳細設計階段。一般說來，在現代軟件項目管理中各種資源的合理分配比例是：項目論證、風險評估階段3%，項目需求分析階段8%，系統總體/詳細設計階段45%，編碼階段10%，系統測試階段34%。
但是，如果軟件項目沒有實施好的話，頻繁地對軟件進行修改、甚至重做，編碼階段就會耗費大量地時間，在整個軟件工程所佔地時間比例也大大增加。很多軟件工程，不能按計劃完成就是因爲編碼階段的問題太多了。
編碼階段，要成功，就必須牢記一條：能做到少修改，不重做，力爭一次成功！！
在編碼階段，只要不是原則性的錯誤，儘量不要推倒前面所做的一切，重新做，畢竟以前做的時候也是考慮了方方面面的因素的，現在出現的問題只是在某方面考慮不周而已，一切都作廢，太浪費了。還有，要是數據庫字段已存在，除非萬不得已，千萬不要修改數據庫字段，能可添加字段。因爲已經存在的字段，很有可能已被軟件開發小組的其他成員在使用，不要因爲你的修改而令其他人也要跟你做相應的修改。最後，軟件界面的修改要慎重，界面的修改很容易使你忽略修改相應的內容，造成軟件大問題沒有，小問題一大堆。
要想做到不修改，不重做，很不容易，要考慮的因素很多。
首先從軟件的角度來說吧:
對於專用軟件，很多時候，一般用戶對於軟件要完成哪些功能已經有了一個比較清楚的輪廓，而且往往在開發合同中已經大致地規定了。但是，開發合同上規定的只是一個大概的框架，用戶心目中的產品究竟是什麼樣子，有時不要說開發人員不知道，連用戶本人也不知道。所以很多時候，都是到了開發工作的後期才發現開發人員的理解和用戶的要求有一些誤解，那麼必然造成時間上的浪費。
對於通用軟件，很多時候是到了開發工作的後期才發現某方面的功能不足，或要添加新功能等等。
在小型軟件公司中，由於開發人員少，這樣意味着不同人員的程序之間交互、接口相對少一些。開發週期短意味着往往是同樣的幾個人從頭到尾負責一個項目。這兩者都讓人容易犯些錯誤。往往是幾個人碰一下頭，討論一下最基本的數據結構、函數接口便分頭去做自己的工作了，沒有一份較正式的文檔。當有的人會對討論出的接口、結構理解有偏差(應該承認人是會犯錯誤的)，一個誤解可能造成以後的返工。
其次從管理的角度來說吧:
1、 有效的團隊組織。
提高團隊組織的工作績效，提高組員的團隊精神。這非常有利團隊有效，有序的工作。有效的團隊建設，這是管理的重要內容。
2、 小組成員的溝通、協調。
溝通，也許在各行各業都已提到了一個相當重要的位置。在一、二十年前，也許您會經常聽到某位大俠單獨完成了某種創舉，成了人們崇拜的對象。可今天，這種大俠，已經很難有生存空間了。取而代之的是，某軍團，又攻克了一座什麼樣的寶壘。這樣，溝通，可以說已經變得無比的重要。在軟件業，溝通可以說是快速學習和掌握新知識，達到技術上的更高層次的最佳途徑。 小組員的溝通，可以很好的加強團隊組織的凝聚力。可能更好的讓項目良性的進行。而培養這種氣氛，形成有效的溝通，這也是項目管理的基本內容。協調幾個人的工作比自己完成一段編碼更重要。如果小組成員在協調上出了漏洞，可能導致很大的問題，所以項目負責人必須隨時監控各開發人員的工作，包括內容是否與要求發生偏差，進度是否滯後等等。
最後從測試的角度來說吧。
傳統觀點認爲，測試是在編碼後的工作。其實，測試和編碼是兩個密不可分的階段，交叉進行的，測試在編碼後期進行的較多！！主要有兩方面:
1、 不經過單元測試而直接進入系統測試;
造成這一現象的原因是每個模塊相對比較簡單，但是爲了測試一個模塊需要建立一些測試環境。例如，爲了測試一個函數是否正確，應該用一些測試數據去調用該函數，需要編寫一些測試數據。但很多開發人員嫌麻煩，覺得反正其他模塊也很快出來了，直接用真正的數據來運行幾次就行了。殊不知，一旦直接進入系統測試，發現運行結果不正確後需要一步步查找。不但耗費了大量的查找時間，而且後面的模塊已完成了，修改前面的模塊又會影響後面的模塊，使的修改的難度增加，修改後導致新的錯誤產生的概率增大，另外，每個人的潛意識都不想否定自己，這種情況下很難真正去修改。還有由於這種測試不完全，真正運行系統，當調用某模塊時，可能大部分時候都是正常數據，極少出現邊界情況，可能某些邊界情況容易被忽視，很久之後才被發現。但是如果對每個模塊進行單元測試時都進行一下邊界測試，就會很容易消除一些隱患。真可謂欲速則不達也！
2、 如果在項目人員配置中設置了專門的測試人員，編碼人員會認爲軟件所有的內部測試工作全部應該由測試人員完成。
衆所周知：軟件程序測試可以分爲“白盒法”和“黑盒法”兩種方式。由於使用“白盒法”對測試人員各方面素質的種種要求，在進行程序測試時測試人員總是最優先使用“黑盒法”。他們的工作方式往往是先對程序進行“黑盒法”測試；如果測試沒有通過，不得已這才考慮對程序代碼進行“白盒法”測試。顯然，這種對“白盒法”有意無意的“逃避”，對軟件的可靠性和穩定性構成了威脅，造成在編碼後期，甚至是在試運行或運行階段需要進行大量的修改。如何解決這個問題？一方面需要提高對測試人員的要求，另一方面也需要程序員完成部分的“白盒法”測試（實際上，程序員往往也是進行“白盒法”測試的最佳人選）。
在代碼階段，除了要想做到不修改，不重做外，還需要對軟件的質量進度等進行控制，必須做到以下幾點：
1、 定期召開項目工作會議，向項目開發人員及時瞭解項目進展情況及存在的主要問題。一旦發現問題，管 理人員應迅速查明原因，儘快採取措施，爭取在儘可能小的範圍內解決問題。
2、 在軟件開發過程中，請專家和用戶按照里程碑評審階段性的成果，判定開發進度 是否與軟件項目定義的里程碑保持一致，開始時間是否與計劃時間一致。
第四章 編碼後的管理
編碼完成後，就是軟件實行試運行、運行階段，並生成相應的版本，並進行相應的備份。這個工作很重要，特別是版本生成備份，很容易出錯。筆者在曾經犯過這樣的錯：給了老版本給用戶；把爲甲做的版本給了用戶乙；備份時把以前有用的版本覆蓋了等等，不一而足。要避免犯這些錯誤，就必須要在每次生成不同的版本或者備份時，都要建立相應的文章。在文檔中，儘可能詳實地記錄本版本或備份的時間、目的，特別是和其他版本的不同之處。寫的越詳實，出錯的概率越