Photo from Marines
我們在討論的過程中，提到了「游擊戰」。但實際上，我們遇到的是未預期的「遭遇戰」。所以我提出對軟體開發「遭遇戰」的三個解法：改善管理手法、加強貫徹的決心、加強人員訓練。
想像一下
你和小隊在森林中急行軍，為的是解救在遠方被敵軍圍困的前哨站。
結果，不知那裏冒出了幾聲槍響和一連串的爆炸聲，你隨即機警的臥倒，但旁邊的弟兄悶哼了一聲，中彈倒在你身邊。
有弟兄放出了煙霧彈，試圖阻礙敵軍視線以減緩敵方火力，但隨即我方的視線也隨之阻礙。因此，無從判斷敵軍的位置，既不知道敵軍的攻勢，也不知道要朝那個方向回擊。
你用無線電向連部回報狀況，但卻從無線電傳來「迅速脫離戰場」的命令。
雖然你心裏不願意，但還是授命，同時向弟兄下達埋地雷的命令，以避免敵人進一步的追擊，造成人員再傷亡。
你們埋了幾個 M18A1 Claymore，又稱為「闊劍地雷」的反步兵地雷，殺傷範圍是前方60度扇形方向的 50 米範圍。
在沒有敵軍追擊的情況下，你們繞過這個敵軍狀況不明的區域，並聯絡上被敵軍圍困的前哨站，在裏應外合下，你的小隊和前哨站的弟兄合力擊退包圍的敵軍。
為了殲滅敵軍，你決定向敵方可能撤退的地點追擊，並用無線電向連部回報、以尋求火力及人員支援。
但出呼意外地，無線電傳來的命令卻是「回到上一個區域」。原來，情報顯示，先前脫離的區域再度有敵軍出沒，且有多個友軍單位傳來傷亡，你授命回到該處偵察敵軍狀況。
在即將到達目的地的時候，前方尖兵伍傳來了一連串的爆炸聲。你聽了聲音判斷是尖兵伍踩到了敵方設置的陷阱。你葡伏前進並沿路小心檢查可疑的地點是否還有其他陷阱，過了一會才到達爆炸地點，翻開弟兄的零碎的屍體和爆炸痕跡一看，「靠么」，竟然是離開前為了防範敵軍追擊所埋設的闊劍地雷...
在現實場景中
我在軟體開發檢討會議中，提出了一個比較嚴謹的軟體開發流程，但W先生表示：
這個比較適合開發時間比較長的專案。
像我們這樣新的軟體開發公司，因為要快速反應客戶、市場的需要，通常幾個星期、甚至幾天就要作出產品，並解客戶回報的Bug。
因此我們需要簡化一些步驟，採用較精簡的流程，就像是在遊擊隊一樣，需要靈活的調派人員。
我認同W先生對現實面的考量，畢竟他在美國擔任顧問已經超過二十年，是相當資深的顧問。但也因此，我認為W先生過去的經歷，同樣造成了他在管理部門時有很大的盲點（請見《部門經理和顧問》一文)。
在當天的會議上我並沒有在這個議題上再說什麼，也應與會人員的要求，在下週的會議上提另一個「精簡的流程」。
軟體開發的遭遇戰
只是當我回到座位後，開始回想從我到職以來所遇到的狀況，根本就和被動接敵的「遭遇戰」沒兩樣！
敵人（軟體的Bug）出現的時間、地點、人數、攻擊方式不確定。但我們受命要在不知道敵人是誰的情況下，就要反擊（Work around）！
但當我們回擊後，剛好敵軍停火了，我們天真地以為擊斃敵人！但實際上，我們根本沒看到敵人的屍體（root cause）！
我一直在思考能不能針對這類型的作戰型態預作準備呢？
思考後，我認為「絕對可以！」我甚至認為這種隨機的「遭遇戰」，也可以打的很有組織、很有技巧，因為我發現：
- 除了隨機出現的敵人（臨時性的廠商需求）外，
- 其他的敵人根本是我們在前幾場遭遇戰中未完全消滅的敵人餘部（一直使用 work around 解 bug）。
一旦這些脫離戰場的敵人，累積到某個程度後又回過頭來反擊時，我們就又得停下原本的腳步、花額外的精力去對付他們。我們就在這不斷的惡性循環中闖不出這個我們自己佈下的泥淖中。
每當我們開始邁向目標的同時，總是有層出不窮、殺不完的敵人出現在我們面前阻撓我們原本的作戰計畫。
軟體開發「遭遇戰」的解決方案
我在前面說：「即使打遭遇戰也可以很有組織、很有技巧」，因為我始終認為：
一流的人才不一定能產出一流的產品，只有一流的團隊才能產出一流的產品；
一流的人才不一定能組成一流的團隊，但一流的管理能造就一流的團隊。
所以我的改善方案是依序完成以下工作：
- 改善管理手法
- 加強貫徹的決心
- 加強人員訓練
改善管理手法
「改善管理手法」是我認為這部門最需要做到的事。
在這間公司，我們目前仰賴個人的能力來運作，但人是會離開的。
我曾見過一位傑出同事（A君）離職後，他的工作分由三個人來接手。但接手的同事卻非常痛苦，因為A君並沒有留下有效、可靠的文件，等到發現A君的程式可能有其他問題需要Debug時，接手的同事無其他文件能參考、僅能一行一行看code，往往累積到有能力去改程式時，幾個星期/月已經匆匆過去了。
而接工作的同事也犯了相同的錯誤：將這些慢慢累積的知識，又繼續放在自己的記憶中。但人的記憶是最靠不住的！等到下個問題出現時、或新增功能時，就又得重花時間回想記憶再次熟悉同一個程式碼。
最嚴重的情況是，當這些接手的同事也離職時，仍然沒有留下有用資訊供接手者參，這個問題就一直惡性循環下去...
我們公司用作專案的態度來作產品，永遠計畫下個 Release 再改善手邊的Bug。但實際上，永遠有更要的事要作，原來的 Bug 因為表面上看不出來、使 priority 降低，又將資源挪去作所謂「更重要」的事了，所以每個 Bug 永遠沒有徹底作完的一天。
因此，我們需要導入一個有效的制度或流程，協助我們能作到必要的事。導入 ISO 系統或其他的管理系統，或許是可行的作法，但即使導入這些系統仍然只完成了一半的事。
制度需要意志貫徹
未完成的另一半，我認為必須靠管理階層展現導入的決心，以貫徹執行制度（維實）。
每每在工作項目不絕、但資源嚴重不足時，就會需要管理階層下達決心，決定要優先完成的事項：是眼前的敵人？還是更重要的敵人？
這讓我想起以前的工作經驗中，曾遇到很有 guts 的經理。
當時，該公司已經建立、並執行軟體開發流程一段時間，也頗俱成效。
但因為人手不足而必須將某些專案外包，所以我們遇到一個難題。我們是否要幫外包廠商訓練人員以符合我們公司的軟體開發流程。後來該經理決定：必須對外包商的相關人員作必要的訓練。
因為他認為：制度是死的，靠的是人的執行力。換句話說：一間公司的竸爭力並非單靠制度，同樣也取決於管理者對執行制度所展現的決心與魄力。
加強人員訓練
不只需要導入 ISO 系統或其他的管理系統，還需要有人按著系統要求去執行。這時就需要透過訓練提昇人員在流程上面的理解，讓員工知道除了自己在特定階段所需要完成的事，還要知道如何和上、下游的成員搭配運作。
這時候，成員除了專精個人技能外，還要知道團隊的其他成員的運作情形。這樣主管才有機會在資源不足時，有機會彈性調派成員去協助/接手其他成員的工作，此外，人員的流動也不致對達成組織目標有太大的影響。
最後，所有成員除了在熟悉個人業務範圍流程外，還必須能反應實際作業與流程之間的差異，這樣才有機會修正既有流程，以提高組織運作的效率和效果。
最後
一般的情況下，能作到上述三點，就能有效降低敵軍（軟體Bug）出現的機率，這樣我們也才能將主要的精力放在主要的敵人（新功能）身上。
在下次的部門會議中，我驚訝地發現硬體部門主管竟然已經意識到這個問題、並開始朝這個目標前進，反觀軟體部門，卻還在原地踏步...
我在《部門經理和顧問》中說：「每個成員的價值不只是他在公司時替公司作了什麼，更重要的是，他做的東西能在他離開公司後、仍能對其他人持續有幫助。」單從這點看，高下立判。
但有些人就是喜歡以「劍及履及」的方式工作，卻一點也不在意最後的工作成果是否有用。
單就這點看，我也無能為力改變誰。
Jose’s Google+ profile
沒有留言:
張貼留言