a、項目經理與公司決策層的溝通，以確定這個需求有沒有足夠的人手和可行性去實現，以及與現有產品的依存關系。
　　b、公司決策層與市場/策劃部門的交流，這個過程將進行的相當充分，並且是反復、長期的，它致力於從用戶的角度對需求進行細化和分解。
　　c、市場部門需要針對細節問題與項目經理交流，以確定這個需求有沒有可行性去實現。
　　d，e，j、這是整個產品的架構設計過程，分為ui架構設計和程序架構設計兩部分。首先架構師需要與項目經理達成思想上的一致，隨後進行設計。這個設 計必須是便於分工、維護和擴展的，而且要能夠承受一定強度的原型開發壓力。ui架構師將根據界面邏輯對產品實施分割，對每個界面上需要放置的內容了如指 掌。程序架構師在與全體開發人員民主討論後，制定出自底至頂的程序層次（例如class、library等等），並劃分出功能模塊（例如首頁、內容列表、 後臺管理、幫助系統等等）。ui架構師與程序架構師之間需要就功能劃分、文件命名規則等等達成一致意見，並不斷在開發中完善思路。
　　f、美工使用photoshop等工具設計界面，並完成圖片切割工作。
　　g、網頁設計師負責書寫靜態模板。如果人手缺乏，這個位置可從程序開發人員中抽調。
　　k、美工與網頁設計師之間需要進行一些協調。一些美工的設計思維並不能完美的體現在網頁上，因此需要不斷的磨合與修正，達到雙方都滿意的結果。但相對來說，美工完成的作品並不需要做太多的改動，因此這裏采用單向箭頭標示。
　　h、對底層邏輯（如類、方法、庫的設計），以及相關文檔的整理。如有精力可以進行小規模的測試，確保日後的開發工作順利進行。
　　i、當底層接口以及相關文檔完成後，模塊化的拼接將變的比較輕松，這個流程將完成基本模塊到外部功能的構建工作。
　　l、這是程序開發人員需要付出最多交流成本的地方。很多的底層模塊在拼接過程中需要進行變動，例如增減參數，修改類、屬性、方法的名稱，將類、屬性、方法移動位置等等。同時，外部的實現需要隨著底層模塊的更改、優化進行相應的調整。
　　m、產品成型後，將交付測試部門進行測試。測試部門返回一個報告，發送給項目經理和程序開發人員。在小規模的開發團隊裏，項目經理可以充當質量保證的角色，前提是他對項目的開發過程有一定程度的了解，否則，應當指派一名專門的質量保證人員來處理bug列表。
　　n、測試部門返回的報告本來是可以發給所有程序開發人員的，但不幸的是，測試人員只跟界面打交道，他們只註重結果，而不註重實現原理。因此bug列表 一般需要交給負責界面邏輯的開發人員進行整理，然後分發給各個成員加以更正。在小規模的開發團隊裏，界面邏輯和底層邏輯可能是由相同的一批人來實現的，那 麽他們需要一個bugzilla來協同處理這些bug。我們也建議測試人員使用同一套bugzilla系統提交bug報告。

　　最後總結幾點：一、詳細分工的目的是為了降低交流成本。二、實際情況會使得開發工作復雜化，所以流程模型要能適應原型開發工作。三、文檔和標準化的規範是極其重要的，它可以使開發過程工廠化，提高代碼質量和可維護性。

轉自：http://blog.csdn.net/hello_simon/article/details/19993343

（轉）web開發流程