中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

敏捷開發(fā)，并不意味著產(chǎn)品經(jīng)理在寫PRD的時候就可以偷工減料，相反，這更考驗產(chǎn)品經(jīng)理的功力，因為產(chǎn)品經(jīng)理需要精簡信息，將真正的有效信息簡單且清晰地傳達給PRD閱讀者，從而真正達到敏捷開發(fā)的目的。

敏捷開發(fā)這個詞越來越為大家所熟知了。簡單來說，敏捷開發(fā)就是以用戶需求為導(dǎo)向，通過快速開發(fā)將產(chǎn)品投入市場，獲取市場反饋，從而快速迭代、優(yōu)化升級、循序漸進的開發(fā)方法。

http://www.aharts.cn/rp/211554.html

http://www.aharts.cn/rp/389092.html

2 產(chǎn)品全局結(jié)構(gòu)圖和重要流程的圖示不可省略

再精簡的PRD仍舊不可或缺結(jié)構(gòu)圖和流程圖。

首先，全局結(jié)構(gòu)圖，作為整個PRD的骨架，可以讓PRD閱讀者對產(chǎn)品的總體功能構(gòu)成一目了然，這樣在接下來繼續(xù)閱讀每個部分的原型圖和對應(yīng)的說明文檔時，思路能夠更加清晰。就像每本書都會有目錄一樣，目錄是讓你最快了解這本書大概的內(nèi)容的捷徑。

其次，一些基礎(chǔ)功能的流程圖（如登錄注冊之類），我們是可以有選擇性地不將其呈現(xiàn)在PRD里的；而那些實現(xiàn)重要業(yè)務(wù)需求的功能流程，我們還是必須將其用流程圖清晰展示出來的。這樣即使在需求會議后，程序員對某個流程比較模糊了，也可以翻一翻PRD來確認。

所以，重要功能的流程圖，可以說是一份PRD的靈魂，是千萬不可以省略的（為了避免全是文字，產(chǎn)生視覺疲勞，以用戶端的優(yōu)惠券功能為例，特附優(yōu)惠券總體結(jié)構(gòu)圖和優(yōu)惠券功能下的一個流程圖）。

（優(yōu)惠券功能總體結(jié)構(gòu)圖）

（獲取優(yōu)惠券方式： “搖一搖”流程）

3 重要名詞需要有清晰簡潔的定義

并不是每個名詞都需要寫解釋、下定義！

我記得剛?cè)胄袝r，第一次寫產(chǎn)品說明文檔，我甚至還寫了“用戶”二字的定義。當時的PRD是直接參照公司產(chǎn)品前輩的，他之前寫了“用戶”的名詞解釋，于是我也照抄了過來。

（反例：曾經(jīng)我寫的名詞解釋）

現(xiàn)在想想覺得略為搞笑。因為這個詞的定義在APP 1.0版本的時候已經(jīng)確認過了。而且，這個名詞應(yīng)該屬于比較容易理解、不容易產(chǎn)生歧義的范疇。所以我相信，像類似這樣的詞的解釋，對于PRD閱讀者來說就是一個無用信息。

好吧。說正事。那么什么時候你需要寫名詞解釋呢？什么詞才是重要的詞呢？

這個名詞在產(chǎn)品設(shè)計中第一次出現(xiàn)且是業(yè)務(wù)需求的重點

例如，當你在設(shè)計優(yōu)惠券功能時，那么“優(yōu)惠券”這個名詞就是一個重要名詞?？赡艽蠹視f：“不對啊，優(yōu)惠券不是很好理解嗎？需要名詞解釋嗎？”我可以明確告訴你，在這個場景下，需要！這是我之前在一家O2O公司工作時，曾寫過的定義：“優(yōu)惠券是指由xxx平臺發(fā)行的，用戶使用XXX APP 結(jié)賬時，用于抵扣訂單金額的電子券”。這個定義指出了幾點關(guān)鍵信息，一優(yōu)惠券的發(fā)行方，僅僅可以使平臺，不能是平臺的商家；二使用場景是用戶在結(jié)賬時；三作用是抵扣訂單金額；四優(yōu)惠券非實體券，是電子券。

容易混淆的名詞

讓我們再來舉個例子。比如，“連鎖店”這個詞已經(jīng)在之前的設(shè)計中出現(xiàn)過，也解釋過了。但是在你當前的產(chǎn)品設(shè)計中，有了一個“商戶組”的概念。乍看之下，真的會讓人云里霧里，有點懵。光從字面理解，好像都是指代一組商戶，具體的區(qū)別并不是那么清楚。那么這個時候，你需要將兩個概念最好放在同一個頁面中以對比的方式解釋清楚，以免造成程序員的大腦短路。

（對比方式的名詞解釋）

為了能真正實現(xiàn)敏捷開發(fā)，請?zhí)崆斑^濾掉不重要的名詞解釋，把頁面的位置留給那些重要的名詞吧！

4 你還需要把規(guī)則以及異常情況都寫上

看到這里，是不是覺得，其實還是要寫挺多東西的呢？沒辦法，規(guī)則和異常情況這二者都是非常重要、不可省略的。其實產(chǎn)品經(jīng)理的PRD把規(guī)則和異常情況寫得越清晰，程序員在開發(fā)時，就能越順利。在你把PRD交給技術(shù)同學(xué)后，你總不希望他們?nèi)晃鍟r的來問你“這個列表具體一次加載多少個商戶”“如果沒有匹配的信息，需要給什么樣的反饋呢”之類的問題吧？這樣首先拖慢了開發(fā)的進度，其次也會顯得你作為一個PM非常的不專業(yè)！

規(guī)則說起來，其實是比較繁雜的一個東西，除了剛剛舉例的“商列表頁一次加載多少商戶”，你可能還要寫許多細致的規(guī)則如，訂單編號的規(guī)則是什么、默認排序的規(guī)則是什么等等。這里就不一一舉例了。相信每個做產(chǎn)品的同學(xué)都是明白的，如果一開始規(guī)則沒寫清楚，需求評審會時，就容易被問得啞口無言。

那么異常情況呢，這個更是關(guān)鍵。千萬不要小看了異常情況。一個異常情況下（特別是用戶端），如果沒有友好的指引，你的用戶很快就能流失殆盡。舉個非常慘痛的例子，還是之前做O2O的公司。用戶在支付完成以后，由于APP沒有收到某支付平臺的回調(diào)信息，所以用戶看到的界面仍舊還是未完成支付的訂單提交頁面。但是用戶的手機確實能查詢到扣款信息。這個時候，那就是非常尷尬了！頁面一動不動，也沒有任何反饋。那究竟用戶算不算付款了呢？這就是由于在產(chǎn)品設(shè)計中，沒有考慮到支付接口回調(diào)異常這個問題，而漏掉了與此相關(guān)的產(chǎn)品設(shè)計。據(jù)當時地推的同事反饋，因為用戶無法取消訂單，而頁面又沒有任何反饋，用戶不得不在商戶那里多呆了半個小時，就為了等支付回調(diào)。

我已經(jīng)用血和淚的教訓(xùn)告訴了大家，敏捷開發(fā)中，切記要把規(guī)則以及異常情況都寫上?。。?/p>

5 記錄下你的PRD變更

最后一點，簡單提一下就可以了。如果提交的原型和對應(yīng)的PRD更新了，記住把變更的內(nèi)容寫上。嗯，就是我們常說的，版本修改信息。需要的字段有：修改時間、修改內(nèi)容、備注、修改人。以及，把版本修改信息放在你原型的第一頁。

總而言之，敏捷開發(fā)，并不意味著產(chǎn)品經(jīng)理在寫PRD的時候就可以偷工減料，相反，這更考驗產(chǎn)品經(jīng)理的功力，因為產(chǎn)品經(jīng)理需要精簡信息，將真正的有效信息簡單且清晰地傳達給PRD閱讀者，從而真正達到敏捷開發(fā)的目的。

P.S：我也是正在學(xué)習(xí)中的產(chǎn)品，以上僅為個人經(jīng)驗，若有錯誤的地方，歡迎指正。

本文由 @Mika 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。