產(chǎn)品需求返工的問題由來已久，也是很多小伙伴們很頭痛的問題，在上一篇《產(chǎn)品效率的提高，關(guān)鍵在于需求返工率》的文章中提到“產(chǎn)品效率的提高，關(guān)鍵在于需求返工率”，那么如何最大程度的降低需求返工率是這篇文章將討論的問題。

需求返工的問題主要出現(xiàn)在需求的收集分析、概念架構(gòu)的設(shè)計(jì)、系統(tǒng)邏輯的設(shè)計(jì)、開發(fā)復(fù)雜度的考量、研發(fā)周期的限制這些問題上，下面就這幾點(diǎn)綜合討論下。

一、需求收集分析

需求的收集分析，可以拆分為收集和分析兩部分,在這里容易造成返工的點(diǎn)主要是：

1. 未能對(duì)有效需求和無效需求進(jìn)行分離，致使工作從一開始就偏離了正確方向；
2. 收集渠道過于片面，造成信息與真實(shí)狀況偏離遮蔽了事實(shí)的全貌，樣本來源太單一無法印證需求導(dǎo)致需求錯(cuò)誤；
3. 未能結(jié)合產(chǎn)品定位，拋開用戶畫像和使用場(chǎng)景談需求和耍流氓其實(shí)并沒什么區(qū)別；
4. 不符合企業(yè)戰(zhàn)略規(guī)劃，產(chǎn)品是為企業(yè)戰(zhàn)略做支撐的，需求偏離了規(guī)劃就是不符合內(nèi)部需要的產(chǎn)品；
5. 脫離了產(chǎn)品現(xiàn)狀，每個(gè)產(chǎn)品階段我們都需要有優(yōu)先級(jí)的去考慮需求的排期和版本的迭代，在不合時(shí)宜的位置提出需求其實(shí)也是一種無效需求。

說完常見問題環(huán)節(jié)，下面來說說相關(guān)處理方法。

1. 需求收集

首先是收集，在上一篇文章中提到需求主要來源于外部和內(nèi)部兩種路徑，在收集需求時(shí)我們需要考慮的是收集哪些用戶的需求，這就要求我們有一個(gè)用戶畫像；

其次是需要收集哪些場(chǎng)景下需求，這就需要場(chǎng)景地圖，用戶畫像和場(chǎng)景地圖我們必須做到有主次大小之分，否則很可能出現(xiàn)需求的分布位置在用戶和場(chǎng)景邊沿交集中。

基于這用戶和場(chǎng)景我們對(duì)收集到的需求進(jìn)行核心交集處理，這一步能夠相對(duì)準(zhǔn)確的圈出需求內(nèi)容，然后對(duì)得到的需求進(jìn)行“拓展需求”的篩選，因?yàn)榕既挥幸恍┬枨笫窃诮患鈪s也很有價(jià)值，時(shí)間允許的情況也是建議過一遍的。

例如我們做女性彩妝的，偶然有一些男性提出的需求，你以為他們就該排除在性別之外嗎？其實(shí)女裝大佬們需求還是很大的。

當(dāng)完成初步需求篩選后，我們需要基于現(xiàn)狀對(duì)需求進(jìn)行優(yōu)先級(jí)整理，首先考量的是產(chǎn)品當(dāng)前狀態(tài)下最迫切的任務(wù)是什么，例如起步階段面對(duì)非急需的大型系統(tǒng)需求我們就會(huì)考慮往后放一放，而能夠快速開發(fā)且?guī)碛脩粼鲩L和存留以及轉(zhuǎn)化的會(huì)考慮優(yōu)先解決。

其次優(yōu)先解決大面積用戶的基本需求，所謂的基本需求就是這需求不解決人家都懶得理你了，大家都不理你了難不成咱們?nèi)樯倭坑脩糁匦露ㄎ唬?/p>

這不現(xiàn)實(shí)，畢竟不到當(dāng)前定位的生命晚期誰也不愿意重新定位用戶群。最后是對(duì)需求的開發(fā)量和版本規(guī)劃的評(píng)估進(jìn)行綜合排序。

從上述不難看出，需求的收集從來不是一股腦的堆積，而是需要產(chǎn)品人員去按照一定的方法和規(guī)律來整理和篩選，最后得到一個(gè)合時(shí)合利的有效需求集。

2. 需求分析

有效的整理需求倉庫能夠從起點(diǎn)就避免掉無效的產(chǎn)品勞動(dòng)！

收集完了需求，接下來就是需求分析，在開始說分析之前需要提到的是“需求分析從收集需求時(shí)就一直在進(jìn)行，它脫離需求收集而單獨(dú)拿出來是不具備任何效率意義的”。

關(guān)于需求分析主要分析哪些內(nèi)容，宏觀上我們拆分為兩部分，分別是業(yè)務(wù)分析和開發(fā)分析。

業(yè)務(wù)分析是基于產(chǎn)品定位、企業(yè)戰(zhàn)略需求、產(chǎn)品周期規(guī)劃這三方面，同時(shí)這三方面需要綜合并行考慮，而不是串行流程過濾，基于定位考量能夠有效控制產(chǎn)品性質(zhì)的穩(wěn)定和業(yè)務(wù)的精準(zhǔn)，周期規(guī)劃是產(chǎn)品成長的規(guī)律偏離可能就會(huì)造成產(chǎn)品的無效成長和冗余；

至于符合戰(zhàn)略需求就不多說了，咱們要做一個(gè)社交電商你卻做了個(gè)微信，相信老板會(huì)感謝你的。

（1）業(yè)務(wù)分析

那么，如何做好業(yè)務(wù)分析？在做需求分析之前我們必須先弄明白產(chǎn)品定位、戰(zhàn)略需求和周期規(guī)劃。

很多產(chǎn)品在研發(fā)時(shí)根本就沒有過定位的思考，而是想到哪做到哪，這就導(dǎo)致產(chǎn)品功能系統(tǒng)越來越龐大臃腫，業(yè)務(wù)效率越來越低，程序邏輯越來越雜亂交錯(cuò)，最終形成一灘爛泥，動(dòng)刀的代價(jià)太大只能放棄。

因此我們必須對(duì)產(chǎn)品有一個(gè)清晰的定位，這里不是指產(chǎn)品的使命定位而是生命周期定位，從定位中我們才能得到階段任務(wù)的方向和范圍，而定位來源于用戶、場(chǎng)景、數(shù)據(jù)的分析，再加上企業(yè)對(duì)它的期望即戰(zhàn)略需求！而不符合定位的需求，隨著時(shí)間的推移必然會(huì)越來越凸顯出冗余感。

接下來再說說如何理解分析戰(zhàn)略需求，其實(shí)這是一個(gè)相對(duì)宏觀的東西，但是一個(gè)務(wù)實(shí)的戰(zhàn)略需求必然清晰的指明需要解決的問題范圍或方向而不是某個(gè)精確的問題點(diǎn)，而需求在戰(zhàn)略考慮上必須包含或交集于它；

在這個(gè)環(huán)節(jié)常常遇到的問題是戰(zhàn)略太模糊甚至空泛，這時(shí)候我們需要做的是與高層詳細(xì)溝通以及精確細(xì)化戰(zhàn)略，磨刀不誤砍柴工。而戰(zhàn)略分析主要是指提煉出業(yè)務(wù)方向和范圍，明確出具體涉及的系統(tǒng)和架構(gòu)。

最后是周期規(guī)劃，這個(gè)規(guī)劃中主要考慮的還是既定規(guī)劃和需求的交集，以及版本設(shè)定的優(yōu)先級(jí)和邏輯前后置問題，常見問題是經(jīng)常出現(xiàn)做好的需求發(fā)現(xiàn)開發(fā)周期過長或者前置內(nèi)容未建立，以及無后續(xù)考慮。

（2）研發(fā)分析

符合業(yè)務(wù)分析后就是研發(fā)分析環(huán)節(jié)了，在這個(gè)環(huán)節(jié)中我們要考慮的就包括需求的開發(fā)難度和周期、系統(tǒng)架構(gòu)設(shè)計(jì)和調(diào)整、需求邏輯轉(zhuǎn)化、數(shù)據(jù)需求和橋接等眾多極度理性和邏輯的事情。

這里涉及到的處理方法我們綜合起來主要是，面對(duì)新的調(diào)整如何讓現(xiàn)有機(jī)制盡可能的少做調(diào)整、對(duì)新增數(shù)據(jù)進(jìn)行閉環(huán)設(shè)計(jì)、對(duì)刪減機(jī)制做好延伸測(cè)評(píng)、對(duì)新的系統(tǒng)盡可能的組件化、對(duì)核心用戶體驗(yàn)做到足夠考量！

首先如何盡可能少的觸碰現(xiàn)有機(jī)制，這主要是兩個(gè)方向考慮，一方面是在之前的工作中就充分的考慮到系統(tǒng)和機(jī)制板塊之間的解耦涉及，在做邏輯和數(shù)據(jù)架構(gòu)設(shè)計(jì)時(shí)盡量秉承著組件式涉及的思想，最大限度的保持各個(gè)中大型功能系統(tǒng)之間的獨(dú)立性。

另一方面是將新的邏輯需求避免在現(xiàn)有系統(tǒng)中做零碎處理，以便減少邊緣和孤立機(jī)制點(diǎn)的存在，同時(shí)盡可能使用通用模塊降低架構(gòu)的零散性提高通用模塊的集成樞紐意義。

例如，對(duì)于復(fù)雜的訂單系統(tǒng)我們通常會(huì)設(shè)計(jì)一個(gè)獨(dú)立的訂單管理樞紐，各個(gè)系統(tǒng)的訂單增刪查改均會(huì)從這里經(jīng)過，這對(duì)整個(gè)產(chǎn)品來說就是一個(gè)集散點(diǎn)，基本管理和監(jiān)控在這里都能等到數(shù)據(jù)和功能支撐，而不必每次涉及到訂單就要去涉及和開發(fā)一個(gè)新的機(jī)制;

同時(shí)如果訂單系統(tǒng)發(fā)生大的變動(dòng)我們只需要在訂單系統(tǒng)內(nèi)部調(diào)整即可，其他系統(tǒng)我們?cè)跇屑~位置做好兼容處理就完事了。這樣的思想在面向?qū)ο缶幊讨杏袀€(gè)非常類似的概念叫單例模式，有興趣的小伙伴可以去了解下。

上述訂單的例子其實(shí)也解釋了閉環(huán)設(shè)計(jì)的概念，在這里補(bǔ)充說明一下。閉環(huán)的設(shè)計(jì)關(guān)鍵不是封閉，而是形成完成的循環(huán)，例如你增加了一個(gè)數(shù)據(jù)的錄入就該考慮到它的整個(gè)增刪查改該如何處理，而不是放在那就不管了，不然它就是一個(gè)冗余數(shù)據(jù)了。

（3）延伸評(píng)測(cè)

關(guān)于延伸評(píng)測(cè)，相信了解測(cè)試的朋友都不難理解它的必要性，在需求設(shè)計(jì)中我們不是做一個(gè)機(jī)制就只看這一個(gè)機(jī)制，還要看到它涉及到的其他相關(guān)機(jī)制，這就是往包里放一件東西和在電路板上增加一個(gè)元器件的區(qū)別，前者是容器概念放進(jìn)去即可，后者是機(jī)制概念需要融入其中并與原主體結(jié)合在一起成功運(yùn)行。

在這個(gè)環(huán)節(jié)我們?cè)诔Ｓ龅降姆倒栴}就是，新的機(jī)制未能與已有系統(tǒng)融合甚至產(chǎn)生各種錯(cuò)誤，因此在分析需求時(shí)首先必須足夠了解原有系統(tǒng)機(jī)制，其次是最大限度遍歷出所有牽涉的機(jī)制，并做好后續(xù)兼容考慮。

最后是核心用戶體驗(yàn)，一句話說明：任何拋開用戶畫像和使用場(chǎng)景的用戶體驗(yàn)設(shè)計(jì)必然是空中樓閣，而需求設(shè)計(jì)離開了用戶體驗(yàn)只是一堆粗糙的積木。

總結(jié)下來其實(shí)所謂的需求收集分析，無外乎結(jié)合內(nèi)外對(duì)已知的需求進(jìn)行有效化、優(yōu)先級(jí)化、邏輯化、數(shù)據(jù)化以及版本化！

在上文中，相信有不少朋友發(fā)現(xiàn)一直未提到另一個(gè)核心概念——真實(shí)需求。

這個(gè)問題在上面文章中其實(shí)隱晦的有所說明但不全面，更多的是關(guān)于真實(shí)需求排除法方面的，而真實(shí)需求其核心方法其實(shí)是用戶同位心，這里就不多做討論了，以后會(huì)單獨(dú)寫一篇關(guān)于真實(shí)需求的文章，這里主要還是說一些基礎(chǔ)的需求管理。

二、邏輯架構(gòu)設(shè)計(jì)

下面來說說許多不擅長后端的小伙伴關(guān)心的問題——邏輯架構(gòu)設(shè)計(jì)。

在上面的內(nèi)容里以及開始闡述架構(gòu)設(shè)計(jì)了，這也是需求整理分析后的下一步工作。

邏輯架構(gòu)，顧名思義是有邏輯的架構(gòu)。許多產(chǎn)品在設(shè)計(jì)稿階段其實(shí)就已經(jīng)出現(xiàn)了很大的邏輯問題，這就導(dǎo)致設(shè)計(jì)稿連討論審核階段都很難通過，就更別說后續(xù)的技術(shù)和測(cè)試評(píng)估了。

在開扯之前先說一句話：“那些對(duì)編程一無所知的小伙伴們，可長點(diǎn)心吧！連養(yǎng)豬的理論都不知道怎么養(yǎng)的好豬？”。

生活里確實(shí)有不少朋友問過我，為什么概念結(jié)構(gòu)圖做的那么好，為什么我的需求設(shè)計(jì)基本不返工等等問題，答案其實(shí)無外乎“邏輯通了嗎？”、“耦合性問題考慮了嗎？”、“編程邏輯你知道嗎？”等等，

對(duì)于一個(gè)需要將開發(fā)需求文檔直接給到技術(shù)人員的產(chǎn)品經(jīng)理來說，邏輯是硬道理！在產(chǎn)品工作中需求返工最大的觸發(fā)點(diǎn)就是邏輯架構(gòu)環(huán)節(jié)，而順暢的邏輯、明確的架構(gòu)、精準(zhǔn)的功能投放、優(yōu)秀的頁面交互、清晰的數(shù)據(jù)結(jié)構(gòu)將決定著一個(gè)架構(gòu)設(shè)計(jì)的質(zhì)量.

那么如何設(shè)計(jì)邏輯？首先我們需要對(duì)需求本體進(jìn)行解構(gòu)，一個(gè)需求會(huì)生成那些系統(tǒng)板塊，每個(gè)板塊需要什么機(jī)制，每個(gè)機(jī)制需要那些功能，每個(gè)功能牽涉那些數(shù)據(jù)？

然后，每個(gè)數(shù)據(jù)作用于哪些功能，每個(gè)功能需要哪些界面，每個(gè)界面如何交互？最后對(duì)界面進(jìn)行整合調(diào)整，提交設(shè)計(jì)。

說起來簡單但每一步都是一堆思考，首先需求解構(gòu)這就像雕刻時(shí)知道我們將會(huì)出一個(gè)什么東西；然后板塊劃分這就是知道這個(gè)東西大概模樣，即雕像是豬還是人有了具體定位；

再進(jìn)行機(jī)制拆解和梳理即在知道這個(gè)雕像是人后在腦海中呈現(xiàn)出各種人類的形象，以支撐下一步設(shè)定；

再然后設(shè)定功能和數(shù)據(jù)，來清新出這個(gè)雕像的性別、職業(yè)、年代等細(xì)一步的形象；接下來需要哪些界面如何交互，就是確定這個(gè)雕像形態(tài)和外觀的樣板；最后提交設(shè)計(jì)就是等著設(shè)計(jì)具體樣子和著手雕刻了！

例子可能不夠恰當(dāng)，但這就是邏輯思路，面對(duì)需求最可怕就是沒思路不知道如何拆解，從一開始就把需求一灘化無從下手，只會(huì)讓后續(xù)的功能無法進(jìn)行。

下面來具體說說如何制作邏輯架構(gòu)，首先我們必須在通過腦圖或者其他工具將單個(gè)需求拆解開來能夠清晰的看到其包含的業(yè)務(wù)線和機(jī)制；

例如，用戶賬號(hào)登錄系統(tǒng)其包含前端登錄交互和后端登錄系統(tǒng)，登錄前置是注冊(cè)，后置信息管理；注冊(cè)需要包含驗(yàn)證和錄入，登錄需要驗(yàn)證正確與否和行為管制（異常驗(yàn)證），信息管理還包括前后端的編輯、新增、驗(yàn)證等等；

通過“需求->概念->抽象->歸納->篩選->具象->邏輯”的步驟等到一個(gè)樹形架構(gòu)概念圖，然后對(duì)這張圖各個(gè)分支節(jié)點(diǎn)進(jìn)行邏輯規(guī)則的初步填充，那么我們就能看到一個(gè)相對(duì)具體的功能系統(tǒng)的邏輯結(jié)構(gòu)了。

在這個(gè)環(huán)節(jié)中我們的主要問題點(diǎn)在概念抽象環(huán)節(jié)，許多朋友不知道如何提取需求中的邏輯元素，這一點(diǎn)需要結(jié)合功能逆推的方法去思考，需求最后提供的功能是什么，這樣的功能需要什么機(jī)制和數(shù)據(jù)支撐，這些數(shù)據(jù)和功能如何整合等。

所以如果你此時(shí)在吃飯且噎住了，請(qǐng)相信我不要妄圖再吃一口來堵下去，不然可能你看不完這篇文章，而你需要的是另一個(gè)方法——喝一點(diǎn)水來疏導(dǎo)。

同理，在邏輯梳理時(shí)不要死命的懟需求原案，適時(shí)適量的從結(jié)果逆推往往效果更好。

另一方面，在邏輯設(shè)定時(shí)應(yīng)提前與技術(shù)口頭上就需求構(gòu)思進(jìn)行溝通，提前了解開發(fā)方案能有效避免許多不必要的邏輯與技術(shù)方案的沖突。

其次在數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)上也應(yīng)該與技術(shù)保持溝通，對(duì)于現(xiàn)有數(shù)據(jù)模型和邏輯有清晰的認(rèn)識(shí)做到心中有數(shù)，這樣才能有效避免冗余。

剩下的就是向下兼容的邏輯考慮，許多系統(tǒng)我們?cè)诘谝辉O(shè)計(jì)時(shí)其實(shí)只是一個(gè)核心版本的架構(gòu)，那么對(duì)于后續(xù)的疊加就需要做好充足的評(píng)估，留好預(yù)置的對(duì)接點(diǎn)避免下次版本設(shè)定時(shí)出現(xiàn)歷史返工。

這個(gè)環(huán)節(jié)主要是數(shù)據(jù)和功能前置，以及回避后續(xù)系統(tǒng)的邏輯沖突，即耦合問題。

邏輯架構(gòu)總結(jié)起來就是其實(shí)也是一句話：“任何龐大的需求體系都必然是由各種細(xì)小功能機(jī)制組合而成！”。

我們做架構(gòu)設(shè)計(jì)時(shí)無外乎就是，將需求拆解轉(zhuǎn)化成功能然后將功能組裝成系統(tǒng)，至于原型界面在你能將邏輯整理規(guī)劃好之后，它們只是順帶的。

三、開發(fā)復(fù)雜和研發(fā)周期

最后，關(guān)于開發(fā)復(fù)雜度和研發(fā)周期，懂程序的看著自己的需求已然心中有數(shù)，不懂程序的應(yīng)急方案是和程序員搞好關(guān)系，不至于估期時(shí)忽悠你，詢問時(shí)懶得理你，長期的建議是花點(diǎn)時(shí)間學(xué)習(xí)下編程達(dá)到能夠?qū)憘€(gè)簡單的小程序就差不多了。

同時(shí)，也給不懂編程和不夠精通編程的小伙伴們以中肯的建議，小功能很多時(shí)候的開發(fā)量絕對(duì)不小，一定要秉持著兼聽的本份仔細(xì)和技術(shù)溝通，不要過于個(gè)人武斷，四十米大刀可不是開玩笑的。

總結(jié)

關(guān)于減少需求返工的問題，主要就是有效的需求收集、準(zhǔn)確的需求分析以及邏輯暢通的架構(gòu)設(shè)計(jì)，對(duì)于需求審核中遇到的問題應(yīng)勇敢面對(duì)、誠懇改進(jìn)，畢竟開發(fā)一半出現(xiàn)問題再整體返工咱們可能要面對(duì)的就不是返工了。

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

題圖來自Unsplash，基于CC0協(xié)議。