一般產(chǎn)品人員進(jìn)行過(guò)需求采集,分析,篩選后就會(huì)進(jìn)行產(chǎn)品的設(shè)計(jì)。
在產(chǎn)品設(shè)計(jì)的過(guò)程中會(huì)產(chǎn)生PRD(Product Requirement Document 產(chǎn)品需求文檔 ),如果是新產(chǎn)品或者在大公司一般還會(huì)有BRD ( Business Requirement Document 商業(yè)需求文檔)和MRD (Market Requirement Document市場(chǎng)需求文檔 )。
當(dāng)寫(xiě)好PRD之后就會(huì)畫(huà)出簡(jiǎn)單的線框圖,在畫(huà)好線框圖后,為了后面更好的評(píng)估開(kāi)發(fā)難度和開(kāi)發(fā)時(shí)間,這時(shí)產(chǎn)品經(jīng)理就會(huì)和開(kāi)發(fā)經(jīng)理和開(kāi)發(fā)人員進(jìn)行一次簡(jiǎn)單的會(huì)議,會(huì)議主要是介紹產(chǎn)品的功能點(diǎn)和交互。
這時(shí)開(kāi)發(fā)人員進(jìn)行給出開(kāi)發(fā)難度,如果功能點(diǎn)太難以實(shí)現(xiàn)或者比較復(fù)雜且優(yōu)先級(jí)不那么高的可能就會(huì)先實(shí)現(xiàn)主要功能(主要為了降低開(kāi)發(fā)成本,看上線后用戶的反應(yīng)再進(jìn)行深度開(kāi)發(fā)同時(shí)也是為了把試錯(cuò)成本降低)。
沒(méi)有問(wèn)題后,產(chǎn)品就會(huì)讓UI人員給出高保真原型圖,同時(shí)開(kāi)發(fā)人員進(jìn)行開(kāi)發(fā)。主要步驟如:
確定需求后,產(chǎn)品人員寫(xiě)PRD和線框圖。
產(chǎn)品人員和開(kāi)發(fā)人員進(jìn)行討論,評(píng)估開(kāi)發(fā)難度和開(kāi)發(fā)時(shí)間。(如果開(kāi)發(fā)迭代時(shí)間固定,主要是評(píng)估難度)
UI根據(jù)線框圖和PRD設(shè)計(jì)出高保真原型圖,同時(shí)開(kāi)發(fā)人員進(jìn)行開(kāi)發(fā),項(xiàng)目管理開(kāi)始。
開(kāi)發(fā),測(cè)試,修改bug(開(kāi)發(fā)中可能會(huì)出現(xiàn)需求更改的情況)
產(chǎn)品經(jīng)理(項(xiàng)目經(jīng)理)進(jìn)項(xiàng)驗(yàn)收,沒(méi)有問(wèn)題上線。
以前的開(kāi)發(fā)大部分都是瀑布式開(kāi)發(fā),現(xiàn)在一把都采用敏捷開(kāi)發(fā)。項(xiàng)目經(jīng)理這個(gè)職位一般也是只有在稍大的公司會(huì)有,在創(chuàng)業(yè)的小公司一般有產(chǎn)品經(jīng)理或者開(kāi)發(fā)經(jīng)理來(lái)?yè)?dān)任。我們公司是由開(kāi)發(fā)經(jīng)理來(lái)?yè)?dān)任開(kāi)發(fā)進(jìn)度管理,最后由產(chǎn)品經(jīng)理驗(yàn)收。
一般敏捷開(kāi)發(fā)流程(每個(gè)公司的迭代周期不同,但大致流程相似。下面是兩個(gè)星期一個(gè)迭代)如下:如果我們需要從第1周周一開(kāi)始開(kāi)發(fā)新的迭代(假定第5個(gè)迭代)。那么就要在上周的周三,產(chǎn)品人員和開(kāi)發(fā)人員進(jìn)行PRD評(píng)審,如有需要修改的地方進(jìn)行修改。(第四個(gè)迭代開(kāi)發(fā)持續(xù)中,UI按照優(yōu)先級(jí)開(kāi)始繪制已經(jīng)確定需求的高保真圖)
在上周的周五產(chǎn)品進(jìn)行修改后,再次和開(kāi)發(fā)人員進(jìn)行評(píng)審,確定沒(méi)有需求沒(méi)有大的變動(dòng)。(UI設(shè)計(jì)持續(xù),啟動(dòng)新的開(kāi)發(fā)迭代(第5個(gè)迭代),進(jìn)行上次迭代(第4個(gè)迭代)總結(jié)會(huì)議和新迭代開(kāi)啟會(huì)議),這時(shí)項(xiàng)目也會(huì)在進(jìn)行拆分,比如按照epic-story-sprint-task的方式進(jìn)行拆分。然后把這個(gè)迭代的任務(wù)拆分成各個(gè)小的task,然后進(jìn)行人員分配。task的時(shí)間顆粒度一般不超過(guò)兩天,分的太粗容易造成delay。task維護(hù)一般使用看板的形式,我們使用過(guò)的有Jira,kanbanflow,icafe等。(可以根據(jù)喜好使用,里面有相應(yīng)的曲線圖和燃盡圖)
第一周周一上班,UI同學(xué)會(huì)給出一部分設(shè)計(jì)的好高保真圖。這時(shí)服務(wù)端同學(xué)會(huì)根據(jù)安排好的優(yōu)先級(jí)給出相應(yīng)功能的接口文檔。移動(dòng)端的同學(xué)進(jìn)行頁(yè)面編碼和設(shè)計(jì)。同時(shí)移動(dòng)端同學(xué)會(huì)根據(jù)給出的接口文檔先造一批假數(shù)據(jù)已備本地測(cè)試(如果有相應(yīng)的接口測(cè)試工具會(huì)更好,我們是用的自己開(kāi)發(fā)的接口測(cè)試沙箱,可以根據(jù)綁定的真假接口進(jìn)行真假數(shù)據(jù)的測(cè)試)。同時(shí),每天下班前都要有站會(huì)。站會(huì)主要說(shuō)自己的三個(gè)問(wèn)題:1.今天做了什么2.有什么問(wèn)題3.明天做什么
開(kāi)發(fā)持續(xù)進(jìn)行,到第一周周四時(shí),會(huì)先發(fā)個(gè)測(cè)試包,讓測(cè)試人員進(jìn)行測(cè)試。當(dāng)然開(kāi)發(fā)過(guò)程中也在不斷測(cè)試。出現(xiàn)問(wèn)題就進(jìn)行修復(fù),bug修復(fù)不再安排時(shí)間,不會(huì)在看板上建新的task來(lái)修復(fù)bug,開(kāi)發(fā)任務(wù)繼續(xù)。
到第二周的周三,要確保開(kāi)發(fā)任務(wù)基本完成。然后發(fā)個(gè)測(cè)試包,進(jìn)行測(cè)試。有bug進(jìn)行修復(fù)。同時(shí)產(chǎn)品經(jīng)理進(jìn)行查看。同時(shí)和產(chǎn)品進(jìn)行下的迭代(第6個(gè)迭代)的PRD評(píng)審。
到第二周的周五,再發(fā)個(gè)測(cè)試包,進(jìn)行測(cè)試。有bug進(jìn)行修復(fù)。產(chǎn)品經(jīng)理驗(yàn)收。(沒(méi)有問(wèn)題,一般會(huì)在夜里凌晨1-2點(diǎn)上線。)上線后可能要安排人員進(jìn)行值守,看有沒(méi)有問(wèn)題。同時(shí)周五還要和產(chǎn)品進(jìn)行確認(rèn)最終新的開(kāi)發(fā)。同時(shí)開(kāi)總結(jié)會(huì)議和新迭代啟動(dòng)會(huì)議,這兩個(gè)會(huì)議也可能放在周一開(kāi)。
至此,一個(gè)迭代開(kāi)發(fā)周期完成。
注意:在開(kāi)發(fā)的過(guò)程中,項(xiàng)目經(jīng)理每天要通過(guò)看板或者詢問(wèn)開(kāi)發(fā)人員的進(jìn)度是不是符合原來(lái)的預(yù)訂計(jì)劃,如果出現(xiàn)delay現(xiàn)象,可能就要通過(guò)加班來(lái)把進(jìn)度提上來(lái)。
測(cè)試人員也要參與需求的評(píng)審,方便后面業(yè)務(wù)測(cè)試。
開(kāi)發(fā)人員要對(duì)自己寫(xiě)的代碼負(fù)責(zé)人,寫(xiě)好后要進(jìn)行代碼review和自測(cè),不能把沒(méi)有測(cè)試的代碼進(jìn)行提交。