艾偉也談項目管理，公司的中場

　　一個公司宛如一隻球隊，成敗不是一個人的事情，是一整隊的事情。那麼球隊在某一場具體比賽裡面最重要的角色是哪一個？不是教練，如果說整個賽季如何可能是教練的功勞。如果是某一場比賽，最重要的角色是中場。對于公司也有這麼一個中場的角色，不過不是老總，而是具體的那個産品經理。

　　其實産品是否成功，部分取決于總體效率如何。我把效率分為兩個部分，一個是工作效率，一個是規劃效率。

　　工作效率很好了解，就是每個工時的投入産出比。提高工作效率很好描述：如果我們以每一個人為坐标軸來觀測，就是要求每個人都有合适的負擔，不能夠某個人負擔過重，更不能某個人負擔過輕；如果我們以每一天為坐标軸來觀測，就要求每一天都有合适的負荷，不能一天忙死，一天閑死。合起來很簡單，就是說每一個人每一天都要有合适數量的工作去做。

　　但是工作效率高了，不代表總體效率就高。比如說每天都在做，但是今天把昨天的推翻了，明天又把今天推翻了，那就是在瞎折騰。是以我們還要有規劃上的效率，保證不會出現類似的情況。上面說的那種瞎折騰看起來好像不可能整天發生，但是實際上在我們面對變化的需求時，就會遇到這樣的事情。

　　現代的軟體工程是如何保證效率的呢？

　　從工作效率來講，就是盡可能準确的給出每一個任務需要的時間，然後根據這個時間給出一個時間線（Deadline）。當然，不準确是必然的，于是還可能會中間有些CheckLine來避免無法完成任務的情況到最後快結束時才爆發，然後就是加班加班再加班。Checkline訂多長合适呢？一星期？我個人認為确定每一天的計劃更為合理，如果做不到，那麼兩三天也比一星期強。因為有的時候你會發現有的人做了一天還是好像沒有什麼進展似的，可能性有三個：要麼規劃得不好，沒有自行細分更細的CheckLine；要麼就是覺得得過且過，到那天再說，不急；要麼就是能力不濟，到最後都是這樣。這三種情況我都見過，是以更緊密地時間檢查周期是很有必要的，至少可以及時看出到底出了什麼問題，可以有更大的餘地進行有針對性地調整。

　　而規劃效率呢，則需要準确區分新增需求、對舊有需求（設計）的改進以及對舊系統Bug的改進。作為項目經理，這幾個概念是需要嚴格區分的，否則會産生很大的問題（這我也經曆過）。

　　對于Bug，無論任何時候都是需要及時修改的。那麼什麼是Bug呢？就是系統的實際執行情況，和原來定義的設計是相違背的，或者對于沒有定義的部分，是超出正常思維方式或者邏輯上有沖突的。與此概念最容易混淆的，是對舊需求（設計）進行改進。我們經常會聽到使用者會回報類似這樣的抱怨：這個文本編輯器非常的不好用，我想要他固定一個具體的大小，它卻隻能夠設定“大中小”，而且還會随着使用者的操作變大變小；那個上傳圖檔的地方也很不好用，隻能一張一張照片的上傳。那麼面對這樣的問題，我們可以很簡單的将它和Bug區分開來：想一下這是當初就這麼定義的呢，還是說定義的和使用者一樣，隻不過開發人員弄錯了？要區分Bug和需求改進，還有一個很重要的原因，是修改Bug和需求是完全不一樣的。修改Bug的時候，隻需要告知程式員哪個地方錯了即可，而修改需求，則需要很多前期的工作，例如确定需求、制定UE、制作UI、套UI、修改代碼等。通常情況下，修改需求都可以“轉化為”新增一個需求。

　　而需求方面的新增和改進，則應該在新一個疊代之前收集，疊代開始階段進行設計，然後進入開發階段的時候就不應該再随意的更改了（除非證明設計有嚴重缺陷）。如果不這麼做，你就會經常體會到今天推翻昨天的代碼的情況。軟體工程有講，軟體開發的整個過程中，越到後面進行修改，成本就越高。這裡隐含着一個意思，就是越到後面出現的改動，你的沮喪情緒也越嚴重。這對整個團隊是非常有傷害的。當然了，這也要求我們的中場，能夠堅守立場不動搖，同時在開始開發之前，認真做好設計。

　　然而這些并不是做好中場的全部，中場還有一個重要的功能是把前後場聯系起來，起到承上啟下的作用。如果我們把系統限定為軟體開發，則後場是UE、UI人員，前場是開發人員。此時中場的一個重要職責是，确定好後場的UE、UI制作是否按時完成，是否達到了前場開發人員能處理的品質水準。有的時候因為各種原因後場過來的東西，開發人員是無法處理的，例如沒有切圖而把整個頁面的PSD給發過來了。中場就要檢查和避免這種情況，如果你聽UI說做完了，你就認為做完了，那是很不負責任的。最後，你的工作也可能因為這樣的原因被拖了進度。

　　如果我們把系統限定為整個公司的範圍，則後場是開發部門，前場是銷售和客服部門。這時候，一定要想辦法盡量減少前後場直接來回的情況。原因是，一個這樣會有很多複雜的路徑存在，到時候責任人不好理清楚，響應速度也可能很慢。另一個原因是，前後場直接開大腳，品質很難控制。比如說客服接到回報說文字編輯器很不好用，直接就告訴相關開發人員，開發人員馬上就開始修改了。這樣做有很多比較要命的缺點：1、所有任務的優先順序可能無法控制；2、開發品質無法控制；3、沒有任何的設計就直接上去了（多數開發人員在這方面确實很差）。也許中場很忙，會有太多的事情做，那麼這個時候也需要交由一個專門的副手來執行着一個工作，而不是前後場大腳亂踢。

　　如果你的職業規劃中，未來有一段時間是要做中場的，那麼上述的這類概念則必須要清楚。我不知道你的經曆如何，就我的經曆而言，違反上述規則的很常見。甚至有的時候，在某些地方我會被告知那樣做是理所當然的（其實對方也說不出是個什麼理，隻是強調就是這樣的，這就對了）。您認為呢？