關鍵詞：技術預研課題，平臺設計，應用場景，故事，信息架構，業務流程，數據流程
一，如何從零開始？
如果讓你把下面這套技術體系串聯起來，從零開始構建一個技術平臺，你如何做需求分析呢，在沒有產品經理幫助你梳理的情況下？
下面這些系統涵蓋了我們研發測試運維日常工作的方方面面：
idCenter：它定義用戶、用戶組、權限。研發測試都有了唯一的身份和權限集合，貫穿所有系統。
iDB：數據庫自動化運維系統能把數據庫建帳號、授予權限、建表、改表結構、刷庫這些日常操作都變成流程，DBA審核通過后就可以自動執行，以及自動回滾。
Touchstone：容器私有云的管理控制臺，管理鏡像庫、應用、容器、主機等。日常發布就在這里做。
JobCenter：定時任務調度和管理。
Summoner：大型計算任務的調度和管理。云縱傭金計算就是在這上面跑的。
Notify：異步消息可靠推送。所有的異步消息都走這個中間件。
Discache：管理memcached和redis。
OAP：運維自動化系統。主要是資產管理、資源管理和發布。
Secret：天機和鷹眼。數據庫、Java、PHP、業務指標，監控報警都做進來了。
你就是一個說故事的人，為了保證大家對故事的理解沒有偏差，所以大家『都希望你說得具體點兒（User Story），把故事落實在產品的需求點（Product Backlog），然后在這些需求點里面排出優先級（Sprint Backlog），然后排出版本（Version），這樣兄弟們做開發和不斷燃燒（Burn Up）』。[注1]
即，
/*
先有場景， \
再有故事， \
通過故事拆解出信息架構，即菜單結構和功能點， \
最后歸入某個版本， \
在所有的故事、功能點和版本都確定之后，我們就進入不斷的排序優先級和循環的過程。
*/
二，何謂應用場景？
大家也許會注意到，當我發起技術預研課題時，我通常都會給出我想象中的、心目中這個課題的愿景，以一個目標用戶是如何使用這個平臺的應用場景的方式。
譬如說：
本地生活服務商戶“魔鏡”計劃
愿景：
為公司分銷、共創和運營的決策提供門店數據支撐，提供（自助）可視化數據和自助數據查詢能力
應用場景舉例：
場景一：
開站決策支持：哪些城市值得開站，哪些不值得？
背后的數據支撐：
開展過互聯網營銷服務并且經營得尚可的門店清單以及銷售情況
場景二：
餐飲和美業品類下，優先向哪些商戶推縱橫客？
背后的數據支撐：
門店的地址電話，用戶活躍度，門店星級，團購和外賣商品數，折扣領取次數等
這就是愿景和場景。
我們對于上游業務部門流轉過來的需求，也必須熟練運用下面這種逆推能力：
先構造出合乎邏輯的多種應用場景，然后回頭審視自己的概念設計、功能設計、信息架構設計是否正確。如果你的表結構等設計不符合這些應用場景，必定是你的設計不對。
WHY？
不合邏輯，必有問題。
再舉一個應用場景例子：
有了應用場景，就可以針對不同的用戶設計故事。
三，從應用場景推導出故事
順著場景展開，就可以得到一個又一個的故事。
譬如說，對于上面的場景，我們可以針對用戶“研發經理小丁”來設計 User Story，我們看到了什么，操作了什么，又得到了什么結果：
越細越好，越有助于研發同學設計頁面，理解系統需要提供哪些接口和數據。
四，從故事推導出信息架構和業務流程
順著故事，我們可以假想出人們是怎么抵達這些故事的。與此同時，即使是同一個應用場景，也會有多種進入途徑。
譬如說，小丁同學既可以在首頁的工作臺上進入應用維護功能，也可以在二級菜單上找到對應的入口。如下圖所示：
通過上圖，我們可以整理出信息架構：
-首頁（工作臺）：應用快捷入口，環境快捷入口，……
-應用管理-應用列表（創建應用、編輯應用）
-環境管理-環境列表（公共配置查看、公共配置編輯）
故事越寫越多，進入途徑梳理清楚之后，我們就能總結出需要哪些 Dashboard、一級菜單、二級菜單，進一步還能整理出業務流轉流程。
以上這種思考問題和推演方法，有助于我們從零開始，一點點切入平臺，而不是像下面這樣“拍腦袋”地逆向設計：
-先構想一級菜單和二級菜單
-再構想菜單點擊之后需要實現的功能點
-最后在做頁面組織
我們的技術預研課題一般都圍繞著這四個核心概念：
-資源
-數據
-流程
-操作
開始構建一個體系。
我們順著場景——>故事——>信息架構——>業務流程——>版本以及版本包含的功能點，就可以把我們所掌握的資源（虛擬機集群、Docker集群、物理機、……），外界采集的數據（組織架構、員工信息、有效門店、交易……），業務流轉的流程，各個部門的操作，順利地結合起來。
注1：
這段『User Story-Product Backlog-Sprint Backlog-Version-Burn Up』的文字出自于《產品的視角：從熱鬧到門道》（百度產品架構師魯克著）。
延伸閱讀：
