從凌開始

無意間在廣播中聽到 104 人力銀行董事長 楊基寬 的一席話，令我體會很深 他先說了這樣的一個故事： 他在英國時，一個十字路口，一個行動不便的乞丐在綠燈時穿越馬路 但轉換到紅燈時，他仍在馬路中 這時所有的車子卻仍然在等待他慢慢的走過 不催、不趕，就算有人真的趕時間，他也會下車來幫那個乞丐 這個場景如果換到台灣，我相信是一堆人在乞丐週圍穿過來穿過去 這代表什麼？我不能很肯定，但我確定的是我佩服英國人的風度 之後他還說了一些事情，我不太記得，但我記得他用強調的語氣說了這樣的一句話： 「把看不慣的事情當成自己的責任感」 我想到我也很多看不慣的事情，但所有的人都只會叫我當做看不到 我終於懂了，我那種不舒服的感覺是什麼 因為我把看不慣的事情當成自己的責任感 雖然我的能力有限，能做的不多 媽媽也說將來跟著我的妻子可能會很辛苦 因為我是這樣的一個人 但我不覺得這是錯的 很開心，能聽到楊董事長的一席話 每個能成大事的人，應該都有凡於別人之處

時常聽到有些人這麼說，這問題「應該」很簡單 當聽到應該就代表有那些一些不確定性 但這樣說其實是很不負責任的 記得有天晚上，有個同事隔天要出差出廠商那裝機 需要帶的資料有上百GB，他跟主管要了顆硬 主管拿了顆硬碟給他，說「應該」可以用 接著就走了 很不幸的，這顆「應該」可以用的硬碟不能用 於是厚著臉皮打了電話跟主管求救 才又找到了顆可以用的硬碟 回家時已經超過晚上十點 雖然我經常可以很快的解決問題 但對於我不確定的問題我不說簡單 因為那可能真的不簡單 有段時間我兼任PM的工作 要分配工作給下面的人 我會很細心的仔細看完工作的項目 甚至加上我覺得重要的關鍵提醒，這一個重要提醒 可能就是讓問題由「應該」很簡單變成「真的」很簡單 但公司卻認為我這麼做是多餘的 在問題解決之前不說簡單 在問題解決之後不說困難

從國中開始寫程式時，程式對我而言，就是達成目的的指令，在當時並沒有所謂時程和效率的考慮，沒有受過正統程式設計訓練的我，只有零星的上過一些相關課程，和絕大多數的自修，但一些專有名詞，像復雜度、NP HARD之類的，我也還蓋得出來。 在軟體討論區甚至是open source 討論區，出現了 IDE 工程師這樣一個名詞，原本這個詞並不是什麼不好的意思，但在那些討論區裡指的卻是一群只會使用圖形化開發工具(泛指微軟系列為主)的工程師，講求易上手，快速開發，但結果卻是常常忽略了一些細節，造成漏洞、效率等的問題。 經常遇到的是開發時使用的小型案例一切正常，但真正上線時，完全攤換，這不全是工程師的錯，如果規劃時周全一點，如果讓比較有經驗的來領導專案進行，如果肯針對不良的程式碼痛下決心大改寫，都可能讓這些問題不要發生。 第一場戰役：jQuery，從開始引入jQuery開始，本來這應該是個美好的開始，但新人進來就開始學jQuery，基本Dom操作的也jQuery，諸如 jQuery("#id") 這樣的式子完全被濫用，基本的 document.getElementById 反而都不會用，有些效能卻是在這些地方消失掉的。 第二場戰役：linq，雖然 linq 讓很多的程式開發更有彈性，特別是 linq to sql 讓工程師幾乎可以不了解 sql 句也能完成資料庫的存取，但如果沒有優良的 DBA 在幫忙輔助管理資料庫，就算 linq 用的再熟再好，也解決不了因為資料庫設計不良造成的效能低落問題。 打了越多場硬戰後，我也了解了更多，快速開發與效率其實也是有辦法兼顧的，快速開發靠的是工具，但效率就必須靠著工程師的素養、經驗、細心。

來源：自由電子報 原文連結：http://www.libertytimes.com.tw/2008/new/jun/9/today-work1.htm 去年獲選為「世界領導大師（Guru of World Leadership）」排行全球排名第一的約翰麥斯威爾（John C. Maxwell），在其即將出版的新書《領導力的黃金法則》裡指出，領導者往往會認為別人離職跟我無關，但事實上領導者通常就是肇因。 資料顯示，高達65%的人是因為他們的主管而離職。我們大可以說員工是離開工作或公司，但事實上他們通常是開除上司。「公司」沒有錯待員工，是人錯待員工；有時同事惹出問題，也會促使他人求去，但員工的頂頭上司往往才是孤立他們的人。 大部分領導者都能讓員工在首次見面時留下良好印象，而且人們對新工作總抱持樂觀態度，希望終能成功。但時間一久，領導者的真面目會露出來，無法維持刻意營造的形象。如果老闆是個蠢蛋，員工遲早會知道。所以，員工會開除什麼樣的上司呢？通常分為以下四類： 類型1／離開貶低他們的人 所有人都喜歡聽好話、都喜歡受人欣賞，然而，許多人在工作上沒有受到正面的回饋與欣賞，甚至常常是相反的，他們覺得被貶低。他們的老闆高高在上，輕視甚至蔑視他們。對任何一種人際關係來說，這種作法都代表災難，即使是在專業的工作領域。 領 導者通常善於在機會或交易中發現價值，對人也需要有類似的心態。在為你工作的人身上找到價值，讚美他們所做的貢獻。他們可能藉由生產貨品或提供服務，貢獻 價值給顧客；也可能透過增加總產值，貢獻價值給公司；還可能藉著增強自己的能力，在工作上發揮到極致，貢獻價值給同事。找一些事表達你對他們的賞識，他們 會感念而為你工作。 類型2／離開不值得信任的人 你是否跟你不信任的人共事過？那是可怕的經驗。沒有人喜歡跟靠不住的夥伴工作。不幸的是，曼徹斯特顧問公司（Manchester Consulting）完成的一項調查顯示，職場信任程度正逐漸下滑，他們也發現，領導者最快在工作上失去部屬信任的五個毛病是： □ 言行不一 □ 將個人利益置於團體利益之上 □ 隱瞞資訊 □ 說謊或說話避重就輕 □ 心胸狹窄 相反地，調查發現領導者建立信任的五種最佳方式就是： □ 保持清廉正直 □ 公開溝通願景與價值觀 □ 尊敬員工如同夥伴 □ 將共同目標置於個人利益之上 □ 置個人風險於一旁，做正確的事 領導者想...

關於蕭規曹隨的故事，可以參考這裡： http://www.epochtimes.com/b5/5/12/4/n1142359.htm 蕭規曹隨，後來被解釋為無為而治 原來的規法，也許不是十分完美 但如果夠用，就不要再做大改變 縱使新的規法很好，真的有用 但在人民疲累時，還是不適合拿出來用的 讓我想到公司最近一些新的策略 在有人離開，公司結構改變時 許多人都出現疲態時 卻又訂立更多新的規矩 造成的結果還不知道 但歷史上的經驗告訴我們 這是有危險的

這幾天想了一些，有一些想法，但也不知道正不正確，先自己記錄下來： 1. 高機動性需要高閒置人力： 從我的了解，有高機動性的工作，像服務業都會有相對高的閒置人力，我以前在便利商店打工時，店長都會交代，就算要打掃什麼的，也要有一個人留守櫃台附近(就是不能太忙)，以應付顧客上門時，能有最高的回應速度。 但工程師似乎人力卡的很緊，如果又要應付一堆必須馬上處理的事，沒有閒置人力，如何做到呢？ 2. 插單工作需要加倍工時： 原本排好的工作，突然有別的工作插進來，要求優先處理，這種情形一方面工程師必須先將目前的工作做個適度的收尾，才能處理這個臨時的工作，而管理專案的人也必須調整進度，所以當有這類插單的工作時，應該是算成加倍工時(人力)。 3. 測試工作重要但亦需要同等工時： 在微軟的經驗中建議，測試人員應和開發人員以 1:1 的配置，在人月神話一書中，也提到完成完整測試的系統，所需要的人月是原來系統的三倍，要完成完整的測試工作，必定要投入相當的人力，但在開發人員兼自己的測試工作員的情況下，工時應該如何算呢？ 以上是最近的一點想法，有很多可能是錯的，還要再研究。 現在開始在看軟體專案有名的管理書-人月神話，希望能有多點收穫。

這是我在 ptt 發問的文章，希望能得到滿意的答案 當純工程師當了兩年，升級了 但變的更慘了，除了工程師要做的 還有管理下面的專案 我必須把專案中的細工作項目 估計出需要的時間，並決定優先順序 還有決定交由誰做 當然我知道估計的時間不可能完全準的 所以我們的估計方法都是需要的時間再乘以1.2來計算 問題來了， 我是一間小公司，業務部門就在RD旁邊 三天兩頭的，業務一遇到問題就直接找上工程師 甚至會有大頭的命令下來插單 在不斷的打斷與干擾間，我估的工時都不夠用了 還有就是插單的估計法 就算插單要將目前工作向後延，但因為插單造成工程師中斷 而且管理人員也必須重新調整時程 我覺得應該當做消耗加倍人力 我們的工程師感覺像服務業 一直要保持高機動性應付各種不是規劃中的事情 但又要低閒置人力 我真的好難估計工時，又怕把下面的人壓死 又怕估得太誇張，老是死在一堆看不見的時間成本裡 卻又說不出來 大家有什麼好的看法嗎？

從二月初升上組長後，工作一直卡卡的，除了原有的開發工作外，多了一些管理工作 手上目前主要開發的專案有： 1. 將完成的新專案，從頭到尾我一人開發，從去年開始，可是收尾也是頗可怕，可是似乎變得不被重視了 2.新專案，我負責雛形和部份功能，還會有一至二人協助開發，但時程很短，而且從我知道時，就已經要開始開發了，沒時間去想了，只能硬著幹，而且又要快速完成，會變成什麼樣我都不知道。 3.舊專案，架構龐大，接手過的離職人數超過5人，基本上現在接手的兩人都沒辦法 100%掌控它，我是負責管理，偶爾協助，但可怕的是經常有變動的、緊急的工作插進來，負責的人員就要快速轉換到別的工作，這才是我花最多時間的。 4.更舊的專案，很少會有變動，但有變動就是緊急 基本上我的時間常常是在各專案間轉換就浪費掉了，而且還有負責管理的部份，又要花時間跟需求單位溝通。 這星期我幾乎每天加班，連星期四 2/28在公司從 AM9:00 到 PM10:00..比平常上班待的還久，結果報誤餐費竟然說 只能報一餐 ，讓人不想再加班。 而且已經累到有點恍神，吃不下飯，但是 兼顧的下場，每邊的專案都 delay，這麼累，還是會被罵 ，那還是想辦法輕鬆點好了。 開會討論後，竟然得到 沒有給工作估好工時，就不能延遲 的結論，於是我必須再花更多時間，先給每個工作估計出需要的時間，再統計好，算出那些可以在期限前被完成，那我估計工作時間的時間應該也要估計要花多久時間，這麼東西啊！ 都不知在寫什麼了，就是覺得不舒服、不高興、不開心，很想對所有朋友說， 最近我很忙，別煩我！

如果把一個專案拆成一些小項，一開始只會有功能，這一段路通常是漫長而平順的。 到了中期後，就出現叉路啦，什麼都冒出來了： 新功能：原來沒規劃的東西 bug：會讓東西壞掉的蟲 風險：不確定什麼時候會發生的問題，機率可能很低 安全：搞不清楚的危險 畫面：好不好看 對於行銷與RD兩方人馬而言，每場槍戰重視的程度大概是： RD 行銷 新功能 低 高 bug 高 高 風險 中 低 安全 高 低 畫面 低 高 看來衝突是免不了的，我只能祈求和平一點