為減少以後再發生類似事情,本文整理了壹系列檢查清單,做為產品功能論證時的參考備忘。
壹、從用戶角度檢查
--why:為什麽會有這個功能,是否能引申出其他需求
--who:產品/功用涉及哪些用戶,拿出用戶所在組織的組織架構圖來核對是否遺漏
--what:這些用戶的核心訴求是什麽
--when:用戶使用的時機,各個用戶操作是否有先後順序,這些邏輯是否限制住了
遇到過的例子:給客戶老大設計的功能很多,客戶方的小兵沒伺候好。或者壹線操作人員功能很詳盡,但沒有為上層領導設計監控報表。
二、用數據數據角度檢查
拿出產品的數據模型,然後針對每壹個數據實體檢查對應的CRUD基本操作是否都考慮到了。
常見缺陷例如:
缺查詢:新增了表單,沒有查詢入口
缺刪除:無用的表單、數據,沒法刪除或者沒法批量刪除
缺新增:壹些數據,尤其字典配置類,上線後沒法維護,總得勞駕程序員後臺增加
缺更新:尤其在壹些狀態字段的更新上要嚴謹,如:有停用,是否需要也得有啟用
三、從異常的角度檢查
拿出產品的操作手冊,然後針對每壹步操作來假設:如何在這壹步操作時系統退出/斷網了,再重新登錄後,還能否繼續。
常見例子:
1、設計壹個保存、提交、審批的簡單流程。在檢查時就要假設:在保存後沒有提交,退出系統了,再登錄進來還有沒有地方重新提交。
2、按向導新增壹個表單,表單最後壹步有個打印操作。假如在最後壹步還沒打印時,系統退出了,還能否再調出來打印? 如果仍需要再重新走壹遍向導再打印,顯示就不太合適了。