繼上一篇:「談網頁設計專案的量化」之後,這篇要討論的是「時間」控管的問題。
http://blog.macroviz.com/archives/566
只要是專案管理,必然牽涉「時間」的控管。
「時間」可以說是專案中比「人力」和「預算」還重要的可調度資源。
野部以前在網頁設計業界,剛開始接觸「時間」控管的時候,踩入一個誤區。
就是根據自己設計和程式的熟練度,把時程排出來,然後把時程表給同事,認為時間到,網站自己會漂漂亮亮、完完美美的做出來。
可想而知,時間一到東西沒有做出來,我這個 PM 當然是讓老闆和客戶罵到狗血淋頭,東西也收尾收得一塌糊塗。
其實「時間」控管不是只有排定時程而已。
「時間」控管背後的真正涵義,是一個責任。
是身為專案領導者要去「揭發」所有可能會影響專案執行時間的因素,並且一一排除。例如:
- 規劃一個專案,要花多久?
- 新技術的學習,要花多久?
- 新模組的研發,要花多久?
- 設計總監看到成品之後的修正,要花多久?
- 專案經理看到成品之後的修正,要花多久?
- 真正的製作時間,要花多久?
- 收拾爛攤子的時間,要花多久?
- 客戶看到成品之後的修正,又要花多久。
- 客戶有沒有可能中途改規格,萬一 PM 沒有檔下,後續如何處理?
- 分工過細所衍生的各項問題,該如何解決?
- 有沒有其他專案或者準專案要交叉執行?
- 有沒有組織內部的政治因素影響專案執行?
上面林林總總的列了一堆,真正製作的執行時間只是其中一小項而已。
這裡順便探討一下,網頁設計領域中,「全才」和「偏才」對時間的影響性:
- 網頁設計背後都是程式 XHTML、CSS、Javascript、PHP、SQL、Actionscript,加上本身還得具備不少美學和排版知識基礎。這些不是拿個 Adobe Photoshop 或者 Adobe Illustrator 軟體拉一拉,另存 html 就叫做網頁設計了。換句話說,網頁設計師就是互動設計師,必須是「全才」,不能是只會設計或者程式的人。或許在軟體開發領域、視覺設計領域而言,這樣叫做專才,可是對網頁設計或者互動設計領域而言,這樣其實只是「偏才」。如何從偏才發展成一個「博大精深」而非「博而不精」的「全才」需要不少時間。但是主要還是看設計師的個人心態以及個人期許和學習企圖心。
- 網頁設計背後需要有強大的「以使用者為中心的人機介面設計理論」作為支持,去規劃動線。這種看似無形卻有形的東西,規劃起來其實很費工夫,而且要有很經驗的人才有辦法做到接近完美。很多極端實戰經驗派的設計師很不屑學術派的理論基礎。以為理論就是陳腐的。可是,由於互動設計至今在世界上還是新興科系,加上 ADOBE 和微軟在這方面不斷提供軟硬體資助學校做互動設計研究,這些理論可都是這幾年經過不斷驗證而被寫在書本上。有時候看到書上寫一條理論,省下好幾個月功夫,何樂而不讀理論?要「實作能力」兼具「理論修養」也需要不少時間。
- 「偏才分工」花在整合和 debug 的時間,遠比執行製作的時間還久。特別是分工過細問題,五個人不見得製作時間會節省五倍,但是整合每個人的模組加上 debug 的時間,肯定是要五倍的。但是因為客戶永遠的名言:「越快越好」,加上經驗薄弱的 PM 如果沒有把持好,隨意承諾,導致許多急就章的網站。回到工作團隊上,開始等量細部分配工作給一批人。可是,萬一到了簽約結案時間還在 debug,實際上就是送給客戶一個最大的話柄當攻擊目標,之後就是進入時程崩潰期,兵敗如山倒,或任客戶宰割。
其實很多網頁設計團隊至今仍未發現,或對以上問題視而不見,不聞不問,形同麻痺。反正案子來了就趕,先上了再說,客戶罵就修,年復一年、日復一日,每天做專案做的跟行尸走肉似的,加班加免錢。卻不知道:
- 和客戶的時程溝通沒有處理好,
- 低估了網頁設計的技術難度,
- 錯估了新開發模組的時程,
- 團隊中具有的能力和效率不夠好的人員,
- 以及偏才分工、分工過細,
是導致專案時程拖延的五大兇手。
野部針對網頁設計的專案管理觀念其實在在地和許多傳統的管理觀念互相衝突。
例如「人才求全」,這在許多產業是大忌,可是在這個領域,若要當大師,必先為全才。
又亦如我反對「偏才分工」,但我支持「全才分工」。
因為網頁設計的環節環環相扣實在太多了。
業界最常見的分工以任務而言通常可粗略分三個角色:專案領導者、視覺設計師、程式設計師。
當然這三個角色可以是三個人,也可以是一人分飾多角。
但是業界很難看到一個人可以同時分飾視覺設計師和程式設計師的人。
除非是達文西轉世,要不然一個強調視覺和感性,一個強調邏輯與理性,
加上人的思維總是會在自己熟悉的框框內打轉,不願脫離自己習慣的學習模式,也無法調適各項技能在內心裡的衝突,自然難以發展成全才。
再舉個例子,視覺設計師CSS版型沒切好,程式設計師很難套程式。
所以切版的人,如果沒有程式設計的底子,切出來的版只是在給程式設計師找麻煩而已。
但是反過來說,如果程式設計師套了程式,因為不懂維持 HTML 在網頁設計軟體裡面的可編輯性,整個版型就亂到無法重新編輯。
那萬一客戶要求要改地方的時候,請問這個責任是要視覺設計師扛,還是程式設計師扛?
所以說,當設計的時候,就該想到程式之後要怎麼寫,當寫程式的時候,就該回想一下之後設計師要怎麼編輯。
要有這樣的能力者,兩個都必須是全才,然後只是任務分工而已。
而透過幫工作夥伴的互相著想,其實幫自己省了更多的麻煩和時間,何樂而不為?
其實我也知道,是許多人不想多學,所以不能為也,但非真不能也。
但以多媒體設計領域或互動設計領域而言,我想我們從事的不是「少」媒體設計吧。
「人 – 機」介面也不是設計出來就好,中間的「互動 (interaction)」都是需要「程式」去支援「介面」的「動作 (action)」啊。
更遑論探討現在市面上一堆 Web 2.0 和 C2C 網站上面的「人 – 機 – 人」的社交性和互動了。
所以這行想走久一點的話,程式設計的邏輯素養和視覺設計的美學素養兼備,怎樣都是躲不掉的。
另外,很多專案領導者喜歡玩工作日誌。工作日誌本身是「中性」的。但是有些人是拿來「勞民」、「擾民」、以及滿足自己的「管理欲」、或是拿來應付上司的「詢問」用的。這樣就是把一個好端端的工具給「污名化」了。
運用工作日誌作為時間管理工具,有以下數點要注意:
- 工作日誌不是「紀錄」,是「計畫」。時間要預先排定,不是紀錄今天做了什麼的流水帳。精準度要到小時。例如:每日幾時幾分至幾時幾分,誰,「預計」會做那些事情?(就是有點…有套漫畫叫做未來日記的味道)
- 填寫工作日誌不是網頁設計師的責任。請專案領導者親自去請教網頁設計師,將時間問出來,專案領導者自己填上。
- 工作日誌不保證進度會照時執行,一但沒有如期交件,表示一定有問題。這時候專案領導者的責任就是趕快跳出來找問題並且排解,不可以等到內部會議才開始檢討。
- 針對已經執行過的工作,需要制定出所有人可接受的「合理執行單位時間 (H) 」,以便後續新專案作為預先排定工作日誌的起牆磚。
其實專案管理的精髓就是「準時 (on time)」,時事人地物的安排、資源調度和風險控管也不過是圍繞這這兩個字的枝節罷了。
P.S. 其實專案規格表的細節,特別是需要新開發的模組,如果定義的不夠詳實,而跟客戶產生爭議,也是一個導致專案延遲的風險,本文暫不探討。只能說,專案前頭規劃時間要捨得投入,後面才會執行的很順利。