中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

需求返工的問題主要出現在需求的收集分析、概念架構的設計、系統邏輯的設計、開發復雜度的考量、研發周期的限制這些問題上，下面就這幾點綜合討論下。

一、需求收集分析

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

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

說完常見問題環節，下面來說說相關處理方法。

1. 需求收集

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

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

基于這用戶和場景我們對收集到的需求進行核心交集處理，這一步能夠相對準確的圈出需求內容，然后對得到的需求進行“拓展需求”的篩選，因為偶然有一些需求是在交集之外卻也很有價值，時間允許的情況也是建議過一遍的。

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

當完成初步需求篩選后，我們需要基于現狀對需求進行優先級整理，首先考量的是產品當前狀態下最迫切的任務是什么，例如起步階段面對非急需的大型系統需求我們就會考慮往后放一放，而能夠快速開發且帶來用戶增長和存留以及轉化的會考慮優先解決。

其次優先解決大面積用戶的基本需求，所謂的基本需求就是這需求不解決人家都懶得理你了，大家都不理你了難不成咱們去為少量用戶重新定位？

這不現實，畢竟不到當前定位的生命晚期誰也不愿意重新定位用戶群。最后是對需求的開發量和版本規劃的評估進行綜合排序。

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

2. 需求分析

有效的整理需求倉庫能夠從起點就避免掉無效的產品勞動！

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

關于需求分析主要分析哪些內容，宏觀上我們拆分為兩部分，分別是業務分析和開發分析。

業務分析是基于產品定位、企業戰略需求、產品周期規劃這三方面，同時這三方面需要綜合并行考慮，而不是串行流程過濾，基于定位考量能夠有效控制產品性質的穩定和業務的精準，周期規劃是產品成長的規律偏離可能就會造成產品的無效成長和冗余；

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

（1）業務分析

那么，如何做好業務分析？在做需求分析之前我們必須先弄明白產品定位、戰略需求和周期規劃。

很多產品在研發時根本就沒有過定位的思考，而是想到哪做到哪，這就導致產品功能系統越來越龐大臃腫，業務效率越來越低，程序邏輯越來越雜亂交錯，最終形成一灘爛泥，動刀的代價太大只能放棄。

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

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

在這個環節常常遇到的問題是戰略太模糊甚至空泛，這時候我們需要做的是與高層詳細溝通以及精確細化戰略，磨刀不誤砍柴工。而戰略分析主要是指提煉出業務方向和范圍，明確出具體涉及的系統和架構。

最后是周期規劃，這個規劃中主要考慮的還是既定規劃和需求的交集，以及版本設定的優先級和邏輯前后置問題，常見問題是經常出現做好的需求發現開發周期過長或者前置內容未建立，以及無后續考慮。

（2）研發分析

符合業務分析后就是研發分析環節了，在這個環節中我們要考慮的就包括需求的開發難度和周期、系統架構設計和調整、需求邏輯轉化、數據需求和橋接等眾多極度理性和邏輯的事情。

這里涉及到的處理方法我們綜合起來主要是，面對新的調整如何讓現有機制盡可能的少做調整、對新增數據進行閉環設計、對刪減機制做好延伸測評、對新的系統盡可能的組件化、對核心用戶體驗做到足夠考量！

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

另一方面是將新的邏輯需求避免在現有系統中做零碎處理，以便減少邊緣和孤立機制點的存在，同時盡可能使用通用模塊降低架構的零散性提高通用模塊的集成樞紐意義。

例如，對于復雜的訂單系統我們通常會設計一個獨立的訂單管理樞紐，各個系統的訂單增刪查改均會從這里經過，這對整個產品來說就是一個集散點，基本管理和監控在這里都能等到數據和功能支撐，而不必每次涉及到訂單就要去涉及和開發一個新的機制;

同時如果訂單系統發生大的變動我們只需要在訂單系統內部調整即可，其他系統我們在樞紐位置做好兼容處理就完事了。這樣的思想在面向對象編程中有個非常類似的概念叫單例模式，有興趣的小伙伴可以去了解下。

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

（3）延伸評測

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

在這個環節我們在常遇到的返工問題就是，新的機制未能與已有系統融合甚至產生各種錯誤，因此在分析需求時首先必須足夠了解原有系統機制，其次是最大限度遍歷出所有牽涉的機制，并做好后續兼容考慮。

最后是核心用戶體驗，一句話說明：任何拋開用戶畫像和使用場景的用戶體驗設計必然是空中樓閣，而需求設計離開了用戶體驗只是一堆粗糙的積木。

總結下來其實所謂的需求收集分析，無外乎結合內外對已知的需求進行有效化、優先級化、邏輯化、數據化以及版本化！

在上文中，相信有不少朋友發現一直未提到另一個核心概念——真實需求。

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

二、邏輯架構設計

下面來說說許多不擅長后端的小伙伴關心的問題——邏輯架構設計。

在上面的內容里以及開始闡述架構設計了，這也是需求整理分析后的下一步工作。

邏輯架構，顧名思義是有邏輯的架構。許多產品在設計稿階段其實就已經出現了很大的邏輯問題，這就導致設計稿連討論審核階段都很難通過，就更別說后續的技術和測試評估了。

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

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

對于一個需要將開發需求文檔直接給到技術人員的產品經理來說，邏輯是硬道理！在產品工作中需求返工最大的觸發點就是邏輯架構環節，而順暢的邏輯、明確的架構、精準的功能投放、優秀的頁面交互、清晰的數據結構將決定著一個架構設計的質量.

那么如何設計邏輯？首先我們需要對需求本體進行解構，一個需求會生成那些系統板塊，每個板塊需要什么機制，每個機制需要那些功能，每個功能牽涉那些數據？

然后，每個數據作用于哪些功能，每個功能需要哪些界面，每個界面如何交互？最后對界面進行整合調整，提交設計。

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

再進行機制拆解和梳理即在知道這個雕像是人后在腦海中呈現出各種人類的形象，以支撐下一步設定；

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

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

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

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

通過“需求->概念->抽象->歸納->篩選->具象->邏輯”的步驟等到一個樹形架構概念圖，然后對這張圖各個分支節點進行邏輯規則的初步填充，那么我們就能看到一個相對具體的功能系統的邏輯結構了。

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

所以如果你此時在吃飯且噎住了，請相信我不要妄圖再吃一口來堵下去，不然可能你看不完這篇文章，而你需要的是另一個方法——喝一點水來疏導。

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

另一方面，在邏輯設定時應提前與技術口頭上就需求構思進行溝通，提前了解開發方案能有效避免許多不必要的邏輯與技術方案的沖突。

其次在數據結構設計上也應該與技術保持溝通，對于現有數據模型和邏輯有清晰的認識做到心中有數，這樣才能有效避免冗余。

剩下的就是向下兼容的邏輯考慮，許多系統我們在第一設計時其實只是一個核心版本的架構，那么對于后續的疊加就需要做好充足的評估，留好預置的對接點避免下次版本設定時出現歷史返工。

這個環節主要是數據和功能前置，以及回避后續系統的邏輯沖突，即耦合問題。

邏輯架構總結起來就是其實也是一句話：“任何龐大的需求體系都必然是由各種細小功能機制組合而成！”。

我們做架構設計時無外乎就是，將需求拆解轉化成功能然后將功能組裝成系統，至于原型界面在你能將邏輯整理規劃好之后，它們只是順帶的。

三、開發復雜和研發周期

最后，關于開發復雜度和研發周期，懂程序的看著自己的需求已然心中有數，不懂程序的應急方案是和程序員搞好關系，不至于估期時忽悠你，詢問時懶得理你，長期的建議是花點時間學習下編程達到能夠寫個簡單的小程序就差不多了。

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

總結

關于減少需求返工的問題，主要就是有效的需求收集、準確的需求分析以及邏輯暢通的架構設計，對于需求審核中遇到的問題應勇敢面對、誠懇改進，畢竟開發一半出現問題再整體返工咱們可能要面對的就不是返工了。

本文由 @葉子 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議。