PRD對于產(chǎn)品經(jīng)理來說至關重要，對于經(jīng)驗尚淺的產(chǎn)品小白來說，一定要注重培養(yǎng)自己的PRD寫作能力。

我17年大學入學后加入了某技術團隊PM組，到現(xiàn)在也有一年多了，最近一段時間，我負責了一個項目從0到1的產(chǎn)品設計和落地跟進。

由于各種因素的影響，目前項目的結果還沒有達到預期，但是在項目過程和復盤中也有一些收獲，以此輸出記錄。

當然，這些是一個沒有工作經(jīng)歷的大學生在校內做產(chǎn)品的一些思考，部分內容可能不適用于公司工作場景，前輩們有好的建議請不吝賜教。

一、寫PRD不要自娛自樂

1. PRD不是寫給自己看的

PRD的主要使用對象有：開發(fā)、測試、項目經(jīng)理、交互設計師、運營及其他業(yè)務人員。開發(fā)可以根據(jù)PRD獲知整個產(chǎn)品的邏輯；測試可以根據(jù)PRD建用例；項目經(jīng)理可以根據(jù)PRD拆分工作包，并分配開發(fā)人員；交互設計師可以通過PRD來設計交互細節(jié)。PRD是項目啟動之前，必須要通過評審確定的最重要文檔。

PRD不是寫給產(chǎn)品經(jīng)理自己看的，這是在初期非常重要的一個認知，不是說在百度上了解到了像上面這些PRD的主要使用對象這么簡單。

說一個我經(jīng)歷的情況，我寫完PRD后自己覺得很滿意，該說的都說了，而且自覺說得很有道理，很清楚，但是交給開發(fā)等對象的時候，他們會吐槽說好復雜，看不懂，這時候我就火了，我辛辛苦苦寫的這份PRD你竟然說看不懂，這是你自己的問題吧。

但是我又考慮了一下，這可能真的是產(chǎn)品經(jīng)理的問題，理由有三：

1. 我的腦子里有這個產(chǎn)品完整的樣貌，所以我在寫的時候會有代入感，這種錯覺讓內容帶有跳躍性，就像教科書上編者知道答案，所以兩三個等式就給出了結果，但是學生看得一臉懵逼；
2. 人總是會習慣從自己的視角出發(fā)來看問題，但是每個人的知識框架是不同的；
3. 寫東西的時候人們會很容易不說人話。

那么我們應該怎么做呢？

2. 換位思考，視目標對象為用戶

明確了目標和問題之后，產(chǎn)品經(jīng)理需要考慮的是我的目標對象想要在這份PRD中獲取哪些信息，如何讓他們更好獲取信息，以及為什么他們需要這樣做來獲取這些信息，換句話說，PRD其實就是你的產(chǎn)品，PRD的使用對象就是你的目標用戶，那么你該如何考慮呢？

1. 用戶通過什么途徑來查看PRD，哪個途徑對他們來說最方便？
2. 用戶打開PRD到找到他們想要的信息的路徑是怎么樣的，如何優(yōu)化他們找到信息的路徑？
3. 用戶如何接受你想要傳達的信息，哪種方式對他們來說最高效？
4. 用戶如何向其他人反饋他的看法和疑惑，怎么讓反饋被更有效地接受？

考慮了用戶使用PRD的完整流程之后，我們就可以開始進行全流程優(yōu)化了。

1. 對于第一個問題，使用Axure寫PRD可以生成在線瀏覽的鏈接，不再受文檔保存的限制。一開始我是用傳統(tǒng)的word文檔來寫PRD，在聽了他們的反饋之后，我開始學習用Axure重新寫了一版，寫對比PRD的工具的文章已經(jīng)很多了，我不再贅述；
2. 對于第二個問題，使用Axure寫PRD可以自定義一些方便查看的交互，比如全局目錄、在修改記錄中添加一個可以直接跳轉的按鈕、可以在PRD和原型間直接跳轉等，只要你考慮得足夠細，可以讓你的用戶在獲取信息時非常爽；
3. 對于第三個問題，使用Axure寫PRD可以讓你非常方便的將內容通過思維導圖等方式進行可視化。這一點個人認為非常重要，將你想要傳達的信息轉化為人們更容易理解的思維導圖等結構圖，可以極大地降低人們信息交流之間的摩擦，當我在用優(yōu)化后的PRD跟程序員們講項目的時候，他們很快就能了解他們要干的事情是什么；
4. 對于第四個問題，使用Axure寫PRD生成的Axshare鏈接提供評論功能，可以在你想要評論的地方生成一個定位標簽，可以直接在評論欄中點擊跳轉查看。

二、5WHY法找出問題的根源

這個項目經(jīng)歷了項目延期、尋找外包、最小可行三個階段，可以說踩了很多產(chǎn)品經(jīng)理的坑，在項目過程中我也在不斷思考并改進，但總感覺沒抓到要點，學習了5WHY法思考框架后，才意識到這些問題其實可以從根源解決。以下是我在復盤時的使用5WHY法的思考過程：

為什么項目會延期？

因為程序員沒有投入時間去做。

為什么他們沒有投入時間去做？

理由如下：

1. 程序員都是學生，在時間和優(yōu)先級上會有沖突，他們選擇優(yōu)先完成自己的事情

為什么項目在他們那的優(yōu)先級不高？

因為沒有給他們明確的重視和壓力（程序員們是另一個技術團隊的，這個項目是團隊老師分配給他們的任務） 。

為什么沒有給他們明確的重視和緊迫的壓力？

因為項目的直接受益者沒有真正重視這個項目。

為什么項目的直接受益者沒有真正重視這個項目？

因為項目的直接受益者不是直接發(fā)起人，也不是需求最痛的人，沒有體會到項目的價值。

所以我應該做的是找團隊老師，跟她講明這個項目的意義和對她產(chǎn)生的價值。

于是我按照這個結論去執(zhí)行，結果團隊真的又平穩(wěn)地動起來了，比原來催他們進度有效多了

2. 程序員看到項目需要實現(xiàn)的功能比較多，覺得要花很多時間，沒有干勁。

為什么他們覺得要花很多時間？因為PRD看起來比較復雜

為什么PRD看起來比較復雜？

因為他們在PRD中看到的是項目的完整結果，而不是階段性可以反饋的目標。所以我應該在開發(fā)過程中使用MVP的模式，讓他們能得到階段性的積極反饋 于是我重新設計了產(chǎn)品MVP的形態(tài)，盡管和完整版相差較大，不能夠徹底實現(xiàn)原先的目的，但是仍僅僅圍繞著我們的核心需求，并且程序員們也覺得輕松了。

因為在信息的呈現(xiàn)方式上太死板。 所以我應該讓信息的呈現(xiàn)更加直觀 在優(yōu)化過程中我通過思維導圖等形式讓重要的信息可視化，讓他們能夠更容易接收。

三、MVP的作用不僅體現(xiàn)在成果，還體現(xiàn)在過程

1. MVP是一個積極反饋

在做這個項目時，我并沒有采取MVP+快速迭代的方式，理由有三：

1. 項目有非常明確的且固定的用戶來源，并不需要投入市場檢驗產(chǎn)品；
2. 項目涉及三個用戶角色，只有三個角色所涉及功能都完善了，才能達到我們做這個項目的初衷；
3. 項目安全性要求較高，在所有功能測試完全之前上線可能得不償失。

那么我為什么又在復盤時改變了主意呢？因為我認為MVP不只是用來做產(chǎn)品驗收的階段指標，還可以給團隊成員一個積極反饋。

人類的“文科生思維”決定了我們更喜歡得到及時反饋。而對于周期較長的項目開發(fā)來說，就是需要給自己一個能跑起來的東西，哪怕這個東西只是給自己看，甚至說為了能讓它跑起來，會需要去多弄一些對于迭代來說冗余的東西，但我能換回來的是一個階段性的積極反饋，這個正反饋循環(huán)能讓團隊成員越來越積極地去給這個東西添磚加瓦來實現(xiàn)下一階段的目標。

2. MVP的正確含義

迭代是重復反饋過程的活動，其目的通常是為了接近并到達所需的目標或結果。每一次對過程的重復被稱為一次“迭代”，而每一次迭代得到的結果會被用來作為下一次迭代的初始值。

根據(jù)維基百科的解釋，其實圖片上方的形式才是理論意義上的迭代，因為它每一次迭代的結果都可以直接用來作為下一次迭代的初始值，而MVP的模式還需要去付出一些額外的資源，最后得到的都是一輛車，上方這種成本才是最低的。

對于我做的這個項目，不需要考慮先發(fā)優(yōu)勢、產(chǎn)品驗證等維度，MVP其實是一個用戶最優(yōu)的概念，而不是一個成本最優(yōu)的概念，但是團隊成員有三個局限：

• 開發(fā)者是學生，屬于兼職參與做開發(fā)，時間和優(yōu)先級上會有沖突；
• 當開發(fā)者看到要實現(xiàn)這么多功能時，好像做完遙遙無期，會產(chǎn)生畏難情緒；
• 看到產(chǎn)品展示成果的周期太長，做著做著會失去興趣，消極推脫。

考慮到這三點，雖然采取MVP的開發(fā)模式會增加他們不必要的工作量，但是權衡比較，這部分工作量遠小于積極反饋所獲得的滿足感，畢竟人不是完全理性的動物。

總結

在學校中做項目，能提升的主要還是作為界面產(chǎn)品經(jīng)理的能力，幾乎不可能養(yǎng)成商業(yè)產(chǎn)品經(jīng)理的意識，界面產(chǎn)品經(jīng)理和商業(yè)產(chǎn)品經(jīng)理最大的區(qū)別是對“成本”概念的理解，而學校會給學生一種成本錯覺，讓人覺得人力成本、試錯成本、技術成本等似乎不太重要。

我希望能夠通過實習去體驗真正的成本意識、資源調度以及復雜系統(tǒng)的協(xié)作機制，能打破自己的認知局限。

如果前輩們能指點一二，歡迎留言交流。

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

題圖來自Unsplash，基于CC0協(xié)議。