產品之路——項目管理

先講講我們的背景吧——

跨國集團分部，隸屬於技術部下轄產品部；分屬不同的股東管理；但是有一個終極拍板的股東來進行管理；集團產品部跟我們技術部產品部做對接，交接需求；測試亦跟產品一樣；分屬兩部分，開發由我們組成，也也算是一個跨國項目的交接吧。

需求，由集團產品進行挖掘、收集、整理、設計、規劃；我們作為技術對接只是被動接受需求，或者由我們這邊進行一些需求的變更以及需求的跟進；這其中遇到很多的問題；我估計也是大家能遇到的，畢竟我們所屬的老闆不一樣，所追求的目標不一致；這就導致了我接下來要展現的問題與初步的解決方案。

目標不一致，這個是我們最大的分歧，這就造就了對產品產生不一樣的期望值。

我們遇到的問題可以分為四大類;

1、 產品與產品之間遇到的問題

1、 產品交接沒有詳細的需求文檔，只有部分需求收集表文檔，但也是不完善的，經過我對產品的理解，做了如下改動：

修改前

修改後

可以看出整個需求管理都是存在有些問題的，只有不斷的去完善；才能更好的管理需求；在這之前，我們還產生了很多的分歧；因為有些產品的需求不明確就評估工時，到時我們評估的時間與實際開發時間存在很大的偏差；並且我們有兩部分測試就會產生歧義；不同的概念與想法都是不統一；我們沒有一個統一的目標和標準；只有產品不斷的變更；所以，就會造成不斷的加載時間，消耗了我們原本的開發時間和拖延了項目進度。

2、 需求收集描述不清楚，有歧義

需求都是有相應的場景才能顯示其功能作用，不然；產品功能就是一個無用功能；這個需求也就是一個偽需求。

需求是什麼：

滿足剛需、痛點、高頻的服務可以非常不起眼，但是它一定是對用戶有價值的。

需求的描述：

用戶需求:描述用戶在場景中使用產品或系統必須完成的任務，達到用戶對產品或系統的功能訴求。

功能需求:開發人員必須實現的軟件功能，使得用戶在場景中能完成他們的任務，從而滿足業務需求。

但是，從我們交接的情況看，只有一個需求記錄表，並沒有實際性的需求描述，需求的描述也是不清不楚；這就導致我們再整個的開發與測試中存在很大的分歧。我們不同的需求來源在整個的傳遞過程中就產生了失真，各人描述的不一樣，理解也有所不同；所要達成的一致都是開發後的總結。

2、 產品與測試之間的問題

1、 需求交接過程產生失真，沒有很好的進行及時複述；

2、 產品需求表述不清晰，存在歧義；

3、 產品需求記錄無文檔，變更無記錄；

4、 整個產品開發過程無閉環，流程混亂

5、 產品與測試之間不能產生交流，需求變更與需求基本靠猜；

3、 測試與測試之間的問題

1、 測試目標不一致

2、 測試項目與期望值不一致

3、 重複測試bug

4、 測試與UI的之間的問題

1、 測試不按設計稿來進行驗收

2、 UI設計稿與開發功能不一致導致測試存在偏差

3、 設計稿又變動沒做到及時更新及走完閉環

我們遇到的問題還不算多，但是足以拖延整個項目進展，究其根源還是需求開發所造成的；所以重點還是在於需求分析；需求分析的任務是通過詳細調查現實世界要處理的對象，充分了解原系統工作概況，明確用戶的各種需求然後，在此基礎上確定新系統的功能。確定對系統的綜合要求，雖然功能需求是對軟件系統的一項基本需求，但卻並不是唯一的需求，通常對軟件系統有下述幾方面的綜合要求。

1.功能需求

2.性能需求

3.可靠性和可用性需求

4.出錯處理需求

5.接口需求

6.約束

7.逆向需求

8.將來可能提出的要求

過程

需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規格說明、評審。

問題識別：就是從系統角度來理解軟件，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標準。這些需求包括：功能需求(做什麼)、性能需求(要達到什麼指標)、環境需求(如機型、操作系統等)、可靠性需求(不發生故障的概率）、安全保密需求、用戶界面需求、資源使用需求(軟件運行是所需的內存、CPU等)、軟件成本消耗與開發進度需求、預先估計以後系統可能達到的目標。

分析與綜合： 逐步細化所有的軟件功能，找出系統各元素間的聯繫，接口特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。

制訂規格說明書： 即編制文檔，描述需求的文檔稱為軟件需求規格說明書。請注意，需求分析階段的成果是需求規格說明書，向下一階段提交。

評審： 對功能的正確性，完整性和清晰性，以及

究其原因還是需求不明確產生這樣的情況，那什麼是需求的標準呢？我們可以從PRD可以看出

1、 完整性

（1） 用戶才是驗證需求完整性的合適人選，業務導向的層次結構是保障完整性的關鍵。

（2）需求完整性存在不同層面

二、不失真 正確性 無歧義性

三、有優先級

四、有技術早期介入

針對以上問題，我提出了以下解決辦法

1、需求規格說明書採用業務導向的樹型層次結構來組織，不能只說一個需求收集表；

2、緩解溝通失真最有效的方法是及時複述

3、需求分析的本質在於業務分析，而非技術分析，場景、用例需要補充到位；

4、需求變更是對原有需求的背離：說明需求描述與溝通有問題，導致需求在交流的過程產生失真；因此應該加強需求過程的管理，加強溝通手段的管理。

閱讀更多 挖掘需求成就產品 的文章

關鍵字: 軟件 財經 需求分析