找外包公司開發(fā)APP，如何把需求準(zhǔn)確的傳達給開發(fā)團隊，開發(fā)公司又如何能夠準(zhǔn)確的把握需求，開發(fā)出符合客戶想要的APP？深圳APP開發(fā)公司樂信科技的產(chǎn)品經(jīng)理分享了一些關(guān)于需求評審的經(jīng)驗，也許能給大家一些啟發(fā)。

 

　　首先，我這里提到的需求包含了：需求，交互，視覺。

　　以前我們的做法是：

　　需求評審：各角色的負(fù)責(zé)人(包含策劃，交互，視覺，開發(fā)，測試，運營等角色負(fù)責(zé)人)來參與，沒問題的需求全部進入交互階段進行交互設(shè)計。

　　交互評審：所有成員(含所有策劃，交互，視覺，開發(fā)和QA)參加，所有交互稿均會交付給視覺同學(xué)進行設(shè)計。

　　視覺評審：基本無

 

　　以上這樣的狀態(tài)，給我們帶來了幾個困擾：

　　首先是所有需求都會進入交互設(shè)計和視覺設(shè)計階段，但是最終有可能因為開發(fā)評估之后做不完而被擱置，形成了設(shè)計資源的浪費。

　　交互評審全員參與，由于人數(shù)眾多，而且分工還未確認(rèn)，開發(fā)并不知道自己負(fù)責(zé)哪部分，所以參與度很低，一般就是交互在講，開發(fā)就在下面聽，也不一定能提出問題，到了后半程，有些同學(xué)就開始玩手機，效率很低。

　　視覺評審的缺失，視覺評審由于沒有約定明確的評審流程，所以有一些視覺沒有經(jīng)過評審就進入了開發(fā)階段，直至需求走查的時候才發(fā)現(xiàn)有問題。

 

　　基于以上問題，我們逐步對相關(guān)的評審機制做了一些調(diào)整，調(diào)整后的情況如下：

　　需求評審

 

　　參與人員：策劃，交互，視覺，開發(fā)，測試，運營等角色負(fù)責(zé)人

 

　　評審目標(biāo)：評審需求的優(yōu)先級和價值，以及初步判斷可實現(xiàn)性

 

　　評審形式：集中會議。需求評審?fù)瓿珊蟮囊惶靸?nèi)，開發(fā)對需求的大小進行初步評估。從估算和計劃的角度來看，可以認(rèn)為這是在需求細(xì)節(jié)還沒那么

 

　　明確的情況下的評估，有可能存在50%±的偏差，但是他能將多余50%之外的需求砍掉，不必再進入交互階段。

 

　　調(diào)整思路：主要增加了開發(fā)的初步評估，將大大超出團隊容量的需求提前砍掉，減少了交互的工作量，使得交互稿可以提前交付，同時也避免了不必要的交互浪費，因為當(dāng)前版本未能開發(fā)的功能，在下一個版本可能優(yōu)先級就又不一樣了，或者早已不符合市場需求了。

 

　　交互評審

 

　　參與人員：團隊核心成員(交互評審)，相關(guān)功能的各角色成員(交互說明)

 

　　評審目標(biāo)：評審交互的合理性，以及交互的可行性評估

 

　　評審形式：分為交互評審和交互說明。

 

　　整體交互稿的交互評審，在交互評審后一天內(nèi)，參與評審的核心開發(fā)針對交互做一個基本的評估。反饋：哪些需求肯定做不完，這些需求就不需要全部進入視覺設(shè)計了。

 

　　在交互和視覺稿基本確認(rèn)之后，在當(dāng)前迭代的后期，再分批跟相關(guān)功能的開發(fā)和測試進行交互說明。此時，開發(fā)的基本分工已經(jīng)確認(rèn)，大家會更細(xì)致來聽，并且能夠提出比較細(xì)節(jié)的問題，當(dāng)然此時交互稿需要修改的問題會比較少，基本不影響整體的安排。

 

　　視覺評審

 

　　參與人員：相應(yīng)的策劃，交互，視覺，以及視覺負(fù)責(zé)人

 

　　評審目標(biāo)：評審視覺稿是否滿足需求，以及從策劃和交互的角度提出建議

 

　　評審形式：當(dāng)面溝通。視覺設(shè)計師會將設(shè)計稿郵件發(fā)給相應(yīng)的策劃交互，抄送開發(fā)，并且邀請策劃和交互當(dāng)面溝通意見。