經過了這一年多,總算,公司總算是找了顧問來協助 CMMI 的導入,因為有政府補助不用錢…真是的。如果沒有這樣的機會,大概公司是永遠都不會有 consultant 介入了。

這 週1~3顧問會來公司幫 RD 們上 CMMI 中開發相關的課程。昨天是 RE(Requirement Engineering),今天是 RM(Requirement Management),明天才會有什麼 technical solution,都是同一個人上的。教法不是很好,條列的在介紹著 CMMI 裡面的一些規則。每一頁還放了過多的文字。第一天還會用力的給他聽一聽、看一看。到了今天,跟本就不想理他,自己看著自己的百年環法特刊跟 eXtreme Programming 的書…有時候是會舉一些例子沒錯,但是跟我們的工作真是風馬牛不相干。偶爾還會說:我不是很了解手機…之類的話。唉~這樣的 consulter 真是好當呀!事前不會了解一下產業的現況,就算找不到,也可以跟我們聊聊。搞到後來,整個課程只有最後的 workshop 改成是手機相關的,事前還說什麼會幫我們公司量身打造課程勒!最重要的是那些 workshop 要做的事情的內容對我們來說還是沒什麼意義,真不知道在搞什麼鬼。

對於這兩天的課程安排真的覺得很怪,為什麼不是教些實務的做法?明明一 開始就說這些課是要給 RD 上的。不教這個也就算了,RE 跟 RM 根本就不是 RD 去管理的,教這個給我們做什麼呢?也許之後被升上以後還可能會用到,但當下不用的話過一陣子也就忘了,那有上還不是跟沒上一樣?

還有,這個 導師看起來對 UML 不熟,所以的 slides 都是以傳統的圖表來繪製。不是 UML 一定好,但至少它已經被許多大型的專案所採用了。就以當做記錄、分析、表達想法的層面而言,實在是很夠了。如果覺得所繪的圖中一些地方可能會造成人家的誤 解,以少量的文字註記不就得了?如果只是為了這種理由而不去使用它,那我想真正的問題應該是他自己那顆不想改變的心吧?UML 之所以成為標準,就是因為它能人所不能。並行程式的設計,這就是傳統 flow chart 所不行的。用一堆風格不一致的圖表去說明東東,看起來才辛苦勒!UML,現在哪個學校沒教勒?呵!當然,我想 XP 跟 UP 他更是不曾去碰過吧,因為在他心中只有 ISO 跟 IEEE,唉~這樣都能當 consulter 的話,那資訊系高中畢業大家都去當專案經理、SA、SD 好了(事實上我是有聽過大學一畢業就當專案經理的)。

以下是我觀查到的這個導師的一些問題:

  • 不會做 slide

一頁放太多字 - 到後來根本就沒有人想看了

圖示少得可憐 - 用很多文字去說明一堆東東的關係,倒不如畫圖輔以少量文字

應該要不時間插 slide map 讓學生知道目前進度、目前在講的東東跟其他章節的關係

  • 不了解學生

不在事前了解學生的背景、經歷

不在事前為學生去調整課程內容

上課時不會觀查學生的反應

不會跟學生互動

只是埋著頭趕進度

  • 不了解現在產業所使用的技術

只能希望,之後主管要去上的哪些課程的內容能新些、正確些,不要把一些過時的東東帶到公司裡強要我們去尊循,這樣子搞的話那工作就不會再是一件愉快的事了。