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

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

2、群：產(chǎn)品服務(wù)于哪類人群。主要功能：功能范圍的限定。產(chǎn)品特色：與同類產(chǎn)品相比的競爭優(yōu)勢。舉例：一款音樂應(yīng)用的產(chǎn)品定義。使用人群：白領(lǐng)主要功能：播放音樂產(chǎn)品特色：音質(zhì)清晰、更新速度快用戶需求概括起來就是：誰在什么環(huán)境下想要解決什么問題。一般可以分解為一個個用戶故事，包括如下三個方面：目標(biāo)用戶：目標(biāo)用戶是在使用人群細(xì)分的基礎(chǔ)上得到的，它也在一定程度上影響了使用場景和用戶目標(biāo)。拆解用戶的時候考慮潛在用戶量和商業(yè)價值。 使用場景：用戶使用產(chǎn)品的環(huán)境，需要關(guān)注不同場景的特點。用戶目標(biāo)：用戶在不同場景下期望完成的目標(biāo)，可從中提取出功能關(guān)鍵詞。三.prd輸由和確認(rèn)一般一份PRD文檔要包含以下這些內(nèi)容：1、概述

3、部分：簡單介紹一下產(chǎn)品的背景，產(chǎn)品的價值或者愿景，產(chǎn)品的簡單介紹，- 些預(yù)估的風(fēng)險點，干系人，名詞解釋等等；2、業(yè)務(wù)需求描述部分：定義好目標(biāo)用戶群體，業(yè)務(wù)流程圖，業(yè)務(wù)架構(gòu)圖，腦圖等等的 介紹；3、功能需求描述部分：這部分才是用到上面所述方法的點，每個功能點都可以用那樣的方式描述；4、非功能需求描述部分：與產(chǎn)品相關(guān)的一些輔助功能，性能要求、易用性要求等等；5、接口描述部分：與外部有相關(guān)接口的需要在這個部分描述；6、附錄部分：培訓(xùn)信息、參考資料等，還可以有運營計劃等等；完整的PRD文檔中，最多的部分就是對功能需求的分解描述，AxureRP可以很好的支撐這個部分的全部內(nèi)容，另外其實AxureRP也有

4、流程圖、UML圖的功能，業(yè)務(wù)流程圖、業(yè)務(wù)架構(gòu)圖等都可以在AxureRP里面實現(xiàn)出來。4 .合同擬定需求確認(rèn)完成后就要開始擬定合同了。合同要列出雙方的責(zé)任與義務(wù)，驗收方式，過程中遇到問題的解決情況，項目資 金打款的問題保密協(xié)議，軟件所有權(quán)，知識產(chǎn)權(quán)、著作權(quán)歸屬，外包完工之后，售后的支援與 幫助。確定雙方的溝通的機制及開發(fā)周期雙方的主要干系人，開發(fā)負(fù)責(zé)人，產(chǎn)品負(fù)責(zé)人，項目支持等簡歷微信群，討論組，文檔上傳共享的網(wǎng)盤等開發(fā)是每周一個周期，進行功能的測試與 UAT然后將工期進展郵件抄送所有人主要是雙方合作方式及實現(xiàn)方式5 .項目計劃一個軟件項目進入系統(tǒng)實施的啟動階段，主要進行的工作包括：確定詳細(xì)的項目

5、實施范圍、定義遞交的工作成果、 評估實施過程中主要的風(fēng)險、制定項目實施的時間計劃、 成本和預(yù)算計劃、人力資源計劃等。在軟件項目管理過程中一個關(guān)鍵的活動是制定項目計劃，它是軟件開發(fā)工作的第一步。項目計劃的目標(biāo)是為項目負(fù)責(zé)人提供一個框架，使之能合理地估算軟件項目開發(fā)所需的資源、經(jīng)費和開發(fā)進度，并控制軟件項目開發(fā)過程按此計劃進行。在做計劃時，必須就需要的人力、項目持續(xù)時間及成本作出估算。這種估算大多是參考以前的花費作出的。軟件項目計劃包括二個任務(wù)：研究和估算。即通過研究確定該軟件 項目的主要功能、 性能和系統(tǒng)界面.6 .需求變更計劃每做一次項目計劃變更， 都會影響到日后的成本估算、活動順序、行程日期

6、、資源需求及風(fēng)險控管的決策，因此甲乙雙方的項目經(jīng)理、IT經(jīng)理都必須以整體的視野、統(tǒng)一的要求，對變更進行控制、確認(rèn)與紀(jì)錄。而需求變更的控制關(guān)鍵在于建立相應(yīng)的控制組織、變更控制系統(tǒng)以及規(guī)范變更流程。充分做好前期的需求調(diào)研、系統(tǒng)培訓(xùn)等工作。深入企業(yè)一線，全面調(diào)查研究，最大程度地挖掘企業(yè)用戶的潛在需求，發(fā)現(xiàn)可能要需求變更的地方， 讓企業(yè)用戶盡快做出是否要進行需求變更。一般把需求變更或者新需求的確認(rèn)最遲時間定在系統(tǒng)培訓(xùn)階段。也就是說，在系統(tǒng)培訓(xùn)完成后、開始準(zhǔn)備雙線并行前，企業(yè)用戶還可以提出需求變更的申請，但是，當(dāng)系統(tǒng)開始雙線運行時，就不允許用戶再提出需求變更等類似的請求了，如編碼的內(nèi)容和規(guī)則、表單的數(shù)量

7、和格式、數(shù)據(jù)流轉(zhuǎn)和統(tǒng)計方式等，否則就要付出變更的代價。建立變更控制組織系統(tǒng)。項目啟動時，盡可能地與客戶溝通，盡快建立正式的對變更進行控制的組織，通稱變更控制委員會（CCB）,成員可包括雙方高層（掛名）、甲乙雙方的項目負(fù)責(zé)人、相關(guān)的需求負(fù)責(zé)人等，負(fù)責(zé)裁定接受變更內(nèi)容、方法、步驟等。建立該系統(tǒng)的目的是統(tǒng)一管理需求變更和跟蹤變更的狀態(tài)，便于項目組測試人員、開發(fā)人員、系統(tǒng)分析員以及PM 相互之間的溝通和交流。建立變更控制系統(tǒng)目的不是讓用戶不提出變更，而是讓用戶不輕易、隨便的提出變更。嚴(yán)格規(guī)范變更流程。一旦需求分析階段結(jié)束，此后如果用戶要求有新的需求加入即將交付的軟件系統(tǒng)中，甲乙雙方的項目組或變更控制委

8、員會，要根據(jù)角色定義，確定變更流程，規(guī)定嚴(yán)格的變更控制流程，并控制新需求提出的頻率。七 . 項目驗收對互聯(lián)網(wǎng)產(chǎn)品而言，驗收有三層含義：產(chǎn)品功能用例化后，用例執(zhí)行符合預(yù)期與需求吻合，正向操作的用戶體驗良好設(shè)計和前端UI 符合評審的標(biāo)準(zhǔn)第一層應(yīng)該是測試人員應(yīng)該重點關(guān)注的，但在小公司或創(chuàng)業(yè)公司，開發(fā)/ 產(chǎn)品本身就是測試，驗收幾乎等同于最后一次測試。但是無論是否有“測試工程師”這個崗位，產(chǎn)品需求的用例化都是十分必要的，即便通過了專門的測試，產(chǎn)品或領(lǐng)導(dǎo)在驗收時，潛意識也是在執(zhí)行相關(guān)的用例；? 第二層說的是普遍意義上的驗收， 產(chǎn)品通過test平臺測試，部署到了 DEM評臺，由產(chǎn)品需求人員進行 需求驗收，當(dāng)

9、然，內(nèi)部成員、相關(guān)領(lǐng)導(dǎo)都可以進行驗收體驗。對DEMO勺驗收，是“裝成用戶”后對產(chǎn)品的使用，通常是正向操作， 同時除了邏輯和流程，驗收人員會更加關(guān)注用戶體驗； ? 關(guān)于前端UI 的驗收，實際上是對“用戶體驗”的一部分標(biāo)準(zhǔn)化，而驗收的內(nèi)容應(yīng)該與“設(shè)計評審”通過的內(nèi)容相吻合。如果沒有設(shè)計評審，那么標(biāo)準(zhǔn)就是公說公有理了。為了避免這種情況，需要在需求和設(shè)計評審前，界定清楚一些基本的準(zhǔn)則和規(guī)范，比如符合公司的VI體系、符合 W3CM面標(biāo)準(zhǔn)、符合 XXX最直觀的還是所見即所得的“需求設(shè)計交互頁面” ? 這個問題其實很好，好在專門提出了UI 的驗收。 本質(zhì)上是因為開發(fā)對UI 或者對前端、兼容性等很容易忽略，因

10、為這是個“簡單但很花時間”的活兒，做起來沒有成就感。當(dāng)然，如果你們有一套自己的UI 庫或前端框架，那么能夠規(guī)避很多前端上的扯皮，但如果沒有，開發(fā)和前端至少需要50%的精力去搞頁面。提前考慮標(biāo)準(zhǔn)、盡量使用框架、讓代碼公用并易于維護，這是前端和攻城師的硬功夫，否則就沉浸在無盡的BUG中，更不用說驗收了。？至于誰負(fù)責(zé)？團隊中的任意相關(guān)人都可以，前端、開發(fā)、產(chǎn)品、或者你們領(lǐng)導(dǎo)?？傊?，驗收就是質(zhì)量的最后把關(guān)，產(chǎn)品自己都看不過去，臭蟲一堆，千萬不要有任何僥幸心理讓用戶幫著驗收。八 . 迭代計劃做產(chǎn)品 Roadmap 規(guī)劃的時候，要想清楚哪些需求是包括在MVP （Minimal VariableProduct） 的。 也就是說第一版必須抓住目標(biāo)用戶的痛點和切實需求。在時間 金錢 資源有限的情況下，弄明白哪些功能點是必不可少的，對產(chǎn)品推出后成功是至關(guān)重要的。？ 如何弄明白這個問題？那就是從用戶調(diào)研數(shù)據(jù)得來。沒有經(jīng)過用戶驗證過的產(chǎn)品原型一般來說都很難經(jīng)得起推敲，因為這是在設(shè)計師（或者產(chǎn)品經(jīng)理）的假設(shè)上完成的作品，而并不一定會獲得用戶的青睞和肯定。？當(dāng)有了 MVP（第一版）以后，就可以在市場的反饋結(jié)果上做下一步考慮，哪些地方是需要修改的，哪些功能點是需要補充的，哪些地方其實用戶反響并不大可以移除的。把這些點做優(yōu)先級排列，最重要和最緊急的放在下一個產(chǎn)品迭代周期