(2) 數據建模。你可以簡單的理解成數據庫設計，在這個過程中建議使用Power Designer或者Microsoft Visio(最好是.NET自帶的那個版本，而非2002或者2003的Professional)，使用數據庫建模工具而非直接進行數據庫設計的理由有很多，我不想去夸夸其談的說可以提高……那樣的空話。最直接一點的好處就是可以圖形化的設計你的數據模型，同時這些建模工具都提供了很好的文檔生成。數據建模一個最基本的原則就是能夠滿足你在需求文檔定義的所有業務數據描述，你整個業務流程中的所有數據都能夠找到直接或者間接的存儲，同時數據之間的關系必須滿足業務的種種約束（比如生日不可以比當前時間大，員工數不可以是負值等等一些要求），這些業務約束可以通過觸發器和約束來表達，同時根據你業務的需要，可以適當的編寫一些存儲過程用來實現你的業務邏輯。最重要的一點，請記住記得為所有設計元素寫注釋，因為這些注釋正式用來描述你設計的最重要依據，也是你日后溝通的依據。
(3) 業務建模�？梢岳斫鉃樵O計，按照推薦的做法，一個系統應該是分層設計的。比如微軟的Petshop就分離了Model、DAL、BLL和UI這樣的幾個層次。如果是基于.NET開發的，我建議使用Rational XDE Plus for VS.NET，從數據庫到商務對象的映射目前有兩種推薦的做法。一個是使用或者自行開發ORM框架用來完成數據到對象之間的映射，Java中可以使用Hibernate、JDO、EJB（Entity Bean似乎不是推薦的做法等等，.NET也有一些ORM工具如NHibernate,ORMapper、OPF.NET等一些開源項目，但是總體不算特別成熟。另外一種做法就是一個一個的編寫你的Business Object了，但是你可以通過一些CodeGeneration工具讓簡化你的重復工作，如果熟悉ASP.NET，建議使用CodeSmith。生成基本的代碼骨架之后，可以將這些代碼通過反向工程生成你的模型圖，然后再通過對象建模反復的校驗你的設計，當然設計過程中良好的注釋是必要的，通過對象模型圖，你可以和團隊成員很好的交流，在出現問題的時候也能夠及時修正你的設計。TDD（測試驅動開發）也得到越來越多的人接受，如果問我什么時候開始寫單元測試，那么我就建議從這個時候開始寫，原則也很簡單，就是你所有的測試用例合起來能夠完整覆蓋你的業務要求，一旦發現測試用例無法繼續編寫下去，那么存在問題的可能是你的業務建模部分（大多情況下，不應該回溯到數據建模階段），這個時候去修正你的設計。反復之后就能夠得到一個比較好初步設計框架。在此基礎上可以進行部分的設計調整，使其更具擴展性和靈活性，當然在一些特殊要求（如性能）的情況下可以在設計完畢的時候降解你的設計，雖然會破壞一些設計原則，但是在必要的時候還是可以接受的。
(4) 業務實現。好了，這個時候是開始編碼的階段了，這個時候開發人員需要一些文檔，如需求文檔（可能是Word形式）、數據庫設計文檔（Power Designer或者Visio的，也可以通過文檔工具直接生成相關文檔），設計文檔，單元測試用例，通過上述的迭代，這些文檔都是非常完整的。此時Team Leader對于開發人員的要求可以算比較簡單了，按照設計文檔提供的接口要求實現，工作完成得第一原則是通過單元測試，因為代碼的骨架在設計階段已經完成，同時對于各個接口提供了很好的文檔說明，就能夠在很大程度上去約束開發人員的散漫和隨意性，從而保證代碼的規范和可閱讀性。而規范的設計也保證了工作量的細化，從而能夠用相對量化的指標去衡量一個開發人員的具體工作量。開發過程中有三方面工具推薦使用：NAnt實現編譯、測試、部署的自動化；版本控制工具如（Visual SourceSafe）實現代碼的版本管理；利用BugTrack工具，從而有效地跟蹤和解決問題。
(5) 測試和部署。大多軟件出現問題的原因是沒有測試和模擬部署，要求開發人員自行完成測試之后就開始投入應用，這樣帶來的問題是顯而易見的，因為大多人對于自己的問題是一種逃避心理，而百盒(White Box)的測試如果沒有通過一些工具有效地保障，讓開發人員通過Code Review的方式是不切合實際的，對于目標環境的模擬部署也是非常必要的，為了減少不必要的麻煩，建議大家可以使用VMWare或者微軟的Virtual Server 2005來進行目標應用環境的模擬。
以上提到的只是開發過程中的典型環節，通過一些工具來規劃化和加速軟件開發過程是必要的，我上述提到的一些軟件是商業產品，在實際使用過程中建議購買商業軟件或者尋找替代的解決方案。但是這些過程對于小型開發團隊是行之有效的，我沒有大型團隊的應用開發，也許是另外一種場景，也不敢班門弄斧了。
2） 完善開發團隊的梯度建設
這個也是小公司存在的非常嚴重問題，整個開發團隊的成員結構是不合理，甚至是畸形的。不知道大家是否同意我這樣的說法，大多公司都是一個所謂的技術牛人帶領一幫資歷比較淺的開發人員進行開發的，一些最核心的工作都是由1-2個人來完成的，其他人實際上來說只是輔助性的工作。不可否認，高水平的開發人員對于一個團隊的效果是明顯的，但是同時帶來一個問題，如果對于開發人員脫控，就會形成“老板怕員工”的現象，這樣的管理弊病導致的結果就是內部斗爭嚴重。設計、編碼、測試、管理等等各個環節人員的平衡是一個相對良好的組織架構，同時盡量不要讓團隊的梯度出現脫節，比如高水平的開發人員和其他員工出現無法溝通的障礙（兩者完全不是在一個水平線上），低、中、高金字塔式的人才結構對于團隊的穩定是至關重要的。這段最直接的是反映在人員招聘上，不是找便宜的或者找牛的，而是選擇合適公司自己定位的。
3） 注重技術資源的基礎積累
生存對于小公司是第一目標，但是很多時候就以為如此，忽略了團隊的基礎積累，在一些公共模塊的應用上，在不同項目之間很多開發人員采用的是Copy/Paste來做的。在日常的開發過程中，應該逐漸形成自己的代碼和組件甚至業務的積累。這些工作可以成為高級開發人員日常工作的一部分。
4） 并行開發
如果你不是一家貿易公司，那么請記得“人無我有，人有我優，人優我絕”，至于“人絕我偷”就免了阿，要讓自己的公司保持長久的生命力，應該永遠保持比競爭對手領先半步，那么這半步來自何處呢？除了保證為生存奮斗的商務開發之外，前瞻性的開發也是必要的，最好的做法就是根據公司實際情況，抽出部分人力并行下一代產品的開發，在下一代的開發過程中產生的一些比較好的產品可以直接利用與現行系統，因為時間周期相對允許的緣故，在下一個版本設計的時候來自時間的壓力會明顯比較少，這樣子帶來的好處是能夠設計更好的系統。因此研發和開發并行對于一個小公司也是必要的，至于多少權重，那就根據實際情況去衡量了。
5） 加強內部外部的溝通
在社區和其它途徑總是可以看到一些開發人員在抱怨公司沒有給他們提供更好的交流技術，他們不知道市場，不知道需求，總是和客戶存在非常大的溝通障礙，那么作為一個管理人員，盡量創造這種溝通的機會也是非常必要的。
6） 堅持員工培訓
小公司員工跳槽的概率是遠遠大于規范的公司的，一個方面是待遇和福利跟不上，一個方面是無休止的加班，另外一個方面就是感覺公司沒有什么前景，學不到多少東西。第一個問題只有隨著公司業務的不斷發展才能夠根本性的得到解決，第二個問題通過規劃化的軟件開發過程能夠減少不必要的重復和錯誤，也能夠適度的得到解決（當然了，碰見真的資本家，趕緊走人吧）。最后一個問題在小公司是普遍存在的，那么給員工創造一個積極向上的發展空間，擁有更多的學習機會，對于管理人員是一個很大的挑戰，這些東西可以歸結為企業文化建設。對于小公司，因為資源方面的限制，很多管理人員會忽略這個環節。
目前所在的公司就堅持每周一次的技術培訓和2周一次的職業規劃培訓。我的做法比較簡單，相對于其他開發人員，我比較熟悉軟件開發過程多一點，所以在開始階段告訴他們在一個小型團隊中怎樣有效的進行協作開發，如何定義軟件開發的各個過程，各個環節中有哪些工具可以提高開發效率，而這些工具具體是怎樣使用的。等到員工熟悉了大致的軟件開發過程，可以每周探討一個技術點如.NET Remoting、Enterprise Services、Web Services、Http管道化等等，通過交流的方式讓團隊成員了解更多開發技術的具體細節，在適當的時候個人邀請一些技術上的朋友幫忙來公司做定期的交流。在職業規劃培訓方面，則是由公司的兩位老大提供一些來自McKensin、Accenture這樣公司的培訓經驗。
7） 明晰的崗位責任制
坦白說，這個方面我目前還是沒有非常清晰的思路，希望得到各位的指點
崗位決定視角，從編碼人員、技術負責人、系統架構師、技術編輯到部門管理人員，這5個不同的崗位也決定了看待問題的不同方式，作為一個小公司的部門負責人，要做的事情很多很多，但是如何將最重要的事情做好呢，也希望和各位探討。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
