兩個人以上的項目，就需要有管理。爲什麼這麼說呢？因爲有兩個人，就需要交流；有交流，就必然會有合作；有合作，就需要有分工；有分工，就需要有協調；有所有這些，就需要有管理。但此刻的管理，我們說，殺雞用牛刀，高射炮打蚊子，都是不智的。但還是需要管理。
然而一個人的項目是否不需要管理？當然不是，因爲有文檔，有代碼，有靈感，有經驗，等等都需要管理。只是此刻的管理是自己完成的，可以更簡單一點。我們已經有過一遍又一遍的調試以前已經fix過的bug體驗，也有過一遍又一遍的查找以前自己實現過的技術的經歷。軟件工程的理論，在開發過程中的作用，就是指導如何做好管理，以取得軟件的可用性、正確性和合理性。如果我們清楚知道這是它的目標，就可以拋開一些對自己不適用的枝節。
那麼它是如何做到這一點的？
我認爲軟件工程中最重要的，最有實際意義的，是它界定了工作職能，從而也確定了責任歸屬。什麼意思？說白了，就是什麼人做什麼事，出了問題誰負責。那麼它是怎麼界定工作職能的？是通過對軟件開發流程的劃分來實現的。軟件工程把軟件的開發劃分成很多個相對獨立的階段，每一個階段都有相關的人員來實現，也就有相關的人員來負責。分工不清，責權不明，是導致管理混亂的最主要的因素。所以即使是兩個人的項目，也是需要軟件工程來指導的，因爲通過它，可以更好的知道如何可以合理分工，劃分工作職權以取得最終的成果。當然，走教條主義的道路是非常愚蠢的。
那麼軟件工程到底是什麼？
軟件工程是針對“軟件危機”提出來的。它是一種工程，把經驗和理論應用到實踐中來，解決軟件開發中出現的各種問題。
這是什麼意思？就是說，軟件工程是用來解決實際問題的。如果軟件開發中沒有遇到管理問題，軟件工程就不需要管理的內容；如果軟件開發中沒有遭遇文檔混亂，軟件工程就不需要文檔的部分。但是如果很幸運的遭遇到了這些，那麼這一切都是不可或缺的。軟件工程不是一個固定的呆板的框框，而是一個有彈性的概念。所以，如果不是要去申請iso或是cmm認證，完全不必要一板一眼的按照iso或是cmm的規範去做。所謂“有企業特色的軟件工程”，完全可以從吸收現有的模式和規範中完善起來。
但這並不是說所有在開發過程中出現的都是軟件工程，只有那些能引導開發走向成功的纔是真正有意義的軟件工程。其他的，最多隻是失敗的嘗試。
那麼應該什麼時候開始實施軟件工程？
軟件工程一定要在一個項目開始之前開始嗎？一定要貫穿整個項目嗎？爲什麼？
不是的，軟件工程可以在項目進行中的任何時候開始，也可以在任何不再需要的時候結束。因爲軟件工程把開發流程劃分成不同的階段，所謂“生命週期”，在不同的生命週期，軟件工程提供了不同的模式可以參考。
那麼軟件公司如何實施軟件工程？
首先要知道軟件工程，理解軟件工程；然後要了解現有的軟件工程的模式和規範。ISO、CMM或是Agility，都定義了一套規範。這些規範是經驗與技術，以及理論的積累。它們存在很多合理的、可行的模式，可以引用和參考；但銀彈是沒有的。當然，我們可以重頭再來，造他們造過的輪子，摔他們摔過的跤；但很明顯，這是不必要的。
實施的最好方法，也是最可行的方法，成本最小的方法，是根據開發的客觀的因素，修改那些規範，以符合我們的開發過程；但是最主要的，是修改我們的主觀認識，以符合那些規範；而最重要的，是在實施中發現那些規範不合理的地方，並改正它。
那是否會變得無法適從，從而陷入混亂？
是的，有這可能，所以任何的修正都應該是謹慎的。所有的修改提議都應該是自上而下的，而決定都是自下而上的。
軟件工程對項目的規模有要求嗎？
我們擔心過小的項目應用軟件工程是否會陷入官僚主義，從而加重項目的負擔？
我們再來看什麼是軟件工程？軟件工程並沒有定義什麼纔是軟件工程！也沒有定義軟件工程自身的規模。軟件工程的意義在於對開發階段的劃分，以及分工和責任歸屬。這與項目的規模沒有什麼衝突。相反，越是小的項目越是需要軟件工程的管理。軟件開發的一個共識，是把一個大的項目劃分成一些小的模塊，再把小的模塊劃分成更小的模塊。如果這些小模塊是獨立的（或者原來就是一個獨立的項目），那麼軟件工程至少可以提高它的重用性。
對於一個軟件工程觀念不深的團隊，不要期望他們在接手大的項目的時候可以使用軟件工程，如果他們在小項目中不願使用的話。前者的複雜度不是他們可以想象和承受的。
應用軟件工程會增加工作量嗎？
是的，但只是針對那些在不使用軟件工程管理的項目中很輕鬆的人而言的。軟件工程會使他們要麼失業，要麼負起責任來。相對工程師而言，他們會從混亂的毫無頭緒的狀態中解放出來，他們的工作會變得有效率。損失的是以前尸位素餐的人將暴露出來——這可能是它的唯一的缺陷，同時也是它受到很多企業/個人抵制的可能原因之一。
我們應該怎麼做？
學習！如果我們不想重頭髮明一個輪子的話。
嘗試！如果我們希望改變的話。