也許，我真的是太早就領會了這個道理了…
很難用簡單的話來說明這個法則，下次回去抄書。
對我來說，每一件事都有讓它很有效率的處理方式，我可以很簡單的抓住這個法則的話，這件事就會很快有了初步規模。如果我的目的是讓人稱讚，做到這裡就收山走人怕是最好的方法了：因為再接下來的工作一定會變成「用80%的力量去做也只能出來20%的成效」了，那時有權評估你的人怕就會來個前恭後倨了。
我做的「IP查詢系統」，在我看來就很像會變成這樣的東西。我花了很大的功夫，從別人的資料庫、這邊網路組的告知資料、GSN通報的「已經違規」之主機而我之前不知道的、臨時問出來的…等來源抓出來的IP做成我自己的資料庫。這實在是一個漫長的艱苦過程；不僅當時因為案子剛起，有很多有的沒有的雜事要做，還有公司內部的壓力，要趕著專案完成。而寫程式其實是一個需要時間和專心的工作（至少對我而言是這樣），特別是有一段時間沒寫，還要選用Perl這種怪怪的語言來寫，當我寫到那個用Perl來Parse Excel檔案的時候實在是有痛不欲生的感覺（現在才發現存成CSV檔案再來處理已經太慢啦…）。但是從我的眼光看起來，公司的專案部分在我這裡的分量只不過是裝機而已，最重要的工作還是在於要把被掃描的風險降到最低。在承辦人已經幫忙提前把IP清單拿來的狀況下，比對是我責無旁貸的責任。偏偏用人工來比對幾乎是不可能的任務（我還是有嘗試過，但是，一來太笨、二來太傷眼，很快我就確定這個是絕不可行的做法）；依據80/20法則，既然這是我主要的工作，而又最花時間（如果用人工比對，我可能好幾天都不用做其他的事情了），我當然要想辦法改善其執行時間了，不是嗎？因此之前PM責備我，說如果我想寫程式就應該轉RD的說法真讓我覺得他不進入狀況；當然他說他有請別人來幫我寫，所以我應該專心的做其他專案裡的東西。不過我覺得這是沒有做過軟體公司PM的人說出來的話。這是一個從頭寫起的程式，所牽涉的規模很大，而在任何程式寫作之前，要緊的是「需求」要先出來。除非你有辦法把這個人派過來，讓我跟他搞清楚需求（我也要開始寫之後一段時間才真正掌握這個Project的做法的），不然就真的是在口頭上佔我便宜而已了。所謂術業有專攻，PM要掌握人力趕上進度是天職，我從來沒有怪他的意思，這裡帶上一筆也不是要打他，而是說明：有的時候要做正確（符合80/20法則）的決定不是一件容易的事情。在這個系統建立好之後，我的手上終於有了可以拿來比對的電子版本，完全消去了人工比對的需要；而且也等於是建立了可以用來自行掃描的清單。原本在我的工作範圍中最難、最花時間的一部分由此變成幾乎是最輕鬆的：清單來，拿程式跑一下，有再通知，沒有呢，愛做什麼做什麼。我再也沒有花什麼工夫來做「比對」這件事，就足以說明，我盡一切力量來處理這件事是對的。事實上，由六月以來再也沒收到任何公文警告就足以讓我說，我沒有白來這個地方了！
我前面說的「做好」，其實是做到了一個段落而已。對我來說，這個系統還有許多需要改進的地方，可惜的是，再下面的任何改進都不可能再有先前80/20的效率比了：不是每一件事都是每個月發生一次（不是MC啦…），也不是每一件事不用電腦做就沒有效率，更重要的是，很多事情都沒有定規，寫成程式反而要考慮很多、變成寫了也不知是否能用上，更有可能下次有機會用的時候自己已經忘記了用法…
我常想，這也許是維運期的問題：所有的系統如果已經上線，那不管做什麼，都會是80/20中的那20，否則怎麼能上線？是以這變成了一個無解的問題，因為已經不存在這種槓桿因素，所以我沒有辦法提起勁去做，那我剩下的駐點時間豈不只有鬼混？唉，這真是一個傷腦筋的問題…如果所有的東西都運作正常的話，我其實還真的是鬼混就好了。雖然有所謂的通報，但是這是一個塞東西；我只有一句話：如果是我去配合發通報的單位的話，遲早會累死；所以如果承辦人不拿這個來對付我，我當然避重就輕囉…
沒有留言:
張貼留言