一眨眼，加入阿裡大家庭已經一年多啦。在一年多的工作中，深深感受到網際網路項目管理與傳統it項目管理的不同，在此嘗試做一下簡單的總結和分析。
本文先講一講需求管理。為啥要先說需求管理呢，因為在所有影響項目成功與否的因素當中，需求對項目的影響力，至少占50%以上。能夠控制管理好需求，項目就成功了一半。
網際網路是一個快速變化的世界，我們所面臨的使用者、環境每天都在改變，這就要求項目團隊能夠适應這種情況，要能夠做到快速疊代、快速上線、快速試錯、搶占使用者。不同于傳統的軟體項目，動辄幾個月甚至幾年的項目周期，網際網路項目通常是以周為機關進行疊代。相對于需求，速度、搶占使用者的速度更加重要。我們需要産品快速上線，更快的擷取使用者回報，在使用者參與和回報中逐漸改進完善産品。
是以，我們要懂得取舍，懂得對不重要的需求說不。
當然，說不不代表不去實作，後期發現這個需求必須實作，你可以補上，總體工作量并沒有增加。
如注冊使用者的功能，可以做得很複雜，也可以隻有使用者名、郵箱、密碼和驗證碼這幾個簡單項，很顯然，前者中有大量的資訊項是不必要的，這些資訊項可以先設計出來，然後放在下一個疊代中去完成。但如果産品的第一個版本就去全部實作，這些不必要的内容會增加開發、測試環節的工作量。
這是傳統it項目與網際網路項目最大的不同。傳統it項目開發周期非常長，會做長時間的需求調研，需求大而全；而網際網路項目大多小而精，在持續不斷的疊代中優化産品。
項目經理需要根據業務需求确定優先級，需求的優先級應該滿足如下幾點：
體驗性的需求優先級就比較低。比如筆者負責的一個處理買家投訴的系統，投訴案件的處理流程是整個系統的核心，應該先完成；而對案件進行批量處理就是一個改善性需求，優先級就沒有那麼高。
這個應該先完成。隻有這樣，才能不影響依賴它的需求的開發。比如建立案件功能，後續的案件處理都需要圍繞建立的案件來進行，是以必須先開發。
這個應該先完成。對于一些模糊的需求，必須等業務方和pd讨論清楚了再動手。如果開發人員按自己的了解去完成了一些不是很明确的需求，結果後面發現需求要改，那前期的一些工作量已經浪費了。
在傳統it項目中，還有一種需求雖然從功能上來說可能優先級很低，但從關注度來說由于是對方公司上司或核心人員很看重的，優先級也會很高，必須優先實作。（不是本文讨論的重點）
确定好需求的優先級後，在項目開發後期，如果項目可能出現延期，項目經理就可以對一些優先級低的需求進行取舍，保證項目按計劃釋出。最後這些未實作的需求可以順延到下一個疊代周期去完成。
網際網路産品需求其實有兩個極端，一個是盡善盡美，盡可能的讓功能更友好，使用者體驗更佳；一個是盡早傳遞，一切改善性的需求都可以犧牲。
隻滿足前者，項目進度可能會不斷的拖延，因為很多功能的工作量其實是在使用者體驗的優化，而不是主要流程的完成。隻滿足後者，很可能會出現一個讓使用者很不滿意的産品。
一個有經驗的産品經理（項目經理），可以很好的平衡好這兩點。這裡有一個方法就是和業務方提前溝通好系統每個功能的互動體驗需要達到什麼效果。
筆者在設計買家投訴系統時，案件查詢有一個目前案件處理人的查詢條件。如果要項目盡早完成，那麼我們就放一個輸入框讓使用者自己輸入處理人賬号就行。如果我們做一下适當優化，可以使用一個下拉框，裡面列出目前所有的案件處理人，讓使用者選擇；更好的體驗是讓使用者自由的在這個輸入框裡面輸入賬号字母，然後系統就會自己顯示相比對的處理人賬号讓使用者選擇。三個不同實作花費的時間是逐漸增多的。但是如果這兩種改進都不做，讓使用者隻是自由輸入的話，使用者互動體驗效果就會很差。具體最終使用哪一個設計，就需要和業務方溝通及平衡工期來确定。
這個世界唯一不變的就是變化了。項目一旦開始，變更也就随之而來。基本上每個項目在開發過程中都會遇到需求變更，這是沒法完全避免的，隻能通過一些方法來控制需求變更的影響範圍。變更不可怕，可怕的是變更不受控制。
是以，項目開始之前先問下業務方或pd為什麼要這樣做，上線後能帶來的業務價值是什麼。 讓業務方或pd把自己的需求想清楚，因為很多時候他們自己還沒想清楚的時候就讓你去實作。
如我們在設計使用者投訴系統時，考慮到不同類型的案件，需要使用者輸入的資訊可能有所不同，是以使用者送出案件界面我們設計了可配置界面，使用者的所有輸入資訊都可配置。後來當新增加一個案件類型時，我們隻需要在背景進行輸入資訊的配置即可，完全實作了代碼的零改動。
所有需求變更都需要該接口人同意。接口人需要對系統架構和業務需求非常清楚，一般都是項目經理。經常到了項目開發後期，都快上線了，業務人員或pd會過來說：“我這裡有一個需求當時沒想清楚，現在想清楚了，你幫我加上去”。這個時候需求的任何變化對工期的影響都是非常大的。一般到了項目後期，我的經驗是，除非這個功能對這期上線的版本有重大影響，否則都放在下一個疊代中去完成。
之前有一個項目，第二天就要釋出了，業務人員跑過來說要增加一個小需求，而我們的開發人員也很好說話，二話不說就加上去了。結果導緻項目釋出延期。而這個需求我們後來評估隻是一個很小的改善性需求，放到下個疊代中去實作完全沒有任何影響。
業務人員有時候提出的需求具有一定的前瞻實驗性質，這時候我們需要将該需求快速上線并接受市場的檢驗，如果業務人員提出的需求滿足市場需要，則可以推廣實施。否則将該需求進行修改完善。
系統需求可以分為功能性需求和非功能性需求，業務人員或pd提出的需求一般稱之為功能性需求，也就是系統必須完成的行為或功能。非功能性需求是指依一些條件判斷系統運作情形或其特性。包括安全性、可靠性、健壯性、靈活性、可擴充性等。
業務人員或pd對非功能性需求往往不太關注，這就要求項目團隊在進行系統架構設計時需要根據項目的具體背景如目标使用者群、通路量等考慮如何實作非功能性需求。同時在制定項目計劃時，也要考慮實作這些内容的工作量。非功能性需求的實作往往是考驗項目團隊系統架構設計能力的時候。
在我們的實際工作中，非功能性的需求往往需要和基礎架構一起配合實作。比如基礎架構幫我們實作了一部分的安全性、可靠性、健壯性、可擴充性等。但有一些是系統自己本身要考慮的。如産品評價清單使用者通路量很大，我們在實作時可以考慮将其放入tair緩存。如果通路量進一步上升導緻tair限流，這時候可以考慮加入本地緩存來做分級緩存。
再比如如果我們開發的是一個内部系統，對浏覽器的相容性要求就沒有那麼高；如果是一個外部系統，在開發時就需要考慮支援目前主流的浏覽器，對浏覽器相容性做好測試。
在進行非功能性需求設計時，還需要注意的一點就是不要過度設計。這裡所說的更多的是技術上的過度設計。設計過度複雜的系統會限制擴充能力。簡單的系統更容易維護和擴充，且成本更低。當然，不過度設計不代表輕視設計，而是演進式的設計。每一次的重構和疊代都映射和更新到最新的設計中來，進而最大限度的滿足系統的功能性需求和非功能性需求。（扯遠了）
總之，如果不在系統設計時充分考慮非功能性需求的實作，往往會在系統上線後帶來嚴重後果。
項目經過幾輪疊代後，整體架構和需求趨于穩定，這時候項目更多的時間是對需求細節的完善。這時候提出需求的業務方，更多的是系統某一個功能的使用者，提出的需求往往具有片面性。這時候作為系統開發人員，要站在全局的角度去考慮問題，避免實作需求後卻對系統的靈活性、擴充性等産生影響。
![項目品質管理-知識領域[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)