jim yeh on 十月 2nd, 2007

參與大型軟體專案的管理常常會面臨任務分工與協同合作的問題,這些問題常常會很複雜,充滿了許多不確定的因素。因此,有關於「如何分工與合作才能讓專案的進行更順利」的這類議題,對於專案管理者而言,就是非常重要的課題。 最近,我從同事的 MSN 的暱稱中看到一段文字:「合作分工與分工合作,那一個比較好?」。我覺得很好奇,於是在 MSN 上問他認為這兩者有何不同。他提道: 這兩者有很大的不同喲,分工合作是分工後再合作,合作分工是合作後再分工。分工後再合作會有個大問題,就是分工後的每一個單位,沒有整合的觀念。而合作後分工則是則是先有完整的構架,再分單位,分別執行。 同事舉了一個我倆都參與過的專案,說明分工合作的容易發生的缺失,他認為分工前要先確認整體結構清楚,才能開始分工,彼此單位間介面才會清楚,不會缺東漏西,再來疊床架屋。因此,他認為合作分工比較好,最好團隊成員能夠在一開始先一起工作再決定如何分工。 同人覺得同事談的是很有趣的整合議題,同事則認為分工合作與合作分工是有意思的中文造字。不過,我進一步思考到合作分工在實際操作上有可能會遇到一些限制,於是我探詢同事的看法,提出了一個問題: 那有沒有需要先分工才能合作的情況呢? 同事提到分工合作或合作分工是一種工作的方式,他認為所有事都是可以在這兩種方式中擇一處理。顯然他誤會了我想要表達的意思了,我向他解釋,提出這個問題並非要質疑他的看法,而是對他的觀點感到好奇,假設合作分工是比較好的做法,那對於各種不同專案的複雜問題,合作分工有沒有可能會遇到要先分工才有辦法合作的情形,如果有,那要怎麼處理呢?這才是我真正想要探索的問題。

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

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

Continue reading about 認證不重要嗎?

     
jim yeh on 八月 24th, 2007

在人際溝通的過程中,我們聆聽他人的意見,並發表我們對他們意見的看法。不過,在彼此間充滿著歧見及情緒反應的討論中,我們常常無法靜下心來傾聽對方所要傳達的訊息。於是在聽從主觀的思想而忘卻聽從內心的客觀分析的狀態下,結果讓我們聽到的都是我們想要聽的部分,卻把不想聽的部分刻意忽略掉。 在這種情況下,我們試圖取得討論的主控權,卻無法參與共同的對話並促進集體思考的創造力,討論的結果往往會變成流於無謂的爭辯。最近同人正在閱讀《深度匯談》這本書,書中提到了在對話中必須先聆聽對方的重要觀念,並提供了一些方法讓我們可以藉由互相地聆聽對方而學習以共同的觀點來思考問題。 《深度匯談》作者威廉.伊薩克認為,我們的想法往往是基於過去經驗對現在情境所形成的推論,它並不是事實,事實是可以透過直接觀察得來的,而不是按照過去經驗推論而來的,這樣會造成個人的偏見。在對話過程中,我們必須堅持事實,依據過去經驗而做推論並不是思考,而是對回憶的反應。所以我們必須能將「依據經驗所做的推論」與經驗本身區分清楚,而書中提到了「推論之梯」,就是可以達成這個目的的工具。

Continue reading about 傾聽的技術

     
jim yeh on 八月 21st, 2007

我們通常會用「工程師性格」來形容那些不擅人際交往,卻能專注於某些專業技術領域的人。大部分的人認為工程師的理性多於感性,這種人雖然缺少生活情趣,不大會與人溝通;但他們實事求是、崇本務實的精神,卻是默默地問題解決者。最近同人向一位朋友提到,我對他印象中認為服務態度不錯的客服人員對我的服務態度覺得很不以為然,因為那位客服人員堅持他們的系統沒有問題,卻沒有了解為什麼我使用上會出狀況,我認為這個客服人員根本就沒弄清楚狀況,就急著斷言他們的客戶使用上沒這個問題,但難道我不是他們的客戶嗎?朋友認為,那位客服人員的反應是工程師性格的表現,所以他認為他還可以接受這種狀況。 先不管那位客服人員是否有工程師性格,同人在比對了朋友在使用相同系統所使用的操作環境後,馬上發現問題所在,該系統並未考慮 Firefox 的瀏覽器,而恰好我是透過 Firefox 來使用系統,於是造成中文的編碼問題,用 IE Tab 就很輕易地解決這個問題。 解決了我的問題後,同人向朋友表示,個人不喜歡這種工程師性格,我認為真正的工程師都會探究問題找答案。不過,朋友對此提出了不一樣的看法。他認為我要先思考一個問題,是否我也是有工程師性格,一般而言,這樣很容易與對方發生衝突。

Continue reading about 工程師性格

     
jim yeh on 八月 20th, 2007

要脫離思想的洞穴,我們必須審視我們的信念,是否忽略了我們不知道我們所不知道的事物而有所遺漏或偏頗。所以,多參考別人的觀點,學會讓自己從不同角度來看事情,這樣才能經得起理性的考驗。

Continue reading about 思想的洞穴

     
jim yeh on 八月 11th, 2007

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

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

     
jim yeh on 七月 5th, 2007

不管軟體開發是工藝還是工程,最重要的還是讓不同觀點能夠適當的運用、調整與熟練,這才是優秀的軟體開發者應有的態度呀。

Continue reading about 軟體開發是工藝還是工程?

     
jim yeh on 七月 3rd, 2007

喲哪桑說: 優秀的工作者,不論是管理職,還是技術職,其工作時數都很長。 因為,這不只是工作時間的問題,而是工作態度的問題。 石頭成針對喲哪桑學長的這個觀點,認為不能把管理者工作認同和管理者工作績效混為一談,提到了: 一個無法讓下屬準時收工的管理者是抱著什麼心態在執行「管理工作」。是否只是為了滿足自己的權力與控制欲望?所以我說管理者要用下屬做 reflection ,透過下屬反觀自己是否「做好管理工作」。 當然,如果下屬也能從工作中得到認同,並願意延長工作時數也沒什麼不好。但那是下屬的事。管理者要學會把自己的感覺和下屬的感覺分開考量。 同人也為此主題,寫了一篇〈核心價值觀與工作態度〉,提出工作者可以選擇適合自己的工作環境,然後從工作中創造出個人的價值與意義,並不需要迎合對自己生命無意義的價值觀,消極地藉由超時工作才能讓經營者肯定我們的表現,因而為此付出青春而追悔莫及。 但同人的文章並非否定工作態度的意義,工作態度當然很重要,但一旦經營者或管理者把它當成批判工作者的工具時,它就不具任何意義了。用自己的核心價值觀來看待他人的世界,怎麼看都不對,經營者或管理者應該學會用更理性、更客觀的角度來看問題,才不會對工作者造成無謂的偏見。 我的文章得到哈米尼斯的迴響,他提道: 面對自己的人生(包含工作),我們應該秉持的態度問題,我們可以選擇工作=賣時間的觀念,但同時也可以選擇把工作當成是一種事業的態度來經營。這兩者所會產生的能量是很不同的,也如同您所提到的,超時工作是一種選擇,沒有對錯,但是如果我們可以透過這種行為進而拿到自己想要的東西,也許這種想法就會產生另外的價值也不一定。 這期的Career談到了Me世代、也談到了21世紀新人才的競爭力。 要發展什麼能力、要用何種態度面對,其實就像公司的核心價值一樣,是取決於「經營者」的。 當個人的角色重新定位成「一人公司」的時候,其實問題不也是一樣的嗎? 當許多人在怨嘆環境不好、競爭規則的改變;也不妨想想你曾經建立過自己的核心價值嗎? 哈米尼斯說的沒錯,成功要有決心、要付出代價,可是在努力之前,請先問一問自己,我們是否確認了目標、認清了方向,培養「以終為始」的習慣[1]。「努力會有結果,但不見得會有好結果」,如果沒有在努力前,先弄清楚方向,我們將會誤入歧途,白費工夫,就算我們的努力,可以得到再多卻不見得會有絲毫的意義,因為那將不是我們人生真正需要的東西。 同人一再強調,身處知識經濟時代,競爭力的來源並不在勞力與資源,而是資訊與知識。windlove 說的好:"台灣陷在製造業的思維太久了,花個一段時間想出一個更有效率的方法,才是真的解決之道。不然,人一天在多也只有24小時,不是嗎??",所以,工作時間拉長或許表面上,在勞力與資源的運用上會很有效率,但卻會造成邊際效應遞減及心理層面因素而造成工作上的捨本逐末,因而降低效能。其實,還有一個更嚴重的問題,那就是一個忙碌的工作團隊,將會形成不利創新的企業文化,造成知識分享的障礙並且管理者會付出相當高的代理成本。 附註  參考史蒂芬.柯維著(2005),《與成功有約》中的第二個習慣。[↩]

Continue reading about 工作時間與知識分享

     
jim yeh on 六月 14th, 2007

記得在 EMBA 策略管理課程中,林維熊教授在第一堂課就跟我們討論核心價值觀的問題。他問我們一個問題,經營者決定企業的策略目標關鍵在那裡?經過學長姐們熱烈的討論後,大家得到一個結論: 企業的策略目標取決於經營者心中的核心價值觀。 由於經營者選擇不同的核心價值觀,讓他看到的世界也有所不同;有些經營者認為成本是最重要的,這樣可以取得價格優勢,於是乎在這樣的經營觀點下,企業活動的價值在於不斷地投注資源來獲取規模經濟的好處;然而,也有一些經營者認為創新才能獲取競爭優勢,藉著差異化的手法來提昇附加價值及品質優勢才是永續經營之道,在這樣的經營觀點下,企業活動的價值並不在於企業生產了多少產品,而是創造了多少知識,而這些知識將會成為使企業立於不敗之地之立基。 其實,選擇沒有所謂對錯問題,而只是有所不同。林教授告訴我們,他非常不認同某位經營者用小便顏色來衡量員工的工作態度,因為在「為達目的,不擇手段」的管理心態下,經營者不可能會去真心地關懷員工,員工也沒有必要為經營者「躹躬盡瘁,死而後已」。那麼經營者與員工的關係就會是一種因利益而結合的相互利用關係,而不是基於為共同目標而建立的相互信任的夥伴關係。所以,林教授認為那位經營者的這種心態,其實是非常不健康的。 同人在看了喲哪桑學長的〈工作時間的問題,是工作態度的問題〉後,讓我想起了以上策略管理所學內容。其實,同人認為學長只說對了一半:

Continue reading about 核心價值觀與工作態度