外包軟件開發(fā)流程

1、外包軟件開發(fā)流程外包軟件開發(fā)流程一 .商務(wù)談判武漢 -沃 -航 -科 -技一款軟件準(zhǔn)備開發(fā)時(shí),首先就就是與甲方公司進(jìn)行接洽與商務(wù)談判,初步了解用戶需求以及這個(gè)項(xiàng)目甲方對資金以及工期與其她的各方面的預(yù)估,初步達(dá)成合作意向。二 .產(chǎn)品需求討論需求分析就是做產(chǎn)品的頭等大事,而需求分析的第一步就就是找準(zhǔn)產(chǎn)品定位。產(chǎn)品定位實(shí)際上就就是關(guān)于產(chǎn)品的目標(biāo)、范圍、特征等約束條件,它包括兩方面的內(nèi)容:產(chǎn)品定義與用戶需求。 產(chǎn)品定義主要由產(chǎn)品經(jīng)理從網(wǎng)站角度考慮,用戶需求主要由設(shè)計(jì)師從用戶角度考慮。明確了產(chǎn)品定位,也就確定了產(chǎn)品設(shè)計(jì)的方向,統(tǒng)一了團(tuán)隊(duì)成員對產(chǎn)品的理解,可以避免團(tuán)隊(duì)內(nèi)很多不必要的爭執(zhí)。產(chǎn)品定義就就是用一

2、句話概括產(chǎn)品, 包括如下三個(gè)方面:使用人群 : 產(chǎn)品服務(wù)于哪類人群。主要功能 : 功能范圍的限定。產(chǎn)品特色 : 與同類產(chǎn)品相比的競爭優(yōu)勢。舉例 : 一款音樂應(yīng)用的產(chǎn)品定義。使用人群 : 白領(lǐng)主要功能 : 播放音樂產(chǎn)品特色 : 音質(zhì)清晰、更新速度快用戶需求概括起來就就是 : 誰在什么環(huán)境下想要解決什么問題。一般可以分解為一個(gè)個(gè)用戶故事 , 包括如下三個(gè)方面 : 目標(biāo)用戶 : 目標(biāo)用戶就是在使用人群細(xì)分的基礎(chǔ)上得到的 , 它也在一定程度上影響了使用場景與用戶目標(biāo)。拆解用戶的時(shí)候考慮潛在用戶量與商業(yè)價(jià)值。 使用場景 : 用戶使用產(chǎn)品的環(huán)境 , 需要關(guān)注不同場景的特點(diǎn)。 用戶目標(biāo) : 用戶在不同場景下

3、期望完成的目標(biāo) , 可從中提取出功能關(guān)鍵詞。三 .prd 輸出與確認(rèn)一般一份 prd文檔要包含以下這些內(nèi)容:1、概述部分 :簡單介紹一下產(chǎn)品的背景 ,產(chǎn)品的價(jià)值或者愿景 ,產(chǎn)品的簡單介紹 ,一些預(yù)估的風(fēng)險(xiǎn)點(diǎn) ,干系人 ,名詞解釋等等 ;2、業(yè)務(wù)需求描述部分:定義好目標(biāo)用戶群體,業(yè)務(wù)流程圖 ,業(yè)務(wù)架構(gòu)圖 ,腦圖等等的介紹;3、功能需求描述部分:這部分才就是用到上面所述方法的點(diǎn),每個(gè)功能點(diǎn)都可以用那樣的方式描述 ;4、非功能需求描述部分:與產(chǎn)品相關(guān)的一些輔助功能,性能要求、易用性要求等等;外包軟件開發(fā)流程5、接口描述部分: 與外部有相關(guān)接口的需要在這個(gè)部分描述;6、附錄部分 :培訓(xùn)信息、參考資料等

4、,還可以有運(yùn)營計(jì)劃等等; 完整的prd 文檔中 ,最多的部分就就是對功能需求的分解描述,axurerp 可以很好的支撐這個(gè)部分的全部內(nèi)容,另外其實(shí) axurerp 也有流程圖、uml 圖的功能 ,業(yè)務(wù)流程圖、業(yè)務(wù)架構(gòu)圖等都可以在axurerp 里面實(shí)現(xiàn)出來。四 .合同擬定需求確認(rèn)完成后就要開始擬定合同了。合同要列出雙方的責(zé)任與義務(wù) , 驗(yàn)收方式 , 過程中遇到問題的解決情況 , 項(xiàng)目資金打款的問題保密協(xié)議 , 軟件所有權(quán) , 知識(shí)產(chǎn)權(quán)、著作權(quán)歸屬 , 外包完工之后 , 售后的支援與幫助。確定雙方的溝通的機(jī)制及開發(fā)周期雙方的主要干系人 , 開發(fā)負(fù)責(zé)人 , 產(chǎn)品負(fù)責(zé)人 , 項(xiàng)目支持等簡歷微信群 ,

5、 討論組 , 文檔上傳共享的網(wǎng)盤等開發(fā)就是每周一個(gè)周期 , 進(jìn)行功能的測試與uat,然后將工期進(jìn)展郵件抄送所有人主要就是雙方合作方式及實(shí)現(xiàn)方式五、項(xiàng)目計(jì)劃一個(gè)軟件項(xiàng)目進(jìn)入系統(tǒng)實(shí)施的啟動(dòng)階段,主要進(jìn)行的工作包括: 確定詳細(xì)的項(xiàng)目實(shí)施范圍、定義遞交的工作成果、評估實(shí)施過程中主要的風(fēng)險(xiǎn)、制定項(xiàng)目實(shí)施的時(shí)間計(jì)劃、成本與預(yù)算計(jì)劃、人力資源計(jì)劃等。在軟件項(xiàng)目管理過程中一個(gè)關(guān)鍵的活動(dòng)就是制定項(xiàng)目計(jì)劃,它就是軟件開發(fā)工作的第一步。項(xiàng)目計(jì)劃的目標(biāo)就是為項(xiàng)目負(fù)責(zé)人提供一個(gè)框架, 使之能合理地估算軟件項(xiàng)目開發(fā)所需的資源 、經(jīng)費(fèi)與開發(fā)進(jìn)度, 并控制軟件項(xiàng)目開發(fā)過程按此計(jì)劃進(jìn)行。在做計(jì)劃時(shí), 必須就需要的人力、項(xiàng)目持續(xù)

6、時(shí)間及成本作出估算。這種估算大多就是參考以前的花費(fèi)作出的。軟件項(xiàng)目計(jì)劃包括二個(gè)任務(wù): 研究與估算。 即通過研究確定該軟件項(xiàng)目的主要功能、性能與系統(tǒng)界面、六 .需求變更計(jì)劃每做一次項(xiàng)目計(jì)劃變更,都會(huì)影響到日后的成本估算、活動(dòng)順序、行程日期、資源需求及風(fēng)險(xiǎn)控管的決策,因此甲乙雙方的項(xiàng)目經(jīng)理、it 經(jīng)理都必須以整體的視野、統(tǒng)一的要求,對變更進(jìn)行控制、 確認(rèn)與紀(jì)錄。 而需求變更的控制關(guān)鍵在于建立相應(yīng)的控制組織、變更控制系統(tǒng)以及規(guī)范變更流程。,挖掘企業(yè)用戶的潛在需求,發(fā)現(xiàn)可能要需求變更的地方,讓企業(yè)用戶盡快做出就是否要進(jìn)行需求變更。一般把需求變更或者新需求的確認(rèn)最遲時(shí)間定在系統(tǒng)培訓(xùn)階段。也就就是說,在系

7、統(tǒng)培訓(xùn)完成后、 開始準(zhǔn)備雙線并行前,企業(yè)用戶還可以提出需求變更的申請,但就是 ,當(dāng)系統(tǒng)開始雙線運(yùn)行時(shí) ,就不允許用戶再提出需求變更等類似的請求了,如編碼的內(nèi)容與規(guī)則、表單的外包軟件開發(fā)流程數(shù)量與格式、數(shù)據(jù)流轉(zhuǎn)與統(tǒng)計(jì)方式等,否則就要付出變更的代價(jià)。建立變更控制組織系統(tǒng)。項(xiàng)目啟動(dòng)時(shí),盡可能地與客戶溝通,盡快建立正式的對變更進(jìn)行控制的組織 ,通稱變更控制委員會(huì)(ccb),成員可包括雙方高層(掛名 )、甲乙雙方的項(xiàng)目負(fù)責(zé)人、相關(guān)的需求負(fù)責(zé)人等,負(fù)責(zé)裁定接受變更內(nèi)容、方法、步驟等。建立該系統(tǒng)的目的就是統(tǒng)一管理需求變更與跟蹤變更的狀態(tài),便于項(xiàng)目組測試人員、開發(fā)人員、系統(tǒng)分析員以及pm 相互之間的溝通與交流

8、。建立變更控制系統(tǒng)目的不就是讓用戶不提出變更,而就是讓用戶不輕易、隨便的提出變更。嚴(yán)格規(guī)范變更流程。一旦需求分析階段結(jié)束,此后如果用戶要求有新的需求加入即將交付的軟件系統(tǒng)中, 甲乙雙方的項(xiàng)目組或變更控制委員會(huì),要根據(jù)角色定義,確定變更流程,規(guī)定嚴(yán)格的變更控制流程,并控制新需求提出的頻率。七 .項(xiàng)目驗(yàn)收對互聯(lián)網(wǎng)產(chǎn)品而言,驗(yàn)收有三層含義: 產(chǎn)品功能用例化后,用例執(zhí)行符合預(yù)期與需求吻合 ,正向操作的用戶體驗(yàn)良好 設(shè)計(jì)與前端 ui 符合評審的標(biāo)準(zhǔn) 第一層應(yīng)該就是測試人員應(yīng)該重點(diǎn)關(guān)注的 ,但在小公司或創(chuàng)業(yè)公司 ,開發(fā) / 產(chǎn)品本身就就是測試 ,驗(yàn)收幾乎等同于最后一次測試。但就是無論就是否有“測試工程師”

9、這個(gè)崗位,產(chǎn)品需求的用例化都就是十分必要的,即便通過了專門的測試,產(chǎn)品或領(lǐng)導(dǎo)在驗(yàn)收時(shí),潛意識(shí)也就是在執(zhí)行相關(guān)的用例; 第二層說的就是普遍意義上的驗(yàn)收,產(chǎn)品通過 test 平臺(tái)測試 ,部署到了 demo 平臺(tái) ,由產(chǎn)品需求人員進(jìn)行需求驗(yàn)收 ,當(dāng)然 ,內(nèi)部成員、相關(guān)領(lǐng)導(dǎo)都可以進(jìn)行驗(yàn)收體驗(yàn)。對demo 的驗(yàn)收 ,就是“裝成用戶”后對產(chǎn)品的使用 ,通常就是正向操作 ,同時(shí)除了邏輯與流程,驗(yàn)收人員會(huì)更加關(guān)注用戶體驗(yàn); 關(guān)于前端 ui 的驗(yàn)收 ,實(shí)際上就是對“用戶體驗(yàn)”的一部分標(biāo)準(zhǔn)化,而驗(yàn)收的內(nèi)容應(yīng)該與“設(shè)計(jì)評審”通過的內(nèi)容相吻合。如果沒有設(shè)計(jì)評審,那么標(biāo)準(zhǔn)就就是公說公有理了。為了避免這種情況 ,需要在需

10、求與設(shè)計(jì)評審前,界定清楚一些基本的準(zhǔn)則與規(guī)范,比如符合公司的vi體系、符合 w3c 頁面標(biāo)準(zhǔn)、符合xxx,最直觀的還就是所見即所得的“需求設(shè)計(jì)交互頁面”這個(gè)問題其實(shí)很好 ,好在專門提出了 ui 的驗(yàn)收。本質(zhì)上就是因?yàn)殚_發(fā)對ui 或者對前端、 兼容性等很容易忽略 ,因?yàn)檫@就是個(gè)“簡單但很花時(shí)間”的活兒,做起來沒有成就感。當(dāng)然,如果您們有一套自己的 ui 庫或前端框架 ,那么能夠規(guī)避很多前端上的扯皮,但如果沒有 ,開發(fā)與前端至少需要 50%的精力去搞頁面。提前考慮標(biāo)準(zhǔn)、盡量使用框架、讓代碼公用并易于維護(hù),這就是前端與攻城師的硬功夫,否則就沉浸在無盡的bug中 ,更不用說驗(yàn)收了。至于誰負(fù)責(zé)？團(tuán)隊(duì)中的

11、任意相關(guān)人都可以,前端、開發(fā)、產(chǎn)品、或者您們領(lǐng)導(dǎo)?？傊?驗(yàn)收就就是質(zhì)量的最后把關(guān),產(chǎn)品自己都瞧不過去,臭蟲一堆 ,千萬不要有任何僥幸心理讓用戶幫著驗(yàn)收。八 .迭代計(jì)劃做產(chǎn)品 roadmap 規(guī)劃的時(shí)候 ,要想清楚哪些需求就是包括在mvp (minimalvariableproduct) 的。也就就是說第一版必須抓住目標(biāo)用戶的痛點(diǎn)與切實(shí)需求。在時(shí)間金錢資源有限的情況下 ,弄明白哪些功能點(diǎn)就是必不可少的,對產(chǎn)品推出后成功就是至關(guān)重要的。如何弄明白這個(gè)問題？那就就是從用戶調(diào)研數(shù)據(jù)得來。沒有經(jīng)過用戶驗(yàn)證過的產(chǎn)品原型一般來說都很難經(jīng)得起推敲 ,因?yàn)檫@就是在設(shè)計(jì)師 (或者產(chǎn)品經(jīng)理 )的假設(shè)上完成的作品,而并不一定會(huì)獲得用戶的青睞與肯定。當(dāng)有了mvp(第一版 )以后 ,就可以在市場的反饋結(jié)果上做下一步考慮 ,哪些地方就是需要修改的,哪些功能點(diǎn)就是需要補(bǔ)充的,哪些地方其實(shí)用戶反響并不大可以移除的。把這些點(diǎn)做優(yōu)先級排列,最重要與最緊急的放在下一個(gè)產(chǎn)品迭代周期的開發(fā)之首,再對新的產(chǎn)品