APP開發(fā)公司 軟件開發(fā) APP開發(fā) 軟件開發(fā)公司

? ? ? ? 產(chǎn)品和開發(fā)之間的矛盾是眾所周知的，其中一個核心問題是需求文檔寫得不好，導(dǎo)致開發(fā)過程很糟糕，產(chǎn)品和開發(fā)不斷產(chǎn)生矛盾。

當(dāng)時只是做一個產(chǎn)品經(jīng)理，并為此很煩惱。雖然他在大學(xué)里學(xué)習(xí)C和Java，但他對技術(shù)的理解是有限的，很難寫出一個合格的PRD。

然后，我和很多新的產(chǎn)品，如 - 如何在網(wǎng)上搜索周圍的珠三角寫一堆搜索模板，一堆文章。

但是，我們會發(fā)現(xiàn)，沒有足夠的實(shí)用的珠三角細(xì)節(jié)直接應(yīng)用于工作，并確保一個順利的發(fā)展過程。

到現(xiàn)在為止，我終于能夠給珠三角的更多具體細(xì)節(jié)。果然是一吻，罵的是愛，感謝那些曾經(jīng)怨恨過自己的開發(fā)商..

寫一個詳細(xì)的說明，什么樣的影響后，這個珠三角的文件？

一個開發(fā)評估：根據(jù)你上次的珠三角文件，不會是你，而是你。

評價試驗(yàn)：我覺得這樣寫的PRD文檔，今后將不能說明需求（“需求說明”解釋特別開發(fā)之前，便于熟悉的需求的發(fā)展）。

在我采訪過的產(chǎn)品經(jīng)理中，你是一個罕見的合格產(chǎn)品經(jīng)理，你必須感謝那些討厭你的開發(fā)人員。

實(shí)際上，只要每個詳細(xì)描述在根據(jù)該寫入PRD所描述的，開發(fā)過程非常流暢。而如果缺乏流暢性，往往是忽略了描述部分的細(xì)節(jié)。

這則詳細(xì)解釋怎么來的？

簡單：不斷發(fā)展..

正在開發(fā)恨了近一年，6個研發(fā)團(tuán)隊(duì)接觸后，我收集到足夠的積分來開發(fā)恨我的注意，以及不斷完善的過程中，梳理出此詳細(xì)說明。從此，一切變得順利..

下面就來具體講解：

一、基本注意點(diǎn)

1. 不同團(tuán)隊(duì)需要不同的PRD

珠三角是開發(fā)，測試看，本質(zhì)上是一個產(chǎn)品，用戶是產(chǎn)品開發(fā)和測試。

因此，PRD是根據(jù)不同團(tuán)隊(duì)給出的具體的基本原則，

沒錯，珠三角是不是一招鮮吃遍天。當(dāng)你接觸到足夠多的團(tuán)隊(duì)時，你會發(fā)現(xiàn)對珠三角的需求因團(tuán)隊(duì)而異：

有些球隊(duì)需要一個非常詳細(xì)的解釋 - 一般比較成熟穩(wěn)定的開發(fā)團(tuán)隊(duì)。

有些團(tuán)隊(duì)專注于深入了解您的需求，而不是詳細(xì)描述是否珠三角本身不夠 - 一般的創(chuàng)業(yè)團(tuán)隊(duì)。

2. 一些注意點(diǎn)

另外，還有一些注意點(diǎn)：

主要是珠三角詳細(xì)的業(yè)務(wù)產(chǎn)品。因?yàn)檫@張筆記來自于實(shí)際工作經(jīng)驗(yàn)，作者沒有做過AI，大數(shù)據(jù)，區(qū)塊鏈等高科技產(chǎn)品，更多的是商業(yè)產(chǎn)品..

珠三角詳細(xì)信息非常詳細(xì)，但珠三角并不意味著你會這么詳細(xì)。如上所述，不同的團(tuán)隊(duì)需要不同的珠三角。但是你可以PRD比較簡單，所以思維功能，考慮到為了避免平穩(wěn)的發(fā)展過程這個細(xì)節(jié)的內(nèi)容。

珠三角只詳細(xì)說明功能的技術(shù)可行性，而不是要求的合理性-珠三角的中心目的，可在其他階段考慮。

二、PRD文檔寫作詳細(xì)說明

首先解釋一下：一些基本的PRD模塊，我們不能說 - 比如：“歷史修改記錄的版本”，這些“需求背景說明”一節(jié)中眾所周知的。

我們只談珠三角的核心部分-如何充分詳細(xì)和準(zhǔn)確地描述每個函數(shù)。

至于其他的模塊，我們把一個鏈接在文本的末尾，您可以下載自己，一目了然明白。

1. 顯示規(guī)則

顯示規(guī)則：與顯示相關(guān)的規(guī)則。

下面是一個展示規(guī)則的橫幅部分的例子：

數(shù)據(jù)的值是空的，如何處理：例如，對應(yīng)于背景場橫幅圖像是空的，那么如何顯示？

顯示數(shù)量：要顯示多少幅橫幅圖片？如何處理超出數(shù)量限制？橫幅標(biāo)題顯示多少字？如何處理超出數(shù)量限制？

排序規(guī)則：如何對banner顯示的圖像序列進(jìn)行排序？？他們是由一個場后臺排序？

2. 交互規(guī)則

交互規(guī)則：相應(yīng)的描述交互設(shè)計(jì)。

比如下圖的banner部分，至少要考慮：

自動輪播的時間間隔。

左右滑動時的交互效果。

點(diǎn)擊互動效果——如點(diǎn)擊XX頁面..

3. 默認(rèn)規(guī)則

對一些默認(rèn)情況的說明。

規(guī)則的默認(rèn)值：XX的默認(rèn)值，xx是空當(dāng)值YY。

默認(rèn)顯示規(guī)則：默認(rèn)顯示xx時.。則顯示yy。

默認(rèn)的交互規(guī)則：在導(dǎo)航欄中，選擇一個默認(rèn)標(biāo)簽 - 如家部分的數(shù)字，默認(rèn)情況下選中該選項(xiàng)卡的底部是“讀”，在頂部導(dǎo)航欄默認(rèn)選擇“的文章。”

其他的默認(rèn)情況說明。

4. 邊界情況

對各種邊界情況的考量，防止出現(xiàn)異常。

比如：

值規(guī)則：當(dāng)字段為空時，如何獲得值？

顯示規(guī)則：

當(dāng)沒有什么時，當(dāng)前頁面顯示什么頁面？怎么顯示當(dāng)前字段沒有內(nèi)容？

可能會影響性能的列表顯示了數(shù)量太大，待談判行動與發(fā)展。

交互規(guī)則：

限制操作的數(shù)量：是否要限制？要限制，多少次？？如何提醒達(dá)到上限后？例如，輸入錯誤的密碼達(dá)到極限后，就必須凍結(jié)一段時間。

輸入內(nèi)容限制：限制，多少次？達(dá)到上限后怎樣提醒？？比如輸入一個手機(jī)號碼限制為11位，之后怎么處理？？

后退按鈕：如果頁面是空的，然后返回到哪里？

提示：提示消失多長時間？就像吐司小費(fèi)一樣，你會在3秒后消失嗎？

編輯：是否可以編輯？當(dāng)涉及到編輯，清楚地描述編輯成功后的相互作用。

例外：如何處理異常？

當(dāng)網(wǎng)絡(luò)異常時，它會顯示什么？

當(dāng)服務(wù)器忙時，顯示什么？

當(dāng)產(chǎn)品下架/頁面已被刪除，等等，其顯示的內(nèi)容？

當(dāng)你被惡意評論或惡意刷評分時，它會顯示什么？

幾個不同狀態(tài)的綜合考慮：

登錄/注銷：例如，如果不記錄點(diǎn)贊美。

允許/不允許：例如，未經(jīng)授權(quán)的時間限制是否顯示？如何互動？

版本兼容性考慮——如果是app，需要考慮不同版本之間的兼容性，web端一般不需要考慮這個..

這是珠三角的核心要考慮，它是站著考慮發(fā)展的角度。

當(dāng)然，由于示例有限，以上內(nèi)容不完整（如下所列），所以組織一個思維導(dǎo)圖下載鏈接，大家可以參考..

例如：APP結(jié)束時，程序的小端，網(wǎng)頁端是不同的，各有其自身的角度關(guān)注。

例如：流程上的注意事項(xiàng)，如果需要考慮設(shè)計(jì)，可以明確標(biāo)注本版本涉及的變更，讓設(shè)計(jì)更快的知道設(shè)計(jì)在哪里；也應(yīng)該給出設(shè)計(jì)的文案，否則設(shè)計(jì)要輸入相應(yīng)的內(nèi)容等等..

例如：與線的功能，盡量遵循現(xiàn)有功能的線一致，很容易開發(fā)，可以降低開發(fā)成本。此時最好明確在線功能的定位，便于開發(fā)并找到相應(yīng)的功能..

對于強(qiáng)大的數(shù)據(jù)的相關(guān)性，往往更難以發(fā)展，你應(yīng)該對性能給予更多的考慮。

如果更改頻率低，寫死比在后臺添加更好。

一般特征可以收集并放在一個文檔中，以便后續(xù)使用相應(yīng)的功能可以直接鏈接到開發(fā)中查看前面的文檔描述..