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