經歷了幾家公司，現在入職時首先問對方的問題就是，你們的開發流程是怎樣的。
先說說上家公司在我修改之前的開發流程。
一，承接需求。從市場，運營同事那邊將需求接回來。（坑：老板CTO人緣極好，因為所有的需求只要找到他的都會接下來。然后安排下來之后如果有什么不能實現的，就安排下面人去駁回，可想而知困難有多大，通常會被懟你老板答應了！！！深惡痛絕，為什么不看需求清單！！！）
二、畫原型，寫文檔。（坑：如果是標準文檔，包含判斷條件，異常處理，補充說明等等，通常會耗費原型的3倍時間。而這個時候開發還不知情，所以能否實現根本不知道，就涉及到后面移交以后的返工修改。此時延誤的工期全算產品經理的責任）
三、移交UI、開發和測試。（坑：1、在上條中提過，沒有論證過可行性。2、開發聽過即可沒有時間研究文檔，對于工期預估不準）
四、內測。（坑：1、開發完后直接丟給測試，此時通常測試壓力很大，且沒有經過自測會有些低級BUG影響測試效率。2、測試開始時已經過很長時間，如果沒有用例和評審則可能測試和開發測完之后你忽然發現和你的需求根本不一致！3、測試和開發經常打架，找產品評理，此時因為各執一詞，產品雖然有原始需求但必然影響另一方的情緒。）
修改后：
一、承接需求，出規范的產品提出文檔，將所需的項目背景，預期目標，定位人群，具體功能，責任人等一一列出，形成規范化需求書，這個過程中可以幫助需求方梳理思路，也能幫產品經理節省大量時間。
二、原型產出，與UI UE 開發組長評審原型可行性。以最快速度先產出原型，此時可以不標注異常邏輯等細節，是以最小代價驗證產品的可實現性。同時如果原型通過，則移交給UI UE，在產出文檔時同步產出設計稿和交互稿。
三、需求評審，需要所有項目成員到場。在完成需求文檔后，提前一天發會議要請，并附上需求文檔的郵件，讓與會人員提前瀏覽，能節省大量開會討論時間。在會議上向所有開發人員移交需求和UI稿。如果有問題，則會后更新發出，重大問題二次評審，如果沒問題，定稿，開發測試人員以此為據開發，后續如果有需求變更走變更流程，此處不細說。
四、測試用例評審，在開發結束前，測試同事需要撰寫出測試用例然后將開發，需求方，產品召集起來確認測試用例。以此為準，否則算需求變更。
五、開發自測，在開發完成后，必須得根據測試用例自測通過才能提交給測試。
六、內測驗收，測試完成后，給到產品經理，產品經理通過后給到需求方驗收。通過后上線。
以上所說是最簡單的瀑布流，如果大家有什么問題可以留言討論。
