星期日, 8月 22, 2010
星期三, 8月 18, 2010
TM營收
以上資料來自http://us.trendmicro.com/us/about/financeinfo/reports_presentations/index.html
我不是會計專家，對於財報我只知道net income越高越好XD
從2008，2009到今年2010 Q2來看，難怪股價會越來越低...
這是要怪經營者還是要怪員工？ 若是50人以下的小公司，每年營收越來越低的話，我想員工關係可能不小，但是若是一個4000人以上的大公司...
星期五, 8月 13, 2010
星期四, 8月 05, 2010
星期一, 8月 02, 2010
約耳趣談軟體 - 附錄
本書最後有讀者問了如何估計軟體開發時程，我簡單節錄約耳的回答：
如果估計的是已經細分過的任務(每個任務長度最長是一天，否則必須再細分下去)，而且評估者要有足夠的經驗，能在估計時間內包含一切(假期、整合時間、「新功能」時間、參加愚蠢經營會議的時間、面試的時間...等)，那只需要10%的緩衝時間。
但這段緩衝時間只是讓自己心安的做法，應該要根據各種類型的緩衝，還有事情的緩急來分配時間，例如：
1. 開發過程中想到的預期外的功能，針對這些新功能的緩衝時間。
2. 由於競爭者做了某些事，為了因應競爭者所需的緩衝時間。
3. 整合各個開發者所寫的程式碼，讓結果正確運行的緩衝時間(依經驗可以是從25%~100%)
4. 在測試時發現問題並修正的緩衝時間。
5. 員工必須執行開發之外的工作，例如：training課程、公司緊急會議、火警演習、準備老闆生日蛋糕...等。
6. 預防發展不順利時的緩衝時間。
7. 因應估計時漏列事項的緩衝時間。
我之前待的TM公司，manager們在列tasks時就已經常常漏列許多tasks了，也沒有在估計"整合"的時間，也常常有高層想到新的東西就硬要加進來做，當然也沒有估計過會議等雜事的時間...
不過我想犯的最大錯誤可能是讓"沒有經驗"的人來評估時程...總之一個佔公司快一半營業額的產品就這樣被搞得亂七八糟，我想過不用多久，大家就會知道了。
如果估計的是已經細分過的任務(每個任務長度最長是一天，否則必須再細分下去)，而且評估者要有足夠的經驗，能在估計時間內包含一切(假期、整合時間、「新功能」時間、參加愚蠢經營會議的時間、面試的時間...等)，那只需要10%的緩衝時間。
但這段緩衝時間只是讓自己心安的做法，應該要根據各種類型的緩衝，還有事情的緩急來分配時間，例如：
1. 開發過程中想到的預期外的功能，針對這些新功能的緩衝時間。
2. 由於競爭者做了某些事，為了因應競爭者所需的緩衝時間。
3. 整合各個開發者所寫的程式碼，讓結果正確運行的緩衝時間(依經驗可以是從25%~100%)
4. 在測試時發現問題並修正的緩衝時間。
5. 員工必須執行開發之外的工作，例如：training課程、公司緊急會議、火警演習、準備老闆生日蛋糕...等。
6. 預防發展不順利時的緩衝時間。
7. 因應估計時漏列事項的緩衝時間。
我之前待的TM公司，manager們在列tasks時就已經常常漏列許多tasks了，也沒有在估計"整合"的時間，也常常有高層想到新的東西就硬要加進來做，當然也沒有估計過會議等雜事的時間...
不過我想犯的最大錯誤可能是讓"沒有經驗"的人來評估時程...總之一個佔公司快一半營業額的產品就這樣被搞得亂七八糟，我想過不用多久，大家就會知道了。
約耳趣談軟體 - 書中的好文節錄 part 2
軟工以及軟體公司的管理真的是很有趣的東西，PC畢竟出現時間還不長，還沒有經過時間磨練的大規模商業及管理研究，因此要從別人研究或是經驗裡學到大型軟體開發及管理實在不易。約耳這本書道出許多軟體開發及管理上的許多「事實」，真的是一本每位軟體從業人員必讀的好書。
繼續節錄裡面一些「中肯」到不行的段落。
1. 客戶不知道他們要什麼。別再期望客戶知道他們要什麼。
2. 重要推論一：把使用介面的畫面展示給非程式人員看時，如果這個介面很不好，對方會認為你整個程式也是很不好的。
3. 重要推論二：把使用介面的畫面展示給非程式人員看時，如果這個介面非常漂亮，對方會認為這個程式幾乎已經完工。
4. 重要推論四：因為政治因素要求由各技術經理或客戶「啟動」專案時，可以提供數種美術設計讓他們選擇。
改變某些元件的擺設方式，改變外觀和字型，移動標誌位置，標誌也可以變大或變小。拿些無關緊要的家家酒內容給他們玩，讓他們覺得自己很重要。這些他們就不會嚴重影響你的時程了。
5. 至少要有一個對所用的語言、類別、API以及平台有數年以上經驗的設計者，否則還是不要啟動專案吧。如果你可以選擇平台，就用你的團體最熟悉的吧，即使這個平台並不是最符合趨勢或看起來最有生產力也沒關係。另外在設計抽象機制或程式設計工具時，多做些努力讓它不會漏吧。
6. 經理人喜歡施行測量系統，而且喜歡把它和獎懲方案綁在一起。不過只要沒有百分之百的監督，工作人員就有誘因來個「下有對策」，心裡只想著那個測量系統，完全不顧工作的實際價值或品質。
7. 軟體組織通常會獎勵(a)寫大量程式以及(b)修正大量問題的程式師。想在這種組織中出頭，最好的方法就是寫一大堆錯誤百出的程式之後再全部修好，而不是多花些時間在一開始就把東西做好。
8. 除非有個程式師掌舵，否則沒有軟體公司會成功的
9. 我並不是說這是我離開Juno的原因，不過它的確解釋了我離開Juno(約耳的前公司)的理由：不管你多麼努力工作又有多聰明，也不管你是否在「負責」，你對再微小不過的事都沒有權力。把你該死的點子訓練以及聰明睿智放一邊，把那些讓我們付錢請你的一切東西通通都丟到一邊吧。而且Juno的經理很多，大概佔總員工四分之一，所以他們有的是時間可以到處亂伸手指，確定他們能掌控。在微軟卻是副總自己從九號大樓出來找你，確定你有權力能把事做完。這對比還真是強烈啊。
10.
A. 有些事需要天份才做得好。
B. 天份很難複製。
C. 有人嘗試複製天份，要有天份的人建立規則讓普通人照著做。
D. 結果所得到的產品品質很低。
「訓練」並不真的能產生一致的結果。
小心方法論。方法論可以讓每個人的表現都提升到不佳但可接受的程度，不過同時也會產生很多約束而激怒更多的聰明人。
11. 事實上如果你曾經把很關鍵的業務拿去外包，就會瞭解外包其實是個地獄。不能直接控制客戶服務，客服就會爛到不像話，爛到像某人在網誌上寫的，想在電話公司找個人(任何人都好)去做些最最簡單的事都辦不到。
12. 如果是核心的事業功能，不管是什麼都要自己來做。
13. 在開始行銷你的「精簡」產品時，你會告訴大家：「嘿，這東西很小，只佔1MB。」大家通常都會很高興，然後就會問你有沒有他們要的重要功能，如果沒有的話還是不會買你的產品。
14. 聰明的公司試圖讓產品的互補物普及化(commoditize)。(例如，PC硬體與軟體是互補物，PC如果賣得好，隨之軟體也會賣得好，virus與防毒軟體或許也稱的上是互補物XD)
15. 無法獲得開發者尊重的產品經理沒有作用，因為他們只會一事無成。當我還在Excel團隊時，開發者會把沒有技術底子的產品經理當作早餐吃掉。
16. 產品經理最重要的技能，就是把自己的想法塞進軟體開發人員腦子裡，讓開發人員以為是自己的點子，然後乖乖照著做。
繼續節錄裡面一些「中肯」到不行的段落。
1. 客戶不知道他們要什麼。別再期望客戶知道他們要什麼。
2. 重要推論一：把使用介面的畫面展示給非程式人員看時，如果這個介面很不好，對方會認為你整個程式也是很不好的。
3. 重要推論二：把使用介面的畫面展示給非程式人員看時，如果這個介面非常漂亮，對方會認為這個程式幾乎已經完工。
4. 重要推論四：因為政治因素要求由各技術經理或客戶「啟動」專案時，可以提供數種美術設計讓他們選擇。
改變某些元件的擺設方式，改變外觀和字型，移動標誌位置，標誌也可以變大或變小。拿些無關緊要的家家酒內容給他們玩，讓他們覺得自己很重要。這些他們就不會嚴重影響你的時程了。
5. 至少要有一個對所用的語言、類別、API以及平台有數年以上經驗的設計者，否則還是不要啟動專案吧。如果你可以選擇平台，就用你的團體最熟悉的吧，即使這個平台並不是最符合趨勢或看起來最有生產力也沒關係。另外在設計抽象機制或程式設計工具時，多做些努力讓它不會漏吧。
6. 經理人喜歡施行測量系統，而且喜歡把它和獎懲方案綁在一起。不過只要沒有百分之百的監督，工作人員就有誘因來個「下有對策」，心裡只想著那個測量系統，完全不顧工作的實際價值或品質。
7. 軟體組織通常會獎勵(a)寫大量程式以及(b)修正大量問題的程式師。想在這種組織中出頭，最好的方法就是寫一大堆錯誤百出的程式之後再全部修好，而不是多花些時間在一開始就把東西做好。
8. 除非有個程式師掌舵，否則沒有軟體公司會成功的
9. 我並不是說這是我離開Juno的原因，不過它的確解釋了我離開Juno(約耳的前公司)的理由：不管你多麼努力工作又有多聰明，也不管你是否在「負責」，你對再微小不過的事都沒有權力。把你該死的點子訓練以及聰明睿智放一邊，把那些讓我們付錢請你的一切東西通通都丟到一邊吧。而且Juno的經理很多，大概佔總員工四分之一，所以他們有的是時間可以到處亂伸手指，確定他們能掌控。在微軟卻是副總自己從九號大樓出來找你，確定你有權力能把事做完。這對比還真是強烈啊。
10.
A. 有些事需要天份才做得好。
B. 天份很難複製。
C. 有人嘗試複製天份，要有天份的人建立規則讓普通人照著做。
D. 結果所得到的產品品質很低。
「訓練」並不真的能產生一致的結果。
小心方法論。方法論可以讓每個人的表現都提升到不佳但可接受的程度，不過同時也會產生很多約束而激怒更多的聰明人。
11. 事實上如果你曾經把很關鍵的業務拿去外包，就會瞭解外包其實是個地獄。不能直接控制客戶服務，客服就會爛到不像話，爛到像某人在網誌上寫的，想在電話公司找個人(任何人都好)去做些最最簡單的事都辦不到。
12. 如果是核心的事業功能，不管是什麼都要自己來做。
13. 在開始行銷你的「精簡」產品時，你會告訴大家：「嘿，這東西很小，只佔1MB。」大家通常都會很高興，然後就會問你有沒有他們要的重要功能，如果沒有的話還是不會買你的產品。
14. 聰明的公司試圖讓產品的互補物普及化(commoditize)。(例如，PC硬體與軟體是互補物，PC如果賣得好，隨之軟體也會賣得好，virus與防毒軟體或許也稱的上是互補物XD)
15. 無法獲得開發者尊重的產品經理沒有作用，因為他們只會一事無成。當我還在Excel團隊時，開發者會把沒有技術底子的產品經理當作早餐吃掉。
16. 產品經理最重要的技能，就是把自己的想法塞進軟體開發人員腦子裡，讓開發人員以為是自己的點子，然後乖乖照著做。
約耳趣談軟體 - 書中的好文節錄 part 1
今天把這本書看完了，節錄一些我覺得不錯的片段下來
1. 在很多程式開發組織中，出現設計爭議時，總沒有人願意做出決策(通常都是因為一些「政治理由」)，所以開發人員只去做那些沒有爭議的項目。
2. 當你和整組人一起建立產品時，通常每個人都會各有所好，因而產生各式各樣真正或虛構的必備心愛功能，如果要將這些功能全部都做出來，恐怕永遠做不完而且要花很多很多的錢。所以你必須馬上開始刪功能，而刪功能的最佳方法就是利用規格的「非目標」章節，列出我們不打算做的東西。
3. 1980年代當微軟開始快速成長時，那裡每個人都讀過The Mythical Man-Month(人月神話，這本中文版出很久了)這本軟體管理經典。這本書的主要重點是說，在進度落後的專案中增加更多程式員，只會讓進度更加落後。這是因為當團體中有n個程式師時，溝通路徑的數量會變成n(n-1)/2，也就是以O(n^2)增加。
4. 不要把程式員升為程式經理。良好程式經理所需的技能(撰寫清楚的文章，外交手腕，對市場的察覺，對使用者的認同以及良好的使用介面設計)幾乎都不是良好程式員所需的。當然有人兩者都行，不過少之又少。
5. 別讓程式人員對程式經理報告。這是很微妙的錯誤。我在微軟當程式經理時設計了Excel的Visual Basic(VBA)策略，並且訂出涵蓋最微小細節的完整規格，詳細敘述應該如何在Excel裡實作VBA。我的規格大約有500頁。在Excel 5.0開發的巔峰時期，我估計每天早上有250人來上班，主要任務就是要實作我寫的這份龐大規格。我完全不知道這些人是誰，不過Visual Basic組就有十幾個人光是在寫這玩意的文件(更不用提寫Excel的文件或是全職負責說明檔內超連結的人了)。不過最誇張的是我位在這層層結構的「底層」。沒錯。沒有人要向我報告。如果想讓大家去做某件事，我必須說服他們這件事該做。當主開發師Ben Waldman不想做我規格定義的某個項目，他跳過不做就好了。當測試人員報怨規格中某個項目不可能做完整的測試，我就得去把這個項目簡化。如果這些人得向我報告，產品可能不會這麼好。...凝聚共識的決策型式卻是做對事的最好方法。
6. 當你一直往上把事情弄得太抽象，就會像上太空一樣沒有氧氣。有時候這些聰明的思想家就是停不下來，然後就創造出這些荒唐又無所不包的高層次宇宙景像，這些東西什麼都好，就是完全沒有實際的意義。
這種人我稱之為架構太空人。要他們寫程式或設計程式是難上更難，因為他們沒法子不想架構。叫太空人是因為他們活在氧氣層之上，我不知道這些人是怎麼呼吸的。他們通常在真正的大公司上班，只要這種公司才養得起大批不事生產，完全沒有貢獻的高學歷份子。
7. Alfie Kohn在哈佛商業評論中一篇已成為經典的文章中寫道：
過去三十年間至少有兩打以上的研究明確地指出，為了報酬而工作的人，表現不如完全不期望有報酬的人。
他的結論是「激勵(或者說賄賂)在職場上是行不通的」。DeMarco和Lister更進一步明白地表示，任何型式的職場競爭及獎懲方案，包括以前流行那種「在某人做對事時馬上獎勵」的把戲，所帶來的傷害都大過好處。給某些人正面激勵 (比如愚蠢的公開頒獎儀式)暗示他們其實只是為了拿那個壓克力獎牌才有表現；也暗示他們在工作上不夠獨立，要有甜頭才會努力；這實在是既侮辱又貶低人格。
8. QA的主管應該有否定權，可以阻止發行不合格的軟體。
9. 就個人層次來說，你曾經注意過某件事嗎？叫某人做一個工作可以做得很好，可是如果給他兩個工作，他會把其中一個做好卻忽略另一個，不然就是兩件工作都做得很慢，慢到你覺得懶鬼都比他勤勞。這是因為程式設計的工作就是需要很長的切換時間。
10. Netscape 6.0第一個公開的beta版終於出來了。5.0版從來沒出現過，最後一版重大改版是大約三年前發行的4.0版。在Internet世界裡三年的時間長得可怕。就在這段時間中，Netscape只能無望地坐看市場佔有率直線下降。...他們做了一個每家軟體公司都可能犯的一個最糟的策略錯誤：
他們決定把程式從頭重寫過。
11. 讀程式比寫程式困難
12. 新程式碼比舊程式碼好的想法顯然是很荒唐的。舊程式碼已經被用過也被測試過。很多問題都已被找出來並被修好。它並沒有什麼問題，不會因為在你的硬碟裡放久了就生出新的問題。...當你把程式碼丟掉從頭重寫時，其實是把這所有的知識都丟掉了。這所有已修正的問題，好幾年的寫程式的成果。...你會讓出市場領導地位。你會把兩三年的時間當禮物送給競爭者。相信我，軟體的一年可是很長的。...你會讓自己陷入一個極端危險的位置，到時候會有很多年都只能發行舊版程式，完全無法因應市場需求的新功能而改變策略，因為你沒有可以發行的程式。這段時期最好還是把公司收起來算了。...你會浪費大量的資金去撰寫已有的程式。
13. 你一定要記住，在要從頭重新開始時，完全沒有理由相信這次會做得比第一次好。首先你的程式團隊根本不可能和當初相同，所以並不會真的有「更多的經驗」。你其實只會把大部份的舊錯重新再犯一次，另外再多加一些舊版本沒有的新問題。
這本書實在是太精采了，一堆名言，下篇待續。
1. 在很多程式開發組織中，出現設計爭議時，總沒有人願意做出決策(通常都是因為一些「政治理由」)，所以開發人員只去做那些沒有爭議的項目。
2. 當你和整組人一起建立產品時，通常每個人都會各有所好，因而產生各式各樣真正或虛構的必備心愛功能，如果要將這些功能全部都做出來，恐怕永遠做不完而且要花很多很多的錢。所以你必須馬上開始刪功能，而刪功能的最佳方法就是利用規格的「非目標」章節，列出我們不打算做的東西。
3. 1980年代當微軟開始快速成長時，那裡每個人都讀過The Mythical Man-Month(人月神話，這本中文版出很久了)這本軟體管理經典。這本書的主要重點是說，在進度落後的專案中增加更多程式員，只會讓進度更加落後。這是因為當團體中有n個程式師時，溝通路徑的數量會變成n(n-1)/2，也就是以O(n^2)增加。
4. 不要把程式員升為程式經理。良好程式經理所需的技能(撰寫清楚的文章，外交手腕，對市場的察覺，對使用者的認同以及良好的使用介面設計)幾乎都不是良好程式員所需的。當然有人兩者都行，不過少之又少。
5. 別讓程式人員對程式經理報告。這是很微妙的錯誤。我在微軟當程式經理時設計了Excel的Visual Basic(VBA)策略，並且訂出涵蓋最微小細節的完整規格，詳細敘述應該如何在Excel裡實作VBA。我的規格大約有500頁。在Excel 5.0開發的巔峰時期，我估計每天早上有250人來上班，主要任務就是要實作我寫的這份龐大規格。我完全不知道這些人是誰，不過Visual Basic組就有十幾個人光是在寫這玩意的文件(更不用提寫Excel的文件或是全職負責說明檔內超連結的人了)。不過最誇張的是我位在這層層結構的「底層」。沒錯。沒有人要向我報告。如果想讓大家去做某件事，我必須說服他們這件事該做。當主開發師Ben Waldman不想做我規格定義的某個項目，他跳過不做就好了。當測試人員報怨規格中某個項目不可能做完整的測試，我就得去把這個項目簡化。如果這些人得向我報告，產品可能不會這麼好。...凝聚共識的決策型式卻是做對事的最好方法。
6. 當你一直往上把事情弄得太抽象，就會像上太空一樣沒有氧氣。有時候這些聰明的思想家就是停不下來，然後就創造出這些荒唐又無所不包的高層次宇宙景像，這些東西什麼都好，就是完全沒有實際的意義。
這種人我稱之為架構太空人。要他們寫程式或設計程式是難上更難，因為他們沒法子不想架構。叫太空人是因為他們活在氧氣層之上，我不知道這些人是怎麼呼吸的。他們通常在真正的大公司上班，只要這種公司才養得起大批不事生產，完全沒有貢獻的高學歷份子。
7. Alfie Kohn在哈佛商業評論中一篇已成為經典的文章中寫道：
過去三十年間至少有兩打以上的研究明確地指出，為了報酬而工作的人，表現不如完全不期望有報酬的人。
他的結論是「激勵(或者說賄賂)在職場上是行不通的」。DeMarco和Lister更進一步明白地表示，任何型式的職場競爭及獎懲方案，包括以前流行那種「在某人做對事時馬上獎勵」的把戲，所帶來的傷害都大過好處。給某些人正面激勵 (比如愚蠢的公開頒獎儀式)暗示他們其實只是為了拿那個壓克力獎牌才有表現；也暗示他們在工作上不夠獨立，要有甜頭才會努力；這實在是既侮辱又貶低人格。
8. QA的主管應該有否定權，可以阻止發行不合格的軟體。
9. 就個人層次來說，你曾經注意過某件事嗎？叫某人做一個工作可以做得很好，可是如果給他兩個工作，他會把其中一個做好卻忽略另一個，不然就是兩件工作都做得很慢，慢到你覺得懶鬼都比他勤勞。這是因為程式設計的工作就是需要很長的切換時間。
10. Netscape 6.0第一個公開的beta版終於出來了。5.0版從來沒出現過，最後一版重大改版是大約三年前發行的4.0版。在Internet世界裡三年的時間長得可怕。就在這段時間中，Netscape只能無望地坐看市場佔有率直線下降。...他們做了一個每家軟體公司都可能犯的一個最糟的策略錯誤：
他們決定把程式從頭重寫過。
11. 讀程式比寫程式困難
12. 新程式碼比舊程式碼好的想法顯然是很荒唐的。舊程式碼已經被用過也被測試過。很多問題都已被找出來並被修好。它並沒有什麼問題，不會因為在你的硬碟裡放久了就生出新的問題。...當你把程式碼丟掉從頭重寫時，其實是把這所有的知識都丟掉了。這所有已修正的問題，好幾年的寫程式的成果。...你會讓出市場領導地位。你會把兩三年的時間當禮物送給競爭者。相信我，軟體的一年可是很長的。...你會讓自己陷入一個極端危險的位置，到時候會有很多年都只能發行舊版程式，完全無法因應市場需求的新功能而改變策略，因為你沒有可以發行的程式。這段時期最好還是把公司收起來算了。...你會浪費大量的資金去撰寫已有的程式。
13. 你一定要記住，在要從頭重新開始時，完全沒有理由相信這次會做得比第一次好。首先你的程式團隊根本不可能和當初相同，所以並不會真的有「更多的經驗」。你其實只會把大部份的舊錯重新再犯一次，另外再多加一些舊版本沒有的新問題。
這本書實在是太精采了，一堆名言，下篇待續。
訂閱：
文章 (Atom)