業務(1.邏輯是否滿足 2.體感是否好) -> 異常邏輯(業務異常,穩定性異常[對自己感知,自己監控不算不算])是否影響體感,兜底降級 ->可擴展性(1.功能上產品想做還沒說的功能 2.業務體量上增加) -> 資金層面(是否有更好更省錢,更省時間的設計) -> 每次行爲可定義是否異常,可值班 -> 監控邏輯(對方出bug開發需要感知) -> 安全
對於"可值班",舉個例子:
排隊投屏, 一旦感知設備不在投屏中,直接投屏. 在投屏中,參與排隊. 如果是依賴服務端狀態,設備出bug,沒有上報,服務端的狀態和設備端不一致, 那麼問題就來了,用戶本來想排隊然後就投屏成功了.
1.服務端對狀態不一致無感知,只能統計監控,無法值班監控,也無法行爲級分析.
哪怕統計粒度出問題,你也無法知道哪個設備出了問題.
實體設計依賴於信息呈現,而不是行爲.
task設計:
task可遍歷性: 依賴於1.角色定義,角色本來就是某種狀態下的人員定義 2.角色行爲. 3.case遍歷全,依賴於角色設計+狀態遍歷.
舉例: 投屏人,排隊人,搶佔者.
投屏人定義比較寬泛,狀態,有一臺設備,有一個投屏工具.
排隊人: 當前有一個投屏人.action: 排隊. 後續角色變更: 可變成搶佔人[直接選擇搶佔]. 或者 投屏人[之前投屏人正常結束].
搶佔人:當前有一個投屏人. action:搶佔. 後續角色變更: 無
第三排隊人: 當前有個投票人且有個排隊人. action: 搶佔或者重試排隊. 後續角色變更: 排隊人或者搶佔人