軟體開發的遭遇戰 Software Development and Unexpected Meeting Engagement - 通達人驛站
2015/10/7

軟體開發的遭遇戰 Software Development and Unexpected Meeting Engagement

這篇文章是從 2008 年 4 月寫的《軟體開發和遊擊隊》改寫後重新發表。當時,我和CTO、軟體部門主管(以下簡稱W先生)、Technical Marketing討論了軟體開發流程。

Photo from Marines
我們在討論的過程中,提到了「游擊戰」。但實際上,我們遇到的是未預期的「遭遇戰」。所以我提出對軟體開發「遭遇戰」的三個解法:改善管理手法、加強貫徹的決心、加強人員訓練。

想像一下


你和小隊在森林中急行軍,為的是解救在遠方被敵軍圍困的前哨站。

結果,不知那裏冒出了幾聲槍響和一連串的爆炸聲,你隨即機警的臥倒,但旁邊的弟兄悶哼了一聲,中彈倒在你身邊。

有弟兄放出了煙霧彈,試圖阻礙敵軍視線以減緩敵方火力,但隨即我方的視線也隨之阻礙。因此,無從判斷敵軍的位置,既不知道敵軍的攻勢,也不知道要朝那個方向回擊。

你用無線電向連部回報狀況,但卻從無線電傳來「迅速脫離戰場」的命令。

雖然你心裏不願意,但還是授命,同時向弟兄下達埋地雷的命令,以避免敵人進一步的追擊,造成人員再傷亡。

你們埋了幾個 M18A1 Claymore,又稱為「闊劍地雷」的反步兵地雷,殺傷範圍是前方60度扇形方向的 50 米範圍。

在沒有敵軍追擊的情況下,你們繞過這個敵軍狀況不明的區域,並聯絡上被敵軍圍困的前哨站,在裏應外合下,你的小隊和前哨站的弟兄合力擊退包圍的敵軍。

為了殲滅敵軍,你決定向敵方可能撤退的地點追擊,並用無線電向連部回報、以尋求火力及人員支援。

但出呼意外地,無線電傳來的命令卻是「回到上一個區域」。原來,情報顯示,先前脫離的區域再度有敵軍出沒,且有多個友軍單位傳來傷亡,你授命回到該處偵察敵軍狀況。

在即將到達目的地的時候,前方尖兵伍傳來了一連串的爆炸聲。你聽了聲音判斷是尖兵伍踩到了敵方設置的陷阱。你葡伏前進並沿路小心檢查可疑的地點是否還有其他陷阱,過了一會才到達爆炸地點,翻開弟兄的零碎的屍體和爆炸痕跡一看,「靠么」,竟然是離開前為了防範敵軍追擊所埋設的闊劍地雷...


在現實場景中


我在軟體開發檢討會議中,提出了一個比較嚴謹的軟體開發流程,但W先生表示:
這個比較適合開發時間比較長的專案。

像我們這樣新的軟體開發公司,因為要快速反應客戶、市場的需要,通常幾個星期、甚至幾天就要作出產品,並解客戶回報的Bug。

因此我們需要簡化一些步驟,採用較精簡的流程,就像是在遊擊隊一樣,需要靈活的調派人員。


我認同W先生對現實面的考量,畢竟他在美國擔任顧問已經超過二十年,是相當資深的顧問。但也因此,我認為W先生過去的經歷,同樣造成了他在管理部門時有很大的盲點(請見《部門經理和顧問》一文)。

在當天的會議上我並沒有在這個議題上再說什麼,也應與會人員的要求,在下週的會議上提另一個「精簡的流程」。

軟體開發的遭遇戰


只是當我回到座位後,開始回想從我到職以來所遇到的狀況,根本就和被動接敵的「遭遇戰」沒兩樣!

敵人(軟體的Bug)出現的時間、地點、人數、攻擊方式不確定。但我們受命要在不知道敵人是誰的情況下,就要反擊(Work around)!

但當我們回擊後,剛好敵軍停火了,我們天真地以為擊斃敵人!但實際上,我們根本沒看到敵人的屍體(root cause)!

我一直在思考能不能針對這類型的作戰型態預作準備呢?

思考後,我認為「絕對可以!」我甚至認為這種隨機的「遭遇戰」,也可以打的很有組織、很有技巧,因為我發現:
  • 除了隨機出現的敵人(臨時性的廠商需求)外,
  • 其他的敵人根本是我們在前幾場遭遇戰中未完全消滅的敵人餘部(一直使用 work around 解 bug)。
我進一步從過去的接戰記錄(bug list)中發現:我們都太急著想要脫離目前的戰場、去對付更要的目標,而屢次放過了眼前敵人。

一旦這些脫離戰場的敵人,累積到某個程度後又回過頭來反擊時,我們就又得停下原本的腳步、花額外的精力去對付他們。我們就在這不斷的惡性循環中闖不出這個我們自己佈下的泥淖中。

每當我們開始邁向目標的同時,總是有層出不窮、殺不完的敵人出現在我們面前阻撓我們原本的作戰計畫。

軟體開發「遭遇戰」的解決方案


我在前面說:「即使打遭遇戰也可以很有組織、很有技巧」,因為我始終認為:
一流的人才不一定能產出一流的產品,只有一流的團隊才能產出一流的產品;
一流的人才不一定能組成一流的團隊,但一流的管理能造就一流的團隊。

所以我的改善方案是依序完成以下工作:
  1. 改善管理手法
  2. 加強貫徹的決心
  3. 加強人員訓練

改善管理手法


「改善管理手法」是我認為這部門最需要做到的事。

在這間公司,我們目前仰賴個人的能力來運作,但人是會離開的。

我曾見過一位傑出同事(A君)離職後,他的工作分由三個人來接手。但接手的同事卻非常痛苦,因為A君並沒有留下有效、可靠的文件,等到發現A君的程式可能有其他問題需要Debug時,接手的同事無其他文件能參考、僅能一行一行看code,往往累積到有能力去改程式時,幾個星期/月已經匆匆過去了。

而接工作的同事也犯了相同的錯誤:將這些慢慢累積的知識,又繼續放在自己的記憶中。但人的記憶是最靠不住的!等到下個問題出現時、或新增功能時,就又得重花時間回想記憶再次熟悉同一個程式碼。

最嚴重的情況是,當這些接手的同事也離職時,仍然沒有留下有用資訊供接手者參,這個問題就一直惡性循環下去...

我們公司用作專案的態度來作產品,永遠計畫下個 Release 再改善手邊的Bug。但實際上,永遠有更要的事要作,原來的 Bug 因為表面上看不出來、使 priority 降低,又將資源挪去作所謂「更重要」的事了,所以每個 Bug 永遠沒有徹底作完的一天。

因此,我們需要導入一個有效的制度或流程,協助我們能作到必要的事。導入 ISO 系統或其他的管理系統,或許是可行的作法,但即使導入這些系統仍然只完成了一半的事。

制度需要意志貫徹


未完成的另一半,我認為必須靠管理階層展現導入的決心,以貫徹執行制度(維實)。

每每在工作項目不絕、但資源嚴重不足時,就會需要管理階層下達決心,決定要優先完成的事項:是眼前的敵人?還是更重要的敵人?

這讓我想起以前的工作經驗中,曾遇到很有 guts 的經理。

當時,該公司已經建立、並執行軟體開發流程一段時間,也頗俱成效。

但因為人手不足而必須將某些專案外包,所以我們遇到一個難題。我們是否要幫外包廠商訓練人員以符合我們公司的軟體開發流程。後來該經理決定:必須對外包商的相關人員作必要的訓練。

因為他認為:制度是死的,靠的是人的執行力。換句話說:一間公司的竸爭力並非單靠制度,同樣也取決於管理者對執行制度所展現的決心與魄力。

加強人員訓練


不只需要導入 ISO 系統或其他的管理系統,還需要有人按著系統要求去執行。這時就需要透過訓練提昇人員在流程上面的理解,讓員工知道除了自己在特定階段所需要完成的事,還要知道如何和上、下游的成員搭配運作。

這時候,成員除了專精個人技能外,還要知道團隊的其他成員的運作情形。這樣主管才有機會在資源不足時,有機會彈性調派成員去協助/接手其他成員的工作,此外,人員的流動也不致對達成組織目標有太大的影響。

最後,所有成員除了在熟悉個人業務範圍流程外,還必須能反應實際作業與流程之間的差異,這樣才有機會修正既有流程,以提高組織運作的效率和效果。

最後


一般的情況下,能作到上述三點,就能有效降低敵軍(軟體Bug)出現的機率,這樣我們也才能將主要的精力放在主要的敵人(新功能)身上。

在下次的部門會議中,我驚訝地發現硬體部門主管竟然已經意識到這個問題、並開始朝這個目標前進,反觀軟體部門,卻還在原地踏步...

我在《部門經理和顧問》中說:「每個成員的價值不只是他在公司時替公司作了什麼,更重要的是,他做的東西能在他離開公司後、仍能對其他人持續有幫助。」單從這點看,高下立判。

但有些人就是喜歡以「劍及履及」的方式工作,卻一點也不在意最後的工作成果是否有用。
單就這點看,我也無能為力改變誰。
 Related Posts with Thumbnails 

0 意見 :

張貼留言