jim yeh on 九月 7th, 2007

本文係投稿於 CNet / ZDNet Taiwan 的文章初稿,未經 ZDNet Taiwan 編輯,其內容可能會略有差異。 上次筆者在〈從高鐵談大型公共建設軟體開發專案(下)〉的讀者回應中,發現有位讀者 Luke 留下了網誌鏈結,並在他的網誌當中發表了他的看法。他不同意筆者對大型公共建設軟體專案有關解決問題心態的觀點,他指出事實上開發人員並不是在大型專案中試煉自己的技能,不斷的調適、熟練的過程,這些應該是平時應該要做的工作,而不是把作專案或是產品當成是練兵。 Luke認為開發人員不應藉由大型專案開發過程中試煉自己的技能,而是要在平時就要有足夠的時間讓他們練就好純熟的技能,這樣在專案開發的一開始才能避免不必要的浪費,並且能夠開發出強壯且靈活有深度的架構。 筆者相信許多軟體開發人員都會贊同Luke的觀點,與其把時間耗費在應付專案永無止境的壓力,還不如在平常多花一點時間研究如何把系統做得更好,以節省專案無謂的浪費。然而,「理想與夢想是美麗的,現實卻是殘酷的」,筆者卻擔心這種以開發者角度出發的理想在實際的專案開發上會是個難以實現的夢想。 為什麼筆者會這麼認為呢?依照個人多年來參與軟體專案開發的實際經驗顯示,軟體專案沒有放諸四海皆準的開發方法,所以開發人員很難事先預知他接下來應該學什麼,專案也不可能等他們學好需要的技能才開始,所以他們技能的學習與成長往往是在專案的做中學(learning by doing)的過程中所累積得來的。

Continue reading about 有放諸四海皆準的開發方法嗎?

     
jim yeh on 九月 6th, 2007

在團隊朝向共同目標邁進的過程中,成員間對問題不同的觀點很容易產生一些歧見。而為了尋求共識,團隊成員常會透過對問題進行討論,找出對問題的解決可以化解彼此歧見的做法。昨天,同人與朋友討論到他過去產品開發的失敗經驗,朋友提到了: 當初的真正問題是,特定開發成員個人的目標與方法,與整體團隊是不一致的。而我跟另一位同事都無法改變他,所以失敗了。 這一段話充分地顯露出朋友的心態,然而同人卻認為,用這樣的心態進行溝通,很難會有好結果。為什麼呢?因為溝通是雙向的,當我們討論的出發點是試圖用言語或行為來使對方改變時,這樣的討論並不會有實質的溝通效果,而只是一種單方面的說服行為,此時雙方很難站在對方的立場來思考問題,討論當然不會有交集可言。 其次,朋友所說的「整體團隊目標與方法」其實指的只是團隊中多數人的看法,但這真的是整體團隊目標與方法嗎?可能不同的人會有不同的見解,在團隊尚未達成共識前,這個觀點只是一個在某些人心中未經審視的假設或信念,當我們把個人信念當成團隊目標時,代表我們並沒有對他人不同的信念予以尊重,在這種情況下,對於立場不同對方而言,他憑什麼要聽我們的,為什麼不是我們聽他的呢?

Continue reading about 尋求共識的出發點

     
jim yeh on 九月 5th, 2007

農曆七月俗稱鬼月,一般人認為此時諸事不宜,沒事還是待在家裡比較好。前幾天,從廣播節目聽到主持人提到農曆七月十五日是中元普渡的日子,但從佛教的觀點來看,這一天也是佛歡喜日。主持人訪問了一位法師,提到了佛歡喜日的由來: 佛世時的印度,因為每逢夏日雨季來臨,所有僧侶皆不外出托缽,只在山中林間打坐經行,專心修持,稱作出家眾的「結夏安居」。到七月十五日這一天,所有僧眾會將修行體悟向佛陀一一報告,有許多人因而證果成就佛道。諸佛菩薩見弟子道業有成,感到欣慰和歡喜,安居到此結束,故此日稱為「佛歡喜日」。 其實佛歡喜日這天,同樣也是「盂蘭盆會」的由來,也是大家常聽到的「目蓮救母」的故事,佛陀教導目犍蓮可在七月十五日僧眾結夏安居功德圓滿之日這天修供養,功德更加殊勝,以所得的福報來解救亡母在陰間倒懸之苦。因此佛陀教民眾在七月十五日做「盂蘭盆會」。盂蘭盆原意為「救倒懸」,就是解救在地獄受苦的眾生,同時將功德回向報答父母養育之恩。 所以,農曆七月其實具有感念父母恩德的孝道與發揚推己及人的慈悲精神之雙重意義。然而,除此之外,同人想到的是古人藉由觀察日月及五星運行,所體會的天地四時之象,也就是地支的六合現象,也可以從天地運行的觀點來認識鬼月。

Continue reading about 農曆七月真的諸事不宜?

     
jim yeh on 九月 4th, 2007

Julian 又對我在〈需求過程的溝通問題〉提出看法,他認為需求可以改變應該基於兩大前提,亦即: 客戶同意專案時程或是時程內的完成工作項目也要可以隨需求一起變動。 客戶同意專案費用也可以隨需求一起變動。 Julian 用了一些經驗來指出開發者對於允許需求變動會遭遇的困難,最後對於需求變動提出他的結論: 需求應該要可以變動,但是前提是客戶夠好可以負擔多出的時程和費用;如果不行,就要向客戶強調一個穩定的需求對專案能否順利完成的重要性,並盡可能的防止變動的發生。誰叫顧客永遠是對的,開發廠商永遠是被坳的哪一方。 同人認為 Julian 說的都是實情,開發者常會覺得很無奈,有很多事看起來是「形勢比人強」的問題,所以要讓專案順利進行下去,不得不採用權宜之計。但變動真的可以防止嗎?軟體專案的實情常會顯示著一個現象,你愈不讓客戶變更需求,客戶就愈會去變更需求。 為什麼會有這種結果呢?因為甲乙雙方的利益不相容,會讓雙方不斷地嘗試增加或減低資訊不對稱的現象,因而造成彼此相互鬥法的動態系統。但如果變更無法避免,那麼要客戶負擔因變更而多出來的成本及時程是可能的嗎?同人認為要視甲乙雙方所簽訂的合約類型而定,從 Julian 的回應看來,我想他所做的專案都是 fixed-price 或 lump-sum 合約而不是 T&M (time and material) 合約。 本來專案合約的類型就不是開發者可以決定的,而是軟體公司與客戶高層間的協議,然而如果開發者如果清楚合約類型的不同,與成本風險息息相關,或許就更可以不去抱持不必要的期望,也就不會有那麼多的抱怨了,至少抱怨的對象可以換一下。;^)

Continue reading about 合約與需求變更

     
jim yeh on 九月 3rd, 2007

最近有網友 Julian 對〈被遺漏的需求〉提出他的觀點,他認為在需求過程中,客戶端負責人員事前不用心收集真正使用者的需求。在事後提出了許多需求變動卻不願意延長專案時程與負擔增加的費用;況且即使客戶答應追加費用和延長專案時程,他認為他也不一定還有資源可以完成其提出的變動,因為資源的使用時間是有限的,一旦超過了資源的使用期限,他必須釋放這些資源給公司的下一個專案。於是他說: 因此在從事專案開發時,我仍然會向客戶強調專案需求的不可變動性,目的是希望他們能看重自己應該負擔的責任,在專案開始前審慎收集及評估種種需求。在專案接近尾聲後若客戶再提出要改東西,我們也比較好大聲的說:要改?先上線和驗收後再拿錢來談吧! Julian 的觀點其實很清楚地顯示需求變更在開發過程中對開發者的困擾,及對需求提供者深切的期望,對於一直從事軟體開發的同人而言,當然很能體會他的心境。但當我們希望客戶能體會開發者的難處,傾聽我們的心聲,希望他們能用心地收集客戶的需求時,但站在客戶的立場來看,他們會不會也希望開發者應該發揮專業,「用心」地導出需求,以有效地解決客戶與使用者的問題。 換句話說,當我們要求客戶正視他們的責任時,有沒有想過開發者的專業在那裡?如果只是一味地要求客戶,卻沒有自我省思時,需求過程就會產生溝通問題

Continue reading about 需求過程的溝通問題

     
jim yeh on 九月 3rd, 2007

本文係投稿於 CNet / ZDNet Taiwan 的文章初稿,未經 ZDNet Taiwan 編輯,其內容可能會略有差異。 近年來在台灣,專業能力認證逐漸形成了一股潮流與趨勢,認證的風氣方興未艾,尤其是對複雜性相當高的大型軟體專案而言,似乎取得了 CMMI 及 PMP 認證的就代表可以增加專案成功的機會。 然而,有一些人卻提出一些不同的看法,有人提出了 PMP不一定是專案成功的保證,即使拿到了 PMP 證照,如果溝通協調的能力沒有提昇到一定的水準,專案管理的工作很可能會徒勞無功甚至一無所得。 另外也有人斷言,要是沒有足夠的根基,無論手上有多少證書,要順利完成一個專案,恐怕還只得聽天由命罷了。而高鐵售票系統出了大問題,卻是由通過 CMMI ML3 的系統承包商所開發的,也讓許多人開始對 CMMI 真能保證軟體開發的品質之權威性產生質疑,於是有人提出了,不要迷信認證,人員素質才是成功的關鍵。 這些對 CMMI 及 PMP 認證的反面意見其實都指向著一個重要觀點,專案要成功,所憑藉的不是認證中所規範的標準程序或是作業流程,而是人員的專業能力與素質。專案會遇到的問題千變萬化,複雜性不是認證有限的程序與流程所能規範的。人對了,世界才會正確。因此,變化無常的專案世界中,最可貴的是專案團隊成員的能力與素質,而非認證中所規範的程序與流程。 問題在管理 認證真的不重要嗎?管理者關心專案目標能否達成,所以,重要的是「認證如何提昇專案的價值?」,而不是落入完善制度與人員素質孰輕孰重的兩難之局,筆者認為這兩者是相輔相成,而不是互相競爭的。換言之,專案管理當局不應該完全執著於認證,但卻也不應該全盤否定認證的價值,重點在於管理者的認知,是真的覺得認證可以解決專案的問題,還是以為認證了之後問題就不會發生了?當然,這無關乎對和錯,但卻與管理是否有效有直接而深遠的關係。

Continue reading about 認證不重要嗎?

     
jim yeh on 九月 3rd, 2007

ZDNet Taiwan 轉錄了同人的〈大型公共建設軟體專案後續討論〉這篇文章,有網友留言對我不猜問題的定義提出了「對問題非猜測的想法」會形成悖論(paradox)的看法。 科學理論的建立,比之這些商業行為了更加嚴謹,但還是能看到有後人推翻前人的決定,何況平凡的一般人?所以若是更進一步地看看作者對於猜的定義,也可以發現「不猜」只是一種不可能的的謊言。作者對猜測的定義是:「非猜測的行為是指對於自己所做的分析猜測,後來做了驗証的動作。」但因為驗証必在提出猜測之後才能發生,仔細想想就知道這是矛盾的,而這種定義即是所謂的 paradox(悖論)。 你無法提出一個「非猜測」,因為你無法提出一個「己經驗証的猜測」。 你也無法提出一個「猜測」,因為你無法確定之後猜測「會不會被驗証」。 一個邏輯上就有問題的規則,怎麼有人還能去遵守?不如把心力放在真正要關心的事情之上…其實世上無人是全知全能,人類的每一個決定最終都只是猜測。 看到這篇回應,同人的第一個想到的是,在《別鬧了,費曼先生》中有一篇〈假聰明,真笨蛋〉的文章,這篇文章提到費曼先生在 50 年代初期,他曾應邀參與一個研討會,談論「平等之道德問題」的感想。他對其他與會者對討論主題沒有明確界定,只有一團團的迷霧讓人搞不清楚他們在說什麼。而會中所發表的一篇論文,他一開始看不懂,但仔細地慢慢讀之後才發現,在華麗的包裝下,那篇論文內容空洞萬分,他認為從那篇論文中,根本看不到什麼內容。 費曼先生在那篇文章中還提到他在那場會議經歷的一件趣事,有一位速記員跑來問費曼先生的職業,他認為他應該不是教授,費曼先生回答他就是個教授。速記員進一步問費曼先生是那一方面的教授時,他終於了解到為什麼他認為費曼先生應該不是教授的原因了。他說: 你看,我是個速記員,我把大家說的每一句話都記錄下來。但他們說的我全聽不懂,而每次你站起來問問題或者說些什麼,我卻能明白你說些什麼。因此我原本以為你不可能是個教授。 費曼先生注意到在那場會議中,每個人都只從自己的角度談問題,完全不管其他人的觀點。他認為明明什麼結果都沒有,其他人卻都拼命地說收穫多豐富、會議多成功等等,但對於觀點不同的意見出現時,卻只會發生無意義的爭辯。於是費曼先生發現,這場會議有許多經過偽裝的笨蛋把他逼瘋了。他提到: 一般的笨蛋還好,你可以跟他們談、解釋,幫助他們走出迷惘。但經過偽裝的笨蛋-明明是笨蛋卻假裝不是,拼命想叫別人佩服他們,希望別人覺得他們聰明、偉大。…一般的的笨蛋並不會騙人,誠實的笨蛋都很不錯;但是,不誠實的笨蛋便糟糕透了!而那就是我在會議中要應付的-一群偽裝過的假聰明,真笨蛋…。 費曼先生對於那種明明不懂還裝懂的人,認為他們在表面上裝出無所不知的聰明,實際上卻是十足的笨蛋,因為他們無法正視自己的無知,讓自己可以走出迷惘,所以這樣的人根本就不用跟他們談。雖然網友對同人文章的那篇回應也讓我感受到一團迷霧,但相信理性的對話還是可以讓真理浮現的,所以我嘗試著先從理解對方所要表達的意思開始。 科學理論的建立,比之這些商業行為了更加嚴謹,但還是能看到有後人推翻前人的決定,何況平凡的一般人? 其實每個人對是非對錯都會有不一樣的認定,因此「事情的好壞並不重要,重要的是你的想法及看法」。但如果因為怕被推翻,因而面對問題裹足不前,那麼什麼事都無法做好。所以,不要以猜測來解決問題的訴求重點並不是從結果來證明我們的一開始的猜測是否正確,因為問題解決並不像算命,必須鐵口直斷才能顯出判斷的神準。而是解決問題過程的品質:開發者有沒有針對對問題的觀察,透過思考、假設與驗證來找出問題,還是只是憑記憶中的刻板印象來反應問題,這兩者對解決問題的成效是會有很大的差別的。

Continue reading about 解決問題不能不猜測嗎?

     
jim yeh on 九月 3rd, 2007

人生是一連串不斷選擇的過程,無論這些選擇是有意識的,或是在潛意識中進行,我們總是無時無刻地在做選擇。為什麼提這個呢?前幾天在公車上看到兩個身著建中及北一女制服的青年在聊課業,聽他們的對話剛好讓我對人生的選擇產生了一些想法。 男:我的國文很不好。 女:為什麼? 男:因為國文老師上課都在唱歌,我不喜歡他的教學方式,而且我不知道他教那些東西幹嘛,我覺得他該教的東西都沒有教。 女:哦。 … 這個對話真是有趣,表面上國文學不好,好像是老師沒有教好學生,所以老師有責任。但仔細想一想,學習這件事好像不是老師的問題吧,這個看似建中的學生似乎不自覺地選擇把自己的問題推到別人身上,好像因為老師教不好,所以國文沒學好,就不是我的問題了。這種心態,實在不是一個可以獨立自主的青年應有的學習態度。

Continue reading about 人生的選擇