本文主要介紹0-1背景產(chǎn)品的產(chǎn)品實現(xiàn)過程。最近，我負責(zé)公司的后端項目。我是一個技術(shù)轉(zhuǎn)型發(fā)展。以前的大部分職責(zé)是后端管理系統(tǒng)。我希望與您分享一些個人經(jīng)歷??。

后端產(chǎn)品通常用于辦公室使用或內(nèi)部人員。實施過程通常包括以下步驟：需求研究，原型設(shè)計，需求評審，開發(fā)，測試和在線。本文重點介紹前期開發(fā)需求研究。原型設(shè)計和要求審查。

需求研究

對后端產(chǎn)品的需求相對清晰，大部分需求來自領(lǐng)導(dǎo)層，一小部分需求來自各個部門，如市場，客戶服務(wù)，人員，財務(wù)等。

在需求研究過程中，有必要闡明研究的目的，如客戶管理功能。營銷部門和客戶服務(wù)部門的工作人員將更加關(guān)注新注冊的客戶，今天使用的客戶，我所依據(jù)的客戶等。對于研發(fā)部門和職能部門，可能只是看看客戶記錄因為他們不需要關(guān)注客戶的具體跟進。在與不同部門的人員進行溝通時，必須有一個重點，員工不注意或幾乎不使用的功能也是無味的，他們無法幫助實際工作。

在需求研究之后，有必要對需求進行梳理。收集的要求是分散的。您可以使用XMind（或MindManager）軟件繪制思維導(dǎo)圖，執(zhí)行簡單的邏輯排序，對相關(guān)服務(wù)或功能進行分類，然后使用小于總分鐘來細化模塊。模式。我們以前的背景分類是根據(jù)業(yè)務(wù)線劃分的，比如移動，PC端產(chǎn)品，然后會有產(chǎn)品模塊下的客戶管理，訂單管理等，以及后來的重新規(guī)劃背景，使用功能劃分，如客戶管理，然后將有移動產(chǎn)品客戶，PC端產(chǎn)品客戶等模塊下。這兩種模式之間沒有對錯，因為后續(xù)考慮了角色權(quán)限，并且可以根據(jù)功能輕松規(guī)劃權(quán)限。

在對需求進行排序后，我們必須開始分類并學(xué)會區(qū)分真假需求。例如，用戶反饋需要添加一個函數(shù)，而不是盲目添加函數(shù)，考慮到這個函數(shù)的用途，有時候他需要B函數(shù)來實現(xiàn)C函數(shù)，那么最好直接提供一個C函數(shù)。對需求進行分類后，應(yīng)根據(jù)時間情況規(guī)劃優(yōu)先級，可根據(jù)四象限規(guī)則進行定義。

原型設(shè)計

設(shè)置框架后，頁面原型設(shè)計開始。目前使用的軟件是Axure。后端產(chǎn)品的終端主要是PC或筆記本電腦。 Axure更強大，更適合PC原型設(shè)計。

在后臺產(chǎn)品原型設(shè)計過程中，我們必須掌握以下幾點：考慮場景的使用，功能強，行為路徑短，效率高，并且存在容錯機制。具體到頁面細節(jié)，需要注意大小適應(yīng)，數(shù)據(jù)添加和刪除，字段長度，必填字段，交互式樣式等。如果有設(shè)計技巧，可以在頁面美觀的原型上進行優(yōu)化，輸出是保真度和高保真原型。

考慮使用場景：就分頁功能而言，我們之前完成的背景通常顯示在20頁，最多50條記錄。當我設(shè)計背景時，我也想根據(jù)這個頁面進行錄制。我只會在與領(lǐng)導(dǎo)討論后知道，但只有客戶數(shù)量為數(shù)萬，每頁顯示20條根本不符合使用情況的記錄。每頁至少有100或200條記錄可以滿足需求。

功能強大：例如，客戶管理，除了查詢，添加，編輯，刪除，詳細信息外，還要根據(jù)業(yè)務(wù)情況考慮是否需要添加任務(wù)，添加訂單，后續(xù)跟蹤，日志記錄等。最好考慮業(yè)務(wù)的所有方面并關(guān)注它。

行為路徑應(yīng)該很短：用戶可以通過1或0次交互來實現(xiàn)目標，所以不要讓他進行2次或更多次交互來實現(xiàn)目標。例如，要查看客戶列表，客戶服務(wù)部門和營銷部門會更加關(guān)注我的客戶。加載頁面時，默認情況下會加載我的客戶數(shù)據(jù)并突出顯示。不要先顯示所有客戶，而是單擊我的客戶以查看所需的數(shù)據(jù)。

效率很高：當這通常用于大數(shù)據(jù)時，有必要考慮加載速度，系統(tǒng)性能問題以及技術(shù)級別的許多優(yōu)化。

必須有容錯機制：后端系統(tǒng)必須具有容錯機制。不能說用戶的操作錯誤或放錯地方，無法恢復(fù)。例如，對于禁用按鈕，單擊該按鈕時，會提示是否確認禁用，禁用后將產(chǎn)生什么效果，并嘗試在操作前給出相應(yīng)的提示。

原型設(shè)計還需要輸出PRD文檔。通常需要60％的時間來繪制原型，40％的時間來編寫所需的文檔。然而，PRD文檔實際上比原型更重要，因為原型具有許多交互，功能細節(jié)等。需要由PRD描述。在需求文件方面，主要是要清楚地描述要求，規(guī)則明確，邏輯嚴謹，格式可以參考原始公司。

需要審核

需求審核分為內(nèi)部審核和團隊審核。

內(nèi)部審查通常，參與者有產(chǎn)品總監(jiān)和產(chǎn)品經(jīng)理。主要目的是針對可疑點。提出了一些可行的解決方案，并做出了決定。另一種是查看存在問題的原型和文檔，然后進行優(yōu)化。例如，列表項的選擇，PC端產(chǎn)品支持是可選的，可以填寫，手機端只支持可選的屏幕尺寸，這顯然是不合理的。如果考慮一致性，則移動終端需要支持。

團隊審核一般參與者包括產(chǎn)品經(jīng)理，項目經(jīng)理，測試主管和設(shè)計師（需要設(shè)計時）。主要目的是討論產(chǎn)品流程和產(chǎn)品實現(xiàn)。為了確保產(chǎn)品著陸，項目經(jīng)理還應(yīng)根據(jù)產(chǎn)品的原型進行設(shè)計。考慮技術(shù)可行性。特別是在優(yōu)化現(xiàn)有功能時，有必要考慮不破壞原始數(shù)據(jù)結(jié)構(gòu)。項目經(jīng)理需要控制一些產(chǎn)品細節(jié)，例如字段長度，必填字段等，并且需要與原始產(chǎn)品設(shè)計規(guī)則兼容。 。

發(fā)展

原型設(shè)定完成后，由設(shè)計師設(shè)計。一般的后端產(chǎn)品由內(nèi)部人員使用，設(shè)計部分相對較弱。開發(fā)可以基于原型或設(shè)計草案進入開發(fā)階段。項目經(jīng)理應(yīng)根據(jù)產(chǎn)品原型規(guī)劃項目（研發(fā)一般區(qū)分前端和后端，調(diào)度周期盡可能詳細）。產(chǎn)品經(jīng)理應(yīng)遵循項目進度表，促進產(chǎn)品著陸，及時了解工作進度。

在開發(fā)過程中，如果需求發(fā)生變化，及時通知相關(guān)負責(zé)人，分享文檔并及時更新，避免開發(fā)人員獲取舊版本的原型或文檔進行開發(fā)和重復(fù)勞動。

測試

在開發(fā)者函數(shù)開發(fā)之后，第一步是確保單元測試通過（開發(fā)人員通常在開發(fā)服務(wù)器上執(zhí)行單元測試），然后進行測試。測試人員可以根據(jù)具體情況根據(jù)業(yè)務(wù)線，功能模塊等進行測試，測試人員通常在測試服務(wù)器（模擬在線服務(wù)器）上進行測試。產(chǎn)品經(jīng)理也在此階段參與測試，重點關(guān)注產(chǎn)品的流程實施是否合理。

測試期間提交的錯誤應(yīng)及時修復(fù)。產(chǎn)品還應(yīng)該注意bug的數(shù)量和修復(fù)的進度，需要定義什么是需求，哪些是bug。我們之前的處理是在測試階段16xx177b 00之前修復(fù)bug的同一天。一方面，工作進展得到保證，統(tǒng)計數(shù)據(jù)也很方便。

上網(wǎng)

測試人員通過測試后，產(chǎn)品人員進行了最終驗收測試。如果沒有問題，項目將釋放在線環(huán)境。最后，測試人員和在線環(huán)境的開發(fā)再次進行了驗收測試，并在確認正確后，在線正式公布。

以上是個人分享背景系統(tǒng)的個人經(jīng)歷，歡迎大家一起溝通，共同進步！

本文最初由@lihuakai發(fā)布。未經(jīng)許可，禁止復(fù)制。

該地圖來自Pexels，基于CC0協(xié)議

« 為什么您的網(wǎng)站沒有賺錢？原因在于 | Scallion 2018卓越領(lǐng)導(dǎo)力訓(xùn)練營與您一起開啟體驗式學(xué)習(xí)之旅 »