今天正好看到關於團隊合作的工作流程問題，起因於一帖對美工與程序員的疑問，我突然有感於一種強烈的思想，所以覺得現在項目團隊一定要更科學合理地來分角色，做到各司其職，方能避免陷入作坊式開發，從而發揮更大效率，並且，我始終以現有的團隊來貫徹這樣的思路。
我就大致描述一下我的項目團隊（算上美工5人）在這方面的情況：
首先，介紹角色：
１．項目組長：相當於項目經理吧，主要職責我就不多說了。
2.界面工程師：是用戶界面交互方面的專家，決定與用戶交互的方式，當然很大程度也影響着界面
3.美工：設計和美化界面
4.高級程序員：設計總體程序結構，制定技術上的規範，併爲小組解決各種難題，幫助項目組長分解每日程序員任務
5.程序員：編寫代碼，實現功能
6.需求人員：與本話題無關，我就不介紹了
7.公關人員：雖然與本話題無關，但我就想在這裏突出其對項目組的重要性，所以順便提一下。至於要攻什麼關大家一定都能猜得出來。
8.其他，如測試人員、文檔管理人員等(想象能有plmm角色)：都很重要，但也與本話題無關。
工作流程：
1.公關人員和需求人員獲得用戶需求，並制定需求文檔。
需求的正確與否是項目成功的首要關鍵環節，這個我就不多說了，和本主題相關的就是他們需要獲取到用戶的各種習慣層次上，主要分爲兩種思路來整理，一種是之前用過軟件系統的考慮如何延續他們的習慣，另一種是之前沒有用過軟件系統的考慮如何適應他們原有手工的工作流程，並作出合理化的改進。
2.項目組長和需求人員以及高級程序員共同根據需求制定大體的設計方案，包括總體模塊和各個可行性功能。
在這裏，項目組長會根據需求人員和高級程序員的意見來合理安排出一個基本雛形，然後去寫Project2003（我覺得這個蠻不錯）...後面還有反覆交復雛形給用戶確認等等我就不介紹了。有一點值得注意的是，項目組長除了需要具備一定的人員管理方法以外，最好還是要懂得技術，這樣能夠制定出更合理、更準確的項目進度，也能帶動團隊工作的士氣。個人認爲項目經理的技術水準應該在高級程序員之上，不然在這個環節中就只能聽取高級程序員的意見了，相信大家如果遇到個不懂技術的項目經理，而他又指責你技術水準有問題時，一定都會自然而然地產生想K他一把的衝動，這樣的團隊還能保持好的士氣麼？技術人畢竟還是需要以能耐服人來得好。
3.開工，項目組長在高級程序員配合下根據預先計劃開始推動項目進展。
這裏是關於本主題的主要環節，首先由項目組長和高級程序員在上一環節設計的雛形的基礎上按照計劃規劃架設各模塊的基本結構。然後以模塊爲單位，我這邊團隊喜歡採用我們稱之爲狼羣戰術的方法來逐步蠶食各個模塊，每個模塊的流程分爲如下幾個步驟
a.高級程序員詳細化拆分該模塊的各個界面和功能，包括前臺和後臺等。需要需求人員給出參考
b.在高級程序員的分配下，界面工程師對當前子模塊制定界面用戶交互的基本方案，也需要需求人員給參考，美工人員則給出美學方面的建議，並達成一致。在這裏，界面工程師會將決定界面的大致框架，並將界面相應的功能描述成文以用於給程序員，一個子模塊界面的雛形在這裏已經誕生，生成的程序文件有aspx和(vb或cs)，建議界面結構最好用表格來設計。
c.美工去做界面，對界面工程師所搭建的界面框架aspx或ascx文件進行處理，如背景、需要配合的圖片圖標及flash等。在這裏環節上，美工已和界面工程師已經在明確需求人員的指導下達成對界面統一風格的一致。因爲界面工程師在之前已經在頁面中制定好標記，所以美工可以忽略有腳本標記的地方。而且，總的來說這一環節上美工主要是預先爲界面定義好各種素材。
d.與美工併發執行的是高級程序員與程序員對功能的實現。程序員們在界面工程師的指導下將功能實現，其間包括滿足交互功能所需的控件、業務規則層、數據訪問層，等等的實現，所涉及編寫的文件則爲界面文件(ascx等)和程序文件(vb或cs)。這裏需要說明的是在實現功能時程序員只要把滿足功能的控件拖到大致位置就可以，然後就關注功能的實現。而此時美工也在設計該界面，但因爲只是設計素材，所以根本不與程序員衝突，在後面的環節中始終以程序員完成的程序文檔爲準。
e.程序員完成功能後，轉交測試人員進行功能測試。。。
f.基本測試通過後，又回到界面工程師手裏，在不改動程序文件(vb或cs)文件的前提下，界面工程師只對界面文件中的各種控件、結構等進行調整。達到滿意的效果爲止。
g.界面基本已經誕生，只是全裸不太文雅，所以這時回到美工手上，給其穿上美工設計的靚裝，加上各種圖片背景等就ok了
h.補充一下項目組長，貫穿整個過程，負責團隊人員之間的協調，監督項目進度，合理分配任務，看誰不幹活就。。。
4.所有模塊都完工後，就是整體的銜接和測試，然後反覆交複用戶徵求意見，這裏參與的是團隊所有的人馬，一直忙到最後期限爲止，然後再延期，直到用戶滿意。
以上是我所在團隊的大致工作流程，大家看了後一定會提出如此分角色人手資源一定不夠的問題。確實，通常來說小公司的開發團隊就幾個人，所以通常很容易做着做着就陷入作坊式做法，大家角色不明確，各自包辦各自的模塊，導致之後程序維護非常困難。我上面所述的工作流程中每個環節都明確指出了每個角色的出現場合，所以我是很強調以角色來分工。但如我前面所提到的，我這邊的團隊也不過5個人，所以，雖然角色衆多，但我們還是可以根據各自的團隊實際情況來分擔這些角色，只要記住一個原則，找合適的人去做合適的角色，即擔當某一角色的人是對該角色領域感興趣的人。比如在我的團隊中，美工是對藝術美感感興趣，我團隊的美工是plmm，可惜只是兼職，沒太多機會，建議大家有條件就找plmm來擔任。需求人員是對整體業務有興趣的人，我這裏的需求人員是辦公室頭，所以向上和外界的公關都是由他搞定。還有兩個是程序員角色，一個偏向於底層數據庫的實現，另一個偏向於邏輯層的實現，而最後我則是很痛苦地擔當了項目組長、界面工程師、高級程序員的角色。之所以這樣，也是無奈，因爲團隊組建才半年不到，兩個程序員尚不能勝任更高級的角色，期望其中一個人能儘快勝任界面工程師角色，那樣就能做到更合理化的角色分配，是理想的團隊結構。