jim yeh on 十月 21st, 2008

本篇文章是投稿 ZDNet 的文章原稿,並以〈專案不確定導致焦慮與迷失〉與〈專案不確定性導致焦慮與迷失(下)〉兩篇文章刊出。原稿未經 ZDNet 編輯,其內容可能會與刊登的文章內容有約略的不同。 專案經理常會面臨天人交戰的情境。當專案「計劃總是趕不上變化,變化總是比不上老闆的一句話」之時,許多專案經理總是會擔心專案無法如期完成或害怕資源不足,而拒絕或延後專案變更的要求。但這樣的行為,卻往往造成工作成果無法符合專案實際需要的結構性因素,而使得專案的失敗機會大為增加。這對於具備智慧及膽識的專案經理而言,當然並不會樂見專案發生這樣的事情。 筆者前一陣子看到喲哪桑在〈換了屁股,我也換了腦袋〉的分享,提到他在時間緊迫的情形下,接受了專案的功能變更要求。那個變更要求原來是由他所提出,當時前任專案經理以時程緊迫為由而答應延後處理,而一直到他接任專案經理仍然還留在原處。但他認為他不能任由「行為造成結構」的情形發生,於是決定不要再讓這個專案變更要求再次拖延下去,並在當下對專案進行變更。 筆者認為喲哪桑的作為令人激賞,並且覺得那篇文章值得推薦。其原因並不是因為他針對專案變更做了什麼樣的決定,而是欣賞他在決策過程中,展現出面對自己的勇氣與解決問題的思考。不過,卻有其他讀者對那篇文章抱持相反的意見。 某位網友對喲哪桑的分享,批評他是靠感情衝動來管理專案,甚至用了「發瘋了你」、「不適任該離開的時候」等情緒性的字眼來指責喲哪桑的不是。他指出喲哪桑的文章所傳達的意念,實在有不可思議的謬誤,並且擔心那篇文章會透過 ZDNet 的報導,將不正確的知識與觀念誤導一般社會大眾。 然而,他對這篇文章的批評卻使人感到困惑,那位網友認為喲哪桑文章傳達的意念有不可思議的謬誤,但看在專業人士眼裡,這樣的觀點又何嘗不是相當嚴重的偏頗呢?筆者認為他的觀點傳達的意念本質上是一種面對不確定性的焦慮感,進而對改變的抗拒而產生無知的迷惘。 專案變更的基本原則 身為專案經理固然不應該因為個人一時的感情因素而使專案陷入危險之中,但在對專案缺乏可供客觀評論資訊的情況下,只憑專案經理接受專案變更的決定,就加以批判其決策感情衝動是否真的恰當?專案管理並不是神學或是玄學,而是屬於管理科學的範疇。因此,如果有人要批評某個專案經理是用感情衝動來管理專案,必須提出具體的事實根據,否則那只是無憑無據的推論而已,而這樣的推論多半只是源自於自我的偏見與扭曲。

Continue reading about 專案不確定感的焦慮與迷思

     
jim yeh on 八月 13th, 2008

新政府團隊似乎想要在就職典禮的活動上,改變舊制以發揮新創意,營造出耳目一新的感覺。但實際上卻反而把問題複雜化,造成一團混亂。這讓筆者想到在軟體開發過程中,也經常出現同樣的情況。改革的困難正是考驗著領導者的領導能力,他應該如何領導團隊來進行成功的改革呢?

Continue reading about 新官上任三把火

     
jim yeh on 六月 30th, 2008

在現實世界中,通常很難找到不僅懂得軟體開發的技能,又同時具備問題領域知識的人才。而且軟體開發專案本身存在時程與成本等限制,多半不允許系統分析師花太多的時間與成本學習問題領域知識。因此,要期待系統分析師學習問題領域知識是不切實際且又不符合經濟效益的做法。 系統分析師要如何展現出系統分析的專業,才能整合問題領域與解決方案領域的知識,有效地提出具體可行的問題解決方案?

Continue reading about 展現系統分析專業的七種能力

     
jim yeh on 四月 29th, 2008

同人相信有不少人會認為 renew PDU 只是 PMI 賺取利益的手段,對於 PMP 工作上實質的幫助並不大。不過,我倒是不會這樣思考這個問題,一來是因為個人的體會,取得 PMP 資格只是專案管理知識學習的開始而非結束。而另一方面,如果我們把 PMP 資格只是當成一種專案管理能力的門檻,那麼我們將會落入競爭性思維的迷思當中,這樣的心態是難以令人成長的。

Continue reading about 專業認證的價錢與價值

     
jim yeh on 四月 17th, 2008

鍾翠玲看到建築師與校方的溝通上出了問題,她認為這是因為校方沒有積極地參與設計的緣故。但如果在軟體專案碰到同樣的現象時,筆者不一定會認為是因為使用者缺乏積極參與。筆者認為,即使使用者積極參與設計,開發者還是會因為與使用者之間存在觀念溝通上的藩離,而聽不見使用者的心聲。

Continue reading about 為何聽不到使用者心聲?

     
jim yeh on 三月 25th, 2008

要如何進行有效溝通呢?最近,同人聽到一場課程,提出如何掌握溝通的「關鍵時刻」的方法,可以讓我們在溝通過程中,透過不斷循序反覆經歷探詢、提議、行動、確認四個階段,與他人進行有效的溝通。

Continue reading about 溝通的關鍵時刻

     
jim yeh on 三月 11th, 2008

在專案時間不夠的情況下,要達成不可能的任務必須要提昇軟開發的產能,必須讓開發的產出與產能可以相互配合。但至於要如何增進良好設計架構的產能呢?

Continue reading about 專案時間不足,如何達成不可能的任務

     
jim yeh on 二月 4th, 2008

對於開發者而言,總是要到驗收前才發現程式有問題可真是可怕的夢魘呀。然而,這樣的現象為什麼老是一而再,再而三地發生,到底是什麼地方出了問題呢?

Continue reading about 總是要到驗收前才發現程式有問題?

     
jim yeh on 十二月 19th, 2007

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

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

     
jim yeh on 十一月 12th, 2007

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

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