2008年7月25日 星期五

重要的事情先做

從事IT行業多年,我一直有一個深刻的感覺,資訊科技日新月異,要能夠掌握足夠的資訊技術,並且讓自己能夠在業界不至於被淹沒甚至能夠在眾多的強者中異軍突起,所需要花費的精神和時間有時候已經讓人喘不過氣。不管是哪一個領域,MIS、SI、Vender site、User Site、Consultant、Trainer我大多都有扮演過這些角色、或多或少也都能夠體會不同角色中的辛苦。

不過也可能是因為IT相關領域(特別是Developer)所需要涉獵的知識一直在變和增加,這些部分已經讓人耗費心力,使得IT人員在一些基礎的管理技能上,顯得有些缺乏。說真的,我認識的IT人員很少不是聰明人(意思就是大多數都是聰明人...我真怕現在很多人看不懂這樣的中文寫法...),我覺得大家都很Smart,但是往往由於缺少了一些基本的管理知識,在專案中常常變成無頭蒼蠅,忙碌,卻不一定能夠產生預期的效益。

關於這部分,我最近和一個同事提起,對於IT人員,不管是系統開發人員,或是MIS、你要妥善規劃你的時間,有一個很關鍵的技巧,就是把重要的事情放在前面,重要的事情先做,一直是時間管理當中很重要的一個部分。

不知道你有沒有讀過一本很不錯的管理書,作者把事情分為四種,急迫但不重要的(P2)、重要但不急迫的(P3)、不急迫也不重要的(P4),即重要又急迫的(P1)。


我記得我以前曾經提過這個觀念,這個觀念對我有非常大的幫助,我一直想找時間與大家分享,回頭想想這四種事情,你會先做哪一種? 你在哪一類的事情上你花了比較多的時間???

一般人P1一定會先做,這個毫無爭議,典型這類的工作是:家裡失火、急病住院…不過這些事情都不常發生,更具體一點的工作像是明天要交付驗收的專案、下午會議要用的報表…等,都屬於P1的範疇。

P1類型的工作往往不會佔用你絕大部分的時間,但是如果你發現自己手上每天的工作全都是P1,這表示你每天都在救火(我就看過這樣的MIS部門和專案公司,我可以肯定的告訴你,你絕對在這家公司待不久,搞不好這家公司或這個部門自己也撐不了多久,碰到這種公司,我會建議你趕快準備104…),如果手上的工作大部分都是P1,不用懷疑,你(或你們)的時間管理絕對有問題。

P1類型的工作,我認為在正常的公司當中一週不應該超過一、兩件,每件應該也都要能夠在三小時內解決。(否則他就不是P1,而是P3轉換成的P1,我待會解釋)

先談P4,你可能以為一般人應該不會把時間花在P4這類不重要又不急迫的事情上,但是你錯了,其實往往在工作上不是這樣,P4類型的時間花費多半都有一個特質,就是有趣、但沒意義

你一定會發現身邊很多人在工作時一直邊打MSN、跟同事作無建設性的閒聊,陪客戶聊天(好像很重要,但是其實並不是只陪客戶聊天就可以爭取到訂單)、或是作些可有可無沒有建設性的外交,打一些沒意義的電話(純粹是因為不想要把VS2005打開進行專案的Debug,所以先找一些其他事情做做,你問他說為什麼不快點Debug,他會跟你說要…醞釀Debug的心情和氣氛),和同事分享小道消息…這是P4的典型的例子。

我要說,如果你花了大量的時間在P4類的事情上,則肯定會慢慢邁向失敗。和客戶溝通有兩種,有建設性的我不會放在P4, 但是無效的溝通和閒聊就變成P4了。

這邊有一個迷思,休閒活動(例如打電動)算不算P4? 如果打完電動之後,讓你得到壓力的紓解、心情變得更輕鬆、腦袋開始更靈活,那就不是P4,因為它有意義,但是如果你熬夜打電動,或是打的廢寢忘食,結果導致該交付的工作無法交付,那就是P4了。

我建議大伙想想,你一天的時間當中,有多少時間花費在P4項目上。如果說過多的P1是讓你感到心力交瘁、逐漸疲乏的關鍵,那P4類型的時間花費絕對是讓人生邁向失敗的指標。

接著,我們來看一個重點,P3,重要,但不急迫的事情。
很多時候,所謂重要的事情,往往不會花你太多的時間(例如你的weekly report,還有應該要在準時交出來的管理計劃,甚至個人的生涯規劃、UAT時間的安排、test script的撰寫…),很多重要的工作一開始絕對都不急迫,這也是我說P1工作其實不應該多的原因,但是請注意,如果你不把重要的事情P3放在前面先做,這些事情自動就會慢慢的變成P1,然後你會發現自己每天的工作都在救火,都在趕進度,都被大家追債,常常會有人質疑你的工作能力和效率,這些都是P3沒有先做的後果。不要懷疑,在資訊界中,我看過其實很多人是這樣的(包括我自己偶而也都會這樣)。

請謹記,重要的信件先回,重要的工作先做,多留一點時間給重要的工作。重要的工作特別是包含了一些計劃、規畫、預防性的工作,很多主管也往往都略過這些工作,而等事情發生了(變成P1,例如專案Delay、客戶抱怨、老闆抓狂…)才跳進去動手處哩,你有沒有發現,這些工作一開始往往都不急迫,但是是很重要(這就是典型的P3),如果你不先做,它們自己就會慢慢自動升級成P1,會有人(上級單位、或是客戶、或是你自己)逼著你立刻要完成,但是往往到了P1的時候,會發現已經火燒眉頭,而且沒有時間提供一個好品質的成果,你會覺得能趕出來已經很不容易了,但是到這時也已經同時給了別人不好的感覺,由於時間有限,所以只好趕出來,但是你也知道,趕出來的品質大概只有60分上下,交付了,卻讓人不滿意,接著大家會開始對你(或你的公司)的工作品質打問號。

然而,其實這些工作一開始都是P3,也就是它們本來都不急,你也有時間可以慢慢作,卻因為放太久,使得它變成P1…導致這種結果。

順帶談一個觀念,個人的健康檢查和保險,是典型的P3,如果你放著不做,有一天發現生病了,非得去住院就變成P1,關於這點,我最近感觸很多,提醒大家注意自己的身體。

所以請記得,重要的事情先做

我們會放著P3不做,往往是因為我們不喜歡這些工作(很像學生的暑假作業,總是到最後一天才寫),還有一個可能的原因是我們不知道該怎麼作,當對工作有疑惑不知道該怎麼作的時候,請主動尋求解答(尋求解答這件事其實也是P3-雖然不急但是卻很重要),很多人都怕跟老闆溝通,可能是怕讓老闆知道自己原來不會這些,或是不能理解老闆的心意,或是怕節外生枝,所以都放在心裡不講,不與老闆溝通的結果是只能揣摩上意,導致工作失準或是只能擱著,放到不能再放的時候才和老闆溝通,往往這時候已經太晚了…

Anyway, 如果你真的開始注意自己每一天的工作習慣,然後把這個觀念用在每一件工作上,分析你的每一個工作到底是P1-P4中的哪一種,並且去改變他,突破這個循環,你一定會發現這個觀念可以有效的提高你的工作效率和成果…

希望對你有幫助。

5 則留言:

匿名 提到...

先不提一堆新技術,
奚江華先生,三年前寫的帖子 :
當 DataGrid 遇上一百萬筆資料,
http://blog.sina.com.tw/dotnet/article.php?pbgid=4907&entryid=3921

小弟我認為這種撈資料的「分頁」觀念真的很重要,

到目前為止,
台灣還有滿坑滿谷的 asp.net 網站,
GridView,還是用 SqlDataSource,每次 user 按頁碼換頁時,或按 title 排序時,
都是「整個資料表」全部重撈,
若有一百萬筆資料,就一百萬筆全部重撈,

或已用了 ObjectDataSource 控件,
但一堆工程師,都不知有此嚴重後果,
尤其重要的是,在系統開發期間都感覺不出來,
導致系統上線幾個月後、資料量變多時
才發現分頁效能奇差無比,
然後一堆台灣客戶,每個人都說 asp.net 效能奇差,
於是乎,台灣一堆人,都不再愛用 asp.net。


但,目前台灣幾乎沒什麼繁中書、blog 文有講到這種現象,
只有 msdn 的黃忠成先生,幾個月前在
msdn 繁中官網,有寫一篇有範例的「GridView 進階應用」文,
但他處理「分頁」,還只是用 sql server 2005 的 Row_Number() 函數,綁死在單一牌子資料庫的專屬解法。

現在台灣滿坑滿谷、效能奇差的 GridView 分頁網站,
其他什麼 .net 3.x, .net 4.0 新技術都免談了。
一堆客戶都已直覺認定,asp.net 網站,
當資料量多時,效能奇差。

然後一堆客戶、業主、工程師,還以為 asp.net 效能很差,
sql server 資料庫 效能很差,
只是開發速度快而已。

反觀對岸的 博客園 blog 社群,
已有滿坑滿谷這方面的「分頁」技術文件,
自己寫 stored procedure,或用 .net class 處理分頁,
且不限於 sql server 2005 的專屬解決方案。

這方面台灣的出版、台灣微軟官方真的很失敗,
沒把這點超重要的一點,大力宣導。

like this:
http://www.codeproject.com/KB/aspnet/PagingLarge.aspx



到目前為止,
出的書,

除了黃忠成先生,有稍微提到外,
似乎還沒任何作家,
介紹到此超重要觀念。

希望能有人站出來,
幫忙告知此一「分頁」問題的嚴重性。

David 提到...

關於這個問題,我的看法是這樣,在ASP.NET開發的領域當中,有相當多的中高階領域尚未被觸及和討論到,確實是相當可惜的,除了效能之外,安全性也是一個被忽略的問題,例如我幾乎沒有看到繁中的ASP.NET書籍討論到ASP.NET中使用到Windows驗證時的安全性問題,NTLM和kerberos與ASP.NET驗證的關係,或是分散式應用程式架構下ASP.NET所扮演的角色,又或是MemberShipProvider的機制,這些主題跟ObjectDataSource一樣,很容易在作者出版書籍的時候直接被忽略了,然而這是為什麼呢?

其實,也不是沒有書籍討論,然而看起來繁中書籍的市場餵納量似乎並不足以支撐中高階書籍的銷售,很多作者嘗試過,但是出來的狀況卻差強人意,久而久之作者很容易就慢慢失去原先的動力了。資訊書籍的作者寫出一本書的時間可能要比做一個專案更長(還不包括內容的醞釀與整理),然而獲利可能是專案的30%不到,我想這可能是大部分讀者無法理解的。

坦白說,這些主題確實很重要,但是依照目前的現況,可能在BLOG或是Seminar上呈現比較容易,在繁中書籍上呈現恐怕比較困難,不過簡中書籍和BLOG上確實資料相對較多,我自己也有開發團隊在深圳,對於兩岸之間軟件設計的發展演進,我也挺有感觸(如果以後有時間,或許再寫篇分享),這些問題我也曾與其他作者以及出版社編輯都有聊到,確實,我們都有責任,不過我想大概也只能量力而為了,台灣的出版市場很蓬勃,但是獲利可能比大家想的要相差很多,儘管我們對台灣有很大的期待,也希望能夠看到軟體產業在這邊能夠有更好的發展,只是市場的支撐力道還是相當的重要。

不過,隨著BLOG和internet的普遍,其實我發現很多業界軟體從業人員的BLOG內容也寫的相當不錯,我想這是一個很好的開始,畢竟只靠幾位作者,遠不及大家一起努力去耕耘,這是一個百花齊放的年代,我相信有好的內容的BLOG一定會爭取到大家的支持,我真的很建議developer,不妨從自己的BLOG開始,如果有好的心得,隨時把它整理出來,和大家一起分享...

當然,我自己也會和大伙一起努力...多抽一點時間寫寫文章...^^

WizardWu 提到...

感謝您的回應。

黃忠成老師,最近一年出的兩本「極意之道」,有稍微介紹到這個「分頁」的大問題,
但只是用 sql server 2005 的 ROW_NUMBER() 特解,這兩本書,和他更久以前出的一本 ASP.NET 1.1 元件設計,也有很多不錯的主題,可惜在台灣都賣得不好。

很可怕的是,該「分頁」主題,在台灣任何繁中 ASP.NET 的書都沒再有人提到,造成了台灣現在線上,滿坑滿谷效能奇差、不斷大量「全撈又重撈資料表」的 GridView。

匿名 提到...

Hi:
我寫了一個動態產生xaml的.cs,這隻.cs放在主要路徑(/)下沒有問題,但我如果開了一個controls的目錄將.cs放入然後重拉就會出現找不到.xaml了,看了source發現他將原來的XamlUrl="#..."改成了"controls/#..."應該是這個原因造成($create(Sys.Preview.UI.Xaml.Control, {"xamlSource":"../Controls/#InLineXaml_ctl00.....)
請問要如何更改才能避免這個問題,謝謝!

binboy 提到...

寫得很棒!能夠照這篇文章執行的人是少數,但還是要往這目標靠近