jim yeh on 十二月 19th, 2007

沒有時程的預估,專案就無從管理;而依照筆者在實務上的觀察中發現,問題的核心並不在時程無法正確預估,而是在於對時程的預估抱持太過樂觀的想法,因而對專案進行了無效的管理。

Continue reading about 軟體專案的樂觀主義

     
jim yeh on 十二月 11th, 2007

雖然「計劃趕不上變化,變化比不上老闆一句話」,但趕不上或比不上並不代表要放棄計劃,否則專案的成功也只是聽天由命的偶然罷了。同人認為,軟體專案要成功,關鍵不在於如何照計劃進行,而是要「計劃」當計劃趕不上變化時該怎麼辦。

Continue reading about 當軟體專案計劃趕不上變化時

     
jim yeh on 十一月 12th, 2007

本文係投稿於 CNet / ZDNet Taiwan 的初稿,並分為上下兩篇文章刊出,未經 ZDNet Taiwan 編輯,其內容可能會略有差異。 如眾所週知的,軟體開發專案具有高度不確定的特質。因此,為了降低需求變動的風險,在專案初期,軟體開發者往往會花費許多的心思,設計出具有彈性的軟體架構以適應未來可能的需求變化。大部分的開發者都了解軟體需求是不可能不改變的,但他們希望不管軟體需求如何變化,軟體開發的設計概念都不會因此受到影響或改變,如果可以做到這一點,軟體開發就會變得比較有效率,同時也能確保所開發之軟體的品質。 然而,現實總是和理想存在著一些落差的,專案的演變往往會超乎開發者事先的預期。尤其是當專案的驗收日期愈來愈接近時,專案可運用的資源也會愈來愈少,專案或許已不如剛開始時充滿了未知與不確定性,但相對地,專案的可變動性也愈來愈小。因此,在專案後期出現專案問題,或是需求的變動,相較於相同專案問題或需求變動在專案初期出現而言,會顯露出更為嚴重的危機與壓力的。 每個人都希望寧願事前多做一些風險管理,勝過事後的危機處理,而且後者的壓力是很容易讓做錯事的。然而,軟體易變的特質及專案環境的不確定性讓人難以捉摸,更不用說預測變化了,卻只能在事後才徒然留下「千金難買早知道,萬金難買後悔藥」的感嘆。但問題還是要解決的,到底軟體開發者在遇到這種危機時該如何處理呢?

Continue reading about 軟體開發者不應該自廢武功!!

     
jim yeh on 十月 5th, 2007

本文係投稿於 CNet / ZDNet Taiwan 的初稿,並分為上下兩篇文章刊出,未經 ZDNet Taiwan 編輯,其內容可能會略有差異。 在日常生活上,我們常會發現從不同觀點中體會出一致性的道理,如同專案管理與易經,我們可以從專案管理的觀念與方法中,常會發現它們與易經的觀念是相通的。尤其在軟體開發團隊中,不管是在問題的解決上或對團隊成員的管理上,都與易經有不謀而合的地方。 其實專案所談的不外乎談人與事,而軟體與其它類型的專案並沒有特殊的差異。因此,我們可以普遍性地說,表面上專案管理與易經看起來各自呈現出不同的風貎,但本質上它們的背後其實存在著共通的一致性的道理。 為什麼會有這種巧合呢?易經所探討的是事物變化的道理,而專案本身就是企業在面臨環境變化的挑戰所應運而生的一種概念。在變化無常的環境中,變是唯一不變的真理,正因為如此,企業要因應環境的十倍速變化,端賴於在專案管理過程中,了解變化的道理來達成專案使命,以滿足企業的實際需求。 所以專案管理和易經的哲理自然是會相通的。換句話說,專案管理雖然是基於專案需要,依照西方的管理理論所發展出來管理概念與方法,但它必然會符合易經的基本原理。 所以,對於專案管理者而言,如果能善用易經哲理,可讓他們在重要概念上具備理解掌握變化原則的能力,同時培養在管理上以簡御繁的技巧。易經的觀念並不複雜,雖然它是探討事物變化的道理,但事物變化的本質是簡易的,是可以被掌握的,事物會遵循著不變的自然法則而改變,而非沒有章法的改變。這就是所謂的易之三義-變易、簡易與不易的道理。

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

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

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

     
jim yeh on 八月 27th, 2007

在軟體開發過程中,需求變動往往會令開發團隊十分困擾,即使許多開發團隊在設計前做了許多努力,希望找到軟體的最完整需求,同時要求使用者確認下來,但最後卻還是發現需求變動終究還是不能避免。最近,同人在上班搭公車的時候,遇見了我目前所參與專案的前一任專案經理,他聽別人告訴他專案此階段已近尾聲了,客戶卻還一直在改需求,他向我表示,他很不能理解這樣的狀況。 怎麼現在還再改需求,那這樣向 power user 展示系統請他們提供對系統意見又有何用? 正巧此時他的站到了,必須下車,臨去之前我只得微笑著告訴他:"需求會變動是很正常的一件事",但我從他的眼中看到他疑惑,似乎是認為專案在需求確認後,不應該任由客戶變更需求。 同人可以理解這位長官的看法,站在管理面的觀點,需求變更會對專案造成不小的影響,既然之前雙方已經針對需求做過確認了,就沒有理由讓需求一改再改,不能因為客戶臨時產生一些新的想法,就要迎合他們改變需求。 不過,從另一個角度來思考,要找到軟體所有的需求,是一件很困難的事情。

Continue reading about 被遺漏的需求

     
jim yeh on 八月 11th, 2007

本篇文章不談高鐵,而是從我所寫的〈從高鐵談大型公共建設軟體開發專案〉的上下篇的讀者迴響中,發現有一些值得探討的議題,在此做個整理。

Continue reading about 大型公共建設軟體專案後續討論

     

本文係投稿於 CNet / ZDNet Taiwan 的上下兩篇文章初稿,未經 ZDNet Taiwan 編輯,其內容可能會略有差異。 這篇文章引來不少爭議,有人認為同人是在為某些組織消毒,所以把同人當人假想敵,而有些情緒性的言詞批評與指責。也有人認為同人說高鐵售票系統未用資料庫技術就是問題所在,以為高鐵售票系統的問題就是迷信新技術。還有人認為,技術才是解決問題的關鍵,要用技術的角度來思考問題才是標準答案。 對於這些意見,同人認為別人的情緒是他的問題,我會寫那篇文章,並不想為誰辯駁,只是提出個人思考的觀點,所以要把同人當成假想敵,想激怒我,本人可沒那麼容易上當。至於看到迷信新技術的推論,實在令人大開眼界,不幸地,這個推論顯然是錯誤的,這就是只會用技術看事情的迷思呀。至於要用技術觀點來思考問題的意見,同人覺得再解釋都顯得多餘了,過去我已談過太多了,碰到沒問題症候群(Gerald M. Weinberg,1986)的患者,這次我選擇躲遠點,明哲保身呀;^)。 以下就是這篇引來不少意見之文章。 高鐵售票系統在上線後產生一連串的問題,除了媒體不斷地報導外,網路上也引起熱烈的討論。其中批評與指責多過讚美,同人對這些意見的感想是「外行人看熱鬧,內行人看門道」。我們是否能從他人的失敗經驗得到些許啟示;還是跟著湊熱鬧,把它當成茶餘飯後的話題,是很值得深思的問題。

Continue reading about 從高鐵售票系統談大型公共建設軟體開發專案