SUMTEC -- There's a thing in my bloglet.

（這一篇更早了，兩年前的了，也是寫一半沒完成，趕緊拯救出來。）

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

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

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

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

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

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

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

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

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

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

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

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