一個公司宛如一隻球隊，成敗不是一個人的事情，是一整隊的事情。那麼球隊在某一場具體比賽裏面最重要的角色是哪一個？不是教練，如果說整個賽季如何可能是教練的功勞。如果是某一場比賽，最重要的角色是中場。對於公司也有這麼一箇中場的角色，不過不是老總，而是具體的那個產品經理。
其實產品是否成功，部分取決於總體效率如何。我把效率分爲兩個部分，一個是工作效率，一個是規劃效率。
工作效率很好理解，就是每個工時的投入產出比。提高工作效率很好描述：如果我們以每一個人爲座標軸來觀測，就是要求每個人都有合適的負擔，不能夠某個人負擔過重，更不能某個人負擔過輕；如果我們以每一天爲座標軸來觀測，就要求每一天都有合適的負荷，不能一天忙死，一天閒死。合起來很簡單，就是說每一個人每一天都要有合適數量的工作去做。
但是工作效率高了，不代表總體效率就高。比如說每天都在做，但是今天把昨天的推翻了，明天又把今天推翻了，那就是在瞎折騰。所以我們還要有規劃上的效率，保證不會出現類似的情況。上面說的那種瞎折騰看起來好像不可能整天發生，但是實際上在我們面對變化的需求時，就會遇到這樣的事情。
現代的軟件工程是如何保證效率的呢？
從工作效率來講，就是儘可能準確的給出每一個任務需要的時間，然後根據這個時間給出一個時間線（Deadline）。當然，不準確是必然的，於是還可能會中間有些CheckLine來避免無法完成任務的情況到最後快結束時才爆發，然後就是加班加班再加班。Checkline訂多長合適呢？一星期？我個人認爲確定每一天的計劃更爲合理，如果做不到，那麼兩三天也比一星期強。因爲有的時候你會發現有的人做了一天還是好像沒有什麼進展似的，可能性有三個：要麼規劃得不好，沒有自行細分更細的CheckLine；要麼就是覺得得過且過，到那天再說，不急；要麼就是能力不濟，到最後都是這樣。這三種情況我都見過，因此更緊密地時間檢查週期是很有必要的，至少可以及時看出到底出了什麼問題，可以有更大的餘地進行有針對性地調整。
而規劃效率呢，則需要準確區分新增需求、對舊有需求（設計）的改進以及對舊系統Bug的改進。作爲項目經理，這幾個概念是需要嚴格區分的，否則會產生很大的問題（這我也經歷過）。
對於Bug，無論任何時候都是需要及時修改的。那麼什麼是Bug呢？就是系統的實際執行情況，和原來定義的設計是相違背的，或者對於沒有定義的部分，是超出常規思維方式或者邏輯上有矛盾的。與此概念最容易混淆的，是對舊需求（設計）進行改進。我們經常會聽到用戶會反饋類似這樣的抱怨：這個文本編輯器非常的不好用，我想要他固定一個具體的大小，它卻只能夠設置“大中小”，而且還會隨着用戶的操作變大變小；那個上傳圖片的地方也很不好用，只能一張一張照片的上傳。那麼面對這樣的問題，我們可以很簡單的將它和Bug區分開來：想一下這是當初就這麼定義的呢，還是說定義的和用戶一樣，只不過開發人員弄錯了？要區分Bug和需求改進，還有一個很重要的原因，是修改Bug和需求是完全不一樣的。修改Bug的時候，只需要告知程序員哪個地方錯了即可，而修改需求，則需要很多前期的工作，例如確定需求、制定UE、製作UI、套UI、修改代碼等。通常情況下，修改需求都可以“轉化爲”新增一個需求。
而需求方面的新增和改進，則應該在新一個迭代之前收集，迭代開始階段進行設計，然後進入開發階段的時候就不應該再隨意的更改了（除非證明設計有嚴重缺陷）。如果不這麼做，你就會經常體會到今天推翻昨天的代碼的情況。軟件工程有講，軟件開發的整個過程中，越到後面進行修改，成本就越高。這裏隱含着一個意思，就是越到後面出現的改動，你的沮喪情緒也越嚴重。這對整個團隊是非常有傷害的。當然了，這也要求我們的中場，能夠堅守立場不動搖，同時在開始開發之前，認真做好設計。
然而這些並不是做好中場的全部，中場還有一個重要的功能是把前後場聯繫起來，起到承上啓下的作用。如果我們把系統限定爲軟件開發，則後場是UE、UI人員，前場是開發人員。此時中場的一個重要職責是，確定好後場的UE、UI製作是否按時完成，是否達到了前場開發人員能處理的質量水平。有的時候因爲各種原因後場過來的東西，開發人員是無法處理的，例如沒有切圖而把整個頁面的PSD給發過來了。中場就要檢查和避免這種情況，如果你聽UI說做完了，你就認爲做完了，那是很不負責任的。最後，你的工作也可能因爲這樣的原因被拖了進度。
如果我們把系統限定爲整個公司的範圍，則後場是開發部門，前場是銷售和客服部門。這時候，一定要想辦法儘量減少前後場直接來回的情況。原因是，一個這樣會有很多複雜的路徑存在，到時候責任人不好理清楚，響應速度也可能很慢。另一個原因是，前後場直接開大腳，質量很難控制。比如說客服接到反饋說文字編輯器很不好用，直接就告訴相關開發人員，開發人員馬上就開始修改了。這樣做有很多比較要命的缺點：1、所有任務的優先順序可能無法控制；2、開發質量無法控制；3、沒有任何的設計就直接上去了（多數開發人員在這方面確實很差）。也許中場很忙，會有太多的事情做，那麼這個時候也需要交由一個專門的副手來執行着一個工作，而不是前後場大腳亂踢。
如果你的職業規劃中，未來有一段時間是要做中場的，那麼上述的這類概念則必須要清楚。我不知道你的經歷如何，就我的經歷而言，違反上述規則的很常見。甚至有的時候，在某些地方我會被告知那樣做是理所當然的（其實對方也說不出是個什麼理，只是強調就是這樣的，這就對了）。您認爲呢？