Categories

工作態度 (1)    方法論 (5)    本土化 (9)    危機管理 (2)    死亡 (1)    自我成長 (1)    自我管理 (3)    決策管理 (1)    版本 (1)    社會 (2)    品管 (3)    風險管理 (1)    效能 問題 (1)    時間管理 (5)    專案 (10)    教育 (1)    產能 (1)    產業 (5)    軟體 (4)    測試 (10)    閒聊 (14)    溝通 (4)    道德 (1)    漫談 (23)    管理 (1)    機器翻譯 (1)    簡轉繁 (2)    翻譯 (8)    booksore (1)    Chinese (1)    Flash (1)    G11N (1)    I18N (3)    Industry (1)    L10N (8)    politics (1)    Project Management (6)    Revision (1)    Software (3)    Testing (4)    Time Management (1)    Translation (4)    UI Design (1)   

2011年2月21日

專案管理 - 知道你自己在做什麼

最近聽到某個專案團隊詢問一個問題,問到說我們的問題追蹤系統能不能有個快速提交問題的表單,好讓外面的協力廠商或自由工作者可以比較簡單的在測試階段提交問題;或者說,能不能有匯入功能,例如透過 Excel 表單匯入問題到系統。

我覺得以工程師的角度去思考問題,大概會覺得這些都是功能面的問題,既有的提交問題程序對工程師來講不會很困難也不會很複雜,能不能有快速提交方式,要看系統擴充性,要不就要重新設計該專案的欄位;至於能不能透過 Excel 匯入,也是看系統本身支援與否,要不就要自己寫一個中介程式來加以處理。

雖說系統易用性對於工程師與其他非工程師來講,會有很大的落差。而若是提到產品開發,很多開發團隊對於產品的易用性往往不擅長,不過這已經是另外一個主題,在此不多做著墨。

是不是可以有快速提交表單,這可以藉由定義哪些欄位屬於必填欄位,哪些屬於選填欄位,然後看系統是否支援在建立新的問題記錄時,可以有機會選擇簡單表單或是完整表單,來看是否可行。

透過 Excel 匯入,我覺得我在解答可行或是不可行之前,我倒想提出個疑問。該專案決定使用這套系統作為問題追蹤系統的用意是什麼?一個專案可以選用任何的問題追蹤方式,不管是口頭回報、一個筆記本記錄、一個共用或非共用的 Excel 表單、SharePoint 表單、或是專門的問題追蹤系統,只要適用於多數專案成員,他就會是個不錯的方式或系統。

如果目前專案的狀況是專案團隊龐大、成員散布在多個國家地區以及不同時區、專案交付物龐雜等等,要求所有成員使用集中式的問題追蹤系統,好處除了狀態追蹤容易以外,還包含他可以是即時的,例如當一個問題產生,回報問題後,被指派的問題解決者會立即收到電子郵件通知。系統還可以快速的依照不同需求來篩選問題。

使用 Excel 表單來匯入問題,意味著提交問題的測試人員將會使用 Excel 來記錄問題?而開發人員依舊使用系統來追蹤問題!那麼接踵而來的問題,將會是後續的問題追蹤。試想,當開發人員與測試人員使用兩套不一樣的系統來記錄/追蹤問題,這兩個團隊以及這兩個系統之間如何溝通/同步?
Excel 表單匯入系統確實解決了從測試團隊回報的問題可以在系統內轉發給個別的開發人員,但是緊接著當問題逐一解決後,勢必要將這些更新的進度在匯出轉成 Excel 然後發給測試人員。然而,狀況不單這麼單純,在過程中還會發生許多往返,例如某問題描述不清,開發人員得要轉回給測試人員詢問更多細節,或是測試人員驗證問題時發現問題仍舊存在等等。這之間將會有很多的溝通會變得相當複雜。

所以,跳出來想一下,當初這專案並沒有使用 Excel 表單來作問題的追蹤,而採用問題追蹤系統,是為什麼?是希望藉由系統來輔助可能的龐雜溝通與追蹤問題?還是其實本來就是個很小的案子,要殺雞卻用了牛刀?


另一個故事是某專案使用了 SVN ,要求所有專案團隊都必須使用 SVN 來工作,包含收件與交件。單一一個可獨立的元件,在專案初期會由團隊 A 主要負責對應階段的工作,到了中後期,團隊 B 便會開始加入來進行其他的加工工程;期間團隊 A 將可能會需要對元近進行問題修正,團隊 B 得針對修正的部份也對應修正在相關的檔案上面。

換個角度來看, SVN 在專案裡相當於是個協同工作平台,好比在 File Server 上面建立一個共用工作目錄一樣,不同團隊都相當於在同一個工作目錄下工作;此外, SVN 本身還具有版本控管機制,每個專案成員完成一個修改後都必須將該修改的版本提交到伺服器,建立一個版本 (revision) 。

實際上各個團隊分散在世界各地,使用 SVN 其實也多少解決了一般 File Server 必須是在區網內同網段的限制。

然而,是不是所有專案成員都了解使用 SVN 的用意?當發現某些檔案怎麼用 FTP 甚至 email 夾檔在交換時,我就覺得不妙了!某階段的檔案,居然看到專案經理藉由 FTP 把檔案發給某團隊,然後要求該團隊也用 FTP 交回來;而該專案經理知道後端主要的開發團隊依舊使用 SVN ,所以專案經理會再把檔案提交到 SVN 。

有沒有覺得跟上面要求把 Excel 表單匯入問題追蹤系統的狀況很像?

專案經理究竟有沒有了解選用的系統的用意以及好處在哪?其實不是一定要使用哪一套系統,就好像切麵包、切水果、切肌肉、切牛肉,你說我通通用同一把刀子可不可以?當然可以!但是我們會從經驗學到,用切蘋果的小水果刀拿來切西瓜,真的很難切,所以我們發明了刀面很長的西瓜刀;同樣的,你說我拿西瓜刀來切蘋果可不可以?當然可以,只是不順手!

專案開始時,得視專案大小、專案交付物的複雜度、團隊數量與團隊成員數量、還有流程複雜度,來選用適合的流程與工具,不是盲目的選了一個,到底適不適用不知道!這就好比你已經買了一把西瓜刀要切西瓜,你究竟知不知道為什麼你買了西瓜刀?或是你究竟知不知道你要切的是西瓜,你究竟知不知道你要切什麼?結果實際要切西瓜,然後你卻又要求人家給你一把小水果刀,原因只是某專案成員小水果刀用很熟,西瓜刀不善用?

知道你自己在做什麼很重要,我一直對於那種搞不清楚狀況的專案經理很感冒。專案經理不是說你只要確保專案照進度走、成本控制在預算內、品質有合乎標準,這樣就行了。實際狀況是在專案進行中就是會有一堆意外,計畫趕不上變化,專案經理就是要扮演很吃重的溝通角色,你若身為一個專案經理,當有人跟你詢問可不可以用小水果刀這樣的問題,而在專案開始時批核採用西瓜刀的你,如果不知道這個決策的背後因素,我相信這專案經理只會花更多時間在溝通。

專案經理是不可能懂每一個專業,所以必要時要請教專家,但不是說專案經理就什麼專業都不用懂,因為你不可能每個小決策都詢問專家,除非你正在進行一個很龐大的專案,而你們另外有個 PMO !

2011年2月8日

領土與統治權的個人看法

也許會是個很有爭議性的主題,不過至少說說我的想法。我也不是什麼有學問的學者,只要是理性的,我倒是樂於聽到不同的聲音。

我老是在想,中華人民共和國老是對全世界稱台灣是「中國」不可分割的領土之一,我到好奇這說法以什麼為本?有史以來,或者說從中國共產黨在中國建立中華人民共和國以來,這個政權從未統治過台灣。回顧台灣在那個年代以前的歷史,先是大清政權將台灣割讓給日本,從此喪失對台灣的主權。接著大清政權被孫中山為首的革命軍推翻,並成立新的中華民國政府。而直到二次大戰日本戰敗以前,中華民國這個政權也從未擁有過台灣的主權!

一些學者或是政治家認為台灣的主權是否歸屬中華民國,本身就已經是個問題,更不用提中華人民共和國。以我來看,當一個領地在過去已然割讓給另一個政權,即便割讓時是基於怎樣不平等的處境下,過去各種族各政權恃強凌弱似乎勢天經地義,除非有更強大的正義的一方出面「主持公道」!然而,當唯一有資格要回失物的這個原始政權(大清)都已然消失,後繼者(中華民國)也未追溯主權,再更後繼者(中華人民共和國)又哪有資格追溯!再者,當大清政府把台灣割讓出去那一刻,他就已然喪失主權。你能想像你祖父把一塊土地讓給別人,然後現在你卻想要去追討回來說那塊土地是你的嗎?

台灣會在二次大戰日本戰敗後被迫歸還(給誰?),個人鄙見認為僅僅是當時美國欲控制太平洋勢力,或者講好聽是要避免共產勢力大幅擴張,因此藉二次大戰,美軍分別在包含日本、韓國、台灣、菲律賓等地都設有軍事基地。

台灣以及澎湖列島在西太平洋確實是個很關鍵的區域,正好日本戰敗,盟軍(或說美軍?)要求日本放棄台灣主權,這身為戰敗國的日本能說不嗎?這就像甲午戰爭大清戰敗,不得已得要割讓台灣是一樣的道理。

我猜也許中共政權認為其為中華民國的後繼合法政權,因此認為當時盟軍同意將台灣歸為「中國」管轄,即便當時是指中華民國,但既然中共認為其為後繼的唯一合法「中國」政權,於是認為台灣應歸其所有?

我基本上不是學者,目前也沒多大興趣逐一考究個中緣由。但想想看,這像不像這樣的故事,祖父做生意失利,把名店讓給某甲,到了老爸那一代,家族的好友某乙因商場得意,恰逢某甲世家商場失利,所以把那名店低價買了回來,讓給了老爸。結果叔叔說祖父臨終前什麼都沒交代,只交代他未來有一天要把那店拿回來,所以就大聲嚷嚷說那個店該歸他所有!

故事當然不一樣,但是一樣可笑。

有興趣可以搜尋「台灣前途未定論」,或是「台灣地位未定論」。可以看到更多學者精闢的見論。

看倌若要辯論,請移駕那些學者的部落格或是論壇。