我就大致描述一下我的專案團隊（算上美工5人）在這方面的情況：
首先，介紹角色：
１．專案組長：相當於專案經理吧，主要職責我就不多說了。
2.介面工程師：是使用者介面互動方面的專家，決定與使用者互動的方式，當然很大程度也影響著介面
3.美工：設計和美化介面
4.高階程式設計師：設計總體程式結構，制定技術上的規範，並為小組解決各種難題，幫助專案組長分解每日程式設計師任務
5.程式設計師：編寫**，實現功能
6.需求人員：與本話題無關，我就不介紹了
7.公關人員：雖然與本話題無關，但我就想在這裡突出其對專案組的重要性，所以順便提一下。至於要攻什麼關大家一定都能猜得出來。
8.其他，如測試人員、文件管理人員等(想象能有plmm角色)：都很重要，但也與本話題無關。
工作流程：
4.所有模組都完工後，就是整體的銜接和測試，然後反覆交復使用者徵求意見，這裡參與的是團隊所有的人馬，一直忙到最後期限為止，然後再延期，直到使用者滿意。
以上是我所在團隊的大致工作流程，大家看了後一定會提出如此分角色人手資源一定不夠的問題。確實，通常來說小公司的開發團隊就幾個人，所以通常很容易做著做著就陷入作坊式做法，大家角色不明確，各自包辦各自的模組，導致之後程式維護非常困難。我上面所述的工作流程中每個環節都明確指出了每個角色的出現場合，所以我是很強調以角色來分工。但如我前面所提到的，我這邊的團隊也不過5個人，所以，雖然角色眾多，但我們還是可以根據各自的團隊實際情況來分擔這些角色，只要記住乙個原則，找合適的人去做合適的角色，即擔當某一角色的人是對該角色領域感興趣的人。比如在我的團隊中，美工是對藝術美感感興趣，我團隊的美工是plmm，可惜只是兼職，沒太多機會，建議大家有條件就找plmm來擔任。需求人員是對整體業務有興趣的人，我這裡的需求人員是辦公室頭，所以向上和外界的公關都是由他搞定。還有兩個是程式設計師角色，乙個偏向於底層資料庫的實現，另乙個偏向於邏輯層的實現，而最後我則是很痛苦地擔當了專案組長、介面工程師、高階程式設計師的角色。之所以這樣，也是無奈，因為團隊組建才半年不到，兩個程式設計師尚不能勝任更高階的角色，期望其中乙個人能盡快勝任介面工程師角色，那樣就能做到更合理化的角色分配，是理想的團隊結構
專案開發經驗談
做專案跟帶兵打仗一樣，需要在時間和空間上有乙個戰略布局。本人用打仗作為比喻，來說明專案策劃過程中，各項活動的重要性 一 戰略布局 瀑布模型是穩紮穩打的做法，步步為營，希望用乙個戰役解決全部問題。適合對敵人情況比較了解或者敵兵比較弱的情況。迭代模型是掃蕩，敵人在暗處，我在明處，怎麼打？集中優勢兵力，一...
專案開發經驗談（二）
1.1 需求變化 專案的需要變化是肯定有的，而且變化一般都很頻繁，我們怎麼應對客戶的這種需求變化呢，以不變應萬變。首先在前期的需求調研要做好，盡可能的替使用者考慮，達到功能質量滿足最大化。需求調研前期的 目標與範圍 和需求調研末期的 功能規格說明書 都要跟客戶簽字確認，這樣既能保證我們所理解的需求就...
專案開發經驗談（二）
1.1 需求變化 專案的需要變化是肯定有的，而且變化一般都很頻繁，我們怎麼應對客戶的這種需求變化呢，以不變應萬變。首先在前期的需求調研要做好，盡可能的替使用者考慮，達到功能質量滿足最大化。需求調研前期的 目標與範圍 和需求調研末期的 功能規格說明書 都要跟客戶簽字確認，這樣既能保證我們所理解的需求就...