tag:blogger.com,1999:blog-43490878647544848352024-09-17T12:43:12.630+08:00我的雜記和我的生活高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.comBlogger69125tag:blogger.com,1999:blog-4349087864754484835.post-78460622923356776792018-04-20T01:29:00.001+08:002018-04-20T01:37:55.610+08:00<div dir="ltr" style="text-align: left;" trbidi="on"> 身為工程師都十年了，但是寫個工程相關的Blog都很懶。<br /> <div> 最近(2018.3)從台灣跑到美國來工作，工作內容到是還好上手不慢，但是美國生活卻是上手很慢啊，菜英文在美國生活不易。之後Blog轉為記錄美國生活吧。</div> <div> <br /></div> <div> 目前來美國剛好滿一個月。 目前完成的事情有:</div> <div> <br /></div> <div> 1. SSN</div> <div> 2. Driver License Permit (Behind-the-wheel-test isn't done yet)</div> <div> 3. Bank Account/Debit Card</div> <div> 4. Credit Card</div> <div> 5. Rent a room with my friend</div> <div> 6. prepaid sim card</div> <div> <br /></div> <div> <br /></div> <div> 待辦事項:</div> <div> 1. Behind-the-wheel-test</div> <div> 2. Buy a new car</div> <div> 3. Build up credit score</div> <div> 4. Other Bank Account, ex: Chase/Citi</div> <div> <br /></div> <div> <br /></div> <div> 之後繼續分享每次事的心得吧。先講講第一天要做事。</div> <div> <br /></div> <div> <br /></div> <div> 如果你剛好也是像我一樣拿L1 Visa來美國的，要記住一件事就是一關卡一關，可以提早完成的就趕快去做。Ex: DMV筆試要居住證明，居住證明可能要先去租個房子有水電帳單或銀行帳單，要租房子可能會需要Money Order，Money Order在Walmart又需要SSN/Driver License才能買(倒)(USPS似乎不需要)，SSN辦又要需等2周以上，銀行開戶又需要SSN。 總之就是一個迴圈的概念啦。</div> <div> <br /></div> <div> <br /></div> <div> 建議到美國前，如果有跟公司合作的銀行，可以在台灣就先線上開好帳戶並且*不要*寄Debit Card到公司或朋友那邊(可能會拖更久)，選擇一到美國就到銀行拿Debit Card並存好你帶的錢，並且跟銀行拿Personal Check，然後立即去買張Prepaid Sim卡，這樣你第一天就有Debit卡/Personal Check/Phone number. 然後馬上去SSN Office 辦理SSN (I-94表格要印)。SSN很重要，沒有SSN沒辦法辦Credit Card去累積信用，所以第一天就要去辦，如果還是住在飯店的話，可以選擇先寄到公司。</div> <div> <br /></div> <div> 基本上第一天結束後，就是等SSN跟找Apartment。但是現在DMV的預約常常都要拖超過一個月，要自己算好什麼時候可以有SSN跟居住證明(水電帳單、銀行帳單、公司的一些證明 總共要兩份)。</div> <div> <br /></div> <div> Anyway, 美國生活不易啊。 :)</div> </div> 高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-11628001363211418032016-06-18T13:14:00.001+08:002016-06-18T13:14:53.986+08:00<div dir="ltr" style="text-align: left;" trbidi="on"> 最近有機會去做了幾個SQL的題目，才發現自己的SQL knowledge有點弱，太多層的巢狀表格就不知道讓怎麼寫，之前大部份是小型資料庫，所以都靠Programming language 去幫忙計算。<br /> <div> <br /></div> <div> Q: Update the field in table if &nbsp;condition is success</div> <div> <br /></div> <div> A:</div> <div> <div> UPDATE OpenOrder SET Status=1 WHERE OpenOrderId In (SELECT OpenOrder.OpenOrderId FROM OpenOrder, SettleOrder WHERE OpenOrder.OpenOrderId = SettleOrder.OpenOrderId GROUP BY SettleOrder.OpenOrderId HAVING SUM(SettleOrder.SettleQty) &lt; OpenOrder.Qty)</div> </div> <div> <br /></div> <div> <br /></div> <div> Q: Calculate the profit per each customer</div> <div> <div> SELECT Client.ClientName, SUM((SettlePrice-OrderPrice)*SettleQty) AS TotalPL FROM Client, OpenOrder, SettleOrder WHERE Client.ClientId=OpenOrder.ClientId AND OpenOrder.OpenOrderId=SettleOrder.OpenOrderId GROUP BY Client.ClientId</div> </div> <div> <br /></div> <div> <br /></div> <div> --</div> <div> 後來花了一點時間再研究後，才知道我忘了HAVING的用途還有3 個 table時我就卡住了... &nbsp;:)</div> <div> <br /></div> <div> Solving problem and deep study always...</div> <div> <br /></div> </div> 高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-54998462983414068662012-06-16T17:01:00.001+08:002012-06-16T17:12:52.708+08:00話中從上一份工作最後一年才開始接觸Python，就被這輕巧、精美又強大的語言所吸引，那時候不知道從那邊聽來的一句話就是好的工程師至少要學會兩種語言，一種是compiler time的一種是dynamic language ，例如像我現在這樣的C++ 和Python，以前在不會(不知道)Python的時候，很多自己用或是公司用的小工具都是用C++, C#自己刻的，雖然C#用起來相對C++輕鬆的多，但是都沒有python用起來方便，從此之後我就開始用google學python，雖然沒搞清楚python但還是寫了幾個有用的工具，也寫了一些 tool給QA工程師用，甚至到最後都要用boost::python把python當成print script 來用(最後因為先離職了 XD)，目前只有完成一個authorization dll透過boost::python把encode/decode export出來給python用，並提供web api可以線上申請試用版。<br /> <div> <br /></div> <div> <div> <br /></div> <div> 後來新工作的關係，我大部分都是跟windbg為伍，不再需要一直寫程式了，很多C++, python的學習也相對都停下來，專心在研究kernel debugging skill，直到後來發現一個windbg extension - pykd，可以透過python來寫windbg的script，我才越來越感覺python的神奇。哈</div> <div> <br /></div> <div> <br /></div> <div> 上星期跑去參加PYCON 2012，對於一個真的沒仔細看Python書只用google來寫python的人來寫程式，每一樣東西都是很神奇的，對於能聽到NumPy, SciPy作者演講感覺到很興奮(之前工作都是跟DSP, Matlab打轉)，聽到各方面的應用各是收獲良多(但是還是要抱怨一下，這次應該投搞主題少吧沒得挑，感覺有些主題相對內容空洞，分享的很沒意義)，我也利用PYCON的週末寫了一下程式，太久沒真的動手寫程式感覺心情真是舒爽啊。</div> <div> <br /></div> <div> <br /></div> <div> 最近利用pykd開始寫一些工作用的script, extension，無論是分析kernel mode, user mode 或是BSOD dump files，希望能更加快我的debugging process。(也許明年我也可以上台分享windbg+python)</div> <div> <br /></div> <div> <br /> <div> <br /></div> </div> </div>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-20915799251672137792011-09-29T09:57:00.004+08:002011-09-29T22:25:55.688+08:00<p class="p1"></p><blockquote>"The journey discussed here starts with "Hello, World!", but where does it end? Far too often, it ends with a promotion to middle management. Too many talented people thoughtlessly take that promotion and find themselves just a few years later in jobs the don't enjoy and yearning for retirement. But for those who have a knack for developing software and enjoy the learning process, software development is a career that can last a lifetime, and it can be a great ride." - Apprenticeship Pattern</blockquote>上一段話是學徒模式簡介上寫的東西，我看了還蠻有感覺的，我之前是在一個小公司上班，大概工作快二年就升上一個小課長，做著一些吃力不討好的事，手邊的工作一樣都不能少，還要去安排工作、開會等事項，我就會想想難道管理職都是技術能力不錯的人當嗎？因為當課長這幾年下來我一直沒有做好我課長的本份，我將我99%的心力放在技術coding上，後來想想我認為這樣是不對的，其他工程師是期望你做好管理職的本份而不是技術上，但我又會擔心如果我不實際去code，誰能擔上這個工作呢。當然事情發生了就要去解決，不過當時我沒有，我只是等著時間的流逝。<p></p><p class="p1">我想我的確是有欠思考，我接管理職時才27歲，太多人與人之間的事還沒學會怎麼處理，更何況去帶給資深、新人一些未來的方向，現在給我選擇的話我當時絕對不會接受管理職這種事，我寧願當個資深工程師做技術，而我的老闆是個聰明的管理者就好了。</p><p class="p1">好險我私底下是一直保持學習的熱情，持續在下班時間接受技術上的新東西，現在離開管理職了，我想我對於自己的技術及學習的能力是很有信心的，可以勝任我之後要做的工作。 :)</p><p class="p1"><br /></p><p class="p1"><br /></p>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-36526145677421452722011-09-28T10:23:00.003+08:002011-09-28T10:30:18.570+08:00最近因為換了工作，需要大量的英文能力，然後我又小時候不學好，現在英文大概只有國一的程度吧(好險新公司可以接受破英文再摩練)，為了努力挽救我的英文能力，現在買書也盡量買原文書，雖然感覺有點自不量力但是這也是沒辦法的，看一本書要很久不過至少看的是自己喜歡的書也順便練習不熟的單字，一舉兩用啊 XDD<div><br /></div><div>---- 書單 -----</div><div>Apprenticeship Patterns</div><div>Refactoring</div><div>Code Complete</div><div>Prefactoing</div><div>-----------------</div><div><div><br /></div><div>ps. 如果以前學生時代有這麼認真讀書的話，我就不會一直這麼孤單了，大學畢業後真正在寫程式的只剩我一人 orz</div></div>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-21139050429240555222011-07-06T20:53:00.000+08:002011-07-06T20:55:39.164+08:00<div style="text-align: -webkit-auto;">1. 善於防守</div><ul><li>使用好的程式設計風格和合理的設計</li><li>不要倉促地編寫程式碼</li><li>不要相信任何人</li><li>程式設計的目標是清晰，而不是精簡</li><li>不要讓任何人做他們不該做的修補工作</li><li>編譯時打開所有警告開關</li><li>使用靜態分析工具</li><li>使用安全的資料結構</li><li>檢查所有的返回值</li><li>審慎地處理記憶體 (和其他寶貴的資源)</li><li>在宣告位置初始化所有的變數</li><li>盡可能推遲變數的宣告</li><li>使用標準語言工具</li><li>使用好的診斷資訊日誌工具</li><li>審慎地進行強制轉換</li><li>提供預定的行為、遵從語言習慣、檢查數值的上下限、正確設定常數</li><li>契約式設計 (design by contract)</li></ul><div>2. 精心佈局</div><ul><li>程式師對程式碼充滿了熱情，因此程式碼的樣式相當能觸動他們的心弦</li><li>如果你的團隊已經有了一個程式設計標準，那麼就使用這個標準，不要使用你自己喜歡的風格</li></ul><div>3. 名正言順</div><ul><li>如果你無法想出恰當的名稱，那麼你也許就需要改變你的設計了。這是有地方不對勁的徵兆。</li><li>在進行命名時，將重點放在清晰而非簡潔上</li><li>在名稱中避免使用多餘的詞。尤其是在型別名中避免使用以下這些詞語：class, data, object, type</li></ul><div><br /></div><div>-----</div><div>讀了三個章節唯一喜歡的只有第一章而已，先花時間看別本好了，這本書就章節跳著看</div><div><br /></div>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-982773801197346922011-07-04T21:07:00.001+08:002011-07-04T21:07:33.500+08:00<div><span class="Apple-style-span" style="font-family: Tahoma; font-size: medium; ">27. 再談團隊殺手</span></div><ul><li>大部分團隊殺手所造成的傷害都來自於徹底貶損工作，或貶損從事該工作的人</li><li>團隊會自動自發設定並堅持一個令人引以為傲的工藝標準</li><li>管理階層相信藉由掛海報可以培養這些美德(品質)，而非藉由努力工作和管理才幹</li><li>長期加班是降低生產力的做法，多出來的工作時間總會被不良的副作用給抵銷掉</li><li>當你打算動用團隊成員不同的加班能力時，這麼做往往會摧毀團隊</li><li>最好不要為了如期完成而加太多班，即使那是一個當你無法如期完成時可以卸責的藉口</li></ul><div>28. 競爭</div><ul><li>當孩子缺乏父母關愛，沒有注入足夠的時間、尊重、關注與感情，較容易產生競爭</li><li>競爭有什麼影響？第一個被攜牲的，就是常見於健康團隊中，輕鬆而有有效的同儕指導</li><li>當今知識工作者所組成的團隊普遍都是技術的混合體，我們越來越相信，大部分的指導係來自於團隊成員本身</li><li>排除那些不能讓管理人員及工程師以工作成果為榮的障礙，這也就是說「尤其」年度考績制度及目標管理必須停用</li><li>目標管理及其類似概念乃是管理上的逃避藉口，藉由過分簡化的外部激勵因素來刺激員工的表現</li><li>任何對團隊成員的差別待遇，都有可能助長競爭，管理者有必要採取行動以降低或彌補這個影響</li><li>促使團隊死亡的管理作為：年度薪資或獎懲考評、目標管理、讀美特定員工的特殊成就、根據績效稿賞、獎勵、分紅、幾乎任何形式的績效評量</li><li>協助所有成員都了解，個人成功與整體成功緊緊相扣</li></ul><div>29. 流程改善計劃</div><ul><li>當今大獲成功的標準幾乎全都是介面標準</li><li>CMM的似是而非，在於流程改善是好的，但流程改善計畫就不好了，或至少通常不好</li><li>能幹的員工始終都在進行流程改善</li><li>組織越「成熟」，就越不願意冒險</li><li>貴公司最出名的災難專案，極有可能正是貴公司這幾年來所做過最棒的專案</li><li>越改善了工作方法，工作就越艱難 - 剩下的都是更知識密集，需要更多技術與經驗的工作</li><li>最值得做的專案，是那些會導致公司降級的專案</li></ul><div>30.讓改變發生</div><ul><li>人們不只是排斥某個特定的改變，他們排斥所有的改變，那是因為人們痛恨改改</li><li>頒布新體制的人將成為所有舊體制既得利益者的公敵，至於會從新體制中獲益的人，則不會積極地給予支持</li><li>對於任何改變，相信、但心存疑慮者才是唯一有意義的潛在盟友，至於兩個極端，盲目忠誠者和強硬反對者都是真正的敵人</li><li>改變能否成功，就看你如何管理相信、但心存疑慮者</li><li>別指望以邏輯推理做為說服眾人的王牌</li><li>咒語：對改變所做的基本回應並不是邏輯性的，而是情緒性的</li><li>絕對不要貶損舊方法，相反地，應該讚美它，以利於走向改變發生的道路</li><li>提醒人們任何改善都伴隨著改變，完全都不改變，就無法有所改善</li><li>一個構想，一個簡化的「更好的做事方式」，就能從舊狀態直接改變至新狀態，事情沒有那麼簡單，絕對沒有</li><li>改變的發生有賴引進外來因素：改變的催化劑</li><li>混亂是改變的必經之路，沒有捷徑</li><li>混亂階段越痛苦，就會覺得新狀態的價值越大 --- 只要你能抵達新狀態</li><li>舊狀態 -&gt; (外來因素) -&gt; 混亂 -&gt; (概念轉換) -&gt; 施行與整合 -&gt; 新狀態</li><li>改變不可能在缺乏安全感的情況下發生</li><li>人類天生對混亂狀態的恐懼感，也許有助於解釋小孩子比成年人更容易學習新事物</li></ul><div>31. 人力資本</div><ul><li>人力資本你可以視為是非常有價值的，若是誤把它視為沉沒費用，只怕會引導經理人採取不當行動，無法留住組織投資的價值</li><li>「無法留住組織投資的價值」是不良管理的主要結果之一</li><li>費用 v.s 投資</li><li>企業整頓的目的，在於擴大編制，而非縮減編制</li><li>擁有知識工作者的公司必須明瞭，人力資本是他們最重要的投資，好公司早就這麼做了</li></ul><div>32. 組織學習</div><ul><li>學習並非單純的經驗累積</li><li>當組織自我改造，開始斟酌經驗所顯露出來的意涵，經驗方能轉化為學習</li><li>學習受限於組織是否有能力把人留住</li><li>有關組織學習的關鍵問題，並非如何去做，而是在哪裡發生</li><li>學習型組織通常具備的特徵就是堅強的中階管理層，但很值得指出，如果有裁員的話，最常被裁的就是中階管理層</li><li>把中階管理層從組織圖中刪除掉，肯定不利於學習，但反過來說卻不一定對，為了塑造出一個生氣蓬勃的學習中心，中階管理者必須相互構通，並學習和睦融洽地一起共事，這非常少見</li><li>更糟的是，經理人缺乏成任何團隊凝結所必須的要素：產品共同擁有的感覺 「有好東西就佔為己有，無法佔有就毀掉它」</li></ul><div>33. 終極的管理罪惡是……</div><ul><li>任何例行的會議多少都令人懷疑具有儀式的目地，而不是為了取得眾人的共識</li><li>早期的人力過剩 - 專案始於規畫和設計，初期的活動若能由一支規模略小的團隊負責執行是最好不過的了</li><li>時間分割不太容易被寒覺</li></ul><div>34. 打造社區</div><ul><li>偉大經理人所能做的事情中最棒的：打造社區</li><li>社區並不會自己出現在工作中，而是必須被創造出來的</li><li>打造社區、使社區健全並滿足每一個人的科學，就是政治學</li><li>拒絕政治是一個災難，是放棄經理人的真正責任</li></ul><div><br /></div><div><br /></div><div>愛德華．戴明(W. Ewards Deming) 『轉危為安』 (Out of the Crisis) 1982</div>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-38882742906994172382011-07-04T09:17:00.001+08:002011-07-04T09:17:17.131+08:00<div style="text-align: -webkit-auto;"><span class="Apple-style-span" style="font-family: Tahoma; font-size: medium; ">工作應該是快樂的</span></div><div><span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Tahoma; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium;"><br /></span></div><div><span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Tahoma; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium;">24. 混亂與秩序</span></div><ul><li>不再有混亂，我們也不會因此而更快樂，相反地，我們會因無聊而哭泣</li><li>敞開心胸的經理人則不同，他們樂於把小睏小睏的混亂留給別人</li><li>建設性地再造少量的混亂 - 先導專案、競賽、腦力激盪、緊張刺激的培訓經驗、訓練、旅遊、會議、慶祝、以及閉關</li><li>先導專案就是把厚重的標準手冊放一旁，嘗試某些新穎而未經證實的技術，初期會很沒效率，這是改變的代價，但這份代價將使你得到新技術帶來的生產力提升，還有一個額外的好處，就是霍桑效應，亦即當部屬從事不同的新奇事物時，所爆發出來的活力與興致</li><li>把專案當成採用某些新技術的先導專案，你可能會因此而花比較少的錢</li><li>當成標準化所達成的是眾產品之間的文件一致性，而無法達到有意義的功能一致性</li><li>先導專案必須特別注意：不要在任何專案中，對一個以上的新技術進行試驗</li><li>在最健全的環境裡，專案成員都會了解，在每個專案中，以某個單一新技術進行試驗是受到鼓勵的行為，然而在其他方面就得按照標準來</li><li>我們每天上班都應該要符合常規並遵守秩序，但還是要保有冒險，做傻事，以及少許建設性混亂的空間</li></ul><div>25. 自由電子</div><ul><li>榮譽會員、大師，以及內部企業家 - 自己決定自己的工作</li><li>大多數人的確如此 - 喜歡老闆講清楚要達成哪些目標才算成功</li><li>最佳經理人的特徵，就是有能力找出少數兼具遠見與成熟的關鍵人物，然後任其自由發揮</li></ul><div>26. 霍爾格。丹斯克</div><ul><li>喚醒沈睡的巨人</li></ul>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-89968233599214459722011-07-02T17:23:00.000+08:002011-07-02T17:24:24.571+08:00<div style="text-align: -webkit-auto;"><span class="Apple-style-span" style="font-family: Tahoma; font-size: medium; ">良好的工作經驗通常伴隨著某種程度的挑戰</span></div><div><span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Tahoma; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium;"><br /></span></div><div><span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Tahoma; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium;">18. 一加一大於二</span></div><ul><li>一支凝結的團隊，就是已經緊密結合到整體力量大於個別力量總和的一群人，他們從工作中所得到的快樂也超乎你預料工作本身所能給予的</li><li>相信員工會自動接受組織的目標，正是管理上天真、過分樂觀的象徵</li><li>我們除了倚賴「專業精神」之外，沒有什麼可以保證大家會朝共同的方向邁進</li><li>要求他們把對專案的注意力轉移到公司稅潤上，不會有任何幫助，反而會使成功變得微不足道，並且失去意義</li><li>我們的工作多半都不太需要真正的團隊合作，但團隊還是很重要，因為團隊的作用在於把大家導入同一個方向</li><li>團隊的目地並不在於達成目標，而在於統一目標</li><li>凝結團隊：優越感、產品共同擁有、樂在其中</li><li>害怕派系是缺乏安全感的症狀</li><li>凝結團隊或許自視甚高、自給自足、令人討厭、又排外，但跟任何可隨意替換與拼湊的人相比，他們更有助於經理人達成真正的目標</li></ul><div>20. 團隊殺手</div><ul><li>你根本無法讓團隊凝結，你可以祈禱，也可以做些有利於凝結的事，但就是無法讓它發生</li><li>應用水平思考法(Lateral Thinking) - 倒轉技巧 - 當問題怎麼也解決不了時，與其尋找達成目標的辦法，不如尋找達不到目標的辦法</li><li>防禦性管理、官僚作風、實體隔離、時間分割、產品的品質降低、虛假的最後期限、派系控制</li><li>只有一個地方，採取防禦態度一定會遭到反效果：你無法針對無能的部屬，事前採取防護措施，假如員工無法應付手邊的工作，你就註定會失敗，當然，要是這些人真的不適任，你就應該另覓新人；但是你一旦決定與這支團隊共事，最好的策略就是信任他們</li><li>「你不信任他們」的訊息，沒有比這個訊息更能阻礙團隊形成的了</li><li>太多管理者都搞錯了不該信任部屬的時機</li><li>擁有做對事情的權利(在你上司眼中或政府眼中是對的)並不重要，唯有推有做錯事情的權利，才能讓你自由</li><li>團隊必須相信自己賴以形成的目標，目標可以是任意的，但至少它得存在</li><li>沒有團隊空間，就沒有立即而持續的強化作用，也沒有機會形成團隊文化</li><li>沒有人會談品質降低的產品，他們談的是成本降低的產品，但這兩者通常導致相同的結果</li></ul><div>21. 義大利麵晚餐</div><ul><li>成功將會帶來新的成功，生產力共鳴將會孕育出更多生產力共鳴</li><li>天生的管理者潛意識裡就知道怎麼做對團隊最好</li><li>藉由小規模而簡單的成功事件塑造整體經驗，你必須加倍觀寒，才能發現經理人介入其中的痕跡</li><li>最好的主管，就是能不斷用這種方式管理，卻讓團隊成員感覺不出「有被管理」的主管</li></ul><div>22. 敞開心胸</div><ul><li>培育凝結團隊是很倚賴運氣的事，沒有人可以持續成功，也沒有人可以保證凝結一定發生，特別是培育出最能幹的團隊</li><li>鐵的事實：某些經理人擅長協助團隊凝結，成功機會也比較大</li><li>敞開心胸的態度跟防禦性管理完全相反 - 它把人放在該被信任的位置，不採取任何自我防禦措施，完全信任底下所有的人</li><li>一個傷害個人自尊的工作環境，其本身就是一種「病」</li><li>你怎麼確定他們不會摸魚？答案很簡單，看他們帶回什麼樣的東西就知道了。</li><li>對開發人員來說，目視監督是一個笑話，只有囚犯才需要目視<span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Tahoma; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium;">監督</span></li><li><span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Tahoma; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium;">臭鼬工廠就是一項藏於某處，在管理高層不知情的情況下所進行的專案，因為基層員工對產品的正確性深信不疑，所以拒絕接受管理階層放棄該專案的決定</span></li><li><span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Tahoma; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium;">自然權威 - 師傅 + 學徒，經理人 + 工程師 (專業能力)</span></li><li><span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Tahoma; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium;">員工比較在乎跟誰在一起工作而不是做那些專案</span></li></ul><div>23. 團隊形成的化學作用</div><ul><li>營造追求品質的狂熱、提供許多令人滿意的完結(closure)、建立菁英感、允許並鼓勵差異性、保留並保護成功的團隊、提供策略性而非戰術性的指示</li><li>一個普遍的認知就是，當團隊表現過於突出，便表示經理人怠忽職守，團隊是否嚴格遵守一致的公司標準，幾乎可說是經理人對團隊控制程度的象徵</li><li>管理上若扼殺與眾不同，就會變得到處與眾不同，當員工表現出桀傲不遜、非常被動、或不願合作，就表示你可能管太多了</li><li>假如你能影響部屬，使之更具生產力、更目標導向，但也更難控制，你會怎麼做？</li><li>成功管理的本質就是讓所有人都朝相同的方向邁進</li><li>這裡有一項很重要的準則，就是團隊必須在某些意識上與眾不同，而非處處與眾不同。 (軍方特種部隊)</li><li>團隊是一種網絡結構，而非階層結構</li><li>一點點介異性，就可能對建立凝結團隊有很大的幫助</li><li style="list-style: none"><br /></li></ul>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-36233009841025343812011-07-01T18:08:00.000+08:002011-07-01T19:11:48.739+08:00雖然當主管也一段時間了，已經佔了我從開始工作到現在的時間50%，可是我一直沒有做好管理職，或許應該說沒有真的用心在做主管，有一些自己的想法都不知道對還是錯，卻又要帶給新人、資深的同事關於生涯規劃、工作心態的一些想法，說出來自己又沒有太大的把握，我在這方面還太嫩了，對於人生或管理上見識太少，人生經歷也太短，還需要有一個好的主管帶著我成長，如果自己還在人生的路上搖搖晃晃的又要怎麼帶領他人呢？<div><br /></div><div><div>我可以教所有人有關技術的東西，這些技術我可以講得頭頭是道，因為我會一直學習進修加強自己工程師的能力，而且我很樂意教別人東西(當老師的天性？)，非常開心有人來問我這些問題，還記得一個同事說如果問我問題的話，還要想辦法避免我講太多才行 XD，我想我有天份在專業技術上，但是管理的天份呢？我仍然不確定有沒有。在一間大概30人的公司，當個小小課長是蠻容易的，只要技術能力強就很容易升上去，但一個技術強的不代表能當個好主管。</div><div><br /></div><div>當主管是完全不同領域了，需要不同的天份，我的心理還沒準備好這回事，也感受我屬下的包容，期許自己有一天能真正做好管理職，只是現在個人興趣還是在專業技術上，我還是沒辦法不寫程式啊。 :)</div></div><div><br /></div><div>感謝我的前主管，雖然只帶了我2年多的時間，卻是我當主管的模範。</div><div><br /></div><div><br /></div>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com1tag:blogger.com,1999:blog-4349087864754484835.post-11135211293957265142011-06-30T11:10:00.000+08:002011-06-30T11:11:03.773+08:00<div style="text-align: -webkit-auto;">由誰來做總比如何去做的影響還要大</div><div>管理科學比較關切的是，如何讓老闆扮演好工作中策略家與戰術家的角色，玩這種遊戲不需要考慮人的個性或才華，成功或失敗是取決於在何時、何地部署那些沒有靈魂的人力資源</div><div>找到適任的人、讓他們快樂到不想走、放手讓他們發撥</div><div><br /></div><div>14. 霍布洛爾因素</div><ul><li>管理一艘橫帆戰艦或船隻，與管理某個公司部門或專案並沒有太大的差異：人員招募、訓練、工作分派、時程規畫，以及戰術支援</li><li>良才出於天生，而非後天的培養</li><li>能迅速估量下屬的實力，並明白何時能仰賴這些人，便是霍布洛爾最偉大的才能</li><li>人通常都不會在一個地方待太久，管理者也缺乏足夠的影響力來改變部屬的天性，假如一開始就不適任，那他將來也不會適任</li><li>整齊劃一的需要，假然是管理階層缺乏安全感的徵兆</li><li>熵就是均勻度或相似度，熵值越高，激發能量或執行工作的潛能就越少。就像熱力學所講的，宇宙裡的熵一直持續在增加，而企業的熵也是</li><li>管理的熱力學第二定律：組織裡的熵一直持續在增加</li></ul><div>15. 雇用雜耍小丑</div><ul><li>面試時，有什麼比要求每個求職者自備一些作品更合理的呢？</li><li>性向測驗可以量測出不適合之處</li><li>在健全的組織裡，讓員工經常做些有趣的自我評量是必要的</li><li>聘雇程序至少應著重某些社會性和人際溝通的特性</li><li>試鏡</li><li>你有責任捕捉從主講人眼神裡所散發出來的迷人熱情，那種在你工作中睽違已久的熱情</li></ul><div>16. 很高興能待在這裡</div><ul><li>聘雇一位新人的成本相當於一個半月至兩個月的薪水</li><li>倘若員工只會待一或兩年，留住優秀人才的唯一辦法就是加速升遷</li><li>離職率會刺激離職率</li><li>最優秀的公司本能地會去努力使自己變成最優秀的</li><li>低流動率公司還有另一項共同特徵，就是廣泛的再訓練</li></ul><div>17. 自我修復的系統</div><ul><li>摒棄雜亂無章又無法控制的自我修復能力，乃是自動化頗為正面的好處</li><li>假如新系統的運作要視情況應變的成分居多，那麼自動化便是一個錯誤</li><li>假如高層所給的方向對他們來說沒有意義，那就一點意義也沒有</li><li>方法論造成文書工作的泛濫，方法的不足，責任感的缺乏，以及士氣全面低落</li><li>大量的文件只會製造問題，而非解決問題</li><li>假如按方法論做下去，出了錯，就是方法論的錯，不是人的錯</li><li>人都希望承擔責任，但必須在多少能掌握自身成功的情況下，他們才願意</li><li>方法論 - 管理階層認為員工無能，打擊士氣莫過於此</li><li>惡意的盲從 - 就算明知結果是浪費時間、沒用的產品、無意義的文件，也照做不誤</li><li>標準 - 經過驗證(內路獲得普遍且成功的證實)，用於執行一項重複性工作的方法</li><li>統一方法是很好，但不一定要透過方法論來辦到這一點：訓練、工具、同儕審查</li><li>人們對差異會感到著迷，喜歡專注，對新奇的事物很感興趣，這就叫做霍桑效應 (Hawthorne Effect)</li></ul>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-13214899997759437212011-06-29T02:50:00.000+08:002011-06-29T02:51:54.062+08:00<div style="text-align: -webkit-auto;">為了協助員工投入工作，你必須努力對付有可能阻撓工作的因素</div><div>浪費一個工作天的辦法有千萬種，卻沒有任何一個辦法可以重拾一個工作天</div><div><br /></div><div>7. 傢俱糾察隊</div><ul><li>改善工作場所是最有助於提升生產力的手段，只要員工被擠在吵雜、無趣、經常被干擾的環境裡，最值得改善的就是工作場所</li></ul><div>8.「從早上九點到下午五點根本做不了任何事」</div><ul><li>所有產業的開發人員普遍存在一項認知，就是「加班是生活的常態」</li><li>待晚一點、提早上班或在家安靜工作，無一不是對辦公環境的嚴厲控訴</li><li>具有十年經驗的人，其表現並未優於只有兩年經驗的人。參賽者對自身所使用的語言，若經驗不足六個月，則表現將不如其他人，除此之外，經驗與表現之間沒有任何關聯</li><li>我們找到對良好績效具正面影響的因素中，有一項是始料未及的：跟你配對的夥伴有很大的關係</li><li>程式設計師之間存在這種「10比1」生產力差異是可以理解的，同樣，軟體公司也存在著10比1的生產力差異</li><li>表現較好的人傾向於待在提供了較佳工作場所的公司</li><li>環境因素：1.你的工作空間有多大？2.夠安靜嗎？3.夠隱密嗎？4.你的電話可以調整為靜音嗎？5.你的電話可以轉由他人接聽嗎？6.同事是否經常非必要地打擾你？</li></ul><div>9. 在空間上省錢</div><ul><li>節省開支 v.s 喪失工作效率的風險</li></ul><div>插曲</div><ul><li>硬科學講求客觀，有非常嚴謹的推理論證，如：物理、化學</li><li>軟科學比較主觀，解釋彈性很大，如：哲學、社會學</li><li>任何你需要量化的東西，都能以某種方式進行評量，而且比完全不去評量要強</li><li>一家無法對自己程式設計生產力進行評量的公司，只是沒有用心去努力嘗試罷了</li><li>你無法承擔一無所知的後果</li><li>評量時請閉上眼睛 - 工作評量在改善工作方法、激勵，以及增進工作滿意度上是很有用的工具，不過，一般幾乎都不是為了這些目的，評量機制反倒變得既駭人又沉重</li></ul><div>10. 腦力時間與身體時間</div><ul><li>員工一天之中有30%的時間對噪意很敏感，其餘時間則是噪意的製造者</li><li>假如他們一週內只有一、兩個小時不受干擾，這並不是他們的錯，而是公司的錯</li><li>讓你的員工把焦點放在神馳時間的重要性</li><li>E因子 = 不受干擾的時間 / 置身工作環境的時間</li><li>單一組織的因子數值會隨不同辦公地點而不同</li></ul><div>11. 電話</div><ul><li>頭號問題人物卻往往是管理者 - 「我老闆一外出，就把他的電話轉到我這裡」</li><li>負責做好工作的人必須享有某種程度的和諧與寧靜，這意味工作時段不宜受到任何干擾</li><li>為了換取若干不受干擾的腦力時間，大家必須接受每天都有部分時間可被干擾，並同意以合理頻率查看電子郵件 --如，一天三次。</li></ul><div>12. 把門找回來</div><ul><li>面對員工對噪音的不滿，你能做的不是治標，就是治本。 治本 - 牆與門</li><li>負責數學演算與邏輯的那半邊腦並不會受到音樂的影響 - 負責聽音樂的是另半邊腦</li><li>但是創音靈感來自於右腦，但假如此時右腦正忙著聽1001首管絃樂，就不會有這種創意靈感了</li><li>封閉式辦公室不見得就是一人辦公室</li><li>最佳的管理，應該要確保員工擁有足夠的空間、足夠的安靜、足夠的隱私，以使他們能夠創造出屬於自己的合理工作場所</li><li><span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Tahoma; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium;">裝設背景音樂或其他形式的粉紅噪音或戴上耳機聽錄音帶，預料都會在員工的工作表現上付出無形的代價：他們將缺乏創意</span></li></ul><div>13. 雨傘步 (辦公空間的永恒之道)</div><ul><li>若工作場所過於封閉或者暴露，其中的人就無法有效率地工作，好的工作場所應力求平衡，身後有牆的工作場所會讓你感到較為自在，在你前方八呎以內，不該是一道沒有門窗的牆</li><li>當今的模組化隔板是妥協下的代表作：給你是沒有任何意義的隱私，卻又讓你有被孤立的感覺</li><li>任何人類團隊要是缺少共同進食的活動，都無法長久共事</li><li>這些模式既不否認個人的特質，也不否認他希望與其他夥伴有所連繫的傾向，這些模式讓人能夠做他自己</li><li>根據非複製公式，沒有哪兩個人的工作空間一模一樣，沒有哪兩個咖啡區一模一樣，任何圖書室或休息區也都是如何</li><li>先判別哪些專案最重要，然後讓這些關鍵專案出走。在企業總部以外進行重要工作通常會有更佳的表現</li><li>只要你的小組生產力較高，離職率較低，就登明你是一個更優秀的經理人</li></ul>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-43803986476483911032011-06-28T15:07:00.002+08:002011-06-28T16:32:47.676+08:00<div style="text-align: -webkit-auto;"><span class="Apple-style-span"><div>[讀書筆記] Peopleware - 第一部 管理人力資源</div><div><br /></div><div>只有當你完成一件事之後，才真正知道該如何完成</div><div>這些習性非常普遍，而且講得理直氣壯，卻往往是錯誤的</div><div>我們大多數人都很容易犯一種特別的毛病：傾向於把人當成零件來管理</div><div><br /></div><div>1. 當下，有個專案即將失敗</div></span><span class="Apple-style-span" style="font-size: medium; "><ul><li>倘若你認定某個問題本質上就是政治問題，自然就會對該問題抱持宿命的觀點</li><li>我們在工作中所面臨的，在本質上，主要都是社會性的問題，而非技術性的問題</li><li>他們對人的憂慮遠多於對技術的憂慮，但在管理時卻又是另一回事，他們主要關切的還是技術</li><li>他們永遠在追尋可望讓工作自動化的技術絕招，對於職務中越是以人為主的層面，卻越不關心，這種現象有部分肇因於管理者的養成方式，他們所受的訓練是如何做好工作，而非如何管理工作</li><li>我們身處的應該是人際溝通產業，工作的成功來自於所有團隊成員的良好人際互動，失敗則肇因於不良的人際互動</li><li><span class="Apple-style-span" style="font-size: 16px; ">人際互動很複雜，效果也非三言兩語所能道盡，然而其重要性往往凌駕於其他工作層面</span></li></ul></span><span class="Apple-style-span"><div>2. 做起司漢堡，賣起司漢堡</div></span><span class="Apple-tab-span" style="white-space:pre"><ul><li><span class="Apple-style-span" style="white-space: normal; ">開發工作在本質上就跟產品製造不同，但從事開發工作的經理人，其思維還是常常承襲了製造業的管理哲學</span></li><li><span class="Apple-style-span" style="white-space: normal; ">允許犯錯 - 你為禁止犯錯所採取的措施，或許能提升一點點技術水平，但團隊社會學將深受其害</span></li><li><span class="Apple-style-span" style="white-space: normal; ">管理：膚淺的定義 - 管理就是踢屁股</span></li><li><span class="Apple-style-span" style="white-space: normal; ">你很少需要採取嚴厲手段才能讓部屬工作下去，因為大部分的人都熱愛他們的工作，甚至你有時還得想辦法讓他們少做一些，以便完成更多有意義的事</span></li><li><span class="Apple-style-span" style="white-space: normal; ">人力商店 - 因為擔心某位關鍵人物會離開，便強迫自己相信根本沒有關鍵人物這回事</span></li><li><span class="Apple-style-span" style="white-space: normal; ">對盲目採行製造業管理風格的經理人來說，員工的獨特性一直是很討人厭的事，相反地，真正會用人的經理人則了解，獨特性會讓專案起更活潑而有效的化學作用，是需要培養的東西。</span></li><li><span class="Apple-style-span" style="white-space: normal; ">處於穩定狀態的專案就是死專案</span></li><li><span class="Apple-style-span" style="white-space: normal; ">應該把整個專案管理的焦點放在開發工作的動力(dynamics)</span></li><li><span class="Apple-style-span" style="white-space: normal; ">當我們在評估人對於新專案有多少價值的時候，通常根據的是人的穩定狀態特質：能寫出多少程式，或能產出多少文件。我們鮮少關心每一個個體在融入整個開發工作時，能有多契合</span></li><li><span class="Apple-style-span" style="white-space: normal; ">當風險升高時，多思考的重要性就大幅增加</span></li><li><span class="Apple-style-span" style="white-space: normal; ">遇到真正困難的工作，就必須學習以更少時間做事，而以更多時間思考工作本身</span></li></ul></span><span class="Apple-style-span"><div>3. 維也約等著你</div></span><ul><li>當人們在大談特談「聰明工作」的話題時，普遍都認為真實世界的管理就是如何讓人工作得更久，更賣力，並以大量犧牲員工的個人生活做為代價。</li><li>無論你有多企盼他們在工作時全力付出，也不能以犧牲其個人生活做為代價</li><li>每加一小時的班，就約莫換來打一小時的混，這種交換在短期內或許能得到好處，但長期而言就很不划現</li><li>處於時間壓力下的人不會把工作做得更好，只會做得比較快</li></ul><span class="Apple-style-span"><div>4. 品質 --- 倘若時間允許</div></span><ul><li>人的個性乃是由少數基本本能所主宰：求生、自尊、繁衍、地域等等</li><li>挑動情緒最主要的因素，就是自尊受到威脅</li><li>你所採取任何可能危及產品品質的行動，都將引爆部屬對你的負面情緒</li><li>在槍桿之下，反而過度限制他們所能做的努力，為求準時完工，將喪失在各項資源之間做取捨的自由，也不可能增加人手或減少功能，唯一能動手腳的，只剩下品質。</li><li>強迫部屬交出一個品質達不到他自認為合格的產品，幾乎可說是一項錯誤的決定</li><li>創作者對品質的看法卻完全不同，由於他們的自尊與產品品質緊緊相繫，所以通常會用自己的品質標準加諸於產品之上。</li><li>品質能夠超過最終使用者所需要的標準，乃是通往更高生產力的途徑</li><li>價格與品質的妥協不存在於日本，甚至，高品質可帶來成本降低的觀念非常普遍</li><li>讓創作者訂自定自認為滿意的品質標準後，所提高的生產力將足以彌補為改進品質所付出的代價</li><li>「品質---倘若時間允許的話」的政策將保證產品沒有任何品質</li></ul><span class="Apple-style-span"><div>5. 重審帕金森定律</div></span><ul><li>帕金森定律 - 無論配置多少工作時間，該工作都會把配置的時間耗光</li><li>帕金森定律幾乎肯定不適用於你的部屬，只要不在他們自訂的品質標準上打折扣，他們會跟你一樣渴望完成工作</li><li>把你的部屬當成帕金森式的員工一定沒效，此舉只會打擊他們的自尊與工作衝勁</li><li>當專案的時程既不合理又不切實際，無論加多少班也完成不了時，專案團隊就會既憤怒又沮喪……而且士氣將跌到谷底</li><li>研究指出，老闆不給時程壓力的專案竟然締造了最高的生產力，這並不能證明帕金森定律不適用於從事開發的工作者，但這難道不令你驚奇嗎？</li></ul><span class="Apple-style-span"><div>6. 苦杏仁素</div></span><ul><li>許多經理人因為絕望，所以輕信可以改善生產力的說辭，淪為技術上的苦杏仁素受害者</li><li>我們確信，這些做得比較好的組織並沒有使用任何特別先進的技術，他們之所以有更好的表現，完全是因為更有效率地處理人事、改進工作場所和企業文化</li><li>簡單卻解決不了問題的辦法，往往比困難的辦法更誘人</li><li>軟體產業的生產力年成長率為三到五個百分點，僅略勝於鋼鐵或汽車產業</li><li>程式語言很重要，因為它會影響你對問題的思考方式，但話說回來，所影響的也僅限於專案的實作部分 (頂多只有5%的效益)</li><li>你要是對部屬施加大量壓大，他們就會有更好工作表現？ 不 --- 這只會減少他們的工作樂趣</li><li>管理者的工作並不是叫人去工作，而是去創造讓人想去工作的情境</li></ul></div>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com2tag:blogger.com,1999:blog-4349087864754484835.post-57179547498493564442011-06-25T17:29:00.000+08:002011-06-25T18:04:50.676+08:00翻了一下之前的文章發現有幾篇去年的草稿都只寫一半就停了，數一數大概有十來篇... XDD<br /><br />今年因為公司的2個資深軟體工師離職了，所以最近都忙著找新人、面試新人、帶新人、準備教育訓練，但我該寫的程式還是一個都沒少，時間不夠用就是看技術資料的時間也相對變少了，rss常常累積了半個月的文章沒看，以前總是可以照著自己的步調寫程式，一天內總是有幾個小時可以看一下新技術學東西，現在連可以安靜寫寫程式的時間也很難，常常就是開會、無意義的出差、當保姆，想想可以專心著寫程式真是幸福的一件事。 :)<br /><br />忙到很時間寫blog是個藉口，懶及文筆不好才是沒持續寫的原因，之所以幾年前開blog就是想練習一下自己的表達能力及分享一下自己的程式心得，為了這兩個目標我還是改掉懶這個壞習慣吧。 囧<br /><br />-------<br /><br />時間過很快，在embedded system領域不知不覺就過了七年了，想說最近幫blog灌一下水寫寫這幾年來的工作心得吧。 :)高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-64814891548947853982011-06-25T09:52:00.004+08:002011-06-25T17:38:23.490+08:00因為前陣子公司電腦跑VS2010實在是太慢了，就把VS2008專案升級的計畫延後，也剛好我老闆願意升級我們的研發機器 (淚)，換了i7-2600 + 8G RAM跑VS2010終於順多了，前幾天找時間升級了一下專案，結果又出現了一些相容性的問題。 囧<br /><br /><div>------------------------------<br /><br />錯誤訊息:<br /><br /><code>1&gt;c:\program files (x86)\microsoft visual studio 10.0\vc\include\stdint.h(72): warning C4005: 'INT8_MIN' : macro redefinition</code><div><br /></div><div>原因: <b>Including stdint after intsafe generates warnings</b></div><div><b><br /></b></div><div>這個問題我原本以為是boost的關係，也找到boost相關的ticket有說明這個問題，後來查得更仔細才發現是Visual Studio 2010和Windows SDK 7.0的定義衝突問題</div><div><br /></div><div>解法:</div><div>參照這篇<a href="http://connect.microsoft.com/VisualStudio/feedback/details/621653/including-stdint-after-intsafe-generates-warnings">MSDN說明</a>，這個問題要等到下次主要版本更新才會修正了，也許是VS2010或是SDK 7.1? 目前的解法就只能忽略這個warning...</div></div><div><br /></div><div><code>#ifdef _MSC_VER<br />#pragma warning (push)<br />#pragma warning (disable : 4005)<br />#include &lt;intsafe.h&gt;<br />#include &lt;stdint.h&gt;<br />#pragma warning (pop)<br />#endif</code></div><div><br /></div>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-36249102713469242202011-06-09T07:17:00.001+08:002011-06-09T07:17:14.819+08:00<div style="padding: 0; overflow: hidden; margin: 0; width: 500px;"><a href="http://www.flickr.com/photos/wanwan722/5811615009/in/set-72157626790821489/" title="DSC05940" style="display: block; padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm4.static.flickr.com/3653/5811615009_d05a1e5f86_s.jpg" alt="DSC05940" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><a href="http://www.flickr.com/photos/wanwan722/5812169298/in/set-72157626790821489/" title="DSC05918" style="display: block; padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm3.static.flickr.com/2582/5812169298_6f29cd3ac4_s.jpg" alt="DSC05918" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><a href="http://www.flickr.com/photos/wanwan722/5812174516/in/set-72157626790821489/" title="DSC05936" style="display: block; padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm3.static.flickr.com/2208/5812174516_cdbc2ae5f6_s.jpg" alt="DSC05936" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><a href="http://www.flickr.com/photos/wanwan722/5812184926/in/set-72157626790821489/" title="DSC05945" style="display: block; padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm3.static.flickr.com/2328/5812184926_d225f07c5c_s.jpg" alt="DSC05945" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><a href="http://www.flickr.com/photos/wanwan722/5812191422/in/set-72157626790821489/" title="DSC05961" style="display: block; padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm3.static.flickr.com/2308/5812191422_fbd15e087b_s.jpg" alt="DSC05961" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><a href="http://www.flickr.com/photos/wanwan722/5812197662/in/set-72157626790821489/" title="DSC05962" style="display: block; padding: 0 0 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm3.static.flickr.com/2739/5812197662_42cb2eccf3_s.jpg" alt="DSC05962" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><br clear="all"/><a href="http://www.flickr.com/photos/wanwan722/5811638921/in/set-72157626790821489/" title="DSC05974" style="display: block; padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm4.static.flickr.com/3059/5811638921_268a8a28c3_s.jpg" alt="DSC05974" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><a href="http://www.flickr.com/photos/wanwan722/5812209282/in/set-72157626790821489/" title="DSC05987" style="display: block; padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm6.static.flickr.com/5302/5812209282_416cb9f2b9_s.jpg" alt="DSC05987" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><a href="http://www.flickr.com/photos/wanwan722/5812213238/in/set-72157626790821489/" title="DSC05988" style="display: block; padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm4.static.flickr.com/3048/5812213238_cc879ca61f_s.jpg" alt="DSC05988" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><a href="http://www.flickr.com/photos/wanwan722/5811652793/in/set-72157626790821489/" title="DSC05989" style="display: block; padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm4.static.flickr.com/3455/5811652793_9bae9d1984_s.jpg" alt="DSC05989" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><a href="http://www.flickr.com/photos/wanwan722/5812223446/in/set-72157626790821489/" title="DSC05990" style="display: block; padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm3.static.flickr.com/2307/5812223446_dab01e470d_s.jpg" alt="DSC05990" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><a href="http://www.flickr.com/photos/wanwan722/5811660473/in/set-72157626790821489/" title="DSC06008" style="display: block; padding: 0 0 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm4.static.flickr.com/3312/5811660473_e2cd46e7cd_s.jpg" alt="DSC06008" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><br clear="all"/><a href="http://www.flickr.com/photos/wanwan722/5812229914/in/set-72157626790821489/" title="DSC06035" style="display: block; padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://farm3.static.flickr.com/2302/5812229914_7284f1a380_s.jpg" alt="DSC06035" style="border:none; margin: 0; padding: 0; width: 75px; height: 75px;"/></a><div style="padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://l.yimg.com/g/images/gallery-empty-icon.gif" style="margin: 0; padding: 0; width: 75px; height: 75px;"></div><div style="padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://l.yimg.com/g/images/gallery-empty-icon.gif" style="margin: 0; padding: 0; width: 75px; height: 75px;"></div><div style="padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://l.yimg.com/g/images/gallery-empty-icon.gif" style="margin: 0; padding: 0; width: 75px; height: 75px;"></div><div style="padding: 0 10px 10px 0; width: 75px; height: 75px; float: left;"><img src="http://l.yimg.com/g/images/gallery-empty-icon.gif" style="margin: 0; padding: 0; width: 75px; height: 75px;"></div><div style="padding: 0 0 10px 0; width: 75px; height: 75px; float: left;"><img src="http://l.yimg.com/g/images/gallery-empty-icon.gif" style="margin: 0; padding: 0; width: 75px; height: 75px;"></div><br clear="all"/></div><div style="margin-top: 0px; margin-bottom: 5px"><p>Flickr 上的相片集 <a href="http://www.flickr.com/photos/wanwan722/sets/72157626790821489/">2011-06 妖怪村+內湖國小</a>。</p></div>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-58359442241686875702011-05-12T00:53:00.008+08:002011-06-15T00:51:23.864+08:00<meta charset="utf-8">1. 焦油坑<div><ul><li>軟體系統產品 - 大部分軟體工程企圖要做出來的東西</li><li>調適自己習於追求完美是學習軟體工程最困難的部分</li><li>你得先把工作做成功，才會得到越多實質上的權力</li><li>我們所倚賴的技術基礎是不斷地在進步，當設計完成的那一剎那，從該設計所代表的概念來看，它就已經落伍了</li></ul><div>2. 人月神話</div></div><div><ul><li>時程預估技術還非常不成熟，這些不成熟的技術背後都反映出一個假設，"一切都會進行得很順利"</li><li>預估技術誤把工作量和專案進度混為一談，"以為人力和工時可以互換"</li><li>以為"每項工作都將只會耗費掉它「理應」耗費的時間</li><li>用人月來衡量工作規模的大小是危險的，也是一個容易遭到誤解的迷思</li><li>只有當工作可被切分，而且投入工作的人彼此不用溝通，人力和工時的互換才算成立</li><li>分配足夠的時間給系統測試是非常重要的</li><li>在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後</li><li>軟體專案會耗費多少時間是看它有多少連續性的限制，該投入多少人力是看它可以切分成多少獨立的子工作</li></ul><div>3. 外科手術團隊</div></div><div><ul><li>生產力最好和最差的比率平均大約是10:1，經驗和表現好壞之間並沒有任何關聯</li><li>參與合作的人數會影響投入的成本，你最好盡可能用最少的人來完成專案</li><li>短小精悍團隊的問題出來了：開發真正大的系統就太慢了</li><li>要同時兼顧工作效率與概念整體性，這實在是兩難</li><li>Harlan Mills建議大系統中的每個個小部分都分別交由一個團隊來負責，而各個團隊則被組織成外科手術團隊</li><li>外科醫生 - 首席程式設計師 (副手是出主意、參與討論、評估)</li><li>傳統團隊裡的成員而言，他們的地位都是對等的，所以因決策的衝突而必須進行溝通和妥協是不可避免的</li><li>外科手術團隊不切割問題、主從關係</li><li>就一個200人參與的專案而言，只要那20個外科醫生能一起合作的話就行</li><li>由一位系統架構設計師由上到下進行全部的設計</li></ul><div>4. 專制、民主與系統設計<span class="Apple-style-span" style="font-family: 'ＭＳ 明朝', serif; ">在系統設計時，保有概念整體性是最重要的原則 <br /></span></div></div><div><ul><li><span style="font-family: 'ＭＳ 明朝', serif; ">只有當功能增強所節省下來的時間超過學習、記憶和</span><span style="font-family: 新細明體; ">查閱</span><span style="font-family: 'ＭＳ 明朝', serif; ">手冊所耗費的時間，電腦的使用便利性才會提升</span></li><li><span style="font-family: 'ＭＳ 明朝', serif; "></span><span class="Apple-style-span" style="font-family: 'ＭＳ 明朝', serif; ">功能概念複雜度比才是系統設計的最終測試標準，好的設計既不可單獨偏重功能性，也不可只偏重簡單性</span></li><li><span class="Apple-style-span" style="font-family: 'ＭＳ 明朝', serif; "></span><span class="Apple-style-span" style="font-family: 'ＭＳ 明朝', serif; ">設計人員總是以功能性來評判系統的優劣，而非簡單性</span></li><li><span class="Apple-style-span" style="font-family: 'ＭＳ 明朝', serif; "></span><span class="Apple-style-span" style="font-family: 'ＭＳ 明朝', serif; ">若只提供基本功能和組合這些功能的規則，還稱不上是簡單便利，你必須讓使用者養成固定的使用習慣，也就是為這些功能提供一整套同一系列的操作方式</span></li><li><span class="Apple-style-span" style="font-family: 'ＭＳ 明朝', serif; "></span><span style="font-family: 'ＭＳ 明朝', serif; ">架構旨在</span><span style="font-family: 新細明體; ">說</span><span style="font-family: 'ＭＳ 明朝', serif; ">明做什麼，實作則是</span><span style="font-family: 新細明體; ">說</span><span style="font-family: 'ＭＳ 明朝', serif; ">明如何做</span></li><li><span style="font-family: 'ＭＳ 明朝', serif; "></span><span class="Apple-style-span" style="font-family: 'ＭＳ 明朝', serif; ">使用便利性的好壞是基於系統的概念整體性</span></li><li><span class="Apple-style-span" style="font-family: 'ＭＳ 明朝', serif; "></span><span style="font-family: 新細明體; ">產</span><span style="font-family: 'ＭＳ 明朝', serif; ">品的成本效能比是非常仰賴實作人員才能</span><span style="font-family: 新細明體; ">夠</span><span style="font-family: 'ＭＳ 明朝', serif; ">提升的，這跟使用便利性得仰賴架構設計師的道理是一樣的</span></li><li><span style="font-family: 'ＭＳ 明朝', serif; "></span><span class="Apple-style-span" style="font-family: 'ＭＳ 明朝', serif; ">約束對藝術而言是件好事</span></li><li><span style="font-size: 12pt; font-family: 'ＭＳ 明朝', serif; ">要達成概念整體性，真的是有賴於讓系統反映出單一的理念</span></li></ul><div><span class="Apple-style-span">5. 第二系統效應</span></div></div><div><ul><li><span class="Apple-style-span">第二個系統是最危險的系統</span></li><li><span class="Apple-style-span">一般來說，第二系統都傾向於過度設計</span></li></ul><div><span class="Apple-style-span">6. 意念的傳達</span></div></div><div><ul><li><span class="Apple-style-span">將修改的程予以量化(quantize)是很重要的</span></li><li><span class="Apple-style-span">架構設計師都必須隨時準備好提出一種實作方式供人參考，但不應該企圖硬性規定採用特定的實作方式</span></li><li><span class="Apple-style-span">開會絕對是必要的</span></li><li><span class="Apple-style-span">將最後的決定權明確授權給首席系統架構設計師，使妥協和延宕得以避免</span></li><li><span class="Apple-style-span">配合錯誤的實作來修改規格將會耗費更多的時間和成本，還不如乖乖按照規格來修正實作</span></li><li>如果有何任不清楚的地方，我們希望實作人員都應該打電話向負責的架構設計師詢問，而不要妄加猜測或自行解釋</li><li>解釋架構上的效力，所以應該公告讓所有人知曉</li></ul><div>7. 巴別塔為什麼失敗？</div></div><div><ul><li>人與人不能彼此交談，就無法合作，當合作失敗，工作就陷入停頓</li><li>良好的電話聯繫制度並明確定義出團隊之間的從屬關係</li><li>例行的專案會議</li><li>專案工作手冊</li><li>組織的目的便在於減少溝通介面和協調的需要量，所以組織就是為了上述的溝通問題而存在的 - 透過人力配置和專案分工來減少溝通量</li><li>樹狀結構的組織是源自於權力和責任的結構，在任何人都不能同時聽命於兩個老闆的原則之下，造成了權力結構成為樹狀的樣子</li><li>溝通結構是網狀的</li><li>管理者 - 技術總監</li><li>組織必須視現有人力的特性來調配，而不是叫人去配合一個純屬理論的組織 <br /></li><li>管理者和技術總監必須給人感覺對主要技術的看法是一致的，重要的技術問題應該在私下場合進行溝通，在他們取得共識之前，管理者必須尊重技術總監在技術上的權威</li></ul><div>8. 預估</div></div><div><ul><li>如果採用了合適的高階語言，軟體開發的生產力也許可以提升到五倍</li><li>寫一個獨立的小程式所花的時間不能拿來做為預估整個軟體系統產品的開發時程之用</li><li>費力程度 = 常數 x 指令數量 ^ 1.5</li></ul><div>9. 地盡其利，物盡其用</div></div><div><ul><li>五磅麻袋裝十磅東西，其隱喻就是在資源不是無限取用的情況下，必須「地盡其利，物盡其用」</li><li>鼓吹系統的整體觀與使用者導向的態度，也許是軟體管理者最重要的職責</li><li>管理者可以做兩件事情，第一件就是確保大家的本事是真正透過程式設計的技術訓練而來，而不是憑個人的天賦或過去的經驗，第二件是認知到寫程式有它專業的技術，組件是要去創造才有的</li><li>每一個函式都應該至少包括兩套程式碼，一套是執行進度最快的，一套是使用空間最少的</li><li>資料的呈現方式是程式設計的本質</li></ul><div>10. 文件假說</div></div><div><ul><li>電腦的操作手冊與性能描述，這是開發任何一項新產品時所必須優先準備的文件之一，並且也是最後完成的文件</li><li>大部分的管理工作總是由成堆文件中的某一小部分具體呈現出來</li><li>只有把事情真正寫下來，遺漏和矛盾之處才會顯露出來，也唯有把「寫」這個動作確實做出來，才能導引出更多細節的決定(mini-decision)，那正是從模糊不清之中理出清晰而明確正策的具體方法</li><li>管理者的基本工作就是要保持組織裡每一個人都朝同一個方向前進，所以他每天的主要工作就是溝通，而非做決定，寫文件就大大減輕他的溝通負擔</li><li>傾聽、報告、引導、訓勉、商議、激勵</li></ul><div>11. 失敗為成功之母</div></div><div><ul><li>所有開發大型軟體系統的經驗都顯示，丟掉重做總有一天會做成功的</li><li>把必然的一次失敗納入正式計畫之中</li><li>定義一個底限是必要的，而且隨著專案進行，這項限制應該要越來越嚴格</li><li>唯一不變的就是變，認清到這個事實，將有助於你面對改變</li><li>不只是目標會改變，軟體開發的策略和技術也一樣會改變，丟掉重做的概念本身就是要讓你接受先學到竅門、然後改變設計</li><li>表格驅動技術 (table-driven)、高階語言、自我說明技術(self-documenting)</li><li>要形成一個利於改變 組織，比設計一個利於改變的系統還要難</li><li>為什麼無法將錯誤一次修正 1. 除非軟體結構非常單純，或是文件寫得非常好，否則往往只是治標而沒有真正治本。2. 負責修改錯誤的人通常不是程式原作者，而是菜鳥或新手</li><li>軟體維護必須搭配比一般發展時更多的系統測試</li><li>任何修改的動作都有破壞原有軟體結構的傾向，並且會增加系統的紊亂程度</li><li>任何事物總是在開始的時候最完美</li><li>若說軟體開發是一個簡單化而逐漸趨於穩定的過程，那麼軟體維護則是複雜化且逐漸趨於混亂的過程，即使有很好的技巧，頂多也只能減緩這種趨勢，軟體終究會走到落伍，再也無法修改的那一天</li></ul><div>12. 神兵利器</div></div><div><ul><li>使用高階語言</li><li>交談式程式編寫</li><li>除錯是編寫程式過程中最難也最耗時的部分，而漫長的回覆時間又是除錯過程中最要命的部分</li></ul><div>13. 化整為零</div></div><div><ul><li>最致命也最棘手的錯誤莫過於系統錯誤，這肇因於各個組件的開發人員做出了彼此不協調的假設</li><li>把產品定義清楚是非常關鍵的工作，有太多太多的失敗都源自於自始至終都搞不清楚要做的是什麼東西</li><li>開發人員不適合規格審查</li><li>開發人員 - 他們就算是看不懂規格也不會告訴你的，他們會隨著個人的喜好自行解釋</li><li>系統除錯所耗費的時間將超乎你的預期</li></ul><div>14. 釀成大災難</div><div><ul><li>為什麼專案會落後一年？ 因為每次落後一天</li><li>老闆想要知道真相有兩個方法：第一個方法是降低角色的衝突以鼓勵據實回報；另一個方法是審查制度</li></ul></div><div> <br /></div></div><div>15. 一體兩面</div><div><ul><li>我們無法主宰我們不了解的東西</li><li>每個程式使用者都需要一份淺顯的程式說明</li><li>好的做法是先求淺顯但涵蓋面廣泛，再逐漸深入解釋細節</li><li>流程圖中的方框符號所代表的涵義跟高階語言的功能相同，可用來將低階的機器語言集合起來，成為較易理解的段落</li><li>一個有條理的高階語言本身就具備了良好的分段，如果每一行程式都要用一個方框來表示，將會使文件過於冗長，還會佔據大量的空間</li><li>嘗試同步維護不同的文件是件愚蠢的事，對於同一件事物的相關資訊，應該盡可能統一放在同一份文件中比較好</li><li>自我說明的做法是來自於使用高階語言的刺激</li></ul><div>16. 沒有銀彈：軟體工程的本質性與附屬性工作</div></div><div><ul><li>在制定軟體需求時，採用多次反覆的方式，並把快速原型製作納入所規劃的每個反覆之中</li><li>讓軟體像生物一樣地發育成長，在系統持續被執行、被使用、被測試的過程中，逐步擴充功能</li><li>持續尋覓並培養年輕一代偉大的概念設計人員</li><li>對於一個軟體實體所做的描述，若將其複雜性抽離，結果往往也連帶抽離了他的本質</li><li>因為複雜性，使開發團隊成員溝通困難，進而導致了產品的瑕疵、成本的超支、時程的落後</li><li>複雜性造成了學習與理解上的巨大負擔，使人員的異動形同是個災難</li><li>所謂抽象資料型別，其概念就是一個物件的型別應該由一個名稱、一組適當的值和一組適當的操作方式來定義，而不是以它儲存的結構來定義，這部分應該是要被隱藏</li></ul><div>19. 人月神話二十年</div></div><div><ul><li>設計時必須靠許多人的構想共同來完成，但成果又必須讓使用者感覺到其概念是前後連貫的一套心智模式</li><li>架構設計師也形同使用者的代理人，在功能、效能、程式大小、成本和時程之間總是衝突的情況之下，他得綜觀全局，站在維護使用者利益的角度上做出取捨</li><li>架構設計師就像是導演，而經理就像是製作人</li><li>切分的界線所在，必須是能讓子系統之間的介面最小且最容易精確定義之處</li><li>錯誤而明確，也遠比模糊不清要好</li><li>架構設計師所要面對的其中一個最困難的議題，就是如何恰如其分地在進階使用方式與便利性之間取得平衡，他們要為新手或偶爾才會用一下的使用者設計出簡單的操作方式，還是要為專業級的使用者設計出比較有效率的進階使用方式呢？最完美的答案就是兩者都提供，並仍然兼顧到概念的連貫與一致</li><li>不要建構出必然失敗的系統 --- 瀑布模型是錯的</li><li>為改變而設計</li><li>當規劃時間比最佳時間的3/4還少時，則幾乎沒有任何專案能夠成功，不論給多少人去做都一樣</li><li>專案如果要成功，人的品質，以及人的組織與管理，遠遠比他們所運用的工具或技術要來得重要</li><li>我們在工作中所面臨的，在本質上，主要都是社會性的問題，而非技術性的問題</li><li>管理者的工作並不是叫人去工作，而是去創造讓人想去工作的情境</li><li>輔助功能原則告訴我們，假如能夠小心地維持基層的自主與責任，領導中心將在威信與效能上獲益，其結果是整個組織「越快樂，越欣欣向榮」</li></ul></div>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-66247198530203835972011-04-03T12:20:00.006+08:002011-06-25T17:28:26.138+08:00<div>第1章 擁抱風險</div><div><ul><li>Charette的風險電扶梯</li><li>假如對某個風險拿不出辦法，他就會把它忽略掉。 (錯誤)</li></ul><div>第2章 風險管理是成年人的專案管理</div></div><div><ul><li>暫時性定義: 可能會造成意外結果的事物就是風險</li><li>風險管理的事務，著重的就是成因風險(causal risk)的管理，亦即你能管理的部分。</li><li>所謂風險，就是還沒發生的問題；所謂問題，則是已經成形的風險。</li><li>風險探索 - 承擔分析 - 應變規劃 - 紓緩 - 蛻變的持續監視</li></ul></div><div><br /></div>第6章 不確定性的臭名<br /><ul><li>事情做錯沒關係，就是不可以不確定 (錯誤)<br />(不正視的風險帶來的不確定性)</li><li>在事後為延誤請求原諒，但是不可以在事前要求認可 (錯誤)</li><li>選擇性短視症 (大家都很小心不讓自己被枕木絆倒，卻沒人發現越來越近的火車)</li></ul><div>第7章 運氣</div><div><ul><li>一般的通病就是全部的風險都在賭運氣</li><li>風險管理是要你在規劃專案時，把焦點放在一旦某些機會沒有抓住的話該怎麼辦。</li><li>做軟體的案子，把失敗的可能性限制在一定範圍內，一般來說，是比追求勝利更重要的事。</li></ul><div>第8章 將不確定性量化</div></div><div><ul><li>「把最早講出來的日期訂為最後期限」，基本上就保證到時一定跳票。</li><li>把不確定性明確標示出來，你便敢放膽冒險。</li><li>不確定範圍要多大才算合理，取決於組織開發程序中干擾(noise)或變異的多寡，而非某個人的感覺。</li><li>不確定範圍大多是介於N的150%~200%之間</li></ul><div>第9章 風險管理的技巧</div></div><div><ul><li>從專案經理的角度，他所認知的計畫就是一群一定要完成的工作</li><li>專案偏離時程，很少是因為工作比預期的更花時間</li><li>「昨日的問題就是今日的風險」 (認知到問題會一再重複出現的本質)</li><li>把事後檢討的輸出結果當作風險管理的輸入資料</li><li>迴避風險 - 放棄報酬</li><li>抑制風險 - 額外準備足夠的時間和金錢</li><li>紓緩風險 - 降低抑制成本，在風險成形之前採取措施</li><li>逃避風險 - 祈求老天保佑</li><li>沒有任何合約可以把全部的責任統統轉嫁給某個單位，不論是客戶，還是承包商，都必須做好某些風險管理</li><li>風險承擔=成本x機率</li><li>致命風險 - 確保致命風險不會發生</li><li>蛻變指標 - 每個滾動的球後面都跟著一位追逐的孩童 (卡車司機座右銘)</li></ul>第10章 風險管理的處方</div><div><ul><li>在專案進行時，持續風險探索程序</li><li>沒有人會為一個完成可能性保證有75%的目標全力以赴，也沒人會為一個完成可能性大概是零的目標全力以赴</li><li>規劃專案時程時，把承諾日期和挑戰性目標分開來訂</li><li>時程 &gt; 目標 &gt; N</li><li>如果交貨日期完全不能改，改用版本漸近的方式</li><li>專案在表面上是不變的期限，但骨子裡卻完全不是</li><li>想平安地公開風險調查報告，除非大家都一起公開</li></ul>第11章 回到根本</div><div><ul><li>把這些「我不知道」的問題弄清楚，因為那通常就是風險的所在</li><li>「對於我不知道的東西，我知道什麼 (或我能知道什麼) ？</li><li>不確定性圖 n: 一種平面圖，以橫軸列舉一組可能發生的結果，以縱軸表示每一種結果的相對可能性</li><li>每個成因風險都是用一張風險圖來描述</li><li>把一組成因風險轉化為加總風險</li><li>透過生產模型來預估 N值 (軟體規模參數和技術因素)，再利用風險模型標出不確定性，得到加總風險圖</li></ul>第12章 工具和程序</div><div><ul><li>RISKOLOGY <a href="http://www.systemsguild.com/riskology/">http://www.systemsguild.com/riskology/</a></li><li>Monte Carlo sampling</li></ul>第13章 軟體專案的核心風險</div><div><ul><li>五個軟體專案常見風險(先天的時程錯誤、需求膨脹、人力流失、規格崩潰、低生產力)</li><li>時程錯誤: 專案規模高估的部分，通常都不足以抵銷低估的部分</li><li>大部分的核心風險都跟團隊績效低落無關，時程錯誤也一樣</li><li>真正表現不佳的，可能是提出或承諾錯誤時程的管理者</li><li>開發軟體多半是為了滿足某些人的事業領域</li><li>被掩飾的問題暫時消失不見了，但不會永遠消失不見。</li></ul>第14章 風險探索的明確過程</div><div><ul><li>閉口不談風險，也不會讓風險消失不見</li><li>組織不準大家談論風險 甚至變成一種不成文規定，而成為組織文化的一環</li><li>需要一個開放、固定、能被諒解的程序，好讓負面言論有說出來的可能</li><li>風險探索儀式必須讓人很放心地分享恐懼</li><li>災難腦力激盪 -&gt; 情境建立 -&gt; 根源分析</li></ul>第15章 風險管理的動態追蹤</div><div><ul><li>持續監控蛻變指標</li><li>持續進行風險探索</li><li>蒐集資料，充實風險庫</li><li>每天持續追蹤完工量測指標</li><li>完工量測指標(邊界元素敲定、實獲率)</li></ul>第16章 漸進式風險紓緩</div><div><ul><li> 最佳投資收益比的風險紓緩策略就是漸進式交付</li><li>大部分專案的做法通常都是被動的，這種被動做法完全得不到漸進式的好處</li><li>假設產品的每個部分都一樣重要，這種謊言充斥於許多專案</li><li>如果系統有個部分必須仰賴技術上的突破才能完成，就該把它納入早期版本</li><li>漸進交付計畫(設計藍圖、工作分解結構、一組版本驗收測試)</li><li>一個版本就是設計藍圖的一個子集</li><li>能被版本驗收測試證實完成與否的工作才歸屬到同一個版本</li></ul>第17章 終極的風險紓緩策略</div><div><ul><li>組織裡的傳統觀念 - 認為建立專案時不預留任何緩衝餘地就是真正勇敢的管理</li><li>起步太晚是喪失遠見與勇氣的象徵</li></ul><div>第18章 價值的量化</div></div><div><ul><li>精確成本和糢糊報酬造就出不倫不類的成本報酬分析，便無法判定風險值是多少，結果，看來只有規避風險最適合</li><li>成本和報酬都必須律定得同樣精確才行</li><li>開發經理接下專案，便有義務提出明確的時程和成本預算</li><li>利害關係人也必須1</li><li>為預估報酬和實際報酬負責，報酬量化和成本量化的精確程度必須相當</li><li>若報酬一點量化數據都沒有，就假設是零</li><li>矯正的時刻：我們無法精確指定報酬的45,328個理由</li><li>雖然軟體最大的風險要不就在技術(產品方面)，要不就在人為(專案方面)，但是，公司最大的風險卻是在價值方法：把功夫浪費在低價值專案而錯失高價值專案，所 耗費的機會成本</li><li>冒險的積極程度必須由報酬來驅動</li></ul><div>第19章 價值也一樣不確定</div></div><div><ul><li>畫不確定圖</li><li>只要大一點的風險，都是以價值為核心</li><li>沒有價值評估，結果就只會是個意氣用事的決策</li></ul><div>第20章 敏感性分析</div><ul><li>想個巧妙的辦法來增加利害關係人負的責</li><li>價值是非常不平均地分佈在系統中</li><li>軟體開發人員應該學著相信「少開發一點軟體」</li><li>系統專案呈現規模不經濟的特徵 (系統規模增加為2倍，則預料系統開發耗費的心力會超過2倍)</li></ul><div>第21章 值不值得冒險</div></div><div><ul><li>IT產業：報酬小，就要冒更多險，不然我們怎麼可能把成本壓低到讓專案不賠本？</li><li>死亡行軍專案：這次的任務實在太重要了，重要到全體專案人員最後一滴血也要搾乾。<br />(既然這個專案有那麼重要，為什麼公司不願分配合理的時間和金錢來做呢？</li><li>死亡行軍專案特徵：預期價值很低、員工成了冤大頭、專後最後幾乎都出盡洋相</li><li>真正的專案評量需要在風險和價值之間取得平衡</li></ul></div>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-26221568538339161872011-03-16T09:02:00.004+08:002011-03-20T08:52:19.371+08:00最近實在是很想用用C++ 0x的功能在我的專案上，所以就跟我老闆申請，好加在老闆也同意了，從VS2008更新到VS2010時大部分是沒問題的，只在編譯時碰到一個warning..<div><div><br /></div><div><br /></div><div> 因為之前我在建立自己的library時，會在debug版後面加個d或是在debug + unicode版本時後面加個ud，方便我自己偵錯也避免連結上的錯誤。</div><div>只是在Visual Studio 2008時，是直接修改$OutDir的檔名，現在Visual Studio 2010則改變做法，增加TargetName, TargetExt的屬性，所以只要把.dll名稱的結尾改為修改TargetName就好了，OutDir則按照Visual Studio 2010的推薦做法設定為$(OutDir)$(TargetName)$(TargetExt)即可。</div><div><br /></div><div><br /></div></div>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-22928128275272942012010-12-10T21:02:00.007+08:002010-12-10T22:12:00.282+08:00今天更新了工作用的boost 1.38，之前也是一直想更新，可是都沒空閒，或是怎麼一更新complier就一堆錯誤。<br />所以剛好今天有空，而且也快年底了，就趕快更新一下，底下列出我更新時遇到的問題。<br /><br /><b><span class="Apple-style-span">1. exception header file改變</span></b><div><br /></div><div><p>由</p><p><code>#include &lt;boost/exception.hpp&gt; </code></p><p>改為 </p><p><code>#include &lt;boost/exception/all.hpp&gt;</code></p> </div><div><br /></div><div>心得: 不知道這樣改的原因是為什麼，原本<boost hpp="">不是好好的嗎</boost></div><div><br /></div><div><b><span class="Apple-style-span">2. boost::exception的 get_error_info介面改變</span></b></div><div><br /></div><div>我自己做的logger library會手動去讀取boost::exception的error info</div><div>原本是像底下這樣</div><div><br /></div><div><code>boost::shared_ptr&lt;char const * const&gt; f = boost::get_error_info&lt;boost::throw_file&gt;(ex)</code></div><div><br /></div><div>改成</div><div><br /></div><div><code>const boost::throw_file::value_type* f = boost::get_error_info&lt;boost::throw_file&gt;(ex)</code></div><div><br /></div><div><br /></div><div><b><span class="Apple-style-span">3. binary archive bug</span></b></div><div><br /></div><div>之前的boost 1.38版本的binary_iarchive是version 5的，現在到boost 1.45該class也更新到version 8</div><div>更新是沒什麼關係，只要有相容舊版的就好，悲劇的就是他不相容... T____T</div><div>想一想，這種大型又多人使用的library，在檔案處理上不相容舊版，怎麼想都沒道理啊</div><div>於是我就去trace底層的程式碼，並且和boost 1.38版的程式對照，終於讓我發現bug了</div><div><br /></div><div><span class="Apple-style-span"><br /></span></div><div>開啟boost/archive/basic_binary_iarchive.hpp並找到</div><div><br /></div><div></div><div><code>void load_override(version_type &amp; t, int version){<br /> library_version_type lvt = this-&gt;get_library_version();<br /> if(boost::archive::library_version_type(7) &lt; lvt){<br /> this-&gt;detail_common_iarchive::load_override(t, version);<br /> }<br /> else<br /> if(boost::archive::library_version_type(6) &lt; lvt){<br /> uint_least16_t x=0;<br /> * this-&gt;This() &gt;&gt; x;<br /> t = boost::archive::version_type(x);<br /> }<br /> else{<br /> unsigned int x=0;<br /> * this-&gt;This() &gt;&gt; x;<br /> t = boost::archive::version_type(x);<br /> }<br /> } </code></div><div><br /></div><div>可以發現到，若目前lvt是5的話會執行else那段程序，x 的宣告是unsigned int</div><div><br /></div><div>我們再看一下boost 1.38的該段程式碼</div><div><br /></div><div></div><div><code>void load_override(version_type &amp; t, int){<br /> // upto 255 versions<br /> unsigned char x=0;<br /> * this-&gt;This() &gt;&gt; x;<br /> t = version_type(x);<br /> }</code></div><div><br /></div><div>Oops!!! 同樣是x，可是size不一樣...</div><div><br /></div><div>有問題的還包括 void load_override(class_id_type &amp; t, int version) 這個function</div><div>不知道boost 的issue tracking有沒有登錄這個bug了</div><div><br /></div><div><b><span class="Apple-style-span">4. boost::thread + MFC DLL 問題</span></b></div><div><br /></div><div>基本上這個問題在boost 1.38就有了，但是原因有點年代久遠我也忘光光了... 囧</div><div>只是沒想到更新成boost 1.45後問題還是沒有解決... </div><div><br /></div><div>如果你是使用MFC開發程式 ，又剛好你建立的MFC DLL檔有使用boost::thread，就會發生compile正常但是一執行程式出現ASSERT。</div><div><br /></div><div>解決方法就是到boost/libs/thread/src/win32/tss_pe.cpp裡</div><div>把底下的程式碼註解掉</div><div><code>extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD, LPVOID)=&amp;dll_callback;</code></div><div><br /></div><div>再重新compile boost問題就解決了</div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-2677748595902953232010-06-04T14:44:00.007+08:002010-12-10T21:41:48.960+08:00<code><br />#include &lt;boost/xml_oarchive.hpp&gt;<BR>#include &lt;sstream&gt;<BR>#include &lt;string&gt;<br /><br />int _tmain(int argc, _TCHAR* argv[])<br />{<br />std::stringstream ss;<br /><br />boost::archive::xml_oarchive ar(ss);<br />const std::wstring str = L"測試";<br />ar &amp; boost::serialization::make_nvp("str", str);<br /><br />return 0;<br />}<br /></string></sstream></boost></code><br /><br />上面這一段程式碼，在debug模式下會出現assert。<br />這時候將str稍微改一下就正常了。<br /><br /><code><br />#include &lt;boost/xml_oarchive.hpp&gt;<BR>#include &lt;sstream&gt;<BR>#include &lt;string&gt;<br /><br />int _tmain(int argc, _TCHAR* argv[])<br />{<br />std::stringstream ss;<br /><br />boost::archive::xml_oarchive ar(ss);<br />const std::wstring str = L"ABC";<br />ar &amp; boost::serialization::make_nvp("str", str);<br /><br />return 0;<br />}<br /></string></sstream></boost></code><br /><br />主要原因是因為locale的關係，在xml_oarchive寫入資料時會透過wctomb將unicode轉成multibyte，此時因為locale不對造成轉換錯誤，而產生assert。<br />所以只要在使用xml archive前先setlocale就ok了。<br /><br /><code><br />#include &lt;boost/xml_oarchive.hpp&gt;<BR>#include &lt;boost/xml_iarchive.hpp&gt;<BR>#include &lt;sstream&gt;<BR>#include &lt;string&gt;<BR>#include &lt;assert&gt;<br /><br />int _tmain(int argc, _TCHAR* argv[])<br />{<br />std::stringstream ss;<br /><br />{<br /> boost::archive::xml_oarchive ar(ss);<br /> const std::wstring str = L"測試";<br /> ar &amp; boost::serialization::make_nvp("str", str);<br />}<br /><br />{<br /> boost::archive::xml_iarchive ar(ss);<br /> std::wstring str;<br /> ar &amp; boost::serialization::make_nvp("str", str);<br /> assert(str == L"測試");<br />}<br /><br />return 0;<br />}<br /></assert></string></sstream></boost></boost></code><br /><br /><span style="font-weight:bold;">不過，比較好的做法是存檔時先將wchar_t轉成utf-8再交給xml archive，讀檔時再把utf-8轉成wchar_t</span>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-73275758403552974512010-03-18T14:55:00.005+08:002010-03-18T15:26:17.650+08:00最近習慣為每個模組加上namespace，享受namespace帶來的設計概念，但是也遇到了namespace的分類問題，常常namespace分得不夠好且使用起來也不方便，主要是我對於我的code的模組有時候分得不夠清楚，都是是在錯誤中學習，將1個模組拆成2個又將2個合併為1個，花了很多時間在這方面... 囧<br /><br />後來大概上網看了一下，一直在想<a href="http://www.boost.org/doc/libs/1_42_0/libs/tuple/doc/design_decisions_rationale.html">boost::tuple的命名概念</a>，我想我以後再設計namespace時就按照這個一般的原則執行就好了。<br /><blockquote>The common principle is that domain libraries (like <i>graph</i>, <i>python</i>) should be on a separate subnamespace, while utility like libraries directly in the boost namespace.<br /></blockquote>文章中也有提到tuple設計的結果<br /><blockquote>The final (I truly hope so) solution is now to have all definitions in namespace ::boost::tuples, and the most common names in the ::boost namespace as well. This is accomplished with using declarations (suggested by Dave Abrahams): <pre><code>namespace boost {<br />namespace tuples {<br /> ... <br /> // All library code<br /> ...<br />}<br />using tuples::tuple;<br />using tuples::make_tuple;<br />using tuples::tie;<br />using tuples::get;<br />}<br /></code></pre></blockquote>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-5011545482449872852010-03-17T18:55:00.003+08:002010-03-17T19:03:10.840+08:00我在管理工作上，一直都做得不是很好，想了一想大概是底下幾個問題<br /><ol><li>時間管理不好，因為自己還是要寫code，專心的時候就不想要去處理別人的問題，導致即使自己的code有準時完成，但是多數人卻因為問題delay了，整個部分的績效及產品的研發速度很差。</li><li>好好先生，我可能想要去當每個人的好朋友，或是不想要給每個人太大壓力，導致最後累的是自己，也許有一天自己也不想給自己壓力了吧。<span class="status-body"><span class="entry-content">今天你不操死他們，有一天你就會被他們操死！<br /></span></span></li></ol>好吧，加油吧，別人的問題優先處理，寧願當個壞人也不要當個讓部門擺爛的好人。<br />基本上我只是很小很小咖的角色，我是非常希望我頭頭也有這種體會，讓整個研發團隊更厲害。<br /><br />------<br /><br />囧，上一篇blog文章是去年的這個時候了，我實在有夠懶...高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-9480796538544217522009-06-15T13:51:00.002+08:002009-06-15T13:54:06.278+08:00最近都忙得沒時間更新blog了... 一些文章也只寫了一半就停了...<br />等6月底趕完這一支程式，希望狀況會好一點...<br /><br />不過，被人瞧不起還挺火大的，只能用實力來讓你閉嘴了... \_/高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0tag:blogger.com,1999:blog-4349087864754484835.post-85931148926288236722009-04-08T19:29:00.004+08:002009-04-08T19:51:53.694+08:00我每次在release程式時，因為主程式的版本變動了，相對的我必需跟著修改Inno Setup script的程式版本<br />[Setup]<br />AppVersion = 1.2.3.4<br /><br />這樣的做法容易會有疏失，Inno Setup script裡面常常會有4、5個地方寫著版本訊息，每次release就全部都要修改，漏改一項麻煩就大了，後來上網找了一下資料，原來這個問題可以透過<a href="http://ispp.sourceforge.net/">ISPP(<em>Inno Setup</em> Preprocessor)</a>來處理。<br /><br />#define AppName "YourApp"<br />#define AppVersion() ParseVersion(AddBackslash(SourcePath) + "../../bin/release/YourApp.exe", Local[0], Local[1], Local[2], Local[3]), \<br /> str(Local[0]) + "." + str(Local[1]) + "." + str(Local[2]) + "." + str(Local[3])<br /><br />[Setup]<br />AppName={#AppName}<br />AppVerName={#AppName} {#AppVersion}<br />AppVersion={#AppVersion}<br /><br />使用以上的語法可以自動取得執行檔的版本，不需要每次都手動修改，以後當我們在release程式也更方便。<br /><br /><br />Note:<br /><ol><li>ISPP是Inno Setup的額外套件，包含在<a href="http://www.jrsoftware.org/isdl.php#qsp">Inno Setup QuickStart Pack</a>裡，必需要先安裝完<a href="http://www.jrsoftware.org/isinfo.php">Inno Setup</a>主程式再安裝Inno Setup QuickStart Pack.</li></ol>高橋旺http://www.blogger.com/profile/12842354151506123772noreply@blogger.com0