天上下著好綿密的細雪。

仔細一看是雪珠、不是雪花。

下午一點，頂著一頭亂髮、撐著傘，走去印第安那大學主圖書館的路上，學校 Jordan Avenue 鐘聲響起。

是 Let It Snow 的旋律： Let It Snow! Let It Snow! Let It Snow!

P.S. 圖片不是我拍的，是從學校網站上引用的。

德光中學傅馨霈 多益滿分
http://mag.udn.com/mag/campus/storypage.jsp?f_ART_ID=226963

小時了了 大未必佳／我高中以上英文 遠遜南韓
http://www.libertytimes.com.tw/2009/new/dec/18/today-life11.htm

野部看到傅馨霈的報導，第一個直覺就是佩服這位同學。

而且其實不只傅馨霈，野部朋友中的英語考試成績強者，
不論是台灣人、中國人或美國人，都下過長期、且大量的閱讀功夫。
若是台灣人、中國人，則是針對大量的單字記憶，下過很多的功夫。

這些可能可以印證了野部的假設：背大量單字和大量閱讀是把語言考試考好的途徑。

當然每次這種考試成績出來，就會有另外一派聲音批判說：成績好，不見得口語能溝通。
這野部認同，並且也有同樣的批判。

當然用有特定目的性的語言考試來評判全民的英語能力確實不太公平。
但是以總體的眼光來看，考好語言考試確實是提升國際競爭力的一個快速途徑，
這點真的沒有什麼好懷疑的。

這裡另外引述了上面第二個連結的一段話：「王舒葳指出，台灣國、高中英語教學偏重單字背誦、文法，機械式知識記憶容易讓學生失去興趣，這也是現階段大學生英語表現不如預期的主因。」

個人認為這位王舒葳經理的說法，很容易引起誤會。 (也可能是記者斷章取義。)

這段話，沒有點出背單字、背文法、大量閱讀本來就是學好英語不可避免的途徑。
也沒有點出問題出在機械式學習，不在於記憶。

因為真正的問題是，英語老師要有責任把這些看似枯燥的記憶過程，變有趣；
而學習英語的學生，也要接受記憶過程就是學習最重要的初階過程，
不能因為預設立場覺得記憶過程無趣，而因噎廢食，避而不學。

要是什麼知識都要有趣才教、才學，那只能說，不論師生，都是任性或懶惰吧。

所以真的就是多背單字、多閱讀，這麼簡單的方法而已。

※2009年12月23日追加文章

英文不好 老師發怒了
http://news.chinatimes.com/2007Cti/2007Cti-News/2007Cti-News-Content/0,4521,11051401+112009122400435,00.html

徐薇不愧是有豐富教學經驗的老師，一點就把問題給點破了。
這篇報導值得一讀。

今天終於再次透過新東方背單詞 5 ，將紅寶書再看一輪，已經是第四輪了，正確率已經達到 91.40 %，感覺應該是到了某個瓶頸，要繼續找其他突破口了。

紅寶書一輪是 8033 字，等級大概就是 Time Magazine 的程度吧。

從第三輪開始，野部只要四天就能看完一輪紅寶書了。

接下來打算一週內看胡敏講故事，另一週把藍寶書看完。

然後老方11張加 CAT和之前 Jeniffer 送我的老方講義也是花一週看一看。

剩下就是把 Big Book 做一做，作文練一練這樣。

差不多農曆年前後，就該上陣了。

之後再順勢連托福一並拿下。

———- 我是分隔線 ———-

今天跟 Jamie, Claire, Doris 開會檢討一下 CSS 部分。

各位做的很棒，終於做出8種瀏覽器 + 2種編輯器 99% 相容的 CSS + DIV 排版了。

可見有志者事竟成也。

看來，我之前針對各種版本和各家廠牌瀏覽器的深入研究是沒有白費了，Jamie 也可以針對團隊內部開班授徒了。

而且我終於發現有人比我心思還細膩了…。

不過，團隊溝通效率上，問題解決效率上，以及時程長短的安排上，還是得再注意。

所以這次我給妳們打90分。

可是，接下來的 MySQL + PHP 才是真正的挑戰。(之後能讓我打100分嗎？)

換給 Claire 當小頭目，Jamie 先休息一下。

別忘了妳們跟我定的生死狀可是還有效的喔，別鬆懈了。

Kemie 也辛苦了，默默地一直在執行另外一個專案，還得一邊準備好幾個補習班的講課，講師生涯，真的也是有甘有苦。

明天我也還得跟 Doodle 討論一下學習的進度，看看有沒有什麼問題。

希望 Doodle 的進度能夠盡快的趕上大家，然後我才能把所有人的能力再做一次整合。

之後，嘿嘿，就是我說的最刺激的，開版大賽要來啦，哈哈。

———- 我是分隔線 ———-

昨天美國早上剛好 Mars 打電話來，討論日文學習的進度，討論到一半，野部剛好要出門買菜，真是不好意思。

所以我把要準備的東西條列如下：

1. 單字是肉  (勤勞背單字，至少要一萬字彙量到兩萬字彙量。)
2. 文法是骨  (文法書在精不再多，我最推薦的兩本就是林錦川和蔡茂豐老師的兩本文法。)
3. 閱讀是皮  (多看朝日新聞，當生字涵蓋量降低到 20% 甚至 10%，可以考慮去考一級了。)
4. 聽力是靈魂 (除了看 NHK 之外，上網路找純廣播無畫面的多聽，我記得 Windows Media Player 的 Radio 有一堆。 http://www.i-radio.fm/ 這個可以參考，不過歌曲放很多就是了。)
5. 口說是思想 (口說嘛，就是想盡辦法去糾纏日本人就是了…)

進度方式如下，兩線平行：

1. 單字 -> 文法 -> 閱讀 -> 口說
2. 聽力 ————————>

按此方法每天若能理想安排四小時讀日文，全年無休風雨無阻，最快半年，最慢一年，定有大成。

———- 我是分隔線 ———-

各位加油，看到你們都這麼拼命，我就覺得人生目標特別有希望。

繼上一篇：「談網頁設計專案的量化」之後，這篇要討論的是「時間」控管的問題。
http://blog.macroviz.com/archives/566

只要是專案管理，必然牽涉「時間」的控管。
「時間」可以說是專案中比「人力」和「預算」還重要的可調度資源。

野部以前在網頁設計業界，剛開始接觸「時間」控管的時候，踩入一個誤區。
就是根據自己設計和程式的熟練度，把時程排出來，然後把時程表給同事，認為時間到，網站自己會漂漂亮亮、完完美美的做出來。
可想而知，時間一到東西沒有做出來，我這個 PM 當然是讓老闆和客戶罵到狗血淋頭，東西也收尾收得一塌糊塗。

其實「時間」控管不是只有排定時程而已。
「時間」控管背後的真正涵義，是一個責任。
是身為專案領導者要去「揭發」所有可能會影響專案執行時間的因素，並且一一排除。例如：

1. 規劃一個專案，要花多久？
2. 新技術的學習，要花多久？
3. 新模組的研發，要花多久？
4. 設計總監看到成品之後的修正，要花多久？
5. 專案經理看到成品之後的修正，要花多久？
6. 真正的製作時間，要花多久？
7. 收拾爛攤子的時間，要花多久？
8. 客戶看到成品之後的修正，又要花多久。
9. 客戶有沒有可能中途改規格，萬一 PM 沒有檔下，後續如何處理？
10. 分工過細所衍生的各項問題，該如何解決？
11. 有沒有其他專案或者準專案要交叉執行？
12. 有沒有組織內部的政治因素影響專案執行？

上面林林總總的列了一堆，真正製作的執行時間只是其中一小項而已。

這裡順便探討一下，網頁設計領域中，「全才」和「偏才」對時間的影響性：

1. 網頁設計背後都是程式 XHTML、CSS、Javascript、PHP、SQL、Actionscript，加上本身還得具備不少美學和排版知識基礎。這些不是拿個 Adobe Photoshop 或者 Adobe Illustrator 軟體拉一拉，另存 html 就叫做網頁設計了。換句話說，網頁設計師就是互動設計師，必須是「全才」，不能是只會設計或者程式的人。或許在軟體開發領域、視覺設計領域而言，這樣叫做專才，可是對網頁設計或者互動設計領域而言，這樣其實只是「偏才」。如何從偏才發展成一個「博大精深」而非「博而不精」的「全才」需要不少時間。但是主要還是看設計師的個人心態以及個人期許和學習企圖心。
2. 網頁設計背後需要有強大的「以使用者為中心的人機介面設計理論」作為支持，去規劃動線。這種看似無形卻有形的東西，規劃起來其實很費工夫，而且要有很經驗的人才有辦法做到接近完美。很多極端實戰經驗派的設計師很不屑學術派的理論基礎。以為理論就是陳腐的。可是，由於互動設計至今在世界上還是新興科系，加上 ADOBE 和微軟在這方面不斷提供軟硬體資助學校做互動設計研究，這些理論可都是這幾年經過不斷驗證而被寫在書本上。有時候看到書上寫一條理論，省下好幾個月功夫，何樂而不讀理論？要「實作能力」兼具「理論修養」也需要不少時間。
3. 「偏才分工」花在整合和 debug 的時間，遠比執行製作的時間還久。特別是分工過細問題，五個人不見得製作時間會節省五倍，但是整合每個人的模組加上 debug 的時間，肯定是要五倍的。但是因為客戶永遠的名言：「越快越好」，加上經驗薄弱的 PM 如果沒有把持好，隨意承諾，導致許多急就章的網站。回到工作團隊上，開始等量細部分配工作給一批人。可是，萬一到了簽約結案時間還在 debug，實際上就是送給客戶一個最大的話柄當攻擊目標，之後就是進入時程崩潰期，兵敗如山倒，或任客戶宰割。

其實很多網頁設計團隊至今仍未發現，或對以上問題視而不見，不聞不問，形同麻痺。反正案子來了就趕，先上了再說，客戶罵就修，年復一年、日復一日，每天做專案做的跟行尸走肉似的，加班加免錢。卻不知道：

1. 和客戶的時程溝通沒有處理好，
2. 低估了網頁設計的技術難度，
3. 錯估了新開發模組的時程，
4. 團隊中具有的能力和效率不夠好的人員，
5. 以及偏才分工、分工過細，

是導致專案時程拖延的五大兇手。

野部針對網頁設計的專案管理觀念其實在在地和許多傳統的管理觀念互相衝突。
例如「人才求全」，這在許多產業是大忌，可是在這個領域，若要當大師，必先為全才。
又亦如我反對「偏才分工」，但我支持「全才分工」。
因為網頁設計的環節環環相扣實在太多了。

業界最常見的分工以任務而言通常可粗略分三個角色：專案領導者、視覺設計師、程式設計師。
當然這三個角色可以是三個人，也可以是一人分飾多角。
但是業界很難看到一個人可以同時分飾視覺設計師和程式設計師的人。
除非是達文西轉世，要不然一個強調視覺和感性，一個強調邏輯與理性，
加上人的思維總是會在自己熟悉的框框內打轉，不願脫離自己習慣的學習模式，也無法調適各項技能在內心裡的衝突，自然難以發展成全才。

再舉個例子，視覺設計師CSS版型沒切好，程式設計師很難套程式。
所以切版的人，如果沒有程式設計的底子，切出來的版只是在給程式設計師找麻煩而已。
但是反過來說，如果程式設計師套了程式，因為不懂維持 HTML 在網頁設計軟體裡面的可編輯性，整個版型就亂到無法重新編輯。
那萬一客戶要求要改地方的時候，請問這個責任是要視覺設計師扛，還是程式設計師扛？

所以說，當設計的時候，就該想到程式之後要怎麼寫，當寫程式的時候，就該回想一下之後設計師要怎麼編輯。
要有這樣的能力者，兩個都必須是全才，然後只是任務分工而已。
而透過幫工作夥伴的互相著想，其實幫自己省了更多的麻煩和時間，何樂而不為？

其實我也知道，是許多人不想多學，所以不能為也，但非真不能也。
但以多媒體設計領域或互動設計領域而言，我想我們從事的不是「少」媒體設計吧。
「人 – 機」介面也不是設計出來就好，中間的「互動 (interaction)」都是需要「程式」去支援「介面」的「動作 (action)」啊。
更遑論探討現在市面上一堆 Web 2.0 和 C2C 網站上面的「人 – 機 – 人」的社交性和互動了。
所以這行想走久一點的話，程式設計的邏輯素養和視覺設計的美學素養兼備，怎樣都是躲不掉的。

另外，很多專案領導者喜歡玩工作日誌。工作日誌本身是「中性」的。但是有些人是拿來「勞民」、「擾民」、以及滿足自己的「管理欲」、或是拿來應付上司的「詢問」用的。這樣就是把一個好端端的工具給「污名化」了。

運用工作日誌作為時間管理工具，有以下數點要注意：

1. 工作日誌不是「紀錄」，是「計畫」。時間要預先排定，不是紀錄今天做了什麼的流水帳。精準度要到小時。例如：每日幾時幾分至幾時幾分，誰，「預計」會做那些事情？(就是有點…有套漫畫叫做未來日記的味道)
2. 填寫工作日誌不是網頁設計師的責任。請專案領導者親自去請教網頁設計師，將時間問出來，專案領導者自己填上。
3. 工作日誌不保證進度會照時執行，一但沒有如期交件，表示一定有問題。這時候專案領導者的責任就是趕快跳出來找問題並且排解，不可以等到內部會議才開始檢討。
4. 針對已經執行過的工作，需要制定出所有人可接受的「合理執行單位時間 (H) 」，以便後續新專案作為預先排定工作日誌的起牆磚。

其實專案管理的精髓就是「準時 (on time)」，時事人地物的安排、資源調度和風險控管也不過是圍繞這這兩個字的枝節罷了。

P.S. 其實專案規格表的細節，特別是需要新開發的模組，如果定義的不夠詳實，而跟客戶產生爭議，也是一個導致專案延遲的風險，本文暫不探討。只能說，專案前頭規劃時間要捨得投入，後面才會執行的很順利。