項目進開發了(le／liǎo)，PM越想越想覺得，有個(gè)需求需要(yào / yāo)改一(yī / yì ／yí)下，這(zhè)時(shí)候該怎麽處理?

這(zhè)往往是(shì)PM的(de)天人(rén)交戰時(shí)刻，一(yī / yì ／yí)邊越看越不(bù)對瘋狂想改，另一(yī / yì ／yí)邊是(shì)“造成延期我要(yào / yāo)背鍋？研發會打我嗎？”的(de)深深恐懼。

我整理了(le／liǎo)一(yī / yì ／yí)套“需求變更SOP”，給所有陷入“改還是(shì)不(bù)改”糾結的(de) PM幾顆定心丸：

第一(yī / yì ／yí)步：矯正認知，不(bù)要(yào / yāo)虛

首先要(yào / yāo)穩住不(bù)慌，PM不(bù)是(shì)神，前期經驗不(bù)足，難免會出(chū)現這(zhè)種情況。

需求變更的(de)出(chū)現，并不(bù)一(yī / yì ／yí)定意味着你失職。每個(gè)産品人(rén)都要(yào / yāo)經曆“上(shàng)線後才能悟透用戶心态”的(de)學習曲線，産品的(de)管理本身就(jiù)是(shì)動态的(de)，如果期望所有需求進入開發後都要(yào / yāo)原封不(bù)動，就(jiù)太天真了(le／liǎo)（僵化、沒有靈活性的(de)機制對公司發展不(bù)利）。

所以(yǐ)隻要(yào / yāo)掌握正确的(de)方法處理，需求變更反而(ér)可能成爲(wéi / wèi)加分項，甚至打一(yī / yì ／yí)個(gè)翻身仗，迎來(lái)口碑逆轉。

因爲(wéi / wèi)在(zài)老闆和(hé / huò)團隊視角裏：新人(rén)偶爾出(chū)現需求變更見得多啦，如何處理才是(shì)能彰顯個(gè)人(rén)職業态度的(de)地(dì / de)方。

第二步：理性check是(shì)不(bù)是(shì)真的(de)非改不(bù)可 󰀐

pm的(de)一(yī / yì ／yí)些小糾結、完美主義傾向，不(bù)屬于(yú)“非改不(bù)可”範圍，放在(zài)下一(yī / yì ／yí)版本叠代即可：因爲(wéi / wèi)需求變更不(bù)僅影響研發計劃，還有可能擾亂上(shàng)下遊的(de)設計、測試、市場等等多個(gè)環節。更嚴重的(de)是(shì)，産品邏輯的(de)嚴謹性本來(lái)就(jiù)靠一(yī / yì ／yí)環扣一(yī / yì ／yí)環的(de)“閉環設計”維系，改動一(yī / yì ／yí)個(gè)點，往往像抽積木一(yī / yì ／yí)樣牽一(yī / yì ／yí)發而(ér)動全身。 所以(yǐ)，變更不(bù)能随性。任何一(yī / yì ／yí)次“改”的(de)決策，都得是(shì)基于(yú)精細判斷，清楚評估的(de)結果。 󰄐

以(yǐ)下問題屬于(yú)嚴重問題，要(yào / yāo)考慮改：

(1) 流程阻斷性問題：比如，用戶路徑裏出(chū)現了(le／liǎo)死胡同，填寫表單時(shí)不(bù)能提交，或任務流因爲(wéi / wèi)邏輯問題直接閃退。這(zhè)類流程性BUG，對用戶來(lái)說(shuō)就(jiù)是(shì)“徹底不(bù)能用”，絕對屬于(yú)頭号優先級必須修改。

(2) 高頻必現的(de)體驗硬傷：有一(yī / yì ／yí)些問題，未到(dào)阻斷性級别，但如果每10個(gè)用戶中就(jiù)有8個(gè)要(yào / yāo)踩到(dào)坑，影響用戶對産品印象，老闆看到(dào)要(yào / yāo)發飙，這(zhè)種也(yě)不(bù)能放任不(bù)管，要(yào / yāo)及時(shí)止損。

除了(le／liǎo)上(shàng)述兩種情況以(yǐ)外，其他(tā)的(de)問題一(yī / yì ／yí)般來(lái)說(shuō)都可以(yǐ)考慮放在(zài)下個(gè)版本叠代。

第三步：決定了(le／liǎo)要(yào / yāo)改，好，做到(dào)最小化改動

如果确定必須得改，那pm要(yào / yāo)做好拆分，盡量保證改動工程量最小。這(zhè)樣對pm自己和(hé / huò)對團隊的(de)影響都能壓縮到(dào)最小。例如保留設計框架，隻調優體驗的(de)關鍵觸點。如果問題嚴重改動量大(dà)，還可以(yǐ)考慮是(shì)否可以(yǐ)不(bù)帶該功能上(shàng)線，或上(shàng)線不(bù)放開入口，下次優化後再開放。

第四步：最重要(yào / yāo)，一(yī / yì ／yí)定要(yào / yāo)做好信息拉齊

确定要(yào / yāo)更改後其實事情才算是(shì)剛開始，接下來(lái)要(yào / yāo)迅速做到(dào)拉齊溝通，遵循“明确、透明、迅速”原則。這(zhè)能保你的(de)同事不(bù)炸鍋，也(yě)可以(yǐ)讓pm少背鍋。

(1) 明确需求和(hé / huò)排期變動，落到(dào)紙上(shàng)：

– 找研發團隊評估變更邏輯的(de)實現性，明确本次改動影響的(de)開發範圍。

– 如果涉及大(dà)改動，拉項目組開對齊會，列出(chū)：新增變 更核心點、影響功能模塊，以(yǐ)及排期将如何變化。

(2) 清晰的(de)協作分工：

– 确定設計師補充稿件所需時(shí)間 & 研發額外開發時(shí)間 & 測試時(shí)間。

(3) 群公告式透明同步：

– 在(zài)變更确定後，做一(yī / yì ／yí)次完整記錄：需求細節的(de)更新文檔+邏輯彙總。

– 實時(shí)公告所有相關人(rén)（包括開發/測試/設計/運營/市場）。尤其要(yào / yāo)注意檢查運營、市場、客服等部門是(shì)否需要(yào / yāo)同步。如果因爲(wéi / wèi)pm忘記通知，造成其他(tā)部門工作受影響，鍋就(jiù)大(dà)了(le／liǎo)。

第五步：加分項—變更後的(de)優化反思和(hé / huò)方法論沉澱

更改完成後，别着急趕工，你的(de)複盤總結是(shì)對過程負責的(de)最後一(yī / yì ／yí)步。 尤其是(shì)對于(yú)産品新人(rén)：每一(yī / yì ／yí)次需求變更，反思原因總結經驗，是(shì)你更深入理解産品工作的(de)重要(yào / yāo)一(yī / yì ／yí)步。

思考2個(gè)點：

1. 此次需求爲(wéi / wèi)什麽當初沒有看清？是(shì)因爲(wéi / wèi)調研深度不(bù)足？還是(shì)對技術約束不(bù)了(le／liǎo)解？

2. 如何讓類似問題更早暴露，避免拖到(dào)項目後期？

如果能在(zài)項目複盤中把上(shàng)面2個(gè)思考同步給項目成員和(hé / huò)領導，你在(zài)大(dà)家眼中的(de)靠譜和(hé / huò)專業程度将提升到(dào)新高度。因爲(wéi / wèi)大(dà)家對1-3年新人(rén)pm的(de)期待，不(bù)是(shì)完美，而(ér)是(shì)可以(yǐ)快速叠代。

最後的(de)建議：聰明的(de)pm如何減少需求變更的(de)發生

新人(rén)pm切忌自己坑自己，一(yī / yì ／yí)定要(yào / yāo)少做複雜的(de)大(dà)而(ér)全需求。

大(dà)需求拆分成層級清晰的(de)小版本，功能主流程盡量“瘦身到(dào)核心亮點就(jiù)好”。這(zhè)樣不(bù)僅對研發友好，對你後續發現問題時(shí)的(de)小調整，也(yě)可以(yǐ)更快上(shàng)手。

作者：芋圓同學 公衆号：PM芋圓

本文由 @芋圓同學 原創發布于(yú)人(rén)人(rén)都是(shì)産品經理。未經作者許可，禁止轉載

題圖來(lái)自Unsplash，基于(yú)CC0協議

該文觀點僅代表作者本人(rén)，人(rén)人(rén)都是(shì)産品經理平台僅提供信息存儲空間服務