靈活開發績效管理之十：阿米巴經營之軟體團隊經營什麼（中）

這是靈活開發績效管理的第十篇。（​​欄目總目錄​​）

經營技術

經營技術是說，不要隻是把做産品/項目的過程當作完成任務或提升自己能力的過程，而是要當作為企業積累技術的過程。

這聽起來很容易，但做起來有難度，比如這幾個問題：

1. 團隊是否有一個可複用的技術庫？（DLL，類，函數，各種層面的）

2. 團隊是否有一個機制令得這些庫被充分利用？（一個可度量名額就是代碼行/功能點，越低越充分）

……

一般而言若不進行有效管理，20人團隊的代碼備援率可能在95%左右，也就是95%左右的代碼是多餘的。在2004年的一次技術改造中，一個19萬行，13人×9年的産品，被改造為1.3萬行，1人×1.5年的相同産品（更關鍵的是缺陷少了，這次改造的直接動因就是原來産品的缺陷衆多而且隐藏很深）。

這并不是個例：這家公司是納斯達克上市的上千人的電信軟體公司，其開發和管理強于一般的中小公司，後者的技術水準可能更差。但由于普遍而言人們使用别人代碼的比例很低（我們常常感覺到用過别人的東西，但若自己數數，又會發現不過就幾百行代碼而已），是以人數越多可壓縮的比例越高；再加上由于多數人連自己的複用做的也不好，是以在未完善管理的情況下，對代碼進行大規模壓縮的潛力一般都接近在2×人數倍以上。

注意這個例子中，較少的代碼不但有更高的生産率，品質也随之提高，甚至更加明顯。

類似這種規模和周期的軟體及團隊，都應該刻意地在開始就不要隻以完成目前任務為唯一目标，而開始架構和積累整個技術架構。

“若剛開始的時候老闆不給充分的時間怎麼辦？”一則我從來沒有見過老闆指着我們的可複用庫說：“不要編寫這個，直接給我壘代碼”；二則及時被給予足夠的時間，多數團隊也沒有形成這樣的可複用庫；三則可複用庫的生效速度是很快的，若前三個月投入複用的時間還沒有賺回來，那麼多半做錯了……考慮到這些，多數時候缺少對技術的經營，其實是我們軟體人員自己的問題。

經營過程

過程就是人們做事的方法，說大一些，就是“企業文化”。

文化是很容易被談論又很容易被忽視的東西。很多底層的程式員能看到遠在天邊的企業文化，但卻看不清楚自己面前的編碼文化。

在2001年的一個團隊裡邊（就是我第一次感受松結對程式設計與139團隊的那個團隊），剛開始隻有5個人，人們不需要專業的測試人員而仰賴高手幫助新手檢視代碼和自己自主測試來保障品質；一年以後，當團隊擴張到25個人的時候，這個傳統仍然存在——此時我們的專業測試人員隻有2個，而且隻負責整體測試。

這是因為在團隊成立的開始，團隊嘗試建立起一種以高品質為榮的團隊文化，所有制造大量的缺陷程式員（包括剛開始時的我本人），都會同時受到鄙視和幫助，人們可以選擇接受兩者，或者隻接受前者。結果是接受幫助的人逐漸擺脫了被鄙視的局面，他們繼承了這種傳統，進而幫助後來的新人。

可以被經營的過程有很多，有很多完全無需上司授權即可進行，另一些需要在進行一定程度後說服上司進行下一步的支援。這些過程包括：

1. 代碼審查

2. 開放的辦公室空間

3. 白闆和經常的讨論會

4. 基于白闆的簡單設計（比如預想陳述）

5. 看闆

6. 松結對程式設計

7. 1-3-9團隊

……

誰來經營

“如果老闆能讓我放手管理，我也可以經營好我們的團隊。可是……”這是常常聽到的一句話。

實際上，老闆一般都是“放手”管理的。多數團隊的上司者（尤其項目經理）與自己團隊相處的時間，超過再上一級的100倍。若這些時間——其實應該說是精力——被充分用來經營團隊，而不是簡單地執行傳聲筒和工頭的角色，本文所說的經營完全可以實作。