需求是part of your plan?

前面講到，最開始我認為需求是流水線上的零件。雖然每一期都會對需求進行“優(yōu)先級判定”，但是那個階段做得更多的是把零件放到不同的地方而已。看起來好像已經(jīng)排了優(yōu)先級，但是這種排序的問題在于——缺少連貫性和繼承性。這個問題的癥結在產(chǎn)品的頂層設計。

當然這個insight來自于我對舊版本的復盤。我驚訝的發(fā)現(xiàn)，在一個大版本里面，竟然每個小版本都有交互優(yōu)化型需求。（我究竟干了些什么樣的需求。。）在移動產(chǎn)品中，大部分交互優(yōu)化型的需求屬于緊急（資源集中在前端并且要跟著發(fā)版上線，時間上游限制）但不重要的需求。不重要，并不意味著交互優(yōu)化對用戶體驗沒有作用，而是說，根據(jù)這個工作的ROI來看，根本不值得每一版?zhèn)顒庸恰?/p>

那么，為什么會出現(xiàn)密集的交互性需求呢？只有一個原因，產(chǎn)品經(jīng)理根本沒有想過“產(chǎn)品框架設計”。就好比一個建筑師首先必須明白房子的結構是怎樣的，產(chǎn)品經(jīng)理也是，必須跳出需求本身去思考產(chǎn)品框架怎么設計。也正好比一棟建筑的結構不能隨意改動，產(chǎn)品經(jīng)理在設計產(chǎn)品框架時，也必須用長期的視角去考慮，要搭建什么樣的基礎框架，更直白點說，一個大版本，基礎產(chǎn)品形態(tài)是怎樣的？整體的思路如何？

經(jīng)過這樣的復盤和思考，我對需求的理解也有所升級：需求應該是part of your plan,是大框架下的小模塊甚至小磚頭，也就是說，所有的需求都要為Plan這個整體目標服務。

整體思路下的優(yōu)先級判定原則

當意識到需求要為整體目標服務時，對需求的優(yōu)先級判定就有了頂層設計思路。

當然，涉及到大版本的整體思路，必須要和相關團隊同步腦暴，形成共識。（后續(xù)會和大家分享下如何做產(chǎn)品規(guī)劃）在團隊達成共識的基礎上，由于大家目標一致，在小版本上的需求管理就會變得容易很多。實戰(zhàn)經(jīng)驗表明：如果團隊目標一致，主要是業(yè)務方和產(chǎn)品有統(tǒng)一的共識，不僅在需求提報環(huán)節(jié)模糊的需求會減少很多，在需求評估環(huán)節(jié)，雙方也更傾向于快速達成一致，低效的撕逼也減少了。

團隊沒有共識的時候，很容易發(fā)散地走向不同的思維路徑，這種情況是我做低年級產(chǎn)品時經(jīng)常遇到的困境，經(jīng)常是溝通了多次之后發(fā)現(xiàn)誰也說服不了誰。在團隊思路一致的情況下，這種情況基本上不會出現(xiàn)了，如果意見不合出現(xiàn)分歧，那就回到爭論的原點從整體的思路出發(fā)看到底哪種方案更有利于共同目標的實現(xiàn)（優(yōu)先級判定的終極原則）。

如果你發(fā)現(xiàn)你總是陷入低效的溝通或者無結論的爭辯，建議lead團隊對產(chǎn)品的框架進行腦暴和review，對于后續(xù)整個的需求管理，這是最重要的步驟。

相關閱讀

資深產(chǎn)品經(jīng)理是如何做需求管理的（一）：需求的優(yōu)先級判定原則

資深產(chǎn)品經(jīng)理如何做需求管理（二）：需求的生命周期

資深產(chǎn)品經(jīng)理如何做需求管理（三）：學會復盤

本文由 @時雨?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。