經驗|我在大廠做設計,如何應對產品需求變更?
不論是大廠還是創業公司,需求變更都應該是有相應的流程和方法,而不是頻繁變更。在變更需求的情況下,設計可以如何應對?文章中給到了三種方法,供大家參考。
最近有同學問了我一個很常見且扎心的問題:“工作中,產品需求方已經確認了需求,但是在設計過程中或設計定稿后,總是會“有理有據”地變更需求,導致下游設計稿一改再改。
設計師該怎么做才能避免這種情況,減少返工呢?”。
其實我的工作中也遇到過很多類似的情況,我們可以根據需求變更的影響程度分“大”和“小”兩種情況來看:?
對上下游影響較小
??如果需求的變更和調整并不會涉及到下游工作量上的大幅增加,只是微量調整,那么就需要你從心理上先接納它,承認它是你工作職責中的一部分,是工作的常態。
畢竟產品都是需要經過不斷迭代和打磨才能呈現出相對完善的狀態。
相比于抱怨,你更需要做的是在承接需求時就對項目的排期做到心中有數,為最終的交付留有一定的調整時間,避免項目整體進度的延誤。
對上下游影響較大
如果大部分的變更和調整對你和其他下游團隊的工作量上造成了顯著影響,會拉低幾個協同團隊的產出效率,那么你可以試試以下兩種方法:
1. “有理有據”地拒絕需求
既然對方可以“有理有據”地變更需求,你也可以“有理有據”地“拒絕”變更需求。 這里的“拒絕”,并不是指完全不理會或者不承接需求,而是指: ? 給出我們原有的時間規劃作為依據;?? 指出需求變更對于我們設計產出的影響;?? 拒絕并解釋無法在原先的時間規化中完成設計內容的原因;? 要求產品方根據需求變更做重新排期,并通知其他相關方。??
2. 對 PRD 的質量提出要求
作為產品最緊密的協作者,設計師理所應當對產品經理的產出和交接的方式提出一定的要求,以確保雙方達成共識,彼此之間沒有信息差,才能保證工作的順利進行。這些要求可以是:?
1)所有的 PRD 需求必須有文檔呈現
正如設計稿是設計師的工作產出,PRD 就是產品經理必備的工作產出。PRD 是整個產品研發過程中很正式的一個環節,既能夠與上下游交接,也能夠將需求以文檔的形式存檔,便于對產品之后的優化迭代和工作追責。
當然,就像不同水平的設計師產出的設計稿質量不同,不同水平的產品經理也會導致 PRD 的產出質量有所不同。拋開寫法風格不談,“能夠將產品需求表達清楚、將需求變更記錄詳細,以確保協作方能夠順利理解需求內容”,就是 PRD 的質量底線。
2)每次需求變更都需要重新排期
當 PRD 中需求發生變化時,并不是簡單的文字修改,而是牽一發而動全身:與之相關的是設計師、前端、后端、測試、運營等團隊的工作排期和規劃。
因此相關的協作方都有權責評估 PRD 中新增需求或修改后需求的變更程度,并要求產品經理重做工作排期。如果改動是在太大,也可以商討是否分兩期實現需求。
以我們團隊平日里的工作方式為例:在承接需求時,不僅首輪 PRD 需要開會做評審,當 PRD 有變動時,也都需要再開會做二次評審。這樣并不會讓工作更加繁瑣,而是會讓產品經理更加謹慎和耐心的對待自己提出的每一份需求及需求的變更,確保需求的產出質量。
3)協作時端正工作態度
產品經理作為上游對接方,在對接時的工作態度不應是:
? 趕緊把需求交出去。?
而應該是:
? 確保上下游協作方能夠完全理解并認同自己的需求內容。
相應的,設計師作為下游對接方,在對接時的工作態度不應是:
? 趕緊把需求接過來并盡快完成。?
而應該是:
? 確保對需求和產品目標有充分的理解和認知,并確保設計目標與之保持一致。
對于產品需要完成的目標應該是一致的,只有這樣,你對于產品需求的變更才會更容易接受,做出的設計評估和決策也會更合理。
工作中的協同問題會影響工作產出質量。
一個高效的產研團隊,也一定是一個在協同方式上找到了最優方法的團隊。
本文由人人都是產品經理作者【元堯】,微信公眾號:【長弓小子】,原創/授權 發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協議。
- 目前還沒評論,等你發揮!