產品設計之抽象思維（上）

「工作進度怎麼樣了？」我向開發的夥伴問道。

「哦，你不懂開發是吧」開發說。

上面往往發生在工作或入行沒多久的開發身上。因為工作性質他們更關注功能實現點，還沒有建立起業務思維，在和非開發人員進行工作對接時沒有考慮如何從對方關注的層級來對信息進行簡化處理，對細節信息模糊化。

如果開發小夥伴在描述工作時能夠運用抽象思維，溝通就會順暢得多了。抽象思維在生活當中有很多的應用。通常我們要對信息抽象化，不是因為講細節別人不明白，而是要借簡單的表述，讓別人在非常短的時間內就能夠了解你要表達的內容。

以前做智能家居作為參展方參展，有人經過展台旁邊，會好奇地問：你們這智能家居是做什麼的？看產品通常沒耐心聽你講太多內容，你需要在開始時候一句話就能講清你的產品。我就跟他們講，就是用手機控制家裡電器啊，比如電視，空調。

你看，我在跟他們講的時候，實際隱藏了很多的細節。至於手機是怎麼控制的，通過什麼方式連接到電器的，手機是不是要裝個app，手機是不是需要聯網，控制的電器有哪些？我都沒去講，為什麼？你上來給他講這些內容，有必要嗎，他會去關心了解這些細節嗎，這些細枝末節反而增加他們對了解事物成本。

在產品設計中，需求分析應該是抽象思維應用最多的地方。從大量的業務資料收集，流程梳理到最終產品的設計本身就是一個抽象的過程。需求的開始工作就是一個不斷匯聚的過程，前期積累必要的資料，然後再一點點剝離不必要細節，重點關注業務流程中的主要業務對象。不斷地做減法，對業務對象的每一個功能都要進行必要的確認：是否可以去掉該功能？去掉該功能後是否會影響正常業務的運轉？而不是做加法，添加這個功能對業務有沒有影響，放在這裡，可能會對有些用戶有幫助？可能？有些用戶？我認為這是一種模稜兩可，和稀泥的思維和態度，沒有明確的產品目標和產品標準，對產品的發展是一種傷害。

從簡單到複雜太容易了，不斷地往裡面加功能就可以。

從複雜到簡單就難得多，保持主幹清晰，分枝適度。

需求分析要做的是去繁就簡，抽出其中的主幹。

抽象思維在需求分析的兩方面有著重要體現，適用性和精簡性。

適用性

剛開始做程序員時，接到工作安排會立馬去寫代碼，結果被老大訓了一頓，先熟悉業務文檔，看兩天，想好再寫代碼。當時不明所以，心想立馬上手幹活還竟然說我。後面工作中慢慢體會到其中的意義和必要性。做程序設計的大忌是，沒有理解透業務，設計好合理的程序結構，一上手就開始寫，代碼的模塊化程度低，復用性低，程序到後面是越來越容易出bug。經驗豐富的程序員就懂得設計合理程序，考慮代碼的擴展性和復用性。

同樣的道理，剛入門的產品人接到需求點往往只考慮到按需求方提出的要求去實現其功能。

實際上，我們在接到需求時從其出發點來考慮，不僅要看到影響需求的決策因素，還要考慮到影響需求發生變化的其它因素，需求背後的動機是什麼？在產品設計的時候就要照顧到這些影響因子，去滿足用戶一類的需求。舉一個例子，

比如說，產品初期業務員提了一個需求，加一個應用下載二維碼，方便客戶掃描下載安裝。業務員在推廣時發現，讓別人到應用市場去搜索再下載十分不方便，客戶與客戶之間傳播也不方便。業務員提出需求的動機是為了方便客戶同事之間應用的傳播與分享，但這裡只涉及到面對面的場景，如果不是面對面怎麼辦？做的時候就要多往前考慮一步，支持微信，QQ等好友的分享功能。

往前一步，除了能夠對用戶提出的要求進行精準的分析，滿足他們的需求，還要對用戶未來的業務作出合理的預測，提前在產品設計上埋下伏筆。等到某一天，市場人員提出需求時，可以直接霸氣地說，我們產品設計已經考慮到這個需求，完全可以支持，2天就能搞定。看下面許可權設計例子，

銷售主管說，產品要加個許可權，要區分開銷售主管和業務員，哪些功能銷售主管有，業務員沒有。顯然，這裡涉及了用戶角色，設計的時候，不光是要考慮到從用戶角色出發，而不是僅僅添加兩個成員，還要做產品結構設計上做好預留，如果未來來了銷售總監呢，後面又來了銷售總監呢？甚至現有的業務功能和公司組織架構發生變化呢？

再往前一步，從行業的發展去著手需求分析，控制事情的發生。對B端產品來說，產品解決的問題不是簡單地將線下的業務搬到線上來處理。比如說供應鏈的2B行業，即使是一個細分行業在某一個事務上處理都有不同的業務規範和準則，凌亂複雜。要是一一對應解決的話，成本巨大，是不現實的。而且還會有這樣情況，為了對接業務滿足某一需求要填一個坑，填完了卻發現了又來一個坑。這也是產品設計上要考慮到的事情，在產品設計上，既能把握產品的適應性，又能控制或影響要發生的事情。當然，做到像微信那樣有影響力的產品，難以想像。

關於「精簡性」的分析放到下一篇文章來講。