起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識新入職的高產，初次評審竟就被開發拿捏了！
“新產初評審，問題現原形?！?新入職的高產人員，在初次評審中就陷入困境。這其中究竟發生了什么？是經驗不足還是另有隱情？讓我們一同揭開評審背后的真相，探尋產品設計與管理的關鍵所在。
系統方法論，遠比經驗沉淀更重要。
昨天下午，我受邀參加一個剛入職高產的首次評審，之所以說受邀是因為該同學是新業務團隊的，并不是我招聘的。
雖然現在帶兩個團隊，畢竟還掛著這個產品負責人的title，也被要求精力強制分布，也算是分內之事。
說心里話，基于對設計的天然熱愛和癡迷，我還是非常樂于投身產品活動，于是也用心聽完了該同學的評審會——雖然長達2個小時、雖然我覺得半小時就該結束戰斗的。
遺憾的是，這次評審會聽下來，又讓我發現了作為高產本不應該犯的幾個典型錯誤。
比如，會議通知時既沒有提前發送相關的資料內容（TAPD鏈接、原型設計、需求文檔等），也沒有組織好會議——沒有提前到會準備，以至會議室被占用，所有與會人員白白浪費了15分鐘。
當然，這些還只是事務管理層面的失策，他在產品層面也是犯了不少錯誤，有些還很典型。
他這次評審的設計是運營需求，旨在通過某個產品推廣來實現業務增長，核心就是“分銷設計”，當然，包括落地頁、傭金管理、分銷配置等諸多模塊。
舉幾個例子：
首先，我沒有干涉該同學的設計評審，只是靜悄悄地坐在后排聽，但他的評審卻和很多初級同學一樣，上來就講原型設計，并沒有先把業務背景、需求范圍、預期價值等整體講一遍。
你看，這個誤區極其常見——我見過太多太多同學有類似的習慣；同時，這個誤區也非常容易改變——你只要講過一次，絕大多數都會改變。
僅從這個角度來說，很多所謂的產品經驗沉淀，如果不是有效的方法論，那就像失去磁性的指南針，只會慣性向前地累計解決問題的成本。
其實，整體看下來，他的設計邏輯并沒有大問題，原型設計和業務流程也符合需求場景，但依然存在以下三個典型問題。
1、接到需求就設計，沒有深度調研場景
事實上，這類問題咱們也反復提過很多次。
該同學也是一樣，我全程聽下來后認為他對業務的調研明顯不足，事后我單獨交流，發現他果然只是被動地接受業務的需求，完全按領導的吩咐去做設計翻譯，并沒有著重進行業務調研。
比如，我們這個需求主要是產品推廣，顯然，轉化率肯定是北極星指標，而核心的設計要素之一則在產品的介紹內容上，即，要能快速呈現價值點，進而引導用戶進行產品推廣。
但從他設計的產品介紹內容來看，他并沒有把握住該業務產品的核心價值點，追問下得知，該同學竟然都沒有和業務同學交流，因為他也是剛入職，他甚至都不知道該產品的業務場景。
你看，只是被動地在做業務的邏輯堆疊，卻忽略了設計價值的內核——業務的表達載體，這對高產來講，屬實不應該。
我在知識星球經常會分享設計常識，幾乎每周都在強調設計的重點在于業務調研，產品同學的價值在于業務價值。
所以，咱們務必要牢記，產品設計要服務于業務場景，千萬不要成為原型設計師。
事實上，你說調研很難嗎？并不是！
很多時候我們缺的只是意識而已，而對于高產來講，所謂設計認知（不僅是業務調研的設計認知）的方法論遠遠比慣性經驗的沉淀要有價值的多得多。
2、宏觀框架很飽滿、微觀細節不完善
很多高產同學都深諳宏觀之道，但卻不屑微觀之學，于是，“不落地”逐漸成為一些高產同學的特有標簽。
該同學的評審同樣如此，又一次地體現了設計細節的不完善，以至于被開發追著問業務邏輯，輪番質詢下完全被拿捏，專家效應蕩然無存。
開頭沒處理好，節奏就亂了。
客觀上，他的設計框架的確很系統，包括與不同業務系統、不同功能模塊的交互聯動、數據處理，等等，都考慮的很全面、很飽滿。
但是，對于某個業務的設計規則、頁面元素，卻存在諸多盲區，這為設計評審帶來了不確定性，也是開發反復詢問的關鍵點。
當然，這也是評審被拖堂的主要原因。
就拿“訂單分傭”模塊為例，因為有不同的訂單狀態，如，待推廣、待分傭、待收款、已完結等，而且，狀態的流轉邏輯不同，可能涉及多個業務系統。
比如，被推廣用戶未訂閱系統時為“待分傭”，當訂閱后則為“待收款”狀態。
以往，我們遇到涉及訂單等多狀態時，都會出具“狀態機”表格，把業務流轉規則、訂單狀態、輸入輸出等都描述清晰，這樣開發同學就很容易理解。
但該同學卻沒有對這些業務規則做詳細描述，雖然這只是設計細節，但畢竟設計不容半點湊合，你不寫清楚，開發效率就會低很多。
而高產的差異競爭力之一，就是能更好地提升開發效率，不是嗎？
3、設計評審要嚴肅，不能隨意做需求變更
需求評審時，當開發說工作量太多做不完時，你會怎么辦？
我相信很多同學都遇到過這類場景，鏡同學在以往面試時也作為面試題詢問過不少產品同學，也收到了各類回答，可謂百花齊放、見仁見智。
該同學在評審時同樣也遇到了此類問題，當時有前端同學反饋頁面太多、工作量太大，詢問能否先做一部分。
讓我驚訝地是，該同學竟然不假思索地說可以，而這之后便“一發不可收拾”，后面好幾個開發同學都提出時間緊、任務重，得砍需求，該君都笑著一一答應。
咱倒不是說不能減需求，而是需求不能這么砍啊，咱應該得知道需求優先級、業務價值緊迫性吧，退一步講，至少也得了解開發具體的工作量吧？
可該同學還沒等開發說完，他就急著滿口答應，這讓我很是意外，我甚至覺得他是不是擔心轉正受影響，把砍需求當做換取好感的兌換券了？
退一萬步講，咱們是產品設計師，需要對上線功能和業務價值負責，要基于市場來做迭代范圍的決策，而不是憑個人意志來隨意定論。
換句話說，我們要對上線成果負責，當然，盡可能多的上線更有利于業務轉化。
更何況作為高產，更應該首先考慮的應該是對業務的支撐，而不是“辦差思維”來決定上線內容，再退一步說，有業務需求范圍在，怎么也不能主動、隨意砍需求呀。
事實上，這位高產下來就被業務總監懟了一頓，因為在他瘋狂修剪之下，原業務需求已經完全失真，本次上線的內容根本解決不了客戶問題。
你看，這絕對不算是好心辦壞事，而是妥妥地設計評審事故，流程意識不強、業務認識不足。
事后我也對他做了指導，他也意識到評審不嚴謹帶來的一系列問題，當然，我相信該同學絕非個例。
最后，鏡同學想說的是，產品設計評審絕非是設計的重點，恰恰是需求轉化的交接點，是新的起點，不能因此松懈，更要慎重對待。
希望對你有參考。
撰寫：東瓶西鏡同學
本文由人人都是產品經理作者【產品大峽谷】，微信公眾號：【產品大峽谷】，原創/授權 發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協議。
大框架重要，但細節也很重要啊，要細心地看每一處小地方，才能做的更好。