jim yeh on 二月 26th, 2007

木星又再一次進入人馬座了,與12年前所不同的是前次乙亥年木土成刑,而今年丁亥年木土卻成三合相位。木星的幸運不再像上次受土星所壓制,而是先前努力今年可望收成的一年;然而開春時盤的行星相位卻多刑衝相位,只有木冥與土星兩三合相位,顯見以今年的年運而言,掌握正確的方向十分重要。 丁亥年開春時盤,以2007年2月18日零時起盤,命宮為天蠍座,宮內有木星與土星成三合相位,與水星及天王星成刑,看來今年還是多意外,因此行事應多採謹慎保守的態度,做任何事都應有萬全的準備及縝密的規劃為宜。 二宮主財,宮頭在人馬座且有冥王星落入,冥王星的極端將加強人馬座在經濟活動的擴張現象,但冥王星刑金星,應小心合夥關係的生變,及孤注一擲的過度投資,除了做好風險控管之外,必須要有明確的目標與做好整體規劃。

Continue reading about 丁亥年運分析

     
jim yeh on 二月 12th, 2007

喲哪桑學長在〈顧客永遠是對的.所以我是對的!?〉中提到了軟體文化的獨裁政體的恐怖-恐怖的不是獨裁者的不夠英明,而是沒有人知道獨裁者不夠英明。 這段話剛好讓我想到我之前寫過的〈容忍異端的文化〉,在組織中,如果有獨裁者存在,他自然不能允許別人有和他不同的意見,一旦發生,就會想盡辦法打壓對方。然而,獨裁者不會承認他是獨裁者,他會用一些冠冕堂皇的理由來包裝他的打壓理由,正如喲哪桑學長所言,那個產品經理以客戶的代言人自居,因此他可以順理成章的取得正當性,而這種正當性可以讓他為所欲為。 依據弗洛姆的理論,在民主社會中,人們有逃避自由的傾向,因為他們對要為自己行為負責任會感到焦慮,於是甘願把主導權交出去,重新去依賴及屈從他人。而逃避自由分為三種行為機制來表現-集權主義、反社會行為及自動從眾。 所以對一個以軟體開發為主要任務的專案團隊而言,一個沒有辦法接納團隊成員有不一樣想法的人,就會形成一個無法容忍異端的文化,而在這個文化之下,主導者建立集權主義,「保護」他的子民,而他的子民只要能放棄自我的理想自動從眾,就可以在這集權中心好好地安身立命,然而對於領導中心不滿的人,則會藉由反社會行為來表達不滿,甚至極端者會有不乏毁滅性的行為。不管是那一種角色,其出發點都是在藉由依賴、屈從他人來抒解無助的感受,但把心理的焦慮壓抑下來,並卻沒有真的解決問題呀!不能容忍異端的組織是很難會有創新發生的。

Continue reading about 建立互賴的軟體開發團隊

     
jim yeh on 二月 9th, 2007

看了喲哪桑學長寫的〈Rule of Thumb in Program Log〉,他說: 程式 Log 的好壞,與軟體開發週期長短有關,也與軟體維護成本有關。 Log 真的很重要,但站在 architect 的角度思考問題,必須考慮多重觀點;所以,我會思考開發人員不寫 Log 的問題是動機問題還是能力問題呢? 如果是動機問題,我想學長的一番話可以激勵開發者,然而如果不單是動機問題,有時候沒有動機是因為能力問題所導致的呢? 「我也想寫 Log 呀,可是時程那麼趕,寫 Log 會增加我們的工作量,Log 可以等以後要 Debug 的時候再寫,先把功能寫出來比較重要!」 開發者的考量也有道理,要解決這個問題,我們應該想辦法讓 Application Log 更容易實現。

Continue reading about 讓 Application Log 更容易實現

     
jim yeh on 二月 7th, 2007

最近有人找我討論專案中日誌功能的整合問題,他認為以 log4j 實作的 Logger 已經完成了,所以系統後端的 service 實作應該直接呼叫到這個特定實作。 不對吧!依據我們系統的架構,任何的實作不應該相依到其它的實作,而是讓有 log 需求的 service 實作擁有一個標準的 Logger 界面,不管以什麼方法實作你的 Logger,只要實作這個標準的界面就可以不讓 service 實作被另一個實作來綁住,這是我們的鬆綁策略,一直以來我們就是這樣做的呀!原來用 console 的 SystemOut 實作,而現在只要把那個實作抽換掉,因為我們用 springframework 來做反轉控制,所以連 Factory 程式都不用寫,只要設定 context 把 Logger 的 bean 應對的 class 換掉就搞定了。 可是對方似乎很堅持,認為用注入的方式太複雜了,他想要用靜態連接,只要用一行程式就好了,不用設什麼設定檔,也不用宣告 attribute 及實作 setter 及 getter。 我發現再這樣討論下去,問題好像會失焦喲,於是問道:請問現行設計有什麼需求不能滿足嗎?對方回應:可以滿足,但這樣作很複雜,程式不好寫,因為…。其實我不想聽他解釋,為什麼?因為既然需求可以滿足,就沒有必要改變我們的設計,他想要做的事是以特定實作來主導設計,而不是面對問題來調整設計,既然要用這種頭痛醫頭,腳痛醫腳的做法,那就不需要架構的藍圖了,而可憐的對方他其實是NPS(No-Problem Syndrome)-沒有問題症候群(Gerald M. Weinberg,1986)的患者,而且似乎病得不輕。

Continue reading about 軟體開發的沒問題症候群

     
jim yeh on 二月 5th, 2007

在獨孤木那邊,有人表達對我的文章的評論: 在我看過同人的文章後. 我覺得他的等級非常高,大概有外太空這麼高. 在外太空這種地方,什麼都沒有. 看到這個回應,我突然想到一段有關國畫大師張大千先生的一段軼事:

Continue reading about 當下即是威力點

     
jim yeh on 二月 5th, 2007

其實我還蠻高興喲哪桑對於我在〈內行人看門道,外行人看熱鬧〉的意見有正面的回應,距離神通高鐵開發團隊,我可能比喲哪桑近了一些,雖然我也沒坐過高鐵,也不屬於高鐵專案成員,但是網路上的言論卻讓我發現,很多人都在不了解狀況下來做評論,這是很危險的。當然,如果立場互換,我的反應可能也會一樣。然而,我觀察到這一點,為文除了自我警愓外,也想藉此做個提醒,有時候我們的觀感可能只是誤解,因為我們沒有看到事情的全貎。 總之,藉由這次事次能認識一個學養豐富又心胸廣闊的朋友,也算是好事一件。喲哪桑說我所引用的參考文獻他也有,真巧!我猜可能是因為我愛看的書和喲哪桑很接近吧,他寫的其它文章一看就知道,呵呵~也是溫伯格書籍的讀者。 看了喲哪桑對我的觀點的感想,我也有一些看法想要表達,於是提出來供大家參考。 喲哪桑所說的 Stakeholder Management 是 PMBOK 第三版新增加的流程-Manage Stakeholder,在 PMBOK 2000 版並沒有這個專案流程。前一版本雖然沒有規範出管理 Stakeholder 的流程,但它卻有提到「專案管理團隊必須識別出 Stakeholder,發掘出他們的需要與期望,然後管理及影響他們的需要與期望以確保專案能夠成功。」,所以管理 Stakeholder 的工作其實是分散在各 Knowledge Areas 的流程中的。而由 PMBOK 第三版把管理 Stakeholder 明顯地寫出來,就知道它的重要性是與日俱增的。 PMBOK 認為識別出 Stakeholder 是格外困難的,到底專案 Stakeholder 是什麼呢?只要是主動參與專案或他們感興趣的事情會對專案的產出或成功有正面或負面的影響的個人或組織。範圍相當廣,不過,當 Stakeholder 的意見衝突時,要以專案的客戶為主,也就是說為了要滿足客戶,其他人的需要及期望都可以被放棄。要在那麼多的不同中找出最接近的解決方案,是專案經理的主要挑戰之一。 以上是管理 Stakeholder 的原理及原則,而實務呢?據我所知,神通大型專案都會管理 Stakeholder,在專案會議中會與客戶討論重大議題並維護 Issue Log,並且會回報給 PMO 以利後續管控。在會議中,專案團隊會與所有 Stakeholder(包括客戶、使用單位及顧問)就議題討論、溝通、協商與談判,如果遇到難題(例如某些 Stakeholder 不肯退讓或專案團隊不該妥協時)會先跟 Stakeholder 保持和諧關係,會議結束後再由專案團隊討論對策後才回覆 Stakeholder,必要時請 PMO 或 Sponsor 出面協調。所以神通在專案管理方面是很重視 Stakeholder Management 的。

Continue reading about 有關「Stakeholder Management」的後續討論

     
jim yeh on 二月 3rd, 2007

最近高鐵售票系統的問題,在網路上引來許多的的熱烈討論。其中喲哪桑在〈從高鐵售票看 CMMI 〉一文中認為神通的問題是開發者與 CMMI 都有問題,有網友針對這個觀點評論說: 就我所知,CMMI是用來規範開發流程,使專案能夠在規定的時間及預算內完成,至於開發出的產品是好是壞,就不是CMMI能控制的了。 另外神通電腦的客戶是高鐵公司,而不是乘客。提需求的是高鐵,驗收的也是高鐵,只要高鐵驗收通過,就不是神通的責任,是高鐵要對民眾負責。 喲哪桑對這則評論另行撰文,並提出: 坦白說,猛然一看我還有點氣,然而再想想,這不正是典型工程師的想法嗎? 「我就只是照規格做哇!你們規格這樣開,我也照著做,明明我沒做錯,為什麼要罵我小小工程師呢?」 唉!這下不只要說ML3的PA沒做好,我還想請神通與高鐵的人去看看PMBOK、看看Stakeholder Management了。 看了這一連串的對話,我發現似乎很多人都可以從高鐵售票系統指出神通的問題,好像他們都變成無所不知的專家,那這樣神通找他們當顧問是不是就會成功了呢? 很明顯地,以上推論並不會成立,為什麼呢?因為那些專家只是在紙上談兵,他們建構了許多假設,然後依據這些假設作出結論。然而那些假設都是未經證實的,所以如果神通找他們當顧問,我想專案要成功就會遭遇更大的風險,因為假設往往是專案風險的主要來源。

Continue reading about 內行人看門道,外行人看熱鬧