2010年4月6日 星期二
給大學生的忠告
2010年4月4日 星期日
D/A轉換器的性能指標
2010年4月1日 星期四
Oring
它跟橡皮筋一樣具有彈性.可朔性.橡膠材質,但也會隨時間劣化損壞,經過一段時間就須更換,算是一種耗品.
NDA
高手主管 開會4絕招
「會議應該是互動的,不應是被動的;會議應該是有架構的,不應是散亂的。」
|《成功的會議》作者韓克爾(Shri L. Henkel)
沒人喜歡開會,但開會卻是組織有效運作的關鍵要素。開會開得好不好,更是檢驗主管的領導能力,以及他的團隊工作能力及效率最直接的途徑。
開會最常出現的場面,不是鬧哄哄,就是靜悄悄。前者人多嘴雜議而不決,後者除了會議主持人滔滔不絕之外沒人發言,兩種情況都是沒有組織、沒有效率的開會,「開會開到死」的怨言自然出現,主管的威信也自然不斷受損。
討論如何開會的著作非常多,綜觀各家之言,把會開好有四大關鍵。
第1招 出席人選適當
一項會議能否開得有效果,首要關鍵因素就是與會者。
很多主管喜歡愈多人開會愈好,因此經常可以看到有些與會者百無聊賴,從頭到尾不發一語,既浪費資源,也有害組織效率。因此,慎選與會人選,是會議能否開得好的第一步。
1.與開會主題直接相關:部門內直接相關的人,才需要出席,避免不相干的人參加,徒然虛耗資源。若是跨部門會議,請別的部門主管指定出席者,後續開會由被指定者出席,但必須將開會通知及會議結論同時寄給被指定者。
2.控制開會人數:開會人數最好不要超過十人,否則會議很難有效率。若開會人數太多,必須分組、分子題討論。
3.事先指定會議記錄者:會議紀錄至關重要,但許多人往往忽略這一點。開會之前,必須先指定誰來做會議紀錄,詳實記錄會議的發言、決議、決議事項執行者及執行時間表等細節。
第2招 沒準備,別來開會
很多人兩手空空來開會,光是讓每個人進入狀況便耗掉許多時間。每個人都做足準備,發言討論才能夠切中問題,否則會議很容易陷入冗長無聊、浪費時間、難以達成結論。
1.事先說明會議的主題及目的:為避免離題及散亂,開會前必須寄發開會通知,清楚說明會議主題及目的,並指定報告人員。
2.事先將議程寄發給與會者:議程中除了討論事項之外,必須訂定報告時間、討論時間等細節,以利會議的推進。
3.備妥並閱讀報告資料:每一位與會者都必須準備好跟自己負責的部份相關的資料及報告,並至少在開會前一天寄給其他與會者;不報告的人也必須在進入會場前先閱讀完所有的報告和資料,並做好提問及發言的準備。每位與會者均做足準備,會議才能迅速進入有效討論及決議。
第3招 有議必有決
很多會議會而不議,議而不決,決而不行。這些問題,都出在議程管理不當及未釐清責任歸屬。
1.檢視上次決議進度:會議一開始,必須先檢視上次會議結果的執行進度,是否有發生問題或遇到困難?方向和時間表需不需要修正?然後才進行新事項議題的討論。
2.討論集中:進行報告時,為避免報告遭到打斷,疑問可提,發表意見則不宜。討論時,必須確保不離題。一旦離題,主管必須適時拉回主軸。與會人員意見衝突爭執不下時,主管必須懂得適度仲裁。必要時可動用表決解決爭議。
3.議必決、決必行:達到決議之後,指定負責及協辦人員,議定完成任務日期、進度檢查點(check points)及凍結點。檢查點目的在於進度回報及進度管理。凍結點指的是過了某個時間之後,該決議不得再做大幅度變動,以免造成混亂及延誤。
4.會議紀錄:會議紀錄必須包含會議名稱、與會人員、召開時間及地點、討論事項、發言,以及決議、負責執行人員、檢查點及凍結點。紀錄整理好之後,開完會的當天、最遲隔天,就把會議紀錄傳給所有與會者。其目的有二:一、讓每個人再度確認會議結果,以免有的人因認知不同而產生誤解。二、白紙黑字記錄下來,以利後續追蹤管理進度。
第4招 開會不拖拉
開會最忌不準時開始,不準時結束,兩者都會嚴重影響所有與會者的工作、增加公司成本,同時延誤相關人等後續時程。
1.準時開始、準時結束:明訂會議開始時間,遲到超過十分鐘不得進場,嚴格制行,讓開會準時變成部門習慣。
2.進程時間控管:事先寄發議程,開會時將議程寫在白板上,嚴格按照時間表開會,如果議題討論即將超時又尚未達成決議,主管必須動用表決或親自決議。假如討論時發現該議題的確牽涉複雜,眼前沒有足夠資訊可供做出正確判斷,或不同部門需要再回去討論,則可暫時擱置,訂定下次開會時間之後,進入下一議題討論。
把會開好 4大絕招
1.出席人選適當
2.沒準備,別來開會
3.有議必有決
4.開會不拖拉
慎選與會人選
1. 與開會主題直接相關。
2. 控制開會人數。
3. 事先指定會議記錄者。
沒準備,別來開會
1. 說明會議主題及目的。
2. 通知議程。
3. 備妥並閱讀報告。
有議必有決
1. 檢視上次決議進度。
2. 討論集中。
3. 議必決,決必行。
4. 會議紀錄。
開會不拖拉
1. 準時開始、準時結束。
2. 進程時間控管。
2010年3月31日 星期三
年輕應該學會的十件事
- 守時買個鬧鐘,以便按時叫醒你。貪睡和不守時,都將成為你工作和事業上的絆腳石,任何時候都一樣。不僅要學會準時,更要學會提前。就如你坐車去某地,沿途的風景很美,你忍不住下車看一看,後來雖然你還是趕到了某地,卻不是準時到達。"鬧鐘"只是一種簡單的標誌和提示,真正靈活、實用的時間,掌握在每個人的心中。
- 不要扭扭捏捏如果你不喜歡現在的工作,要麼辭職不干,要麼就閉嘴不言。初出茅廬,往往眼高手低,心高氣傲,大事做不了,小事不願做。不要養成挑三揀四的習慣。不要雨天煩打傘,不帶傘又怕淋雨,處處表現出不滿的情緒。記住,不做則已,要做就要做好。
- 忍受孤獨每個人都有孤獨的時候。要學會忍受孤獨,這樣才會成熟起來。年輕人嘻嘻哈哈、打打鬧鬧慣了,到了一個陌生的環境,面對形形色色的人和事,一下子不知所措起來,有時連一個可以傾心說話的地方也沒有。這時,千萬別浮躁,學會靜心,學會忍受孤獨。在孤獨中思考,在思考中成熟,在成熟中昇華。不要因為寂寞而亂了方寸,而去做無聊無益的事情,白白浪費了寶貴的時間。
- 要著眼未來走運時要做好倒霉的準備。有一天,一隻狐狸走到一個葡萄園外,看見裡面水靈靈的葡萄垂涎欲滴。可是外面有柵欄擋著,無法進去。於是它一狠心絕食三日,減肥之後,終於鑽進葡萄園內飽餐一頓。當它心滿意足地想離開葡萄園時,發覺自己吃得太飽,怎麼也鑽不出柵欄了。相信任何人都不願做這樣的狐狸。退路同樣重要。飽帶乾糧,晴帶雨傘,點滴積累,水到渠成。有的東西今天似乎一文不值,但有朝一日也許就會身價百倍。
- 學會堅強不要像玻璃那樣脆弱。有的人眼睛總盯著自己,所以長不高看不遠;總是喜歡怨天尤人,也使別人無比厭煩。沒有苦中苦,哪來甜中甜?不要像玻璃那樣脆弱,而應像水晶一樣透明,太陽一樣輝煌,臘梅一樣堅強。既然睜開眼睛享受風的清涼,就不要埋怨風中細小的沙粒。
- 管住自己的嘴巴管住自己的嘴巴。不要談論自己,更不要議論別人。談論自己往往會自大虛偽,在名不副實中失去自己。議論別人往往陷入雞毛蒜皮的是非口舌中糾纏不清。每天下班後和你的那些同事朋友喝酒聊天可不是件好事,因為,這中間往往會把議論同事、朋友當做話題。背後議論人總是不好的,尤其是議論別人的短處,這些會降低你的人格。
- 把握機遇機會從不會"失掉",你失掉了,自有別人會得到。不要凡事在天,守株待兔,更不要寄希望於"機會"。機會只不過是相對於充分準備而又善於創造機會的人而言的。也許,你正為失去一個機會而懊悔、埋怨的時候,機會正被你對面那個同樣的"倒霉鬼"給抓住了。沒有機會,就要創造機會,有了機會,就要巧妙地抓住。
- 學會與人溝通若電話老是不響,你該打出去。很多時候,電話會給你帶來意想不到的收穫,它不是花瓶,僅僅成為一種擺設。交了新朋友,別忘了老朋友,朋友多了路好走。交際的一大訣竅就是主動。好的人緣好的口碑,往往助你的事業更上一個台階。
- 重視愛情千萬不要因為自己已經到了結婚年齡而草率結婚。想結婚,就要找一個能和你心心相印相輔相攜的伴侶。不要因為放縱和遊戲而戀愛,不要因為戀愛而影響工作和事業,更不要因一樁草率而失敗的婚姻而使人生受阻。感情用事往往會因小失大
- 寫備忘錄寫出你一生要做的事情,把單子放在皮夾裡,經常拿出來看。人生要有目標,要有計劃,要有提醒,要有緊迫感。一個又一個小目標串起來,就成了你一生的大目標。生活富足了,環境改善了,不要忘了皮夾裡那張看似薄薄的單子。
程式設計師的格言
1
每天有24小時。
所謂的「今天之內」,是指到明天早上為止。
2
程式不會照自己所想的跑。只會照所寫的跑。
3
需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。
4
我對軟體設計的方式導出的結論,有兩種方式。
一是把軟體設計得單純到很明顯不會有缺陷,
不然就是把軟體設計得複雜到沒有明顯的缺陷。
- C.A.R.Hoare
5
程式碼不要在開發現場寫! 去客戶那寫!
除錯不要在期限前做! 上線後再做!
6
畫面藍了。
7
先說「沒辦法」的人贏。
8
有意見的話你寫
9
要殺一個程式設計師不需要刀,改三次規格就好
10
首先要先懷疑別人,被懷疑的人或許會把問題解決掉。
(註:通常會「先懷疑自己」)
11
開發沒有終點。只有釋出(release)。
12
無論規格多晚才能確定,結案期限永遠不會變。
這是所謂的「期限守恆定理」。
13
客戶總是覺得水跟追加需求是不用錢的。
14
付錢愈計較的客人愈囉唆。
15
在排定開發行程時,總是視而不見一些連小學生都會的算數。
業務部門總是一堆不知道1+1=2的人。
16
一個人掛了大家都掛了。
17
bug過了一晚可能就變成規格了。
18
好的規格找一個天才不如找三個凡人。
爛的規格找一百個凡人不如找一個天才。
19
客製軟體中30%的價格用在確認規格上。
30%用在修改規格上。
30%用在找bug。
結果初期規格反映在價格上佔的比例只有10%。
20
對客戶來說SE是部下,程式設計師是家畜。
對SE來說客人是錢,對程式設計師來說顧客是看不見的病毒。
除了弄完程式以外,沒有其他驅除的辦法。
21
顧客想受SE喜歡,要自己瞭解到系統開發需要時間與金錢,早點確定規格。
SE想受顧客喜歡,則要讓程式設計師討厭自己。
22
很多SE跟程式設計師都暗自想著有錢有閒的話什麼系統都想自己動手做,
不過都沒這種機會。
23
品質的劣化程度依規格改變的次數與規模而定。
24
業務是認為空想能夠實現的夢想家。
SE則是深信任何障礙都能突破的冒險家。
程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。
25
有才能的程式設計師第一次看到設計細節時,要先理解程式的目的。
接下來要設法讓SE瞭解到以指定的方法、工時並無法完成這個工作。
26
程式是運氣與直覺堆砌而成的奇蹟。
若不具備這兩者,不可能以這樣的工時實現這樣的規格。
修改規格是對奇蹟吐槽的褻瀆行為。
而追加修改則是相信奇蹟還會重現的無謀行動。
27
程式設計師聽了「把自己當作顧客去著想!」而開始思考。
啊,像夢一樣。
28
對於因為興趣而寫程式的人來說,所謂的技術是程式語言能力。
對於因為工作而寫程式的人來說,所謂的技術是邏輯思考能力與人際溝通能力。
程式語言可以看著手冊溝通,客戶不行。
29
程式系統在交貨之前會不斷縮小。
先用元件定義取悅老闆。
再拿經費概算要部長妥協現實的方案。
在運用會議中,課長會嘗識減少自己責任範圍。
在細節會議中,負責人會把範圍縮到自己記得的部分。
30
SE需要持久力,程式設計師需要爆發力。
31
準時離開公司,工作會變多。
32
完美的程式需要完美的時間與金錢。
聽說揮霍著美國的國家預算的NASA,也覺得時間跟錢不夠。
33
詳細設計要在程式碼的註解裡做完。
註解是唯一的自衛手段,至少要讓自己看懂。
34
還有時間看程式碼的話就執行他。
CPU跑得比腦細胞快。至少這時候可以休息。
35
程式的異常該稱為「bug」還是「規格上的限制」是看期限還剩多久決定的。
36
所謂便服日,好像社會上把他叫做假日
(註) 日本有些公司會有所謂便服日(不用穿西裝的日子),通常是星期五,但...
37
地獄持續一段時間後,充滿殺氣的怒吼會變多。
再持續一段時間,說話會變少但牢騷會變多,壟罩在凝重的氣氛裡。
再持續下去,反而會海闊天空,四周洋溢充滿活力的聲音。
這種狀態稱為「Programmer's High」,也是倒下來的人開始出現的時候。
38
遠處的火災一定燒到這裡。
39
禱告,然後跑吧。
40
程式不是用腦記的,要用身體記住。
41
明天能放假的話死了也罷。
42
外面有下雨耶,昨天開始下的嗎?
43
若不能心靜不移,身體會掛。
若不讓自己殘忍,自己會被殺。
44
客戶會說謊,業務會作夢,SE會做白日夢。
程式設計師則惦惦。(愈來愈自言自語)
45
(日文文字遊戲)
SE總是不負責的說「別逞強」,
業務總是無理取鬧不准說「沒辦法」。
46
規格書就像航海圖,客戶則是洋流。洋流陰晴不定,航海圖就變垃圾。
程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。
47
再嘮嘮叨叨下去也是要付錢的。
48
多想個10秒鐘,你可以不說「嗯,這個做得到」。
49
人是無法從別人失敗記取教訓的動物。
砍成本、改規格、加需求、趕上線,從來沒有人從眾多失敗中記取教訓。
50
老手用來提振精神的魔法格言:
「不過比起以前來說算是…」
新人用來提起幹勁的魔法格言:
「把這件工作做完的話…」他們還不知道工作是沒有終點的。
51
所謂交案期限,是指開發現場從公司換到客戶那裡的日子。
52
程式、SE、經理不是職務。是逃不掉的責任。
53
業務是最難搞的客戶。
54
能夠迅速想到解法的程式設計師太多了。
他們能用一分鐘想到方法,用一天去寫程式。
不需要花一小時想到解法,再用一小時去寫程式。
- Jon Bentley
55
漂亮的規格,可以從沒有bug出現看出來。
明明爛的就是設計,為什麼是這樣…
56
上線後的除錯才叫做bug。
57
追加需求確定後交貨期限就無法確定,
交貨期限確定後追加需求就無法確定。
這稱為「追加需求與交貨期限的測不準原理」。
58
除三個錯就會冒出一個錯。
這稱為bug的無窮迴圈。
59
不祥的預感總會實現。
不過程式設計師不會去煩惱不祥的預感,那是SE的工作。
60
要解決地獄的辦法,就是客戶把錢交出來。
61
不懂電腦的操作者是發現bug的天才。而且無法重現。
62
每次開會就更改規格的客戶,
他的操作手冊要等到操作寫好的程式後才能寫出來。
63
搞不懂的時候,Currency(長整數)比Interger(整數)好用。
Variant(字串、數字都能存的萬能變數)又比Currency(長整數)好用。
安全第一。
(VB程式設計師如是說)
64
啊,那是微軟的規格。
65
程式設計師所不滿的規格也一定會讓客戶不滿。
(這是說程式設計師覺得難寫的地方常常是SE溝通有落差)
66
程式設計師需要的技能,
包括交涉、時程管理、業務分析、提案、設計、程式語言、架構、維護、使用。
SE需要的技能則減掉程式語言、架構、維護與使用。
專案經理需要的能力則再減掉業務分析、提案與設計。
業務需要的能力再扣掉時程管理。
67
正因為健康,才能做不健康的事。
68
規、規格、是規格啦。不過有一點跟規格不太一樣啦。
69
那是你說的規格。
70
開發室沒有窗戶,那是因為以前…
71
爛了也是因為規格。
72
SE: 真沒辦法。
PG: 也沒註解。
(碰到不知道是誰寫的程式,大家都束手無策的狀態)
73
為什麼你不能兩三下解決掉他啦。
因為之前兩三下搞定的東西也被你兩三下就否定了。
74
不會動的bug就只是普通的bug。(會動的bug則能視為規格)
75
今天好好清理bug,bug應該死光了吧。
咦?Windows也死了唷。
76
客戶不會去想最壞的情況。要他面對最壞的情況,他會認為是漫天開價。
SE則會顧慮最壞的情況,準備應付最壞的情況。
程式設計師比誰都早預料到最壞的情況,而無視最壞的情況。
77
唯一不產生bug的方法,就是不寫程式。
第二好的方法,就是在時程跟人員確定之後的每次改規格,都重新檢視過整個專案。
78
共同責任是程式設計師的責任。
管理職?那是啥?好吃嗎?我沒吃過耶。
79
如果可以改行的話,想找個準時下班不叫「逃跑」的工作。
80
對職業程式設計師來說,漂亮的程式是單純而自然的邏輯、簡單而基本的指令、豐富的註解,
也就是新手程式設計師也能馬上動手改的程式。
而要寫租這樣的程式,需要單純、簡單、美麗的規格。
但可惜客人總是喜歡搞很複雜。
81
設計者應該是不該要求製作者製作出超過設計以上內容的吧…
82
無論是做的比規格書裡的多,還是只照規格書裡的寫,SE都會找程式設計師的碴。
所以程式設計師只做規格書裡的寫的內容。
83
SE對程式設計師說的「常識」每三小時變一次。
84
自己看規格書。不能跑的是規格。
85
「沒辦法」是要看把一天當多少小時來算。
一天常常指的是3人日,一個月常常是指4.5人月喔。
86
工時要減掉一半的單體測試與一半的系統測試,
而交貨期則要另外加上上線後的兩個月。
87
能拿到錢的規格變更稱為「受理項目」,
拿不到錢的規格變更則稱為「SE的規格確認失誤」。
程式設計師是這麼看的。
88
累了。我想睡了。可以回家嗎。
(累了吧,我也累了。好累喔怎麼了。反正就是規格啦,管他的)
89
試圖降低成本的話,為了配合預算,品質會下降,不過漫天開價做出來的品質也不見得好到哪裡去。
90
REDO到底該怎麼唸一直搞不懂。是利斗嗎、李度嗎、R E D O嗎,難道是 red 零 嗎? 拜託加上注音吧。
(譯註:我比較煩惱 Linux)
91
有人在程式碼註解裡寫日記。
像「今天是雨天…」,「想回家…」之類的。
甚至還有「修改日: 2003/10/10 不能同意你更多」這種註解出現。
說到這個,好像也看過「吃大便」這樣的註解。
92
小學生時第一次看到電腦
國中時第一次學會怎麼用
高中與大學學會程式語言
出社會後才發現自己走錯路
93
「不要讓老闆當業務比較好」
94
說來說去,要去研究根本不知道為什麼會動的東西為什麼不會動了,找拿破崙來也沒搞頭。
------------------------
ex 1
就算程式裡沒bug,編譯器會有bug。
就算編譯器沒bug,OS會有bug。
就算一切都沒bug,客戶會決定什麼是bug。
ex 2
規格與規格書是不同的東西。
ex 3
比期限更重要的是靈感與睡眠。
ex 4
比知識與經驗重要的是手冊與時間。
ex 5
能動就好了,能動的話…
ex 6
過了三天就是別人寫的程式碼。
ex 7 (大搜查線系列)
規格變動不是在會議室裡發生的!是在現場發生的!
ex 8 (大搜查線系列)
異常不是在模擬測試時發生的!是上線後才會發生的!
ex 9
漂亮的設計三天或許就膩了
骯髒的設計三天就習慣了
ex 10
bug與規格是一體兩面
ex 11
電腦裡沒有bug,bug常在人心。
ex 12
無論怎麼檢查,不管怎麼確認,上線前一晚就是睡不著。(RFC968)
ex 13
估價需要1%的經驗與99%的直覺
ex 14
沒有什麼事情比直接讓找不到任何bug的程式直接上線還要可怕的了。
ex 15
・『程式設計師』=能將SE條理不通的說明翻譯成程式碼的高手
・『SE'=與客戶討論改寫規格書、與程式設計師討論後再改寫規格書,程式出貨後還要繼續改寫規格書的人
・『PM'=每天修改自己定下的行程表的人
・『業界老鳥』=臉色蒼白缺乏表情的人
・『外包』=幫不會寫程式的正職員工寫程式的人
・『coding'=複製貼上的工作
・『單體測試』=指開始寫程式
・『除錯』=把程式碼註解掉的工作
・『新同事』=在火燒屁股的專案火上加油的人
・『出貨日』=把只完成一半的系統上線的日子
・『末班電車』=業界平均的下班時間
・『颱風假』=一年一度可以準時下班的業界假日
ex 16
當誰寫的程式碼跑出bug時,那個人大概都不在了(墨菲定理?)
ex 17
最終手段
「重開機」
意外的常常都很有效
ex 18
最強藉口
以前「那是硬體的極限」
現在「那是Windows的規格」
ex 19
「程式碼的可信度,不會比寫的人還可信。