你会先写PRD，还是先画原型？
道路很遠，
腳步更長；
肩挑凡世，
拳握初心。
我們要在發展中解決問題。
大概是2020年初，我和公司領導拜訪一國企的某處長，向他匯報我們的系統建設，他是我們的甲方，也是我們雙方合作的主導者，那次給我留下了深刻的印象，也徹底改變了我對國企領導的幼稚偏見。
面對我們系統仍存在的不足，面對諸多利益的交錯，面對前進與后退的選擇，面對可能不良后果的影響，他一錘定音，說了上面那句話。
最終，我們并沒有辜負他的信任，準時交付了產品，合作很成功，但當初過程時壓力巨大，差點功虧一簣，多虧他幾次力挽狂瀾。
事實上，他也不僅僅是因為信任，我后來理解，更多的可能是來自經驗的哲學，是在閱歷和經驗的積累上，對于解決問題的自信和掌控力。
時至今日，每當需求評審遇到左右為難的問題時，或者說團隊建設存在什么沖突，我都會說：我們在發展中解決問題。（競品分析 · 拿來主義）
這句話，我覺得不是妥協，更不是放棄，而是敏捷思維下的聚焦注意力，永遠抓住主要矛盾，堅定地擁抱效率。
當下，敏捷思維大家都說爛了，但據鏡同學鷹眼觀察，真正用心體會和遵循的，屬實并不多。
很多時候，我們都是人云亦云，然后匆匆行事，甚至來不及思考。
這兩天，有不少產品同學加我微信，咨詢我需求文檔、原型設計的事兒，好在鏡同學峽谷游走小十年了，原型從未掛機，需求說明文檔更是家常便飯，始終堅定不移地走群眾路線。
這不，前天有個新朋友問我一個老問題：需求設計時，先寫需求文檔，還是先畫原型？
這是一個好問題，我很想談談我的想法。
第一、談下我對需求說明文檔、原型設計的理解。
從落地的成果價值上來看，我認為原型設計的重要作用在于需求傳遞，是向上下游不同崗位評審產品需求的重要載體。
產品功能、交互設計、業務邏輯、頁面元素等等，通過原型設計，可以最高效率的完成需求的傳遞，降低理解成本和失真率。
或者說，原型設計的重要功能是偏向對外的需求傳遞。
那么，回過頭來說，需求文檔呢，拋開便于追溯問責、撕逼時有依據這些段子不談，我以為需求說明文檔的價值其實可以體現在兩部分：對外的需求傳遞和對內的需求指導。
對外的價值在于是需求理解時的依據，評審會畢竟不可能照顧很多細節，有很多業務規則、字段來源、輸入輸出，限制條件等需求功能點，需要在文檔上體現，開發人員可以依據需求文檔進行更加準確的設計，有了參照標準和設計圖，才不至于有偏差。
對內的價值往往容易被忽略，其實，需求文檔更是產品設計過程的重要效率工具，可以指導我們的需求設計，通過模板要求和流程方法，會引導你想的更深更細更全面。
如果你有過復制過某個產品設計的工作情況，你就會發現，一開始你就有一個完備的需求文檔，那簡直爽的不要不要的，需求設計簡直就是百里開了透視掛。
第二、產品經理的首要任務是什么？
很多同學看到這個問題，心里肯定默念，產品設計嘛，你這不廢話么，還當我是峽谷青銅么？
如果你的答案是產品設計，鏡同學很遺憾的告訴你，你特么答對了。
但，你在工作中未必就是這樣做的，就像前文說的，很多話我們都是聽著聽著就記下來了，但并沒有理解。
產品設計其實可以拆解成兩個工作包：需求設計和需求傳遞。
需求設計是從產品經理的專業視角來說，要完成產品功能的建筑，而需求傳遞則是從管理輸出的方面考慮，要將設計好的產品功能，傳遞給他人，確保對方理解高效、準確。
好了，那么需求設計和需求傳遞哪個重要？
沒錯，是都重要。
哪個應該放在更高的優先級來做呢？
毫無疑問，你只有完成了需求設計，才有了做好需求傳遞的基礎。
就像鏡同學打野一樣，我都沒有六神裝，怎么帶領隊友越塔強殺，逆風翻盤？
不合邏輯嘛。
第三、產品設計的靈魂是什么？
看了上述兩點，聰明的同學已然明白：產品設計的工作首先是需求設計，而需求說明文檔對于我們產品經理來說，有內部驅動作用，可以指導我們進行需求設計。
鏡同學似乎看到課代表已經舉手：先做需求說明文檔！！！
沒錯，鏡同學最初也是這么做的，甚至，一度也是這么作為部門要求的，我當時常說：先把需求文檔寫好，需求文檔寫好了，原型設計自然就出來了，原型設計做出來了，我們就可以和技術評審了。
但凡看過《盜夢空間》的同學都知道，層次感是個燒腦但很有價值的事情，那就讓我們再深入一點，往前邁進一點：產品設計的靈魂是什么呢？
這次咱不給課代表搶答機會，直接說答案：效率。
是的，效率才是產品設計的關鍵所在，也可以說是產品設計的靈魂，高效、準確的定位業務需求，將需求翻譯成可傳遞的成果，才是產品設計的王道。
第四、是正解，但不是最優解！
好了，我們重新梳理下：原型設計和需求說明文檔，我們似乎應該先選擇需求說明文檔，因為需求說明文檔從邏輯上來說，對我們產品設計有指導價值，但產品設計的靈魂是效率，那么需求說明文檔作為高優先級，合乎法理，是否就能適應實情呢？
并沒有！
舉個不恰當的例子，需求說明文檔就像是著正裝，很正規，也很有價值，但是穿起來太麻煩，我就想去樓下吃個宵夜，大褲衩白背心一字拖，可能五分鐘就能實現我的需求。
我再翻箱倒柜折騰一番，烤羊肉串的可能早就收攤了。
敏捷開發的真諦就在于各個環節都要效率優先，集成起來才有可能形成整體的效率同心環。
十年磨一劍，在當下的互聯網時代，很難有生存力。（有情懷但又有資本干爹罩著的除外）
顯然，需求說明文檔并沒有兼顧效率，因為寫起來并不是那么容易，總是三易其稿，隨時推到重來，常常沒有靈感和思路。
這就是理論和現實的差距，也是我原先的誤區，你以為需求說明文檔就是盛裝出席的少女，但打扮起來是真不容易。
第五、敏捷才是硬道理。
歷史的價值，往往就在于探索后積累起來的寶貴經驗。
事實上，越來越多的需求，越來越短的工期，活活讓一個新窮人愣是發育成了六神裝，更關鍵的是，還掌握了快速發育的方法。
再拿到一個新需求，我們現在不會糾結先寫文檔還是先寫原型，而是會先建立一個敏捷模型。
這個模型其實很簡單，只是一系列思維的集成體，有業務分析、有競品分析、有產品設計、有問題清單等等，產品需求設計依據這個模型去開展，在設計的過程中可以進行原型設計、可以逐步去完善需求說明文檔。
鏡同學以為，原型設計和需求文檔哪個先寫并不重要，重要的是要有發展的思維，敏捷的思維，懂得效率優先，而不是拘泥形式或者流程制度，有時候畫一會兒原型，完善下文檔，有時候，寫個功能文檔，再去優化下相關的原型設計，最后整合輸出又怎么了嘛。
秋水共長天一色！
當然，每個人公司的環境不同，有些公司就是嚴格要求先寫出完整的需求說明文檔，然后再進行原型設計，鏡同學原先也在誤區里，也委屈了當時的小伙伴們。
就像脫離開劑量談毒性沒有意義，單純的評估哪個好也不科學，很多事我們原本也無力改變，但是，我們可以改變自己，可以訓練自己的敏捷設計思維，每一個需求設計對我們而言都是教導員。
適合自己的才是最優解，我們需要做的是，運用敏捷思維，找出適合自己的敏捷模型，高效地完成需求設計，這才是咱們產品經理的首要任務，其次，才是需求傳遞。
敏捷思維才是我們的初心，也是我們工作的出發點和落腳點。
如果有什么困難阻礙了敏捷的腳步，直接踢開它，如果發現暫時踢不開，又可能會耽誤眼下工作，怎么辦？
那就在發展中解決問題。
如果你喜歡這篇文章，歡迎關注上面的公眾號
最后歡迎有問題的小伙伴加微信：yw5201a1?溝通交流。
更多干貨可關注微信公眾號：產品劉
··················END··················
今日研報：貝殼研究院發布《2021住房消費品質服務報告》，公眾號后臺回復“?住房消費”，即可下載完整PDF文件。
RECOMMEND
推薦閱讀
數據產品經理為什么吃香？
從業6年，給你5點建議
B端可視化：圖表設計（2）
產品經理這些事情你不要做
點擊“閱讀原文”
查看更多干貨
總結
以上是生活随笔為你收集整理的你会先写PRD，还是先画原型？的全部內容，希望文章能夠幫你解決所遇到的問題。
