黑社會大發現 -- 電費帳單上有排放CO2的公斤數

今天晚上等著收看線上版日本秋季日劇時, 瞥見我家的電費帳單上居然有排放CO2的公斤數, 還要我們節約用電、愛護地球.
真沒想到台電也跟得上時代, 搭上"全球暖化"的潮流.



更沒想到的是, 喊沒多久的"加入聯合國"口號, 也出現在帳單上, 真是走在時代尖端啊 ...
以後我可以決定自己的帳單的版面嗎? 我要三隻小豬和無敵丁丁印在上面. 當然啦, 愛護地球的字樣絕對不能少.

黑社會請你好自為之

我沒什麼資格寫這些東西, 但真的是搞不懂現在的年輕人在想什麼.


我並非資訊科班出身, 也不是聰明人, 有時候一件事情要反覆看過好幾遍才記得住、討論好幾次才有較完美的解法, 我總是很慶幸身邊有一群優秀和善(毛爺是和善的人)的夥伴鞭策我、勉勵我、包容我.
我能給予後進在技術上的指導不多, 在工作態度上及對專案的態度上, 我倒是能開導他們, 慢慢的和他們談談 ... 起碼我是這麼認為.
一路走來, 遇到不少好夥伴、好前輩, 還有一些剛踏進資訊業的新鮮人, 大家都很認真打拼.
但是, 目前碰到的這個後進, 讓我差點就想去看心理學的書, 把他解剖一下.

他不是個笨蛋, 自己看書學Java, 轉進JAVA領域, 頗好學.
但當我才這樣想(好學), 建議他有空要看點JP基本概念的東西, 他說以前都看過, 他比較想了解我在閒聊時提到的Design Pattern.
沒想到馬上一堆OO基本概念有問題, 也不會用command line包jar檔案, 不會用command line執行程式, 請他上Google找, 還是找不到.
他也不太熟JAVA API, 如JNDI等等, 請他花點時間找資料(反正他老闆沒跟他壓時程), 又在那邊很為難的樣子.
負責的Migration程式可以做一個多月(把A,B,C資料表內的某些欄位, 併到D,E,F資料表內), 算是有難度啦.
Migration程式常常run到當, 被User叫去改程式, 在那邊扭扭捏捏哀聲嘆氣, 讓他在座位上debug每次都會睡著.
建議他使用Log4j紀錄Log, 還給他範例直接照抄, 他嫌要花時間study, 用開IO的方式做.
請他架設另一個可以包版的環境, 可以拖半個月, 一問他, 又會說:"哎唷, 那個...."


這幾天大家回公司度假, 我特地丟了這篇文章給大家看Using JAX-WS and JAXB with WebLogic Server 10
他說好閒, 希望快點有新任務. 問他對JAXB的感想, 他說上網找了一下, 要下載一堆東西, 還要Tomcat, 他覺得很麻煩, 就不試了.
問他不能stand alone測試JAXB嗎? 他丟給我一個網址, 說他是照著上面寫的來做.

到底是誰說測試JAXB一定要有Tomcat?
底子不好, 不趕快利用時間補強, 難道打算在開發專案的過程中才鍛鍊?


人非聖賢, 重要的是態度.
專案的確有時程壓力, 第一要務是要把事情做完, 但如果態度上就是只想把事情做完, 連更進一步的態度都沒有, 一起合作的人或客戶會覺得很無力. 更別提出門在外, 我們都是代表公司的.


這位同事的職稱掛著是"系統設計師", 他可能要好自為之了, 或者說, 我們也該好自為之.
因為 ... Payment (線上付款) 的 SD, 要由他來開給大陸PG實作.

黑社會感言 -- 真正在乎的事

我們年紀越大, 越在乎的事情就越多, 但大多是"看起來"或是"自以為".

我們在乎地位, 但地位可能是用喊出來的, 不值幾個錢.
我們在乎成就與經驗, 但時光匆匆流逝, 終將只是"好漢當年勇".
我們在乎所得與財富, 但所得與財富的高低, 與幸福程度一點關係都沒有.
我們在乎輸贏, 這次贏了又如何? 百年之後有多少人會記得我們曾經贏過? 除非我們參與第三次世界大戰.
...

我們在乎的事情看起來很多, 卻好像不是那麼值得花力氣去在乎.


最值得我們在乎的, 還是自己曾參與過的每一個活動的過程, 而不是成果.
最值得我們在乎的, 是與自己的生活有密切關係的人 - 朋友, 親人.


這次 外婆80大壽&大舅60歲生日 壽宴, 原定於上週六晚上, 因遇颱風, 改至今日晚間舉行.
時間一改, 人就少了, 大表弟與二表弟在外地唸書、三表弟要準備明天的段考、二表妹也要準備明天的段考.
我總覺得外婆心中應該覺得有點落寞吧, 與預期不甚相符.




外婆的眼神仍是炯炯有神, 但仔細一看, 似乎比去年略顯沒精神.
年紀大了吧... 這幾十年來, 也真辛苦她了.

大家改天好好聚聚, 讓我好好拍拍.


敬祝 福如東海, 壽比南山.

黑社會不負責影評 -- 令人驚艷的 跳躍時空的情書(The Lake House)

三天內, 看到兩次HBO播放的跳躍時空的情書, 讓我十分驚喜.
這部電影, 在開拍前, 備受亞洲影迷關切, 因為這是改編自超級叫好叫座的韓片觸不到的戀人.
我對韓國戲劇一點興趣都沒有, 當然沒看過觸不到的戀人, 卻很想看看改編後的美國片跳躍時空的情書.

如我預料, 不到2HR的戲, 整部戲的風格清新脫俗, 沒有灑狗血的男女愛情戲, 只有邏輯不通的夢幻優美風景愛情小品.

女主角 - 由珊卓布拉克飾演, 一位忙碌的女醫生, 除了工作, 她沒有其他的目標與方向. 曾有個超積極愛作長遠計畫的男朋友, 卻還是選擇一個人生活著.



男主角 - 由基努李維飾演, 一位務實的建築師, 有個嚴格自大的名建築師父親, 他卻選擇和工人們一起蓋房子, 蓋出讓人居住的房子.

女主角於2006年搬出湖邊小屋, 留下一封信給後任屋主. 2004年搬進屋的男主角, 卻收到這封信.
兩人透過不合邏輯的書信往來, 逐漸了解雙方, 成為莫逆知己.

男女主角相愛的劇情, 是最受網友抨擊的, 沒有邏輯可言.
我個人偏愛最後一段, 也就是更多人批評的女主角寫信搶救男主角大作戰(避免男主角被車撞死). 女主角在2008年得知男主角於2006年被公車撞死後, 發現自己在2006年於車禍現場搶救的傷者就是男主角, 急忙開車到湖邊小屋寫信提醒男主角.
轉念想, 現在有越來越多人相信時空旅行的存在, 若這是小叮噹設下的局, 也就沒那麼說不通吧, right?
(對我來說, 這是可接受的啦, 畢竟我最愛的電影內, 就有星艦迷航記和似曾相識)


湖邊風光一覽無遺, 芝加哥的街景相當有時代感.
導演運用剪接技巧, 塑造出男女主角"遠距離超時空"對談場景.






有網友說珊卓老了, 基努臉皮鬆弛了, 但這都不影響這部片的可看性.
不過 ... 基努的哭戲和吻戲得要加油, 不然又是駭客任務Neo.


推~~~ 適合在假日悠閒的觀賞.

黑社會不知所以然 -- 一個什麼都沒有的WorkShop

我只能說 ... 參加這個workshop, 不知道學到了什麼.

主辦單位, 為了模擬一個真實案子的狀況, 特地在WorkShop開始的前兩天, 才公佈分組名單和題目.
與其說是題目, 不如說是一個故事, 一個充滿對既有系統無數抱怨的故事, 每一組要設法去發掘各單位的真正需求.

第一天:
第一次需求訪談, 取亂數決定先後順序, 每一組訪談各單位主管, 皆分配到30分鐘的時間. 訪談完都要產出會議紀錄.
第二次需求訪談, 取亂數決定先後順序, 每一組訪談各單位主管, 皆分配到20分鐘的時間. 訪談完都要產出會議紀錄.

在兩次訪談完後的當天晚上7:00, 做Scope Difinition的報告, 每一組都要派三人上場.

第二天:
上午, 須先繳交事務流程圖, 給老師們審閱.
下午3:00, 繳交SRS初稿.
下午4:00, 繳交事務流程圖+UI+Report.
晚上9:00進行老師們的逐一講解.

第三天:
原本有一次各組預演, 11:00才繳交最終版文件, 沒想到 ... 一個強烈颱風直撲台灣而來, 老師們緊急宣布, 改成早上7:30繳交文件, 吃完早飯馬上閃人, 擇期做最後的上台報告.


這樣的課程, 看來精實, 精實到有點亂七八糟, 不知自己在幹麻.
或許是我們這組還沒有默契, 或許是我對事務流程圖不熟悉, 或許是我還不懂Function Point的計算方式 ...
什麼Function Point, 什麼事務流程圖, 什麼簡報技巧... 先把文件趕出來再說吧!
尤其是決定第三天要提早閃人, 更是把大家的步調又打亂了 ...

這次的課程中, 除了對課程安排的報怨, 我當然也有深刻的自我反省:
1. 題目設計的範圍太模糊, 當然啦, 真實狀況有可能這樣, 只是時程緊湊到大家花太多時間在趕文件, 而不是把時間用在搞懂需求.
2. 一個專案, no SOP no SOW no Function List no docs ... 什麼都沒有, 我已經幾百年沒碰過這種一看就很塞的專案.
3. 以後要和組員及早培養默契, 準備工作不足, 所以才會在第一輪訪談時不知道要問什麼, 不知道問題的權重.
4. 沒搞清楚各部門的business flow, 應該要直接搬白板到各主管們的面前, 當場畫押. (場地就只有桌子椅子)
5. 第一次與第二輪訪談中的間隔, 時間有限, 每個人都沒有好好review第一次的會議紀錄, 所以有人問了重複的問題, 被釘.
6. 花太多時間在趕文件, 沒有人真正從頭到尾了解需求. 連算Function Point都只有一個人在算, 因為其他人都在趕別的.
7. 上台做簡報, 有經驗的人不多.
8. 各項規劃上, 不足的地方頗多, 包含抽籤決定順序, 與公布事情的安排上(一定都要從宿舍走到集合地點)
9. 最後一天時程變更, 導致作業又亂掉了, 等於兩天晚上都沒睡.

唉, 很累阿~~~
在颱風開始肆虐的週六, 我ㄧ回到家, 跑去吃麥當勞, 然後就開始昏睡->頭暈->發燒. 週日也是頭暈->發燒->拉肚子.
上完這課程, 我還是不知道怎麼畫古早的事務流程圖, 不知道怎麼算Function Point, 不知道怎麼做需求訪談.

題目如下, 請參考:

Problem Statement

奇妙公司(EG)是台灣最大且最多角化經營的公司之一，EG 擁有 13 條主要產品線，滿足客戶服務需要是該公司最為重視經營理念，但是公司現在面臨組織調整與YesGood 服務系統無法反應產品、市場和服務競爭環境的改變。當初YesGood 系統從規劃到建立經過3 年，幾經波折終於建置完成，上線後狀況不斷，維護團隊人力又全流失，無法即時滿足公司應變需求。業務主管反應，客戶投訴案例開始增多，客戶對於EG 服務滿意度下滑，業績估算會下降2 成。由於系統效能不佳，客服人員無法線上即時更新客戶資料，必須先將客戶反應用筆記錄等下班後再上系統補登打，常常要忙到8、9 點，IT 已經診斷幾次速度有改善一點，但是還是未能完全解決到底是AP 問題還是網路層問題。

另外，全省客服獨立運作，有些縣市客服電話量少，有些縣市電話量大，電話量大之外縣市業助要兼作客服人員，有時忙到沒人幫忙接電話，也沒空追蹤客戶來電後續處理狀況，造成客訴量增加。相對的也造成業務抱怨業助份內之內勤進銷存作業常常延誤。工程師也常因一方面趕出勤一方面幫忙接客服電話，影響服務品質。而且每次出勤後設備換修及客戶基本維護資料，並未能即時更新到YesGood 系統上，每次出勤前都要花時間確認客戶目前規格才能帶備品前去換修。由於出勤租賃設備之維護資料更修尚不能與總務維護的固資系統同步，例如：A 客戶退回後業務單位直接送B 客戶，未通知總務固資更換使用人，所以總務固資帳也很亂，總務也很無奈。

因為沒有好的IT Solution 及全省統一的SOP 完整客服流程，客服每日電話處理量由100 件降到60件，回應速度延長二倍，衍生出更多客訴問題。另一方面，系統的合約資料採各區自行建立未統一管控，導致業助每月發票開立時需花五個工作天逐一核對單一客戶請款資料，今年發生三次客戶單據不完整拒絕付款，公司累計損失已達十餘萬。工程師由於出勤前置時間平均拉長20 分鐘，每日可出勤次數相對減少1-2 次，有些合約無法依要求期限內到場維修完成，間接影響客戶第二年續約意願。反觀競爭同業「比你快公司」使用對的 IT Solution 及不斷的流程改善，已成為EG 最大競爭廠商。

公司高層主管指示奇妙公司要成為兩岸三地台商最佳的IT夥伴。因此爭取成為客戶DMO(Desktop Management Outsourcing) 的供應商夥伴，將會是我們與客戶維繫長期關係的重要手段， 因此公司提供新一代的客戶服務系統(New Generation Yes Good) 取代現有的YesGood， 提升服務品質， 協助公司達到成為兩岸三地台商最佳的IT夥伴的策略性目標. 公司高層主管於今年6月指示成立跨部門小組 (業務主管，財務主管，客服主管，工程部主管及IT主管)針對公司之SOP及新一代客服系統 YES Good提出規劃，並請廠商於1年內依規劃完成新一代YesGood建置。
.

奇妙公司工作小組已於9月完成SOP， 為了系統能夠如期完成， 奇妙公司要求其長期配合廠商ABC公司協助新一代YesGood系統的開發， 整個計劃軟硬體部分預計900萬元，其中軟體部分約350萬元。

您是ABC公司負責本案的專案小組成員， 請貴組安排時間與奇妙公司的工作小組成員進行訪談，蒐集相關資訊，對工作小組提出需求分析報告， 並提交軟體需求規格書供工作小組確認，以利整體開發工作之進行.。

PS : ABC 公司過去的平均生產力資料為 2 FPs/人天， 專案小組成員平均人月單價10萬元。