互聯網項目管理淺析之需求管理（互聯網項目管理淺析之需求管理論文）

背景

一眨眼，加入阿里大家庭已經一年多啦。在一年多的工作中，深深感受到互聯網項目管理與傳統IT項目管理的不同，在此嘗試做一下簡單的總結和分析。

本文先講一講需求管理。為啥要先說需求管理呢，因為在所有影響項目成功與否的因素當中，需求對項目的影響力，至少占50%以上。能夠控制管理好需求，項目就成功了一半。

需求不可貪大求全，要懂得取舍

互聯網是一個快速變化的世界，我們所面臨的用戶、環境每天都在改變，這就要求項目團隊能夠適應這種情況，要能夠做到快速迭代、快速上線、快速試錯、搶占用戶。不同于傳統的軟件項目，動輒幾個月甚至幾年的項目周期，互聯網項目通常是以周為單位進行迭代。相對于需求，速度、搶占用戶的速度更加重要。我們需要產品快速上線，更快的獲取用戶反饋，在用戶參與和反饋中逐步改進完善產品。

因此，我們要懂得取舍，懂得對不重要的需求說不。

當然，說不不代表不去實現，后期發現這個需求必須實現，你可以補上，總體工作量并沒有增加。

如注冊用戶的功能，可以做得很復雜，也可以只有用戶名、郵箱、密碼和驗證碼這幾個簡單項，很顯然，前者中有大量的信息項是不必要的，這些信息項可以先設計出來，然后放在下一個迭代中去完成。但如果產品的第一個版本就去全部實現，這些不必要的內容會增加開發、測試環節的工作量。

這是傳統IT項目與互聯網項目最大的不同。傳統IT項目開發周期非常長，會做長時間的需求調研，需求大而全；而互聯網項目大多小而精，在持續不斷的迭代中優化產品。

確定需求優先級

項目經理需要根據業務需求確定優先級，需求的優先級應該滿足如下幾點：

1. 主流程，或者核心需求優先級最高

體驗性的需求優先級就比較低。比如筆者負責的一個處理買家投訴的系統，投訴案件的處理流程是整個系統的核心，應該先完成；而對案件進行批量處理就是一個改善性需求，優先級就沒有那么高。

2. 被其他需求依賴的需求優先級高

這個應該先完成。只有這樣，才能不影響依賴它的需求的開發。比如創建案件功能，后續的案件處理都需要圍繞創建的案件來進行，因此必須先開發。

3. 確定不變的需求優先級高于不確定的需求

這個應該先完成。對于一些模糊的需求，必須等業務方和PD討論清楚了再動手。如果開發人員按自己的理解去完成了一些不是很明確的需求，結果后面發現需求要改，那前期的一些工作量已經浪費了。

在傳統IT項目中，還有一種需求雖然從功能上來說可能優先級很低，但從關注度來說由于是對方公司領導或核心人員很看重的，優先級也會很高，必須優先實現。（不是本文討論的重點）

確定好需求的優先級后，在項目開發后期，如果項目可能出現延期，項目經理就可以對一些優先級低的需求進行取舍，保證項目按計劃發布。最后這些未實現的需求可以順延到下一個迭代周期去完成。

項目經理要平衡好進度和用戶體驗

互聯網產品需求其實有兩個極端，一個是盡善盡美，盡可能的讓功能更友好，用戶體驗更佳；一個是盡早交付，一切改善性的需求都可以犧牲。

只滿足前者，項目進度可能會不斷的拖延，因為很多功能的工作量其實是在用戶體驗的優化，而不是主要流程的完成。只滿足后者，很可能會出現一個讓用戶很不滿意的產品。

一個有經驗的產品經理（項目經理），可以很好的平衡好這兩點。這里有一個方法就是和業務方提前溝通好系統每個功能的交互體驗需要達到什么效果。

筆者在設計買家投訴系統時，案件查詢有一個當前案件處理人的查詢條件。如果要項目盡早完成，那么我們就放一個輸入框讓用戶自己輸入處理人賬號就行。如果我們做一下適當優化，可以使用一個下拉框，里面列出當前所有的案件處理人，讓用戶選擇；更好的體驗是讓用戶自由的在這個輸入框里面輸入賬號字母，然后系統就會自己顯示相匹配的處理人賬號讓用戶選擇。三個不同實現花費的時間是逐漸增多的。但是如果這兩種改進都不做，讓用戶只是自由輸入的話，用戶交互體驗效果就會很差。具體最終使用哪一個設計，就需要和業務方溝通及平衡工期來確定。

控制好需求變更

這個世界唯一不變的就是變化了。項目一旦開始，變更也就隨之而來。基本上每個項目在開發過程中都會遇到需求變更，這是沒法完全避免的，只能通過一些方法來控制需求變更的影響范圍。變更不可怕，可怕的是變更不受控制。

1.我們首先要明確，項目越到后期，需求變更對項目的影響越大。

因此，項目開始之前先問下業務方或PD為什么要這樣做，上線后能帶來的業務價值是什么。 讓業務方或PD把自己的需求想清楚，因為很多時候他們自己還沒想清楚的時候就讓你去實現。

2.系統設計時要考慮未來的需求變化，使系統具有靈活性和擴展性。

如我們在設計用戶投訴系統時，考慮到不同類型的案件，需要用戶輸入的信息可能有所不同，因此用戶提交案件界面我們設計了可配置界面，用戶的所有輸入信息都可配置。后來當新增加一個案件類型時，我們只需要在后臺進行輸入信息的配置即可，完全實現了代碼的零改動。

3.確定項目需求接口人

所有需求變更都需要該接口人同意。接口人需要對系統架構和業務需求非常清楚，一般都是項目經理。經常到了項目開發后期，都快上線了，業務人員或PD會過來說：“我這里有一個需求當時沒想清楚，現在想清楚了，你幫我加上去”。這個時候需求的任何變化對工期的影響都是非常大的。一般到了項目后期，我的經驗是，除非這個功能對這期上線的版本有重大影響，否則都放在下一個迭代中去完成。

之前有一個項目，第二天就要發布了，業務人員跑過來說要增加一個小需求，而我們的開發人員也很好說話，二話不說就加上去了。結果導致項目發布延期。而這個需求我們后來評估只是一個很小的改善性需求，放到下個迭代中去實現完全沒有任何影響。

4.快速迭代，快速上線，持續完善

業務人員有時候提出的需求具有一定的前瞻實驗性質，這時候我們需要將該需求快速上線并接受市場的檢驗，如果業務人員提出的需求滿足市場需要，則可以推廣實施。否則將該需求進行修改完善。

非功能性需求的管理

系統需求可以分為功能性需求和非功能性需求，業務人員或PD提出的需求一般稱之為功能性需求，也就是系統必須完成的行為或功能。非功能性需求是指依一些條件判斷系統運作情形或其特性。包括安全性、可靠性、健壯性、靈活性、可擴展性等。

業務人員或PD對非功能性需求往往不太關注，這就要求項目團隊在進行系統架構設計時需要根據項目的具體背景如目標用戶群、訪問量等考慮如何實現非功能性需求。同時在制定項目計劃時，也要考慮實現這些內容的工作量。非功能性需求的實現往往是考驗項目團隊系統架構設計能力的時候。

在我們的實際工作中，非功能性的需求往往需要和基礎架構一起配合實現。比如基礎架構幫我們實現了一部分的安全性、可靠性、健壯性、可擴展性等。但有一些是系統自己本身要考慮的。如產品評價列表用戶訪問量很大，我們在實現時可以考慮將其放入tair緩存。如果訪問量進一步上升導致tair限流，這時候可以考慮加入本地緩存來做分級緩存。

再比如如果我們開發的是一個內部系統，對瀏覽器的兼容性要求就沒有那么高；如果是一個外部系統，在開發時就需要考慮支持目前主流的瀏覽器，對瀏覽器兼容性做好測試。

在進行非功能性需求設計時，還需要注意的一點就是不要過度設計。這里所說的更多的是技術上的過度設計。設計過度復雜的系統會限制擴展能力。簡單的系統更容易維護和擴展，且成本更低。當然，不過度設計不代表輕視設計，而是演進式的設計。每一次的重構和迭代都映射和更新到最新的設計中來，從而最大限度的滿足系統的功能性需求和非功能性需求。（扯遠了）

總之，如果不在系統設計時充分考慮非功能性需求的實現，往往會在系統上線后帶來嚴重后果。

日常維護中的小需求的管理

項目經過幾輪迭代后，整體架構和需求趨于穩定，這時候項目更多的時間是對需求細節的完善。這時候提出需求的業務方，更多的是系統某一個功能的使用者，提出的需求往往具有片面性。這時候作為系統開發人員，要站在全局的角度去考慮問題，避免實現需求后卻對系統的靈活性、擴展性等產生影響。