作者：帥帥的帥

全文共 2912 字，閱讀需要 8 分鐘

—— BEGIN ——

今天我們來聊一個尷尬的話題——改設計。

在工作中，很多PM都可能會遇到這樣一種情況：

“產品的文檔已經交付了，產品也已經在開發了。可是，你突然發現有個功能設計有一點問題，需要做一些改動，這時你該怎么辦？”

這種“雷”對于幾乎各種級別的產品經理都會遇到過，或大或小地都會經歷一次這種生不如死的過程，有時感覺研發工程師恨不得拿刀剁了自己，可是本著對產品負責的態度又不得不提出來。這種結果往往導致團隊士氣低下，關系變差，產品延期，PM信任危機，等等。

那遇到這種問題究竟有沒有解決方案呢，或者說有沒有應對的方法論呢？

我們今天就簡單來聊一聊，產品開發到一半，用什么姿勢來思考“改設計”這個事。

區分真老虎和紙老虎

事情往往來得很突然。可能是和別人溝通中，可能是給技術講解產品時，可能是自己突然領悟到，也可能是在讀某篇文章時，你突然意識到，“我設計的產品功能有問題。”

此時，你的內心應該是Bi了狗了。接下來，你的內心活動可能是這樣的一條路徑：

產品功能有問題 → 我得修改 → 我怎么搞定我的技術 → 我死定了

沒錯，你這樣想就是死定了。因為這只是你的內心活動，而不是客觀事實。

我們很多產品經理遇到問題時，都是自己把自己給嚇死的。我們太容易把客觀事實、迫切程度、迭代規劃、內心感受、同伴關系等問題攪和在一起來考慮，你在做判斷的時候就很痛苦，自以為事情很緊急很迫切，卻不知道哪個是客觀事實，哪個是你臆想出來的恐懼。

? 我們舉一個例子：

比如某個數據產品經理，他在為一個新產品設計一個新的數據分析工具，大概有條件篩選、數據排序、數值計算、對比分析等一些基本工具，他在設計時考慮了數據分析的輸入是什么，操作有哪些，輸出有什么，從而設計出一個比較完整的數據分析工具，我們稱之為v1.0。

看來看去似乎并沒有太大的問題，而且也比較簡單，所以產品文檔寫好之后就交付了。突然某天，在和技術老大碰細節的時候，技術老大說，你怎么沒考慮到數據如果太大處理不了怎么辦？我們在流程上是不是要首先做數據過濾啊，不然數據存在數據庫里，一口氣幾十萬條數據都拿出來，豈不是亂套了！

這個問題真夠唬人了，想想還真是個大麻煩事，如果一口氣幾十萬條數據都被導出來，那豈不是把產品得搞掛了。看來得改設計了，可是開發已經進行到一半了，這怎么辦？

此時最怕的是自亂陣腳。

這個產品經理需要好好分析一下，技術老大說的這種情況會在什么場景下出現。作為技術老大，他需要考慮的很多都是極端情況，這樣才能確保產品在后續迭代中不會掉到坑里，他關心的并不是產品設計，而是技術設計。能夠提出這樣問題的技術老大是很有經驗的，但另一方面也可能印證一件事，他提出來的問題并不是眼下最緊要的，可能是將來才會遇到的。

就拿這個例子來說，大量的數據過濾是建立在數據量已經足夠大的基礎上，對于一個新產品而言，如果忽略了這個功能，是不是致命，下一個版本能不能彌補，是在發現問題時需要立刻考慮的，這些就是我們前面提到的“客觀事實”。這個功能缺失一定是個問題，但是不是要立刻修改又是另一個事情。

所以，產品經理千萬要在問題出現的時候，把“客觀事實”從所有復雜的信息里摘出來，認清楚這個客觀事實是真老虎，還是眼下的紙老虎。

學會評估，是處理問題的第一步

當問題被拋出來的時候，立刻行動并不意味著立刻去改，而是立刻評估。

因為此時產品已經開發過半，返工和延期都是很影響研發進度的，而且還會影響到后續功能的設計。你需要學會評估一切因素，從而做出最合理的判斷。

? 評估迫切程度：立馬做，還是以后再做

如果這個修改是不得不改的，那么它才有返工的必要，否則就應該延后到下一個版本。

如何來判斷迫切程度呢？我認為只有一點即可，這個功能如果不改，當前版本用戶的使用是否會出現不可控制的斷點和風險。

我們舉個例子：

比如一個登錄功能，如果是v1.0版本，你在設計的時候忘了加驗證碼。我們推演一下，因為是v1.0，可以假設此時的用戶量并不大，大概也就多則幾萬，少則幾千，此時即使沒有驗證碼，也沒有大問題，安全風險也相對較低。當版本迭代到v2.0，或者v3.0時，用戶量已經比較大了，驗證碼就必須要有了，因為有安全風險。

再舉一個例子，關于用戶使用斷點的例子：

比如一個聊天功能，如果在設計的時候，忘了設計本地緩存。此時我們再推演一下，如果是v1.0版本，用戶數量不太大，每個人手里的聊天群平均下來都不太多，緩存的確可能會影響到一些網絡不好的用戶的體驗，但是早期用戶大多是奔著核心功能來的，緩存沒有并不是最重要的斷點，用戶是可以勉強接受繼續使用的，而且產品經理、運營是可以通過人力方式設法維系用戶。

但如果版本是v2.0，此時用戶對于沒有緩存的意見就比較大了，再不做緩存的話，聊天群如果比較多，則非常影響體驗，立馬形成了用戶使用的斷點，所以就很迫切。

所以，我們評估迫切程度是要和當前的版本相結合的，然后判斷用戶使用是否有斷點和風險。根據經驗，一般能夠被評為迫切程度很高的修改是很少很少的，大部分功能都是可以延后再補救的。

評估研發難度：優化和分拆設計

如果很不湊巧，你就是趕上了一個被評估為迫切程度很高的設計改變，此時你要做的事不是立刻安排人去做，而是在完成新的設計之后，評估研發難度。

為什么要產品經理評估研發難度？這是為了幫助你更好地完成這次設計的修改。

我們一般在做產品設計的時候，第一個確定的方案往往不是最佳方案，這種方案會更多靠直覺推演。當我們深入到評估研發難度的時候，我們會發現最早的那個方案可能在研發難度上需要很長時間，或者需要多人參與，所以產品經理要學會重新評估，以及分拆設計。

我們可以將一個復雜的功能分拆成若干個簡單的功能，當前只去開發最重要的那些，而不重要或者復雜的，如果迫切程度不高，我們可以把它們推遲到后續版本里。如此就可以極大地節約工期。

關系的維護是一定要做的工作

一切評估結束，我們看看怎么去和你的小伙伴們解釋這個問題。（其實本不是特別想寫這個部分，但是想想卻又是繞不過去的坑）我簡單羅列幾個可供參考的方法。

? 勇于承擔責任

產品經理是產品的CEO。

勇于承擔責任是必須要有的勇氣和擔當，哪怕主要責任不在你，也需要站出來承擔責任。一個好的PM首先是一個好的Team Leader，否則不會有兄弟愿意和你一起賣命工作。錯本身不可怕，怕的是甩鍋怯懦的PM，這樣的PM很容易失去同伴的信任。

? 明確分析原因

無論是通過一個小的會議，還是通過郵件，都需要明確分析產生這種修改的原因。

這種做法的目的不僅僅是將事情告知大家，而是要讓所有人明白，這個是全團隊的大事，通過正式的方式來通報所有參與者，顯得正規合理得當。如果你只是私下里和大家說道說道，你的同伴會覺得你這個人相當不靠譜，也很不正規，他們在做這件事的時候也會不正規，最后可能又會帶來新的問題，而鍋還得你來背。

? 陳述新修改的影響

修改后帶來的影響一定要提前講清楚，這樣所有人心里都有一個預期。

這里有一個小的Tips，你可以把你做優化以前的設計所帶來的影響，和你優化之后所帶來的影響進行對比，告訴大家我們產品經理通過努力，將影響降到了最低。這么做一方面讓大家有個對比，比較容易接受，另一方面是大家會看到你這個產品經理在這個修改上很努力，很為大家著想。

好的溝通是確保未來長期良好合作的基礎，千萬不要充當一個只會分派工作，不會解釋說明的產品執行者。

? 學會總結，不在同一個坑里跌倒第二次

當大家都接受了你的修改設計，并且已經開始工作之后，你一定要學會總結，以確保下次別再掉坑里了。

最好的成長來自于總結別人的錯誤，其次的成長便是來自于總結自己的錯誤。

總結一定要深刻，你需要分析你這次設計中缺失的環節，你手里的產品功能在后續的設計中還有哪些地方可能還有坑，而且還需要總結你這次處理的好不好，有沒有后續的負面影響。總結并沒有特別的方法論，具體問題需要具體對待。但是可以肯定的是，你總結的越細節，越能推演出前后的關系，你也就越能體會到成長。

祝愿各位年輕的PM們，在后續的工作中能夠多總結，少犯錯。