經(jīng)歷了幾家公司，現(xiàn)在入職時(shí)首先問對(duì)方的問題就是，你們的開發(fā)流程是怎樣的。

先說說上家公司在我修改之前的開發(fā)流程。

一，承接需求。從市場(chǎng)，運(yùn)營(yíng)同事那邊將需求接回來。（坑：老板CTO人緣極好，因?yàn)樗械男枨笾灰业剿亩紩?huì)接下來。然后安排下來之后如果有什么不能實(shí)現(xiàn)的，就安排下面人去駁回，可想而知困難有多大，通常會(huì)被懟你老板答應(yīng)了！?。∩類和唇^，為什么不看需求清單！?。。?/p>

二、畫原型，寫文檔。（坑：如果是標(biāo)準(zhǔn)文檔，包含判斷條件，異常處理，補(bǔ)充說明等等，通常會(huì)耗費(fèi)原型的3倍時(shí)間。而這個(gè)時(shí)候開發(fā)還不知情，所以能否實(shí)現(xiàn)根本不知道，就涉及到后面移交以后的返工修改。此時(shí)延誤的工期全算產(chǎn)品經(jīng)理的責(zé)任）

三、移交UI、開發(fā)和測(cè)試。（坑：1、在上條中提過，沒有論證過可行性。2、開發(fā)聽過即可沒有時(shí)間研究文檔，對(duì)于工期預(yù)估不準(zhǔn)）

四、內(nèi)測(cè)。（坑：1、開發(fā)完后直接丟給測(cè)試，此時(shí)通常測(cè)試壓力很大，且沒有經(jīng)過自測(cè)會(huì)有些低級(jí)BUG影響測(cè)試效率。2、測(cè)試開始時(shí)已經(jīng)過很長(zhǎng)時(shí)間，如果沒有用例和評(píng)審則可能測(cè)試和開發(fā)測(cè)完之后你忽然發(fā)現(xiàn)和你的需求根本不一致！3、測(cè)試和開發(fā)經(jīng)常打架，找產(chǎn)品評(píng)理，此時(shí)因?yàn)楦鲌?zhí)一詞，產(chǎn)品雖然有原始需求但必然影響另一方的情緒。）

修改后：

一、承接需求，出規(guī)范的產(chǎn)品提出文檔，將所需的項(xiàng)目背景，預(yù)期目標(biāo)，定位人群，具體功能，責(zé)任人等一一列出，形成規(guī)范化需求書，這個(gè)過程中可以幫助需求方梳理思路，也能幫產(chǎn)品經(jīng)理節(jié)省大量時(shí)間。

二、原型產(chǎn)出，與UI UE 開發(fā)組長(zhǎng)評(píng)審原型可行性。以最快速度先產(chǎn)出原型，此時(shí)可以不標(biāo)注異常邏輯等細(xì)節(jié)，是以最小代價(jià)驗(yàn)證產(chǎn)品的可實(shí)現(xiàn)性。同時(shí)如果原型通過，則移交給UI UE，在產(chǎn)出文檔時(shí)同步產(chǎn)出設(shè)計(jì)稿和交互稿。

三、需求評(píng)審，需要所有項(xiàng)目成員到場(chǎng)。在完成需求文檔后，提前一天發(fā)會(huì)議要請(qǐng)，并附上需求文檔的郵件，讓與會(huì)人員提前瀏覽，能節(jié)省大量開會(huì)討論時(shí)間。在會(huì)議上向所有開發(fā)人員移交需求和UI稿。如果有問題，則會(huì)后更新發(fā)出，重大問題二次評(píng)審，如果沒問題，定稿，開發(fā)測(cè)試人員以此為據(jù)開發(fā)，后續(xù)如果有需求變更走變更流程，此處不細(xì)說。

四、測(cè)試用例評(píng)審，在開發(fā)結(jié)束前，測(cè)試同事需要撰寫出測(cè)試用例然后將開發(fā)，需求方，產(chǎn)品召集起來確認(rèn)測(cè)試用例。以此為準(zhǔn)，否則算需求變更。

五、開發(fā)自測(cè)，在開發(fā)完成后，必須得根據(jù)測(cè)試用例自測(cè)通過才能提交給測(cè)試。

六、內(nèi)測(cè)驗(yàn)收，測(cè)試完成后，給到產(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理通過后給到需求方驗(yàn)收。通過后上線。

以上所說是最簡(jiǎn)單的瀑布流，如果大家有什么問題可以留言討論。