編輯導語：一個新項目從立項到上線需要經歷很長一個周期，期間也會遇到很多的問題，從需求提出到設計再到研究開發，需要清晰統一的目標和整個團隊的協作；本文是作者總結的從立項到上線會遇到的問題清單，我們一起來看一下。

要把踩過的坑，轉化為前進的奠基石。

無流程，不組織；對自己負責，對團隊負責。

一、需求分析階段

需求類型，來自其他部門提出的需求：

1. 反思點

• 能不能一句話說清楚要解決什么問題？
• 有沒有其他更簡單的解決方式？
• 我理解這個需求背后真正的訴求了嗎？
• 我有對這個需求合理性的分析嗎？
• 我有對這個需求普適性的分析嗎？

2. 產品原有功能的優化迭代

• 我全面了解原有的這個功能嗎？
• 原有功能的數據我分析了嗎？存在哪些問題？我這次優化要解決什么問題？
• 原有功能有哪些亮點和作用？我這次優化怎么保持和擴大？
• 新的設計部分哪些可以復用原來的能力或者當前已經在開發的能力，避免重復開發？

3. 從0到1的產品

• 這個需求符合戰略方向嗎？
• 我想清楚了為什么要做這個功能嗎？這個功能的核心價值是什么？
• 我需要做市場調研或者用戶調研嗎？怎么確認這是不是偽需求？
• 我做了版本迭代規劃嗎？什么是這個產品的MVP？

4. 參考/模仿其他業內產品或功能

• 我深刻了解他們做的成功背后真正的原因了嗎？
• 我們用戶群體和使用場景相似嗎？
• 我怎么棄其糟粕取其精華？

5. 老板提的需求

• 老板真正的目的是什么？
• 老板有沒有明確的時間要求？
• 老板是自己的想法還是傳達其他部門角色的想法？如果是后者需要了解清楚是誰的想法再具體去溝通

二、需求設計階段

概念陷阱：我創造了新的概念嗎？這個概念有必要創造嗎？如果一定要創造我解釋清楚了嗎？

準確描述：我準確描述問題了嗎？如果把自己當做研發，從研發的角度看我們的需求文檔，能完整理解需求嗎？

邏輯是否清晰：設計中的邏輯是不是嚴謹？業務流程邏輯有沒有問題？功能描述邏輯有沒有缺失？

核心目的：設計結果有沒有背離最初的初衷？是不是緊緊圍繞我做這件事情核心目的？

分享激勵：我做了分享激勵嗎？分享是鏈接還是海報？我有時刻把獲取新用戶作為產品經理的使命之一嗎？

學科專業性（針對教育行業）：我有從學科專業性角度審視設計嗎？我需要跟老師們溝通下給出建議嗎？

運營思維：我從運營角度反思設計了嗎？這是一個靜態的功能還是一個可運營的產品？

關聯角色的思考：有沒有跟其他角色包括不限于運營、市場、創作部、客服、銷售、服務、老師等角色溝通確認了，對他們的業務有沒有影響甚至負面沖擊？

需求控制：我有沒有把簡單的事情復雜化了？哪些功能可能不應該放到1期？

需求延展性：功能設計是不是有足夠的延展性？下一次迭代是可以直接拓展功能還是要重構系統？

忽略了入口：我是不是只處理了子頁面的優化而忽略了入口？靜默更新一些內容等著用戶來發現嗎？

更新機制：以什么機制更新內容和數據？系統在一定周期自動更新？用戶狀態變更后再更新？運營手動更改配置更新？

緩存機制：是否要提前緩存？需要緩存多少？自動緩存還是用戶手動下載？

版本兼容：我考慮了新版本功能在舊版本中不能使用的兼容處理嗎？是兩個版本采用不同的功能還是老版本提示用戶升級的方式呢？

數據兼容：我考慮了老數據兼容處理嗎？老用戶的年級、訂購、會員等狀態變更嗎？

用戶體驗：交互夠不夠不順暢、提示文案是否太過技術化生硬難懂、icon能不能看懂、能不能記錄用戶的使用數據、保持上一次學習記錄、用戶等待時間是不是過長、空狀態有沒有文字提醒等保持上一次學習記錄、用戶等待時間是不是過長、空狀態有沒有文字提醒等。

多種角色：新老用戶、會員非會員、已完成未完成、已領取未領取當不同的狀態的規則描述。

退訂場景：用戶的退訂規則考慮了嗎？退訂后對規則有影響嗎？退訂場景的信息要變更嗎？

換班場景（僅針對教育行業）：用戶班級更換了影響哪些數據？功能會不會受影響？

登錄狀態：未登錄下的規則考慮了嗎？登錄入口有嗎？登錄或退出登錄的狀態變更考慮了嗎？

過期場景：活動過期、會員身份過期、優惠券有效期過期等。

無網絡情況：考慮到沒有網絡頁面的提示信息。

切換網絡情況：考慮到4G和無線網絡切換時頁面的提示信息和交互細節。

用戶無權限：緩存、下載內容時，設備無內存情況。

無數據情況：該頁面沒有任何數據的提示信息。

數據延遲：支付狀態中，第三方數據回調延遲等。

操作頻繁/性能問題：直播過程、網校課堂中的發送消息頻繁、發送表情頻繁、送花頻繁、舉手頻繁、連麥頻繁等、點贊頻繁、點贊又取消再次點贊、退出教室、進入教室頻繁、發送短信驗證碼頻繁、反饋、投訴頻繁等。個性化推薦等造成的大量數據請求帶來的性能問題。

分享功能：有沒有考慮分享功能和分享主副標題icon信息以及分享出去后別人打開被分享頁面的樣式等。

刪除功能：有沒有考慮評論、作品等刪除功能，包括用戶主動刪除；被舉報后系統自動刪除；工作人員刪除等。

用戶反饋出口：有沒有考慮一些內容制作類，尤其是答案是唯一性的題庫、音頻等，用戶可以有反饋的地方；并且nms中要有對應的反饋出口，與業務溝通反饋內容處理流程。

新手指引：較復雜的功能什么場景下給出指引，如何指引。

評論管控：評論要不要審核管控再放出來？一級評論、二級評論等管控。

小屏手機：文案會不會過長？小屏手機顯示不下的異常問題。

ipad適配：ipad有沒有適配，ipad哪些布局樣式要單獨定義。

事件埋點：關鍵行為的點擊事件的數據有沒有埋點。

轉化漏斗：關鍵路徑的轉化數據有沒有追蹤記錄。

統籌把控：我有沒有作為整個項目的負責人統籌把控包括不限于內容準備、營銷推廣、線上核查、客服話術、班主任銷售話術等方方面面的準備度？

三、需求投入開發

需求變更：過程中我有堅守自己的底線嗎？需求一定要變更的話我有周知到所有項目相關人員嗎？

進度更新：知曉提測時間嗎？符合領導和業務要求嗎？跟進確保開發在預期的進度了嗎？

四、需求驗收階段

忽略了入口，只走了里面的環節，忽略了入口，可能會出現：

• 里面功能優化了但入口沒有任何提示，靜靜的等用戶發現。
• 入口沒配置好，在測試環境隨便找了一個入口，沒有對正式的入口配置策略進行商定，
• 沒有把各種類型的數據流程全部驗證一遍
• 沒有把自己設想成是一個用戶去還原用戶的使用場景

忽略了多種角色的驗收。

忽略了未登錄狀態的驗收。

一些特殊的時間節點，比如需要切換年級、更換學期時的操作是否順暢，體驗是否符合預期。

忽略新人指引的驗收。

沒有通知業務或需求提出人及時驗收，在實際業務場景中去發現問題和審視方法。

不去驗收運營配置流程，只局限在功能是否完整。

輕易妥協于造數據、造賬號很難等說法——因為測試環境不好造數據，賬號沒有權限等奇怪的理由就妥協，沒有對待驗證時應有的嚴謹態度。

驗收時間太晚，導致發現問題后修改影響上線進度。

后話：這些年我都經歷過什么，才能總結這么多教訓??！

本文由 @盒小癡—在線教育PM 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自pexels，基于 CC0 協議