2009/07 永豐永豐基金經理人換人了

永豐永豐是一支個人覺得績效不錯的基金, 不過最近換基金經理人了, 我就去查一下新的基金經理人, 看看他的過往績效怎樣? 看了覺得很失望, 現在可以考慮不要繼續買永豐永豐了.元原原廖韻瑜(轉到元大多多,元大新主流)換謝其勛, 新經理人掌管的永豐高科技,永豐領航科技自96年11月至今操作績效-33,台股績效-26.

阿基師的客家小炒步驟

先準備配料：

魷魚必須先把外面的一層膜撥掉，避免腥味，接著切成絲

豆干跟有點肥的豬肉切成同樣大小的片狀

蒜苗斜絲,

蔥斜絲,

芹菜切成段,葉子可步要,

辣椒斜切,

九層塔三四葉, 切碎提味用, (吃的到味道卻看不到).

1.不要放油，先抓豬肉放下去乾炒，把豬油炒出

2.加入豆干一起拌炒，咬炒到豆乾外面有一點焦，裡面卻還是嫩嫩的狀態

3.加入魷魚拌炒，

4.加一點水，稍微煨一下, (讓豬肉, 豆乾的甜度悶出來和魷魚結合一起). 等水稍微乾一點，油又被逼出時

5.加入配料 : 蒜,蔥,芹,辣椒 乾煸一下.

5.調味 : 2大匙米酒, 2大匙醬油炒一下讓醬油的味道出來, 再加入少許的糖.

6.起鍋前再加入 : 蒜苗綠色的部分, 九層塔, 烏醋.

一個團隊負責多個系統, 開發工作已排好未來的半年計畫, 還有一推搶著安插.

賴 san( くん ) 說他有一個五人團隊, 工作內容則是開發維護零零總總的五套軟體系統, 原本的規劃應有十個人, 但因為景氣不好公司裁員外加人員外流, 目前人事也凍結, 但開發工作已排好未來的半年計畫, 而且還有一堆已知的需求尚未排入, 更恐怖的還有已等待超過一年的需求等著排. 外加三不五時必須應付上頭安插的非預期工作或是一定要先安插的工作.

聽賴 くん 講到這只有哇的一聲, 心想 : 嗯, 工作確實吃重.

賴 くん 繼續說著, 這些系統都不是小系統, 還有部份的系統是與產線有關或控制的系統, 平時電話就不少. 又有資料分析系統, 使用者對資料有疑問, 必須發不少與上游系統溝通及追蹤.

聽賴 くん 講到這忍不住說 : 你那不是五人團隊, 是無敵鐵金鋼團隊.

賴 くん 問到, 其實我是要問像我這種狀況要怎樣處理?

我回答 : 是不是找新工作會比較好一點, 而且簡單.

賴 san( くん ) 這個問題真的很棘手, 光想想像就很恐怖了, 真的遇到了, 日子應該蠻慘的. 但想想現在的景氣, 應該也有人有相同的情況與問題, 替賴 san( くん ) 分析一下也不錯. 賴 san( くん ) 目前所遇到的問題應該有 :

1. 工作量多, 人員不足. 時程安排策略.

2. 系統眾多, 人員配置策略.

3. 系統眾多, 互相支援策略.

4. 既是產線系統, 值班及備援策略.

5. 編制十人的團隊管理策略.

6. 上游系統溝通及追蹤策略.

看看賴 san( くん ) 的型態, 有一些大方向是一定要抓住的.

1. 十人團隊, 團隊的運作要有一定的流程,準則或方向.

2. 所有系統一定要有負責人, 掌管所有大小事.

3. 既然是產線系統, 系統人力備援一定要有, 值班相關準則規範.

上述三大方向的實行細則, 及注意事項 :

1. 十人團隊, 團隊的運作要有一定的流程,準則或方向.

要管理一個十人團隊, 況且系統這麼多, 真的不容易, 所以 :

1.1 團隊的運作流程一定要流暢, 做事方向大家都要清楚, 例如 : 一個新的需求下來, 一定要先瞭解需求, 確認需求無誤之後才可以開工, 至於需求怎要叫做無誤呢? 當需求範圍大時, 就必須要制定需求文件, 請需求者確認畫押, 當需求範圍小時, 有一定的進度就要和需求者再做一次的確認. 如果以時間來看, 最好一個星期一定要和需求者開一次會, 有實際的進度看成果(例如操作畫面), 沒有實際的進度就看文件, 這樣的作法不僅可以和需求者建立緊密的關係, 對於內部也可以有推升的效果.

1.2 該注意的方向一定要明確, 不要變來變去. 一個產線的系統, 品質一定很重要, 所以開發過程中, 要怎樣作法品質的把關, 就必須明確定義, 例如一定要有人最後的品質認證, 或是軟體的單元測試(Unit Test).

所以有時候也可以把流程與項目合併, 例如開發的流程中有一個步驟是品質管控, 而管控的方式就用單元測試實作.

1.3 仔細且頻繁的確認一切事項. 軟體開發看是簡單, 卻時常錯誤百出. 最好每天都要確認一切的事項都是在軌道上正常的運作.

2. 所有系統一定要有負責人, 掌管所有大小事.

2.1 挑選系統負責人. 開發行為和維護行為有著不一樣的注意構面, 也有不一樣的深度, 開發行為從無到有, 所費時間較長, 可以從長計議, 事情單一專注; 維護行為必須, 反應迅速, 舉一反三, 事情多且雜. 但無論怎樣, 一個系統一定要有人負責.

2.2 負責人全權負責. 系統除了要有負責人外, 這個人也要有能立全權處理所有事物.

3. 既然是產線系統, 系統人力備援一定要有, 值班相關準則規範.

3.1第二系統負責人. 系統既然多, 又是產線的系統. 一個系統不能只有一個人會, 一個人不可能只會(或管)一套系統.

3.2 值班規則. 既是產線系統, 問題發生了, 必須要再第一時間恢復. 但問題出在系統這麼多, 並不是所有的系統都是自己開發的, 所以疑難排解標準手冊就變的很重要.

會議中老是做自己的事或人到心不到

怎樣的會議(課程)會使得一個人心不在焉.

會議中我總會不在意的注意與會的人參與情況, 大概就這幾種了.

1. 認真參予, 有問有答. 這總人對於會議內容清楚透徹.

2. 偶爾參予, 但又有問到重點. 這種人我真的不知道他是否對於整個會議的內容都清楚透徹. 一個典型的例子就是 : 他會在會議中使用 NB 處理一些事情, 可是有時又可以和與會者對答. 我想姑且把這種人當作是一個強者, 他就是有能力可以同時做兩件事好了, 因為聽聽這種與會者詢問的問題, 與對答的內容又很清楚.

3. 卯起來做自己的事, 只是偶爾抬起頭來應付會議主持人.

4. 找周公去了.

想想學生時代的課堂上, 也大概是這樣一點都沒有變.

會議主持人, 或是主管, 總是希望與會者能夠清楚透徹整個會議討論議題. 如果是老師, 總也希望所有的學生都可以吸收到課堂上所授與的知識. 但總是會有正反兩群參予者, 只是程度的不同. 為什麼有人就是屬於反面的那一群呢?

小朋友拍痰

這幾天小朋友感冒鼻塞的很嚴重, 晚上睡覺就像大人的打鼾聲一樣大, 帶去看醫生, 熱心的醫生示範了拍痰的方式給我看, 並告知我們一邊拍 200下, 共 400下, 小孩如果哭, 就讓他哭, 小孩子感冒鼻塞最重要的不是吃藥, 是拍痰, 和喝水.

以下是收集自網站上找尋到的文章說明.

‧為什麼要學拍痰？
　由於痰在肺之深部，比較黏稠不易咳出，若能應用重力原理(拍痰)及改變身體姿勢，使積在肺的痰鬆脫，經由支氣管、氣管流出再藉著咳嗽將痰咳出，使寶寶能早日康復。
‧什麼情況下需要拍痰？
　一般五、六歲前之小孩無法自己用力咳嗽，所以當小孩感冒咳嗽有痰聲時，需借助家長拍擊小孩的背部，以協助將肺部裡的痰咳出。
‧如何拍痰才能達良好的效果？
　1. 拍痰的方法：
　一般可利用叩背器或手呈杯狀，利用手腕關節自然活動彎曲的力量溫和並穩定的重覆拍擊胸壁，使該部位的痰被引流，叩擊時應有「砰砰」的中空聲音而非拍掌的聲音。
　2. 拍痰時身體姿勢擺置：
　依痰液部位不同而採不同姿勢，其方法如下列所示：
　(1)痰液部位：肺上葉(肺尖)　
　姿 勢：小孩採坐姿、後傾30度
　拍擊部位：兩側鎖骨以上之部位
　(2)痰液部位：肺上葉後節
　姿 勢：小孩採坐姿、前傾30度
　拍擊部位：兩側背部上方
　(3)痰液部位：肺下葉後底
　姿 勢：俯臥、臀抬高約20公分
　拍擊部位：拍擊脊椎兩側肋骨下方
　(4)痰液部位：左、右肺下葉前底
　姿 勢：側臥、臀抬高約20公分
　拍擊部位：拍擊腋下部
．拍痰時之注意事項：
　1.拍痰時間：
　＊ 一般每天約3~4次，通常於睡前、飯前1小時或飯後2小時做，以免嘔吐致嘔吐物吸入肺部。
　＊ 接受呼吸治療後或服用化痰藥30分鐘後拍更有效。
　＊ 每次拍痰時間一般約5~10分鐘，視病童情況而定，而同一部位叩擊約60~90秒。

    ＊ 洗澡後, 吸收了水蒸氣也是好時機。
　2.拍痰時應先拍患側再拍健側。
　3.拍痰方向應由下往上、由外向內並有做規律性的移動。
　4. 拍痰之力量避免太輕或過重，以免拍痰無效或造成病童傷害。
　5.拍痰中隨時注意兒童有無呼吸困難、臉色蒼白、發紺等。
　6.應避免拍擊肩胛骨、脊椎骨、下背部(腰部以下)、臟器部位。
　7.拍痰時應固定好小孩，以免滑落。
　8.拍痰後應鼓勵小孩咳嗽，嬰幼兒則依情況可請護理人員予以抽痰
　9.拍痰過程中有任何疑問，應隨時詢問護理人員。  

Create Oracle Account

建立一個 Oracle 帳號, 我們會依循下列步驟.

1. 建立該帳號所需要的 Tablespace.

2. 建立帳號.

3. 給予該帳號權限.

大概就這三個步驟就完成了, 實在很簡單, 來看一個實例好了.

1. 建立該帳號所需要的 Tablespace.

    CREATE TABLESPACE TBS_RED_BEAN

    LOGGING 

    DATAFILE '/oracle/data/tbs_red_bean.dbf' SIZE 50M REUSE 

    AUTOEXTEND 

    ON NEXT  5120K MAXSIZE  51200K EXTENT MANAGEMENT LOCAL UNIFORM 

    SIZE 1024K SEGMENT SPACE MANAGEMENT  MANUAL

2. 建立帳號, 並限定其使用空間大小.

   CREATE USER RED_BEAN  PROFILE "DEFAULT" 

    IDENTIFIED BY RED_BEAN DEFAULT TABLESPACE TBS_RED_BEAN

    TEMPORARY TABLESPACE TEMP

    QUOTA 51200 K 

    ON TBS_RED_BEAN

    ACCOUNT UNLOCK

3. 給予該帳號權限.

   grant CONNECT to RED_BEAN;

   grant CREATE SESSION to RED_BEAN;

   grant ALTER SESSION to RED_BEAN;

   grant SELECT ANY DICTIONARY to RED_BEAN;

   grant select on green_bean.employee to RED_BEAN;

讓檢討會議評論與學習在歡熱中完成

檢討會議評論是管理中不討好的議題, 被檢討的人心情不好, 檢討別人的心不在焉, 深怕太認真, 下一次換成自己是被檢討的對象時無法下台.

這個議題雖然很嚴肅, 但是要輕鬆對應, 才會有好的效果. 所以改變氣氛是很重要的(老師都這樣說). 但不管怎樣改變, 效果都不如以下我所使用的方法.

本人所使用的方法是在不知不覺中進行. 

畢竟這是一項工作, 怎有可能不知不覺中進行呢, 當然是不可能, 只是進行方式改變一下而已. 原則如下 : 

1. 在不知覺中開始會議 : 不要會議室, 不要講台, 一切的現況都沒有改變, 只有主導者知道, 會議已經開始了.

2. 會議目的是主持人的底牌, 最後才亮出 : 會議已經熱烈的討論中, 但沒有人知道目的, 卻被引領直奔結論.

3. 慎選第一個發表者 : 既然是檢討會議, 怎可不發言呢, 不要第一個發言者就弄僵了整個氣芬 . 要掌握好氣氛.

4. 讓每個人都發言, 且引領出改善方案.

5. 被檢討者最後發言 

如何看緊你的員工

朋友問, 最近覺得員工的工作狀態不是很好, 大家的進度很慢, 到底要怎樣讓大家認真工作?

我回答 : 哇哈..., 你門公司也會有狀況阿, 你們這些高科技公司, 也有這樣的困擾, 那一般的素質比較低的產業, 不就更嚴重嗎. 好吧, 我們的經驗是這樣的.

就是要看緊點, 所謂的看緊, 就看你怎樣做了喔.

以前我們一個案子有聘請委外的人力(Outsourcing), 這些人力是非常貴的, 一個人力月支出約是我們員工的兩三倍, 你想, 有這種資源的單位, 怎樣使用這些資源, 做了什麼事, 沒有被好好 Review 是不可能的. 所以當你手中有這種資源時, 管理這件事必須格外的做好.

而我們就是每天 Review, 看看昨天做了哪些事情, 完成了哪些, 有沒有怎樣的問題是導致工作沒有辦法進行的, 還有今天計畫要進行怎樣的工作...等. 因為我們有點類似研發的工作, 如果沒有把問題發掘出來, 導正錯誤的方向, 讓這些錯誤繼續進行下去都是在讓費資源, 而多久 Review 一次就是停損點. 故每天 Review , 最多的損失就是一天.

這樣的頻繁 Reivew 對於員工來多, 其實是一個很大的壓力, 所以也需可以改良 Reivew 的方式, 或是說關切, 未達相同目的有不同的作法.

Coverage Lost

朋友告訴我說, 她們現在已經開始在使用NCover這一套元件了, 我想她們又進步了不少, 值得高興.

做系統, 寫程式, 走到這個地步, 我想在台灣已經算是很了不起了, 我必須向您鼓掌.

要談論 NCover , 就必須談論 Unit Test, 哎呀...(還是不要談的好, 對於打字慢的我這可是一種煎熬).

所以直接切入 NCover, NCover 可以讓您知道, 您的程式碼, 有哪些是會被你的測試程式執行過, 然後算出所佔的比例, 這個比例值也就是 Coverage, 當然值越高(表面上)是越好的. 因為這只是表示【被你的測試程式執行過】的比例, 我想說的是執行過不等於被測試過, 我認為這只是一個可Auto Monkey Test. 故我必須強調 : Coverage 雖是一種被認定的指標, 但如果要真的做好測試這件事, 不能只看 Coverage, 還是要做好最基本的 Test Plan, 規劃好 Test Case. 就是這麼一回事喔.

買賣價金信託履約保證

「買賣價金信託履約保證」是一種不動產交易安全的機制，將買賣價金以信託方式管理，確保買賣雙方就買賣價金的給付或返還安全無虞，並由建築經理公司（建經公司）負責流程審控與代書管理作業，並負擔價金保證的責任，可以有效防止一方的惡意或意外情勢所造成他方價金權益的損失，增進買賣過程的順利與安全。

一般來說，簽立買賣契約後，若發生可歸責賣方之因素，以致無法完成產權移轉登記及完整點交房地產、並解除買賣契約時，即由建經公司將買方已給付之價金返還給買方，確保買方在依約履行、卻未能取得房地產時，可完整取回已支付之全部價金。

以我的經驗來說, 這句話真的很令人安心, 也很切實, 不過就如同條文中的說明一樣, 只有在未履行時才有保障, 如果事有一點小瑕疵, 那可能還是要自己處理. 

我買房子的時候就發生了, 車位沒有產權的問題, 而且是機械式上下的車位, 車子停好後, 將機械規定位, 上方的車位與路同高(等同一個平面車位), 而下方的車位呢, 則是在地下, 所以說呢, 上方的車位是比較方便的, 而交屋前仲介及賣方, 都說她們的車位是上方, 到交屋的那一刻, 卻說沒有產權, 而我去詢問社區的人了解一下狀況, 大家都說, 社區的機械式車位是沒有分上下的, 是共同持有, 先到先停, 不然就是雙方協調, 輪流使用上下車位.

這樣的結果, 造成我的貸款已經撥出, 可以車位產權有問題, 我堅持不交屋, 我的想法是, 折扣10~20萬的價差, 不然就是不要買了, 但仲介, 賣方卻都不理我, 很像要一直拖下去, 這樣對我而言是很重的商害, 因為房貸現在已經開始算利息了, 所以我就找上 「買賣價金信託履約保證」公司, 詢問要怎樣處理, 我是否可以不要買了, 對方的客服被我搞的不知道要怎樣應付, 最後由她們的律師和我說, 答案是不可以 : 「因為這樣的事情只可以列為交易的小瑕疵, 但合約一樣可以履行了, 我一樣有一棟可以住的房子, 房子本身也沒有任何安全上的顧慮, 不足以構成不履約的條件, 但未方遲遲不出面處理, 但您可以依據條約請求延遲交屋的賠償每日X金額」. 這就是我的實際經驗.

老闆只要軟體上線前要有另一位QA人員QQQ~~

最近被問到這樣一個案例:

因應系統穩定性, 不要有臭蟲的出現, 老闆要求系統上線前一定要有另一員工把關QA, 但是這位把關的QA人員根本不知到完整詳細的規格, 造成大家的困擾, 緊張.

我想這是老闆的本能, 老闆本來就這專門下這種指示, 細節就要看看下面的人怎樣制定與實作了, 至少老闆已經清楚的表達他要做到的事, 細節的部份當然要有員工去想.

問題的解法很簡單, 我們必須先將遊戲規則制定出來, 與老闆確認一下, 然後去執行即可. 但我想有幾個點一定要說說清楚.

1. 初次上線的軟體系統是不大可能保證沒有臭蟲的.  (如果要硬ㄠ可以做得到, 我也承認是可以做得到, 但這是一個具風險及成本問題.  以及不能說的秘密), 

2. 身為開發者可以做的是什麼? 要減少臭蟲的產生, 以其避面臭蟲的再現. 這是很重要的, 如果可以做到這兩點我想已經很了不起了.

3. 要有所本, 有所依據, QA要怎樣把關, 不是讓 QA 人員以自由心証的方式去做這件事就可以的, 但是不可缺少的. 就好比 微軟的軟體測試方法中所說的一樣. 除了要有明確的說明要測試哪些, 還要加上一些經驗法則.

一個系統可以沒有Owner嗎?

一個系統可以沒有Owner嗎?

系統大又多, 一個團隊有七個人的組織, 卻想要所有的人都要懂所有的系統細節, 這到底是好事還是痴人說夢話.

以事有專精, 效率的出發點來看, 這就是不被允許的, 事實就是這樣, 但卻又不敢面對, 如果目標是這樣, 那為何每次問不同的問題, 總是會早不同的特定人來問, 這不是心裡就擺明了, 也很清楚.

所想只有一個答案, 因為不願意面對自己錯誤的決策.

如果要達到, 所有的人都可以維護所有的系統, 只有一種方式可以達到, 就是把商業營運放一旁, 以學習為重.

印象中的零用錢來自

在我的印象中, 我只有和媽媽要過一次零用錢, 隱約記得是要去買冰棒, 僅此一次.

我的零用錢都是自己賺來的, 其實究類似打零工, 像是...

1. 挖荔枝或龍眼仔. 在荔枝或龍眼大量產出價錢不好的時候, 就會有工廠的人載來一籃籃的荔枝或龍眼在一些廣場或是廟前, 要把這些荔枝或龍眼剝殼挖出裡面的仔, 然後工廠帶回去加工. 奶奶總是很喜歡帶著二姐和我一起去, 我記得一籃約有十斤, 約要發費一小時的時間才可以挖的完, 所取的報酬10元, 一天大約只可以挖6-7籃吧, 而且回家時都是腰痠的要命.

2. 撿蝸牛. 無論是好天氣或是雨天, 都可以撿蝸牛, 當雨天是比較的時機點, 雨天可以撿比較多, 只是麻煩了一點, 要穿雨衣與雨鞋. 在我的家鄉有很多人種植檳榔, 檳榔葉子是蝸牛最喜歡棲息的場所了, 必須將一片片的檳榔葉翻起來, 仔細的檢查過有沒有蝸牛. 當撿拾完畢後如果數量夠多, 就會拿到隔壁相去一個專門收集的地方賣給收集人, 如果數量不多就會暫時用家裡養雞的雞籠關起來, 怕蝸牛沒有東西吃還會去摘地瓜葉給蝸牛吃. 這些蝸牛後來我才知道其實是被食用的.

3. 摘毛豆夾. 這是最好賺的零工, 摘一斤價值四元, 一天可以輕鬆摘到200~400, 但是要很早起床, 可能是太好賺了, 大家搶著做. 我不知道這背後的運作邏輯是怎樣的, 然而我們摘毛豆夾的模式是這樣的. 前一天我們可以得知明天要到誰家的毛豆田裡摘毛豆, 一大早到了田裡後, 先將準備要摘取的毛豆收割好一堆, 然後開始摘取, 摘取沒過多久夏天的太陽就曬的我們感覺熱了起來, 有些人會戴斗笠或是帽子, 厲害的人會準備500萬的那種大傘立起來, 也許是太好賺了, 我們中午的時候幾乎不會休息, 母親會回家煮好飯帶過來給我們吃, 這樣利用一點時間飽足一頓後繼續摘取.

4. 放青蛙或釣青蛙. 這是我最喜歡的一種賺取零用錢的方式了, 因為過程充滿了熱趣, 放青蛙的方式是先準備好放青蛙的道具, 這種道具其實很簡單, 只要一個魚鉤, 魚線, 竹子這三樣即可, 當然也要有蚯蚓作為餌, 不然青蛙不會自己上鉤的, 當道具準備好後就是到水田裡, 將這陷阱插在水田裡, 等隔天再來收取這些陷阱. 此外還有一種我最喜歡的釣青蛙, 釣青蛙的工具有點像放青蛙陷阱的加大版, 也可以想像是釣竿, 但是沒有魚鉤, 而是直接綁一條蚯蚓, 重點是在要怎樣釣? 不向釣魚一樣放這等魚上鉤, 而是必須讓蚯蚓餡上下跳動, 這樣可以吸引青蛙的注意, 增加釣到青蛙的成功率, 但還有一個重點就是要有耐心, 不是當青蛙一口吃下蚯蚓餡就急著拉起來, 必須等一下子, 等青蛙將餡吃進去一點才拉起, 如果沒有就會於心喜拉起青蛙在半空中時就婉惜的看見青蛙掉下去了.

軟體專案準時達交的風險控制

最近金融風暴席捲全球, 驚嚇中對於風險控制的討論逐漸變多了.

但今天我要想的是【軟體專案的風險控制】, 記得曾經有位大師說 : 專案永遠一定是延遲的, 不可能有提早或是準時的, 不是因為能力問題, 而是因為策略或運作面的問題. 問題是這樣看的, 今天老闆給100元的成本執行專案, 可是你最後只使用了90元就完成了專案, 下一次再一個新的專案成本需要200元, 這時老闆會允許給你200元或是只給你180元, 這就是一個很玩味的問題.

其實軟體專案的風險問題, 不管是在 Software Project Management, PMBOK 裡都有詳盡的說明, 主意大約是這樣的【透過管理，正視風險，預先規劃，過程監控,  並依據重要程度處理事件】.

我想作法大約就是 : 

1. 專案進行前, 先建立一個可能面臨的風險表格, 內含風險事件名稱, 風險等級, 處理方式. 

2. 專案進行中, 隨時依表監控, 當有表徵出現時, 依循處理.

3. 再來就是看看要不要定時或偶而來一個應變演練.

4. 當然所有事請過後一定要來個撿討與改善, 以便使得風險控制可以做的更好.

哎呀, 講了這麼多, 心裡就怕了起來, 要做真的很多事, 這樣專案怎可以如期完成了?

不過重點還是要想想一個軟體專案, 到底會面臨怎樣的風險這倒是要好好思考的.

軟體專案準時達交常見風險 : 

1. 人員異動. 這件事軟體公司, 小公司, 小專案, 真的很常見, 不過就我所知, 現在個客戶也都意識到這一個問題了, 所以很早以前我就已經有被某些客戶要求將人員異動加入合約中(這一召有夠狠 : A. 人員離職就要拿更多的資源來. B. 人力不可挪移. ...等).

2. 持續性的需求變動. 不知道有沒有人沒有遇過這一個問題, 如果有到要請教怎樣做到的? 

3. 不實際時程及預算. 如果遇到這一個問題, 包袱打包一下走人吧. 軟體產業真的是一個極度競爭的產業, 常常遇到一個標案, 底價可以差到10倍. 是大家的認知有這麼大的差異嗎? 還是另有因素, 當然都是有的. 

4. 使用者的程度不好(好傷人的話, 本身沒有責任嗎). 軟體系統開發者需不需要了解產業知識, 這個問題也很熱門, 那功能做錯了, 是使用者程度不好, 沒有說清楚, 或者是開法者太過膚淺, 沒有挖掘到真正的需求, 沒有引導好使用者. 本人覺得見仁見智, 不多說.

5. 專案團隊/領導者的經驗不足(專業能力不足).  常常有出道才一兩年的程式撰寫者搖身一變就成了專案管理者, 而那些倒楣的專案就成了試煉專案, 客戶賠上的不只是一個失敗的專案, 還有位專案所投入的額外成本. 當然一個領導者, 也不是這麼容易的.

6. 時程安排過於樂觀.

7. 軟體的可靠度、成熟度不理想.

8.資源的過度使用.

9.問題隱藏在良好的表象內.

10. 錯誤的功能及即時處理.

好的就到此為止, 在寫下去, 身為IT的我也要被唾棄了.

我們家妹妹也腸絞痛

那到底甚麼是嬰幼兒腸絞痛呢？又怎樣會腸絞痛就不多說了, 直接說妹妹的狀況.
大約是妹妹一個月大的時候, 這種狀況維持約有3星期, 每天到下午都會哭鬧, 但不是很嚴重, 還可以安撫的狀況, 只是動不動就哭, 很難餵奶, 不是喝不完就是要分很多次餵; 至於晚上就嚴重多了, 大概要哭到三點才會入睡, 在沒有入睡的這段期間, 幾乎都是在哭, 不睡覺, 喝奶不好餵, 大概的狀況就這樣, 問問週遭的同事, 也沒有這樣的情況.
妹妹的狀況我們大概撐了兩個星期, 受不了只好找醫生, 醫生就說是腸絞痛, 開了藥給妹妹吃, 但觀察起來覺得只有一點點的改善, 期間因為太痛苦了, 又買了益菌, 酵素等產品.

怎樣支配時間

在<上哈佛真正學到的事>一書中提到, 對哈佛一年級的學生來說, 最重要的應該是盡快熟悉管理時間的方法, 也就是學習如何將「必須做的事」和「想做的事」均衡安排.
我想這是我們生活中的寫照, 當邁入職場時, 這更是一項重樣的議題 : 也許我們每日都非常的忙碌, 記事本裡記滿了一推待辦的事項等這處理, 可是有些事情就是一直重複的出現在筆記本裡, 但永遠的一再被埋沒, 又一再出現. 這就是典型的情況.

通膨下的基金

最近買基金的朋友們一定很傷心, 因為最近基金跌幅已經有兩成了吧, 辛辛苦苦賺的錢就這樣不見了, 到底要不要繼續持有呢? 相信這是大家心裡的一個重大疑問?

基金的投資分成兩部份 : 定期與單筆.
定期地基金就是要分善風險, 當市場下跌時, 是一定要繼續扣款投資, 這樣當景氣迴轉時, 才可以嘗到甜頭, 只是口袋一定要夠深, 因為景氣何時回轉不一定, 所以之前常聽說的以基金養基金的作法, 這時可能就會破功了, 因為當上次贖回的總金額現在還在扣款, 當金額扣完時, 可能景氣尚未迴轉? 就有點像單筆. 這是一個定期的觀念, 但不樣忘了, 買到不好的基金, 也有可能永遠沒有漲回的時候, 或者漲福永遠比別人少, 所以也要注意自己持有的基金績效平均而言是不是都是前段班?
至於單筆的投資, 其目標就是要買在低點, 像現在通膨嚴重, 就不是單筆的投資時機點.

機會就像遭小偷

機會就像遭小偷 來的時候不知道, 走的時候才知覺.
用這句話來形容機會實在貼切不過了.

資料庫管理者的工作與挑戰

1. 系統面 穩定的資料庫
2. 資料面
3. 管理面

William Hunt Gross - 債券天王

閱讀自商業週刊 :
William Hunt Gross - 太平洋投資管理公司創辦人暨投資長, 唯一贏得3次晨星最佳固定收益基金經理人. 公司總資產8,120億美元, 從1987年起平均每年為客戶賺進10%的報酬率, 開啟主動式債券交易風格.

Gross 於大學畢業那年的一場車禍, 於住院時讀到加州大學教授索普 (Edward O. Thorp)所著-打敗莊家(Beat the Dealer)一書 : 教人用記牌方式在二十一點撲克牌遊戲獲勝. 出院後, 他帶著兩百美元到賭城試身手.

一開始, Gross 受不了周圍環境的菸味和酒氣, 經常無法集中注意力天都沒贏, 因此他會沮喪的不敢回到賭桌上. 而去觀察哪個發牌員比較會帶來好運. 後來發現一直換賭桌, 根本無法記住莊家已經出了哪些牌, 也就無法預測牌盒裡還有哪些牌.

這已經與打敗莊家的精神背離了. 因此 Gross 決定改變策略, 在同一個賭桌連賭四個月. 其間就算他輸了大注, 也從不退場, 繼續留在牌局中, 用兩美元下注, 就這樣當初的兩百美元盤纏, 竟然翻了五十倍成為一萬美元.

在這期間 Gross 建立起一套評估未來事件的機率 (也就是投資上的風險) , 將其分為長期與短期, 如果用二十一點比喻, 留在牌盒裡未發的牌, 代表的就是長期機率, 而莊家所發的下一張牌, 則是短期機率. 當你記住莊家已經發出哪些牌, 就掌握了長期機率, 你可以算出, 牌盒裡是點數大的牌多, 或點數小的牌多. 因此莊家接下來會發出什麼牌？你猜中的機率因此提高, 也可據此決定是否補牌.

Gross : 我從賭桌上瞭解, 當你看到勝利機會倒向自己時, 一定要持長期觀點. 因為短暫壞運所造成的損失, 會因長期趨勢有利於你而被攤平. Gross 悟到, 即便出錯只要對的次數加起來多於平均, 你就可以打敗莊家.

帶著長期觀點的思考架構, Gross 第一份工作是太平洋保險公司的債券分析師, 並於進公司六個月後提出 : 把債券當成股票, 在市場上買賣的做法.