APP開發項目的(de)需求要怎麽做(zuò)

 

開始一個(gè)APP開發項目，對(duì)于APP開發團隊而言，首先要知道做(zuò)什(shén)麽。APP開發的(de)全過程是：做(zuò)什(shén)麽，怎麽做(zuò)，做(zuò) ，成果檢驗，交付部署；其中，“做(zuò)什(shén)麽”對(duì)應的(de)是需求分(fēn)析過程，“怎麽做(zuò)”對(duì)應于軟件架構設計過程，“做(zuò)”對(duì)應于開發過程，“成果檢驗”對(duì)應于測試，部署由運維團隊執行後，如果達到用(yòng)戶的(de)要求，則軟件上線後進入軟件的(de)運行生命周期。

在實際的(de)軟件項目開發中，“做(zuò)什(shén)麽”，“怎麽做(zuò)”和(hé)“做(zuò)”是緊密結合在一起的(de)，“做(zuò)”，“成果檢驗”和(hé)“交付部署”通(tōng)常也(yě)會是一個(gè)持續交付過程，“成果檢驗”的(de)内容會受到“做(zuò)什(shén)麽”的(de)影(yǐng)響，開展“做(zuò)什(shén)麽”階段的(de)時(shí)候，也(yě)要考慮到如何部署和(hé)交付。所以軟件開發的(de)全過程，都是緊密結合在一起的(de)，如果刻意劃分(fēn)爲獨立的(de)幾個(gè)階段，忽視其作爲一個(gè)整理(lǐ)的(de)綜合影(yǐng)響，每個(gè)環節的(de)實施過程必然會遇到因上一階段考慮不周全帶來(lái)的(de)問題，從而影(yǐng)響整體開發效率。

基于此，我們的(de)需求分(fēn)析，從需求深度劃分(fēn)，可(kě)以分(fēn)爲三個(gè)層次：原始需求分(fēn)析、業務架構分(fēn)析和(hé)功能架構分(fēn)析。這(zhè)三個(gè)層次依次遞進，沒有嚴格的(de)界限。

原始需求是從用(yòng)戶或業務角度看到的(de)，或應該有的(de)需求，或項目團隊經過初步挖掘後整理(lǐ)出來(lái)的(de)、未經進一步提煉的(de)需求。
如果拿做(zuò)項目與做(zuò)産品做(zuò)個(gè)類比，原始需求有點類似與産品經理(lǐ)所說的(de)“用(yòng)戶故事”，由于原始需求可(kě)能是開發者分(fēn)析出來(lái)了(le)，也(yě)可(kě)能是行業專家或目标客戶 / 用(yòng)戶提出來(lái)的(de)，原始需求可(kě)以不止步于“用(yòng)戶故事”，在該階段做(zuò)一定的(de)業務邏輯的(de)抽取和(hé)提煉，對(duì)接下(xià)來(lái)“業務架構”階段的(de)需求分(fēn)析也(yě)是有幫助的(de)，所以這(zhè)兩個(gè)階段沒必要确立一個(gè)嚴格的(de)界限。

業務架構階段的(de)需求分(fēn)析，是對(duì)原始需求的(de)抽象和(hé)再提煉，在形成業務架構之前，首先要梳理(lǐ)清楚功能需求和(hé)非功能需求，非功能需求是爲接下(xià)來(lái)的(de)功能架構及怎麽做(zuò)鋪路的(de)，本節暫不展開；功能需求又分(fēn)爲“顯式的(de)功能需求”和(hé)“潛在的(de)功能需求”，如上一節列出的(de)需求，均爲顯式功能需求，潛在的(de)功能需求要從多(duō)個(gè)角度去考慮，如整理(lǐ)出用(yòng)戶組、權限對(duì)應的(de)完整業務邏輯，是屬于可(kě)以推測并進一步開展工作的(de)潛在功能需求，而修改密碼、個(gè)人(rén)信息、用(yòng)戶管理(lǐ)和(hé)忘記密碼等功能，是上面漏掉的(de)、但又會影(yǐng)響到系統完整性的(de)潛在需求，而需要提供一個(gè)系統初始化(huà)接口的(de)功能需求，是站在運維實施角度提出來(lái)的(de)潛在需求。

業務架構爲軟件系統的(de)開發奠定了(le)基礎，在實際的(de)軟件項目中，通(tōng)常可(kě)以在此基礎上讓需求分(fēn)析再往前邁一步，将"做(zuò)什(shén)麽"和(hé)“怎麽做(zuò)”是緊密聯系起來(lái)，承上啓下(xià)，我将這(zhè)部分(fēn)需求分(fēn)析稱之爲“功能架構分(fēn)析”。
爲什(shén)麽需求分(fēn)析中要做(zuò)功能架構分(fēn)析？
定性的(de)說，這(zhè)一步工作也(yě)可(kě)以納入“怎麽做(zuò)”的(de)環節再開展，但我認爲把它作爲需求分(fēn)析的(de)最後階段，對(duì)整個(gè)項目過程而言更有效率。這(zhè)部分(fēn)工作依然是圍繞需求分(fēn)析展開的(de)，前文所述的(de)需求分(fēn)析工作通(tōng)常開發者也(yě)會參與進去，所以業務架構分(fēn)析和(hé)功能架構分(fēn)析本來(lái)就是銜接在一起的(de)連續過程，如果把這(zhè)一步工作從需求分(fēn)析中抛離，項目進行到怎麽做(zuò)或做(zuò)的(de)階段時(shí)，發現現實（代碼邏輯和(hé)系統實施）和(hé)理(lǐ)想（業務邏輯）不一緻的(de)概率會更大(dà)，開發過程中可(kě)能會有更多(duō)關于“需求分(fēn)析沒做(zuò)到位”的(de)扯皮，甚至不得(de)不重新返回需求分(fēn)析階段再次梳理(lǐ)需求，這(zhè)都會帶來(lái)本可(kě)避免的(de)項目進度延誤。
所以，需求分(fēn)析如果隻考慮“原始需求”和(hé)“業務架構”兩個(gè)維度，是有盲點的(de)，功能架構分(fēn)析雖然可(kě)以作爲“怎麽做(zuò)”的(de)第一步，但把它作爲“做(zuò)什(shén)麽”的(de)最後一步，能有效減少因爲沒有“向後看”帶來(lái)的(de)需求分(fēn)析不充分(fēn)的(de)問題，能夠把需求和(hé)實現更緊密的(de)結合在一起，它在一定程度上對(duì)業務架構做(zuò)了(le)進一步的(de)細化(huà)，也(yě)在一定程度上影(yǐng)響了(le)業務架構的(de)最終成果。

綜上，在APP開發項目中，如果要把需求分(fēn)析做(zuò)到位，止于功能架構分(fēn)析才是保險的(de)。