PRD對于產品經理來說至關重要，對于經驗尚淺的產品小白來說，一定要注重培養自己的PRD寫作能力。

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

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

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

一、寫PRD不要自娛自樂

1. PRD不是寫給自己看的

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

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

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

但是我又考慮了一下，這可能真的是產品經理的問題，理由有三：

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

那么我們應該怎么做呢？

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

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

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

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

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

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

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

為什么項目會延期？

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

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

理由如下：

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

為什么項目在他們那的優先級不高？

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

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

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

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

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

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

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

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

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

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

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

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

三、MVP的作用不僅體現在成果，還體現在過程

1. MVP是一個積極反饋

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

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

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

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

2. MVP的正確含義

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

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

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

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

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

總結

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

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

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

本文由@ Cemeworm 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。