Gadget

目前仍無法透過加密連線存取這項內容。

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 !

0 Comments: