互聯網項目的特點之項目管理要點(2)

　　比如我們在做一個注冊的頁面，里面有個城市的輸入框。城市的輸入框可以做得很友好。如果要項目盡早完成，那么這個輸入框我們只要讓用戶自己輸入就行。一個比較好的設計就是兩個下拉環框，一個選擇省份，然后再選擇城市。但是一個更好的設計是讓用戶既可以選擇，也可以自由的在這個輸入框里面輸入拼音首字母，漢字，然后系統就會自己顯示相匹配的城市讓用戶選擇。后兩者的改進肯定會花時間，但是如果這兩種改進都不做，讓用戶只是自由輸入的話，后期維護的時候就會出現用戶輸入不標準的城市數據，如果我們需要用戶的城市數據做一些其他功能，就會有錯誤數據的風險。

　　3. 懂得對不重要的需求說不

　　如果你不能平衡好工期跟功能改進的話，有一點你一定要意識好，就是你一定要懂得對不重要的需求說不。這很簡單，你對一個需求說不，只要這個需求不是一個會造成其他功能依賴的核心需求，就算這個需求后面發現必須實現，你可以補上，總體工作量并沒有增加。但是如果你花資源去完成了這個需求，后面卻發現這個需求是不重要的或者可以簡化的，那你已經浪費了一些工作量。兩者的代價相比，明顯前者的代價比較小。

　　4. 理好需求優先級

　　需求的優先級應該滿足如下幾點：

　　a. 確定不變的需求應該先完成，如果項目組去完成了一些功能，結果后面發現需求要改，那前期的一些工作量已經浪費了。

　　b. 被其他需求依賴的需求應該先完成，只有這樣，才能不擋住依賴它的需求的開發。

　　比如登錄功能，很多登錄后的頁面都需要當前登錄的用戶信息。

　　c. 主流程，或者核心需求應該先完成，改善性的需求應該后完成。

　　比如信息列表頁面，很多功能需要用戶在信息列表里面選擇要操作的記錄。因此信息列表是核心需求。而在信息列表頁里面一個列顯示格式的美化，這屬于改善性需求。

　　#風險管控

　　風險管控是項目經理一個非常重要的技能。一個好的項目經理應該盡量在早期把所有的風險都列出來，一個一個解決。一個流暢的項目，從前期到后期風險點應該是倒三角形的，就是前期風險很多，后期風險越來越少。而項目管理不暢的，則是一個正三角形，上面風險少，到后期風險就多了。

　　項目經理應該盡可能的找出所有的風險點。假設有一個點，你不確定他是不是有風險的，那即使我們把早期把它當做一個風險點重視起來，帶來的代價也遠遠小于在后期等它爆發出來的時候再處理。

　　我們現實中就有一個很適合的例子。我們有一個功能是SSO，讓合作方去調用我們的接口實現免登錄直接從他們的站點跳轉到我們的站點繼續使用。因為關系到第三方，所以我們前期就有些擔心到時候這一塊會不會出現什么東西不可控。

　　不過大家也就是想想而已，沒有太在意。

　　在項目后期的時候，需要跟第三方站點聯調，通過他們的站點來測試我們的SSO接口和接下去的流程是不是可用的。結果這時候發現，因為第三方安全管控很嚴格，外部人員無法訪問他們的站點。于是我們的測試工作就停滯在那邊。后面弄得雞飛狗跳，兩個公司的IT以及架構組的人討論來討論去看這個問題怎么解決。

　　發布時間最終還是因為這一點拖延了。

　　#外部依賴最不可控

　　風險管控還有個要點要記住，項目組能處理的問題，算是小問題。需要項目組外的人員處理的，才是大問題。因為項目組外的人員不受你調配，他應承你的時間不一定是你滿意的時間;即使是你滿意的時間，也不一定真的就能確保在那個時間完成;就算真的完成了，也不一定就達到你想要的效果。

　　#必要的時候，任務要步步緊跟

　　項目經理并不是把任務簡單分出去就可以不管的。如果你的開發人員不是很有經驗，或者技術實力很強，思維很縝密，那你應該緊緊的跟進你分發出去的任務。

　　1. 你應該經常去看一下他們的任務開發到了什么程度，可以的話，讓他運行給你看一下。

　　2. 問一下有沒有什么問題，有什么可以幫助他的。因為很有可能他就有個問題在糾結，而其實你因為經驗或者了解更多的背景，很簡單就為他指出簡單的解決方案。

　　3. 你在檢查的過程當中，也會有可能發現一些他可能還沒發現的問題，或者跟這個任務相關聯的問題。

　　任務的完成進度和完成質量，是影響項目進展的一個重要因素。項目經理的一個主要職能，就是幫助每個任務的快速推進。

　　#做當前，看后續

　　當我們把當前的做的迭代的需求，流程，依賴以及其他的疑問理清楚，讓項目組可以順利推進的時候，項目經理不應該再專注在當前的迭代，而是要開始想整理下一個迭代的事情，讓大家在完成當前迭代的時候，不需要暫停在那邊，去等待梳理下一個迭代的問題。

　　舉一個例子，當前的迭代我們在做用戶登錄的功能，做完這個迭代，接下去我們就要做登錄完的首頁展示。開發組在做登錄的時候，項目經理也跟著在那邊搗騰登錄的細節。等下一個迭代開始的時候，項目組才發現首頁展示只有原型圖，UI 跟HTML都還沒做出來，而其他功能更沒有準備。于是項目組就只好花兩三天的在那邊等UI和HTML。

　　#固定的項目組成員

　　這是一個很簡單的要求，但是并不是所有的人都會重視。

　　正如隨便加一個開發人員進來并不能夠立刻讓整個項目進展加快，換一個人的話，整個進展肯定也會受影響。

　　#組員潛力

　　每一個程序員，測試人員，美工，產品經理，都比你想像的要聰明。如果你沒有對你組員的能力有個清晰的認識，那你可以嘗試給他的任務增加一些難度，超過你原來的預期一點點。他能完成，你以后可以再增加一些難度。直到他直接跟你說他搞不定。如果你覺得你已經有個清晰的認識了，那你也應該記得，只是你覺得。

　　我們有一個項目，里面有個很棒的程序員Joy，平常是個很低調的人。項目經理分任務的時候，就給他幾個特定的模塊讓他完成。他也堅守崗位，做好他份內的事。項目因為種種原因，不斷的拖延。但是Joy還是很誠實的做好他的本分。

　　后來有人跟Joy講，你以后要把自己當dev lead看，所有開發的事情你統籌。

原文轉自：http://www.kjueaiud.com