原型只是表象，過早的進入業務細節，很容易偏離方向而浪費時間。對產品經理而言，持續對使用者、業務和商業模式的深刻洞察，特別從商業層面去梳理業務架構，是產品經理的高階能力。
產品經理的終極目標，就是去架構公司的業務，解決從市場機會到商業變現的過程，這需要很好的商業意識、業務洞察、戰略規劃和架構能力來相互配合。 （雖然我們很多時候可能都沒有這樣的機會，但產品經理更不能把自己禁錮在「畫原型」的牢籠之中。）
這種能力需要在實踐中逐步累積學習，我們應當從產品的資訊架構，遞進到產品的業務架構，更多的去思考資訊架構、產品架構和未來業務架構的關係，抽象一些發展產品架構能力方面的因素，不斷的進步。
在整個系列的前 7 篇文章中，詳細的闡述了：如何在受限的環境下真正啟動一個全新的產品，這個過程涉及對產品經理的授權，以及如何打造團隊的問題。也分析了3大嚴重困擾新產品成功的原因。
建立了團隊，爭取到了資源，也明確了產品方向，作為這個產品的最高負責人，下一步應該從哪裡開始？答案是：設計整個產品的業務架構、產品架構和資訊架構。
一、什麼是業務架構？
實際上，當一個簡單產品誕生時，它的業務、產品都相對簡單，比如：某些工具類的產品，在做產品規劃時，往往就不再單獨考慮「業務架構」了。
還有一種情況是：產品經理主動不去考慮「業務架構」，而是直奔主題，動手畫「產品原型」。
關於業務架構，簡單的說就是，「企業希望從這個產品身上得到什麼」，以及「使用者想從產品身上得到什麼」，比如：電商平台這種戰略性目標是顯而易見的，使用者買到想要的東西，企業賣出可以賺錢的商品。
為了實現這一目標，我們還必須弄清楚那些用戶，能夠通過什麼管道達成他們的目標，甚至還可能會有其他的目標。
也就意味著產品端必須清晰的規劃出一個完整的業務互動的過程，搞清楚一個產品涉及到的各種不同的角色，他們所期望的目標，以及他們需要完成的業務動作，從而為產品設計打下基礎。
客戶的期望才是產品的真正價值。如何實現客戶的期望則是產品經理的價值。
比如：音樂類產品的業務大致包括了內容版權的生產、管理、消費，涉及到的就是使用者如何消費內容，版權方如何產生內容，以及平台方如何基於內容進行的營運等。這個過程用一個圖的表達，可以是這樣的：
這種建構的方式，就是「以什麼業務作為驅動」的設計方法，它考慮的是整個業務之間的互相協作來達成整體業務發展的問題。
換言之，「業務架構」考慮的是：如何為用戶提供價值，以及企業可以通過什麼方式來實現盈利的問題。
強調的是：我們能為用戶提供什麼？為了實現這一目標，我們需要做什麼？
用這個思路來看新浪微博，其在營收業務層面，新浪微博主要依靠流量變現業務，比如廣告業務等；在用戶成長業務方面，微博主要的思路就是通過扶持KOL來產生內容和社交關係，從而做大垂直領域的流量。
基本上，微博就是以社交為支撐，推動垂直業務來增加用戶活躍，帶來廣告的變現。在此基礎上的用戶畫像和社交關係，都是為了推動精準廣告收入的提高。
用這個思路來看O2O平台，它涉及的使用者既可以是終端使用者，也可以是企業用戶如電器賣場。作為連接使用者和服務使用者的「實體」則有客服、門市和工程師，整個平台基於使用者的服務請求形成的業務訂單實現整個平台的業務流程。
（ ps：實際上業務架構圖的表達方式並無固定公式，關鍵是如何清晰的表達整個模型是如何有效的開展業務，並在此基礎上，能夠進一步分解出產品的架構。）
通過整個業務的架構，我們能夠清晰的釐清整個平台的使用者對象、業務關係，也就確定了整個產品的業務邊界範圍，確定了整個團隊內的業務語言。所有的產品功能都基於兩端（使用者端和服務端）的業務價值來展開，從而避免了很多不必要的系統開支和過度設計。
二、什麼是產品架構？
如果把業務架構比作房子的地基，那產品架構就是房子的承重牆了，決定了產品的整體方向的結構。
以O2O平台為例：其業務主要是為了解決使用者的「設備配送」、「設備安裝」、「設備維修」三大類型，涉及的業務對象包括終端使用者（發起服務請求）、門市（回應使用者的服務請求）、工程師（履約服務工單）。
為了解決這一業務需求，整個平台需要完成三類服務實體（使用者、門市、工程師）圍繞「服務工單」的業務流轉過程，我們可以用一個圖來表達這種關係。
（ps：此文為簡化版，後續另一篇文章再詳細闡述如何建構整個產品架構。）
這個圖，我們能從上往下看用戶發起請求後的一系列動作過程，也可以從下往上看，為了支撐使用者的服務請求所需要建構的一系列服務。
從上圖也可以得出一個結論：產品架構可以指導產品經理思考如何解決使用者的問題，如何滿足用戶的期望。
作為產品的指南，「產品架構」解決的是如下三個問題：
1. 產品方向
按照產品架構圖的結構和路徑，產品的RoadMap也就可以被清晰的拆解出來，同時它還能指導技術架構的選擇，比如：業務的容量，擴展性等等，為未來的產品發展指明了方向。
2. 產品邊界
不做什麼，很多時候更為重要，確定一個產品的基本邊界，可以讓這個產品少走很多彎路，降低很多的風險和不必要的成本。這對於創業團隊來說，有些時候非常關鍵。
3. 產品路徑
產品架構設計了各個功能模組的業務範圍，針對每個功能的內外關係有清晰完整的定義。當一個產品的架構被確定後，也就確定了產品的反覆運算周期內的範圍，並且能夠幫助上下游清晰的理解產品的結構、功能和複雜度。
從其解決的問題來看，我們也能很清晰的瞭解，一個好的產品架構圖的基本要求：
- 功能經過抽象，做到標準化、互相獨立
- 清晰的功能邊界，架構分層明確
- 具備反覆運算改善的能力
三、什麼是資訊架構？
很多時候，產品經理拿到一個「業務需求」，就不自覺的啟動類似axure的工具，開始在畫布上指點江山，建構產品原型。這其實是一種對產品的誤解，也是一種不太高效的工作方式。
我們太容易從內容的呈現角度去思考解決方案了（人類的思考惰性是更傾向於直接得到某種結果），而原型確實能夠快速的看清楚產品的功能模組、頁面配置和交互邏輯等元素。
這種誤解，讓我們慣性般只顧產品的外觀表現，而忽略內在的建構邏輯，最終的結果就是產品的健壯性、擴展性不夠，用戶體驗欠佳。
這個內在的建構邏輯就是：資訊架構，它決定這個介面需要呈現什麼內容，以及呈現的方式，明確的表達這個介面所需要解決的問題，也就是業務痛點。資訊架構最直接的例子就是商城了。
從地下的停車場，到各個不同品類的樓層，然後各個樓層通過電梯、走道進行連接，讓有不同需求的顧客分流在不同的樓層。每個人都可以找到一個路徑去到自己想去的地方，這個就是商城的資訊架構。
對產品而言（是一個商城本質上也可以被看成是一個產品），是同一個道理，在同一個介面上，如何按照一定規則對產品的資訊和內容進行組織變成極為關鍵，包括每一個功能按鈕的位置都變成極為重要。因為它決定了使用者在使用產品時的行進路線是否順暢（體驗是否良好）。
也就是在畫原型之前，首先要對用戶的行進路線做一個規劃，讓使用者在任何一個頁面都找到他想要的資訊，能夠通過最合適的路徑去到下一個想去的頁面。思考的重點是在功能架構被確定的情況下，如果擺放按鈕，設置跳轉連接，才能高效的滿足用戶的使用需求。
這就像一個超市，怎麼設計一條合適的路線，讓用戶能夠逛到你想要他逛到的地方，買到他想買的東西。如果沒有合理的資訊架構，整個超市就一定會變成雜亂無章。
資訊架構考慮的是如何高效的解決用戶的問題，也就是如何提升用戶的體驗問題。
要注意的是在資訊架構層，業務架構和產品架構都是黑盒不可見狀態，也就是業務價格和產品功能架構都已經被確定，你可以盡最大的能力裝修房子，而不是拆除房子的承重牆，不可以撬掉天花板，也不能動地基。
ps：產品經理應該學一點建築學。
四、架構，是一種遞進的能力
資訊架構、產品架構與業務架構的關係，可以認為是一種遞進的思考方式：
- 資訊架構：是最前端的表現層架構，也就是給最終使用者呈現的內容；
- 產品架構：連接業務和使用者表現層的產品功能的架構，解決的是如何實現用戶的價值問題（解決具體的問題）；
- 業務架構：包含商業邏輯在內的業務運轉機制的架構，解決的是產品邊界的問題，最終的目的是闡述整個產品商業模式。
以上分析可以得到一個結論，形象一些來說，業務架構是心臟，產品架構是骨架，資訊架構是肌理脈絡，最外面呈現的UI，只是皮膚了。
這個結論給我們的實際指導意義是：「別再把自己當原型專家，畫原型是最容易的一件事」。《用戶體驗五要素》一書中，詳細闡述了這3層結構在使用產品開發中的應用（有興趣的朋友可以再讀一讀這本書）。
業務架構、產品架構和資訊架構，既可以從上往下看，也可以從下往上看，都能夠推導出最終呈現在使用者面前的產品形態，只是取決於設計者如何結合實際應用採用的方式。
如果反過來看，其實是從業務架構一步步推導出最後的資訊架構，從而以前端的表現層呈現在用戶面前。
對三種架構的思考是我們把事情做對的重要方法，作為產品經理，持續對使用者、業務和商業模式的深刻洞察，特別從商業層面去梳理業務架構，是產品經理的高階能力。
本文授權轉載自《人人都是產品經理》，作者：杜松
