都會女子的異想世界

~P161

上週老闆召開技術部門會議，各部門主管報告下半年的工作計畫。

KiKi 媽咪在去年接了個案子，搞了一年，終於第一階段上線了，自我檢討後，將失敗原因大約歸類了一下，並寫下下半年可以針對某一個可行性方案做了計畫，預計在下半年一定要完成一個內部教育訓練，並將之執行下去。

這次報告，KiKi 媽咪排在最後，先聽聽其它相關部門主管的報告。

部門 V 開始報告，這位主管技術能力強，有很多想法，每次在會議報告中總是語出驚人，提出技術開發的方法總是新奇的不得了，聽完報告，好像參加過一場新技術研討會，總覺得自己實在是井底之蛙。

但，好像聽了幾年，有沒有點...怪怪的？

部門 R 開始報告，這位主管剛上任，將帶領 PM & SA team，那簡報，好像在介紹 UML 課程表，心想，會畫 UML 就代表著案子會做好？UML 到底在 SA 中佔著什麼樣的地位？

該 KiKi 媽咪報告了，一開始我就弱了，因為我沒有像前兩個主管，引用一些有名的方法論，而只有一個方法：【經驗】。

KiKi 媽咪要寫下所有 PG 及 SA 會忽略掉的程式撰寫【原則】，並將這些原則的施行當成考績的重要參考，我相信只要注意好這些小細節，程式品質可以上昇 50% 以上。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

回到家，剛好翻到第三部第十七章：自我修復系統，作者也提出，方法及方法論的不同。

引用一段很有趣的內容：

「方法論就是一套通用性的系統理論，用來指導如何從事某一類腦力密集的工作，通常是一本厚重的手冊，其中明確而詳細地規定在任何時機所該採取的步驟，無關乎執行的是什麼人、在那裡或何時。撰寫方法論的是聰明人，執行方法論的則可以是呆瓜，呆瓜不必用腦袋做事...」

將一個應該用腦力工作的聰明人，訓練成不用腦袋工作的呆瓜？
對這些思考型的員工而言，他們會乖乖地照做？
還是陽奉陰違的進行，最後專案搞的亂七八糟？

但方法論真的不好嗎？

不，它是好的！
如何用【方法】去使用，才是真正的關鍵！

作者最後的結論為：

不是不能使用方法論，而是這方法論必須已經在公司實際執行過，並修正過的，最好適用過幾個案子後，才將之變為公司的標準化，這其實就是所謂的：【Best Practice】。

簡單說，Best Practice 不就是俗稱的經驗法則嗎？

書中有句話很有趣，它引用了毛澤東的名言，開發環境應為：百花齊放，百家爭鳴。

我將作者的理念，加上我自己的理念導出：

1. 訓練：有一套共通性的【核心方法】，但讓員工用自己的方法做事。且不斷也提醒及深入員工的心中，重點是：將它放入考績考核中。

2. 工具：使用一些工具，可以助於歸納核心方法，但不需要一定全部照作，如 UML，誰規定一定要畫 sequence diagram？

3. 同儕審查：Review 機制一定不能省，不但可以讓同儕之間更彼此了解及鼓勵外，也可以營造良性競爭的氛圍。

又一個交響樂組織的概念：

一．同時演奏同一樂譜；（核心理念）
二．演奏著必須了解其樂器的特性；（用對工具）
三．指揮必須尊重演奏的專業，並引發出最大的潛力；（訓練）
四．各演奏者間的互相支援；（同儕審查）
五．不斷的練習。（Best Practice）

如同交響情人夢野田妹一樣，創造，會讓心更快樂，當然，產值一定也會相對提高！