互聯(lián)網(wǎng)產(chǎn)品的開發(fā)流程

互聯(lián)網(wǎng)新產(chǎn)品的開發(fā)流程1. 戰(zhàn)略規(guī)劃我沒有參與過戰(zhàn)略方向的制定，僅有幸以旁聽的形式進行過幾次戰(zhàn)略討論，這些討論會與其說是戰(zhàn)略討論會，不如說是公司管理層極力說服大家朝著某個戰(zhàn)略方向走，也就是戰(zhàn)略思想灌輸。2. 前期分析這個階段需明確項目的主體目標，主體目標的明確需通過一系列的分析得出，而不是憑空而來。首先要了解整個領(lǐng)域的情況，競爭對手，用戶，甚至需要關(guān)注一下國家政策。對于互聯(lián)網(wǎng)產(chǎn)品來說，了解競爭對手的成本相對較低，通過對競爭對手的分析，可以發(fā)現(xiàn)對手做的好的和不好的地方，可以為自己的產(chǎn)品節(jié)省大量時間。其次發(fā)現(xiàn)項目的優(yōu)勢和劣勢，可考慮那些優(yōu)勢會是帶來商業(yè)利益的關(guān)鍵點，那些劣勢會阻礙項目進程，考慮如何去克服，盡量避免樂觀思維。最后，盡管不是這階段最重要的，可與技術(shù)專家溝通項目目標，考慮技術(shù)選型。理想情況是，盡可能利用現(xiàn)有的東西，尤其是開源產(chǎn)品。另外，技術(shù)專家經(jīng)過初步分析后，可能會考慮人員招聘的需要。3. 需求設(shè)計3.1. 需求概念設(shè)計這階段的開始往往是伴隨著頭腦風暴會，選出一些靠譜的功能，然后由產(chǎn)品經(jīng)理給出一個功能范圍定義，最好能附上部分核心功能的交互流程。通過需求確認會議，找上老大們敲定下來項目的功能范圍，需要有會議記錄，否則會出現(xiàn)項目進行中會有老大們跳出來要求改方向的事故。3.2. 正式立項召開立項會議，確定項目負責人和項目組成員，并由產(chǎn)品經(jīng)理根據(jù)概述文檔或MRD向老大們和項目組成員闡述本項目的主要任務(wù)內(nèi)容和目標，描述產(chǎn)品是什么，為什么要做成這樣，能解決用戶的什么問題，市場優(yōu)勢是什么，未來發(fā)展預(yù)期等等。幫助項目組成員理解項目的目的、目標和意義，對產(chǎn)品達成統(tǒng)一認識。4. 需求確定根據(jù)以上階段積累的產(chǎn)品藍圖，產(chǎn)品經(jīng)理撰寫一系列的文檔，主要產(chǎn)出物是PRD和交互原型。4.1. PRD（ProductRequirementDocument產(chǎn)品需求文檔）PRD側(cè)重對產(chǎn)品的產(chǎn)品功能和性能的說明，相對于“概述文檔”中的同樣內(nèi)容，要更加詳細，并進行量化。簡單來說，這份文檔的作用就是文字化需求“怎么”去開發(fā)，對產(chǎn)品涉及的方方面面：流程圖（Visio）、表格（excel）、邏輯、實現(xiàn)中需要注意的事項、小細節(jié)等進行盡可能詳細的描述；簡而言之，這份文檔是可以無所不包的，目標是幫助大家規(guī)避開發(fā)風險，在不開發(fā)任何一行代碼的情況就已經(jīng)清晰地認識到全部的產(chǎn)品目標、開發(fā)過程和工期、實現(xiàn)難度等等。4.2. 交互原型對于開發(fā)人員而言，也許一份好的PRD文檔足以讓他們立刻開始編碼工作，但就整個項目來看，技術(shù)層面的開發(fā)風險（我們是否在正確的開發(fā)產(chǎn)品）往往能夠通過經(jīng)驗、技術(shù)化手段來規(guī)避；產(chǎn)品風險，或者稱之為體驗風險（我們是否在開發(fā)正確的產(chǎn)品）我們開發(fā)的產(chǎn)品用起來究竟“怎樣”，就需要通過圖像化的“文檔”，幫助大家了解到產(chǎn)品最終在用戶手里的使用體驗。交互設(shè)計師根據(jù)產(chǎn)品需求做出交互原型，真實再現(xiàn)用戶交互過程，并與PM進行內(nèi)部評審。（視情況，如沒有交互設(shè)計師此步驟由產(chǎn)品經(jīng)理與美工配合完成）4.3. 需求評審相關(guān)領(lǐng)域的顧問（即有豐富經(jīng)驗者：產(chǎn)品專家、技術(shù)專家，不是項目團隊成員）、PM和項目組成員（如項目組中沒有美術(shù)還可以邀請他們參加）參與的評審PRD和交互原型的會議，一般項目經(jīng)理、產(chǎn)品負責人需參與會議。會議必須有主持，并在會后出MEMO（備忘）或PRD更新說明。項目組中的開發(fā)人員接到PRD后，需評估完成開發(fā)的大致時間，以及任務(wù)分解安排。4.4. 界面和視覺設(shè)計由美工（視覺設(shè)計師）設(shè)計頁面風格、布局、關(guān)鍵界面等，交由產(chǎn)品經(jīng)理和交互設(shè)計師進行效果圖評審。效果圖通過后，美工產(chǎn)出效果圖、layout和資源給前端開發(fā)工程師。前端開發(fā)工程師根據(jù)設(shè)計頁面切圖，編寫HTML，CSS，JS源代碼。5. 開發(fā)和測試階段5.1. 系統(tǒng)設(shè)計在編碼之前，開發(fā)人員應(yīng)視其系統(tǒng)需要，進行概要設(shè)計、數(shù)據(jù)庫設(shè)計，并進行內(nèi)部討論和評審，邀請顧問參與。除系統(tǒng)設(shè)計的基礎(chǔ)思路外，需考慮差異化設(shè)計，保證互聯(lián)網(wǎng)產(chǎn)品的安全性、可靠性、可擴展性等?；ヂ?lián)網(wǎng)是一個快速變化的世界，我們所面臨的用戶、環(huán)境每天都在改變，這就要求系統(tǒng)設(shè)計能夠適應(yīng)這種情況，為產(chǎn)品開發(fā)做到快速迭代打好基礎(chǔ)，降低因產(chǎn)品版本升級帶來的系統(tǒng)重構(gòu)風險。5.2. 程序開發(fā)開發(fā)人員對文檔有疑問或不理解，需與產(chǎn)品經(jīng)理進行溝通，了解其真實涵義，不得以任何理由私自更改已確定的PRD、原型、設(shè)計圖和資源等。確有功能需做調(diào)整，開發(fā)人員需與產(chǎn)品經(jīng)理共同協(xié)商完成。5.3. （alpha最初）測試在開發(fā)小組內(nèi)部進行，測試的方法也較多，黑盒、白盒、壓力、應(yīng)力等。此階段應(yīng)完成80%以上的需求開發(fā)，測試以PRD為準。測試完成后，收集反饋，修復(fù)BUG，優(yōu)化流程。5.4. 集成測試測試工程師根據(jù)PRD、交互原型和效果圖分析測試需求，指定測試計劃，撰寫測試用例。在開發(fā)完成測試后，根據(jù)測試用例開始集成測試。5.5. 產(chǎn)品驗收測試工程師宣布產(chǎn)品通過集成測試后，申請產(chǎn)品經(jīng)理驗收。如產(chǎn)品與PRD和交互原型相差較大，產(chǎn)品負責人有權(quán)不接受產(chǎn)品，責任由開發(fā)部門負責。6. 產(chǎn)品發(fā)布產(chǎn)品經(jīng)理驗收通過后，測試工程師安排產(chǎn)品在生產(chǎn)環(huán)境進行部署的計劃。系統(tǒng)發(fā)布需要有嚴格的發(fā)布規(guī)范和工具來支持，尤其要支持“版本恢復(fù)”功能，一旦新版本出現(xiàn)問題，可以立刻能恢復(fù)到之前的穩(wěn)定版本。7. 系統(tǒng)運維系統(tǒng)運維是指系統(tǒng)的日常管理和維護，這包括對服務(wù)器硬件、網(wǎng)絡(luò)、帶寬方面的維護，以及軟件系統(tǒng)的日常管理。在互聯(lián)網(wǎng)項目中，系統(tǒng)運維的核心工作是對服務(wù)器和網(wǎng)絡(luò)的管理。在項目開始的時候，需要進行硬件選型、網(wǎng)絡(luò)規(guī)劃；在項目上線后，要對硬件和網(wǎng)絡(luò)實施不間斷的監(jiān)控，并及時進行調(diào)整。往往，很多開發(fā)人員不具備系統(tǒng)級的知識和經(jīng)驗，因此他們所開發(fā)的程序經(jīng)常對這些方面的問題考慮不足。這就需要運維團隊的系統(tǒng)專業(yè)人員給出建議。關(guān)于系統(tǒng)對CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等方面的要求，運維團隊需要和開發(fā)團隊緊密合作，來不斷完善系統(tǒng)。8. 產(chǎn)品運營隨著產(chǎn)品的上線，運營工作也隨之開始。運營的核心目的是讓產(chǎn)品活的更好、活的更久。產(chǎn)品運營通過使用產(chǎn)品內(nèi)部資源，盡可能留住用戶，提高活躍用戶數(shù)，引導(dǎo)用戶行為將其轉(zhuǎn)化為產(chǎn)品的商業(yè)利益。產(chǎn)品經(jīng)理在該階段