班傑明的奇幻旅程 vs 阿甘正傳

看了班傑明的奇幻旅程 , 發現它的敘事風格與故事模式與阿甘正傳有點相似
首先 , 兩者都有一個愛他的媽媽 , 而且不願意放棄故事中的主角 ,
然後呢 , 主角都會愛上一個女孩子 , 但是這個女孩子可能會跟花蝴蝶一般 , 閱人無數 ,...
           不過最終都會回到主角的身邊 , 而且幫主角生下一個孩子
其三 , 主角會碰到一個算是老大似的傢伙 , 帶著主角去增長閱歷與見聞
           阿甘碰到的是他們的班長
           班傑明碰到的是船長 （甚至帶他去體驗女人...）

其四 , 兩者幾乎都可以不用為了柴米油鹽醬醋茶煩惱
           阿甘是因為他的班長幫他投資蘋果電腦
        班傑明是因為繼承了父親的遺產 

兩者的差異是:
                    阿甘一個最最平凡的人在行不平凡的事業 ,
                    班傑明一個最不平凡的人在行平凡的事業

不過好看的是這兩者的故事內容都是未知的 , 沒有看到最後一刻 , 不會知道結局是甚麼
<就是因為不知道結局 , 故事才會吸引人>


後記:
寫完這篇之後 , 才發現兩者的編劇是同一個人 , 難怪會有那種十分好像很熟悉的敘事風格...

Google Earth 5.0 中文部份出現方框 , 無法顯示的解決方式

Google Earth 5.0 中文部份出現方框 , 無法顯示的解決方式
(UBUNTU 8.10)

裝完 Google Earth 5.0 之後 , 一啟動發現選單變成方框 , 無法顯示
解決方式:

(1)確認本機是否已經安裝 Qt4
     否 -> 請安裝 Qt4
     是 -> 繼續下一步

(2)搬移Google Earth 5.0 內附的 Qt4 相關檔案 , 到其他目錄
執行以下指令:
 cd  ~/google-earth
 mv libQtCore.so.4 ~/Desktop
 mv libQtGui.so.4 ~/Desktop
 mv libQtNetwork.so.4 ~/Desktop
 mv libQtWebKit.so.4 ~/Desktop

(假設:
(a) 你的 Google Earth 5.0 是裝在你的使用者目錄下的 google-earth
(b) 我們把檔案暫時搬到你的桌面目錄
)

(3) 重新啟動 Google Earth 5.0
      應該可以正常的看到 選單的中文顯示了

(4) 刪除剛剛搬移的4個檔案

解說:
可能是 因為 Google Earth 內附的 Qt4 有些問題 , 所以我們把 Google Earth 5.0 內附的 Qt4 拿掉 ,
讓他 吃系統的 Qt4就可以了

UBUNTU 8.10 - 解決新增硬碟或外接硬碟沒有資源回收筒問題

UBUNTU 8.10 - 解決新增硬碟或外接硬碟沒有資源回收筒問題

UBUNTU 8.04 / 8.10 在新增外部硬碟時不會自動建立資源回收筒
所以在外接硬碟 , 刪除檔案時會出現訊息 , "無法移動檔案到回收筒"
這樣對某些人來說 , 可能不會有困擾 , 反正刪除了就刪除了
但是有時候人有失手 , 萬一誤刪了就再也救不回來了 ,
所以還是要設定資源回收筒比較保險一點

注意事項: 本篇文章只適用於 格式化為 ex3 , fat32 的硬碟磁區
            如果是格式化 ntfs 的硬碟磁區 , 目前此解決方式無法解決問題
           <我用 USB 隨身碟進行測試發現的結果>
症狀:
新增外接硬碟(包含使用 硬碟分割編輯器 去增加硬碟分割跟格式化)
不會自動新增 資源回收筒

原因:
在外接硬碟沒有 , 回收筒的目錄
為了保險起見 , 還是要先讓檔案可以移動到回收筒之後 , 再決定要不要清除回收筒


解決方式:
開啟終端機 Terminal
輸入以下指令:

cd /media/M500-1
sudo mkdir .Trash-1000
sudo chown demo .Trash-1000

然後移除外接硬碟
重新接上外接硬碟 , 讓 UBUNTU 重新 Auto mount
應該就可以有 資源回收筒 ,

說明:
(a)
M500-1 是你的外接硬碟經過 UBUNTU 自動掛載上去 /media/ 下的名稱 ,
看看你的硬碟名稱為何 , 請修改為你自己機器上的名稱

(b)
sudo chown demo .Trash-1000
demo 是指你目前登入電腦的帳號名稱 , 看看你的帳號是甚麼 , 換掉demo



測試方式:
在外接硬碟 , 透過檔案瀏覽器 ,
EX: 在 /media/M500-1/SUB1 目錄 下
按下滑鼠右鍵 , (新增文件->空白檔案) , 新增一個空檔案 , 然後刪除那個空檔案 ,
看看是否仍然會跳出 "無法移動檔案到回收筒"
如果不會就是成功了 ,

接著可以看看刪除的空檔案是否出現在外接硬碟的 .Trash-1000 裡面的子目錄下
如果是 , 表示資源回收筒手動建立成功
(檔案瀏覽器 , 要在功能表選擇 -> 顯示-> 顯示隱藏檔 , 這樣才會看到 .Trash-1000的目錄)

備註:
(1)沒有必要去修改 /etc/fstab ,  因為沒用 , 會有權限問題 ,
(2)上述作法是單一使用者的作法 , 因為我的電腦都是個人用

專案管理_技術的問題 , 請以技術來解決

看過一些系統開發案 , 專案嚴重延誤 , 問題一堆 ,
有不少的狀況是 PM 完全不尊重公司內部的技術專家 , 聽信外部廠商的說法所造成

(當然 , 公司內部的技術專家 , 要真的熟悉相關的技術 , 了解每一塊的決策會影響後面的那一塊 , 然後需要衍生甚麼樣的問題處理等等)

系統開發專案 , 有時候最基本的問題就是 , 找來的廠商技術有問題 , 觀念有問題 ,
(為什麼會找這樣的廠商過來 ?


 有時候 , 公司的運作 , 是一堆利益問題跟政治問題所組合 ,
 就好像招標的時候 , 完全不提選商要用價格標 , 但是呢,


 如 果經過一堆選商的委員去評分 , 選出的廠商不是上面那些大主管們內定的廠商時 , 大主管們甚至會直接推翻選商的委員的評分結果 , 直接稿個價格限制 , 逼迫被選上的廠商自動棄標 , 然後大主管們也不是採用第二名或是第三名 , 而是搞個內定的廠商(可能是選商委員給 0 分的
 , 用這種玩法 , 你說過來的廠商的成員 , 他的素質會有多高?
)


系統開發專案有問題 , 有不少是根本性的技術問題 ,
但是有時候 , 常常會發現 , 很多PM並不是尋求專家的建議 ,
而是自顧自的 , 用所謂的 Soft Skill  去試著解決廠商因為技術能力而導致的問題

(技術能力的涵蓋:  包含程式語言 ,  工具的使用 , 軟體開發流程的觀念 , 品質的要求等等....)

這個時候 , 你就會發現 , 例如廠商技術能力不足 , 導致可能連 SA文件都出不來 , 或者是交付的程式可能是無法編譯或是執行的 , 或者是因為不熟悉某項特定產品而亂搞一通的

像這類技術問題 , 你只要看到PM不是從技術面去處理 , 而是在作搞定所謂"人"的問題時 ,
那可以掛保證的 , 專案還會繼續出問題下去 ,
因為不對症下藥 , 病是不會好的 ,....

專案管理可以管理許多問題 , 但是絕對沒有聽到說 , 不針對問題的源頭或是問題的核心去處理 ,
然後問題就會消失的


我看過某些系統開發專案 , 在廠商胡搞瞎搞之後 ,
系統還是上線了 , 但是公司的主管卻不敢把它全面的鋪到所有單位去使用 ,
因為廠商的技術有問題 , 寫出來的系統根本撐不住所有單位一起使用 ,
(過了一年多 , 廠商仍然沒有把問題解決 )

這樣的系統是有上了 , 但是只有鋪到一兩個單位去使用 ,
那開發這樣的系統效益何在?



有時候 , 技術問題 , 要根據專家的意見 ,
有時候 , 專家意見是不得修改的與忽略的 ,

技術問題絕對不是你找 5 個臭皮匠可以湊成一個諸葛亮 ,
碰到技術問題 , 如果你不是聽從專家意見 ,
而是在搞多數決 , 搞民主投票方式的話 ,
絕對可以保證你的系統問題叢生～～～
(例如 , 在開發 Web 系統時 , 找幾個搞 AS400  , 只會 COBOL的專案成員 , 跟一個熟悉 Web 開發技術的專案成員(專家)人(EX: JSP/ .NET) 進行多數決  , 去討論 Web 系統的架構以及可行的技術)


(如果你碰到 PM 這樣搞的 , 就要留意了 ,
 開發軟體系統 ,  技術問題不以技術解  ？

看過不少這種例子 , 一堆不懂技術的人在旁邊說風涼話 , 作建議 , 說沒關係 , 沒影響.....等等不富責任的話 , 最後有問題的時候 , 這些人絕對不會負責 , 一定是去找別人出來死....


基本這種對自己不在行的領域喜歡隨便亂說話的人都是不負責任的人 ,
這種人 ,  才是最不希望專案完成 , 系統上線的人 ,

另一種人(技術專家) , 是在專案一開始 , 已經在考慮專案要怎麼上線 , 怎麼測試 , 怎麼運作 , 怎樣問題會最少等等 ,  這種人多半會在發現問題的當下 , 立刻反應問題 , 並且要求或阻止廠商繼續讓問題擴大 ,
但是常常 , 這種人常常會被打成是 不希望專案完成 , 系統上線的人.... )



但是經驗可以發現 , 系統開發專案  , 當你不以"技術"解決"技術問題"時  , 你的系統大概也差不多該完了...

專案管理_假的Lession Learn

在一般專案結束之後 , 也會進行 Lession Learn ,
看看可以學到些甚麼教訓(做錯的事) 或是經驗(作對的事) ,
不論要學到甚麼 , 都必須要誠實的面對問題 , 才能發現真正的問題所在


但是我要說的是在專案的過程中 , 就應該不斷的檢視與檢討 ,
而不是等到專案結束的時候才來進行Lession Learn...
當專案發生進度延宕 , 廠商一再提出相同的作法 , 而一延再延的時候
正確的作法應該是找出真正的問題所在 , 針對真正的問題所在去解決

但是因為在職場上 , 很多人不願意誠實的面對問題 ,
不願意面對問題 , 採用相同的錯誤作法 , 只會讓錯誤一再重複發生


當進度落後時 , 可以採行幾個方式去檢查 , 可能的問題所在
a.請廠商提出他們的專案成員組織文件 , 看一下 , 有多少人 ,角色為何 , 每個角色負責的工作為何 ,
  再去抽樣詢問廠商的專案成員 , 看看他們是否都知道自己所負責的角色為何?  應該負責的工作為何?
  實例: 曾經看過廠商的PM完全沒有這樣的文件紀錄 , 然後抽問廠商的專案成員 ,
            廠商的專案成員完全不知道自己要負責那項工作事項,
           
            在經過我直接詢問廠商PM寫下廠商的專案成員組織文件後 , 明顯的發現廠商的人力嚴重不足 ,
            廠商PM才開始進行人力的interview, 這個時候已經過了3個月

b.確認一下廠商的專案是否上下游可以銜接一致
  上下游可以銜接一致 , 舉例來說就是下游的所需要輸入就是上游的產出  , 如果下游需要 A 當作輸入 , 但是上游完全沒有產生 A 當作產出
 這時候你就可以確定廠商的上下游沒有銜接一致 ,
 沒有銜接一致會有甚麼問題?
 如果你的專案的許多區塊可以是完全獨立沒有關聯的 , 哪就沒有關係,
 但是你的專案想要平行開發許多區塊 , 但是又沒有先找出關鍵點(諸多區塊會相依使用的那個重點區塊 , 如果沒有先作 ,後續的區塊可能會有問題)


另外一個很重要的問題 , 當廠商的進度一延再延 , 完全沒有完成的產出時 ,

停下吧 , 千萬不要再跟廠商說: "你自己說 , 你自己排 WBS , 舖出一個可以做的到的時程"
如果廠商真的沒有問題 , 他自己怎麼會一延再延 , 東西出不來 ,


千萬不要這樣作 , 因為這樣不能解決問題 ,
應該請廠商提出他們對自己的狀態與問題的檢視與檢討 ,
如果廠商認為他們完全沒問題 , 那大概這個專案也差不多完了 ,
為什麼?
專案一定是有問題 , 才會一延再延 , 完全沒有產出 ,
但是廠商又認為自己沒問題 ,
沒問題的問題 , 才是最可怕的大問題 ,

廠商連自己錯在哪裡 , 哪裡有問題都弄不清楚 , 你說不可怕嗎?

在廠商沒有真正的認知到自己的問題出在哪裡之前 , 請千萬不要再叫廠商自己去舖 WBS 與排時程了
(如果他沒問題 , 又怎會修改了 n 版的 WBS 與時程 , 仍然沒有半點產出 , n 大於 10 )
(這種作法 , 用台語的俗諺說 , 叫: , 請鬼開藥單)


專案管理的課程中 , 有提到 Milestone , 我聽過的一種說法是 ,
Milestone 是 Kill Point ,
意思是每一個Milestone都會是用來審視與決定專案是否要Kill 或是繼續往下走的決定...


如果廠商不斷的延誤 , 連第一個 Milestone 都沒完成 , 已經過了專案預定的完成時間 , (意思就是 100% 延誤 ) , PM還決定要繼續給廠商機會的 , 那就有問題了....

專案管理_是交付比例還是完成比例?

實例:
 有的PM在面對廠商的產出時 , 跟必須要上交給公司高層的status report時 , 跟實際狀況竟然不一樣 ,

 PM跟廠商講好,只有有交付,他就會掛進度 ,
(PM同意廠商PM 可以不作SA , SD先有開發[這又是另外一個大問題])

經過 n 個月後 , 在廠商完全不作 SA , SD 的狀況下 ,進行開發
廠商交付了十來個Java Class Source Code ,
就這樣 , 進行Code Review的時候發現,

 這些Source Code 無法完整的被編譯 , 因為還有Source Code沒有交付 ,
 即便可以可編譯 , 也無法執行 , 因為還有必要的設定檔沒有交付 ,
 經過人工的審閱之後發現 , 這些Source Code 無法被編譯 , 執行 , 更何況是測試與上線
基本上可以說完成度 是 0% ,

公司簽約金付頭款就 一百多萬 , 得到甚麼?
 (如果加上購買另一個軟體套件的費用 , 至少投入 兩百多萬 , 更不提公司內的專案成員 , 加上 User單位的人力投入 , )
投入兩百多萬 , 加上公司人力至少 70人月的投入(包含其他單位的人力)
公司能夠得到甚麼? Nothing , 沒有分析文件 ,沒有設計文件 , 沒有可執行系統 , 甚麼都沒有 ,... ,



有交付不等於有完成 ,
專案管理雖說是以產出為導向 , 但是也從來沒有說拿著沒有完成的產出當作進度的

但是PM的Status Report中的進度回報可不從來都不是掛零 ,....
 現在專案有問題了 , 可能會被中止 , 那就牽扯到什麼是有效(完成)產出


 迄至目前為止 ,
 沒有 SA 文件 , 沒有SD文件 , 更沒有可執行的系統模組 , 一個都沒有
 等於專案的完成產出是零

 但是PM在先前的 Status Report 中可不是掛零 , 為什麼會有這種差異頗大的落差?

因為 PM 掛的是進度都是只要廠商有開始作 , 就算數 , 而不是以廠商完成了才算數 ,
也就因此種下此惡果的因之來源

現在PM要為了掩飾他先前所交付的Status Report 是有進度的 , 有產出的 ,
現在又在玩一些把戲 , 說看看專案要被中止了 , 什麼樣的產出對公司是有價值的?
要廠商已交付那些產出為目標 , 至少交出文件來...
甚至還要潑污水給專案成員 , 說有些專案成員希望專案被中止 , 而不說因為他的問題導致今日的果,
這個就是會做事的 PM...

<從一開始 , 專案就偏差了 , >

專案管理_QC不是萬靈丹

最近碰到品質很差的開發商 , 交付完全沒有品質的半成品時

老闆跟 PM 的反應竟然是只要多多投入人力去作 QC , 就可以了


請問 , 投入一萬個人力去作QC , 能夠把 搖搖欲墜的小木屋 , QC成為 鋼骨結構的摩天大樓嗎?

明明知道要蓋摩天大樓 , 但是看到開發商連地基都沒準備 , 就開工了 , 到目前為止交付的都是一片一片的木板 ,  然後說這樣叫有產出 ?

PM 也收...

如果有那家公司可以說 , 他們可以投入人力去作 QC , 然後可以把 搖搖欲墜的小木屋 , QC 成摩天大樓的
請告訴我,....