PM新同學的一些建議

目標明確

所有需求都應有一個明確的、可量化的目標，後續可以據此評估的需求效果。但是具體實施上，建議：

• 對於有明確預期的需要給出量化目標，目標要符合邏輯，比如，提高XXX收益周/月YOY/環比增長xx%，增加新用戶xx/月，新增xxxpv/uv等等。
• 對於一些體驗型/優化型的需求，難以量化，或者前期量化成本高，比如，一些交互側更新，數據覆蓋的增強，PM/DEV達成一致即可，本著快速迭代/快速試錯的方式來搞。通過快速迭代/快速試錯，給出一個性價比合適的優化。

溝通套路

• 對於不懂的問題，先找自己的TL/其他PM學習
• 其次，通過公司的文檔系統裡面搜集相關的需求文檔來學習了解
• 其次，找DEV同學講解
• 其下，找DEV同學翻代碼了解
• 其次，相關問題PM內部做好傳承

系統設計的一些點

大多數需求，順著用戶的操作流程畫一個腦圖基本就囊括了需求的多數可見功能，比如

• 商品列表，是否影響排序，篩選如何做，優惠是否有影響
• 商品詳情，列表的一致性，是否有信息需要從前端同步，彈出浮層考慮了嗎，UGC，篩選，選擇/過濾邏輯，促銷優惠
• 交易，多品類是否考慮，促銷，搭售打包，優惠的優先順序/互斥，UI交互明細，數據對交互的影響，明細，實時校驗邏輯，錯誤反饋提示文案/話術，
• 支付，是否需要修改默認支付方式，是否需要引入支付側優惠，是否有前期鏈條的優惠提示/引導
• 訂單，相關內容的展示，是否有動態交互提醒（根據變化，更新訂單詳情展示），用戶身份的相關性。

上面是用戶側，還有需要考慮到系統後台，支付/風控/用戶中心/運營/銷售等影響：

• 是否後台系統後台，需要感知到需求變化，有相應的展示
• 是否需要對客服的同學培訓話術
• 運營系統是否需要感知到反饋/流程是否需要調整
• 銷售系統是否受影響
• 清結算的同學是否知曉/認可相關的結算規則，結算周期，是否需要小批量，短周期驗證
• 風控/反作弊風險是否需要關注

需求過程

• 評審環節提出的問題，需要歸檔，限時反饋
• 開發測試團隊需要有需求的分析/概要技術點/工作量/已知風險
• 對於跨>=3個團隊或開發周期大於2周的需求，需要有技術負責人，技術負責人負責項目的整體質量和進度，
• PM需要跟進/配合技術負責人
• PM驗收需求，確認上線

推薦閱讀：