[文章] 股票投資重點收錄

以下是個人觀看投資書時，覺得重要的內容，把它記錄於此，因為是初學者，所以都記錄一些基本中的基本~

一定要有自已的停損點，且遇到一定要捨得賣掉 !

進入市場之前要先做的一件事就是：判斷現在是多頭還是空頭。如果是空頭就別進場，多頭才能進場。如何判斷? 用季線(60MA)幫助判斷。確認是多頭以後，進場選股，選股最簡單的就是挑帶量長紅的股票買進，這種股票上漲機率大。進場以後就用停損點移動法操作。

推薦網站：
WantGoo玩股網：有豐富的即時資訊，其中的俏祕書功能，更是選股的好幫手~
除權除息表：可查詢年度的除權除息日，一般來說，在除權除息日前一天還有紅K時，代表能買進。
台股觀測站：除了股票的資訊外，還有期貨、外匯等資訊，個人滿喜歡其中的類股總覽功能。

找到正在起漲點的股票方法：
爆量長紅+突破盤整區間
爆量長紅+突破季線
連續爆量長紅

基本面分析：
(1)每年營收都增加。
(2)每年營收都增加，而且增加速度越來越快。
(3)營收收增加，而且淨利增加。
(4)毛利不要太低，也就是不賺辛苦錢。
(5)由虧轉盈。

可以把閒置資金分成三等分：
第一分買台灣50，它是多頭時必買的股票之一。
第二分買定期股，建議買中鋼(25元以下買)和中華電信(60元以下買)，買了不用賣。
第三分買強勢股，找法是先確認哪一類股的漲勢最強，再從中找出哪一支大盤漲時它漲更多，大盤跌時它跌更少的。

評估是否該換股的3個指標：
(1)當大盤累計漲幅超過3%，手上持股卻原地踏步。
(2)當個股跌破停損，但是大盤還在多頭時。
(3)個股表現，明顯弱於同類型股票時。

黃金交叉：
上升中的短期移動平均線(MA)由下而上穿過上升的長期移動平均線(MA)。
死亡交叉：
下降中的短期移動平均線(MA)由上而下穿過下降的長期移動平均線(MA)。

應用均線，判讀盤勢強弱：
日均5MA、10MA：用於分析短期走勢。
日均30MA、60MA：用於分析中期走勢。
日均125MA、250MA：用於分析中長期走勢。(不建議，因為資訊太久以前的了)

應用平均線買進股票的法則：
買進：
(1)移動平均線從長期下降轉為水平，並且有改變移動方向往右上方移動。收盤價從平均價的下方向上方移動與平均線相交，並超越平均線。
(2)收盤價在平均線上方變動。雖然出現回跌，但並沒有跌破平均線，又回頭上升。
(3)收盤價曾一度跌至平均線下方，但平均線保持上升趨勢。
(4)收盤價在平均線上方運動，突然暴跌，距離平均線很遠，這是賣超現象。
賣出：
(1)股價在平均線上方運動，並呈現上升趨勢，離平均線愈來愈遠，表明近期內買入者都已獲利，隨後會有獲利回吐。
(2)移動平均線由向上逐漸轉為水平，並且呈下降趨勢，股價從平均價的上方與平均線相交後，跌至平均線下方。
(3)收盤價在平均線下方移動，反彈時沒能漲破平均線，且平均線正趨於下降。
(4)股價在平均線附近徘徊，平均線正呈明顯的下降趨勢。

1-2-3進擊戰法：多頭、空頭都適用的超強進擊戰法
只有完整經過下列3階段挑選出來的股票，才是完全符合1-2-3進擊戰法的股票。
(1)K線(價格線)原本處空方排列，突然發動強力的漲勢，拉出一根紅K，並第1次攻入10MA，雖然已經打好了第1支腳，但先以反彈視之，並記1次成功，先不要急著入市，等待再次確認。(若10MA仍處跌勢，未能走平，此時就不算。)
(2)此時因季線仍處跌勢往下，仍屬空方排列，不過若成功站穩第1支腳，股價開始修正，與前一波低點比較，技術線型大約會花上最少半個月，最多一個月的時間慢慢打底。
(3)打底完成，此時貼緊盯盤，見盤中再次突破10MA，見量就攻，別等待再度出現第2根紅K。

3-5攻擊戰法：
買：3日均價上升、5日均量上升、紅K棒。
賣：3日均價下降、均量縮至5日均量下面、紅K棒。

不蝕本投資術：
假設投資人有100萬，分次進場，先投入10萬本金，第1筆加碼金10萬，第2筆加碼金30萬，第3筆加碼金50萬，依次進場。
10萬本金賺到1.4萬，才進第1筆加碼金，因為(10萬本金+10萬加碼金) X 7% = 1.4萬，如果在第1筆加碼金進場後，賠了7%，那也只是賠了10萬本金賺到的而已，所以不會蝕本。以此類推。


參考來源：楚狂人投資致富SOP、主力作手不願告訴你的操作祕訣、看圖抓飆股(1-2-3進擊戰法)、平民股神教你不蝕本投資術

[文章] 1.01 的法則 v.s. 0.99 的法則

只要你每天都進步 0.01，一年下來就會比剛開始進步非常多，會是一年以前實力的 37 倍 (更精確的說，是 37.783434 倍，1.01^365 = 37.783434)。

相反的，如果每天都比前一天退步 0.01，那麼一年以後，你祇有一年前的 0.03 倍實力 (更精確的說，是 0.025518 倍)。

資料來源：Meme -- 教學與反省

[文章] 丹布朗(Dan Brown)作品簡介

由於達文西密碼一書而讓我開始看丹布朗作者的書，其實早在達文西密碼出版前，他就已出版過三本書，只是沒被注意到而已。

• 數位密碼(1998)
• 天使與魔鬼(2000)
• 大騙局(2001)
• 達文西密碼(2003)
• 失落的符號(2009)

之所以會被他的書吸引，主要是因為他都會在前序告知書中提到的哪些東西或許很不可思議，但都是真的! 例如一些高科技產品、古老集會之類的。

數位密碼

賣點：
電腦科技、國家機密與個人隱私的問題。

感想：
觀眾反應兩極化的一本書。此書提到政府使用科技來竊聽民眾，以及蠕蟲病毒等相關科技產生的問題。對電腦科技不那麼在行或挑剔的讀者，會覺得小說情節緊湊，編碼解碼的對決也很精采! 但多懂一些電腦的人，會發現有一堆不合理的內容。

天使與魔鬼(已拍成電影)

賣點：
科學與宗教的對立衝突。

感想：
書中提到反物質，一種比核子還能產生更多能量的東西，甚至能用它製造出小型的宇宙，現今科學家也還在努力研究它，而製造反物質的「歐洲核子研究組織」（CERN），也是Internet的發明單位，CERN 擁有一架新式飛機，可在一小時內從美國波斯頓飛到瑞士日內瓦。

另一個覺得有趣的是對稱文字的藝術，表現出來的文字或圖示，上下左右顛倒後還是會長的一樣。

(WATER)

(EARTH , AIR , FIRE , WATER)

大騙局

賣點：
大量運用科學主題，政治與科學的佳作。

感想：
因為個人對科技產品很感興趣，所以覺得這本書最好看^^

此書提到美國太空總署(NASA)為了取得經費而假造對外太空研究已有相當的進展，開始進行製造假隕石及外太空生物，拿顆石頭模擬隕石表面進入大氣層時受到的高溫灼燒，以及如何從冰山底部挖洞放入隕石，讓外界看起來隕石已經存在很久一樣的假像。

也提到一些高科技產品，例如像蚊子一樣的微型機器人，可以執行監看或暗殺的工作。以及科技武器，它不用子彈，直接吸取地上的雪來當子彈。

微型機器人

達文西密碼(已拍成電影)

賣點：
耶穌結婚生子。

感想：
很喜歡裡面的變位字謎，將一段文字，經過排列後可變成另一個意思，例如：
Oh Draconian devil (阿，嚴峻的魔鬼)  ==>  leonardo da vinci (李奧納多達文西)
Oh lame saint (阿，跛足的聖人)  ==>  the mona lisa (蒙娜麗莎)

失落的符號

賣點：
知性科學。

感想：
強調思維科學，主張人的心靈思維與肉體結合時，將擁有莫大潛力，就像祕密一書提到的一般。只是有點雷聲大雨點小，在翻閱了將近五百頁後，發現失落的符號只是一句話。

書中有提到「給靈魂秤重」，將即將死亡的人放一個可以枰出極細微的艙體裡，等到他斷氣的時候，能發現體重有減輕一點點，那個差額就是靈魂的重量。但由於一個人只能枰一次，所以無法重覆實驗並證明之。

另一個有趣話題是「感覺剝奪艙」，艙裡裝滿了特殊液體，將生物放到此液體裡是不會窒息死亡的。電影《夜魔俠》裡的主角，夜裡就睡在這樣的艙裡。《別鬧了，費曼先生》一書裡也記錄了作者的進艙經驗。

[文章] 哈佛溫德勒（Widener）圖書館的訓誡

哈佛的溫德勒（Widener）圖書館有二十則訓誡，它有一段不同尋常的來歷。

捐贈者Widener是一位富家子弟的母親，兒子酷愛讀書，可惜不幸在著名的鐵達尼號遇難，母親為紀念兒子而捐款建造。


1. This moment will nap, you will have a dream; But this moment study, you will interpret a dream.
此刻打盹，你將做夢；此刻學習，你將圓夢。

2. I leave uncultivated today, was precisely yesterday perishes tomorrow which person of the body implored.
我荒廢的今日，正是昨日殞身之人祈求的明日。

3. Thought is already is late, exactly is the earliest time.
覺得為時已晚的時候，恰恰是最早的時候。

4. Not matter of the today will drag tomorrow.
勿將今日之事拖到明日。

5. Time the study pain is temporary, has not learned the pain is life-long.
學習時的苦痛是暫時的，未學到的痛苦是終生的。

6. Studies this matter, lacks the time, but is lacks diligently.  
學習這件事，不是缺乏時間，而是缺乏努力。

7. Perhaps happiness does not arrange the position, but succeeds must arrange the position.                                                                  
幸福或許不排名次，但成功必排名次。

8. The study certainly is not the life complete. But, since continually life part of - studies also is unable to conquer, what but also can make?  
學習並不是人生的全部。但連人生一部分的學習也無法征服，還能做什麼？

9. Please enjoy the pain which is unable to avoid.                            
請享受無法迴避的痛苦。

10. Only has compared to the others early, diligently, can feel the successful taste.
只有比別人更早、更勤奮的努力，才能嘗到成功的滋味。

11. Nobody can casually succeed, it comes from the thorough self-control and the will.
誰也不能隨隨便便成功，它來自徹底的自我管理和毅力。

12. The time is passing.                                                
時間在流逝。

13. Now drips the saliva, will become tomorrow the tear.            
現在睡覺流的口水，將成為明天的眼淚。

14. The dog equally study, the gentleman equally plays.        
狗也會學習，紳士也會荒於嬉。

15. Today does not walk, will have to run tomorrow.
今天不走，明天要跑。

16. The investment future person will be, will be loyal to the reality person.
投資未來的人，是忠於現實的人。

17. The education level represents the income.
教育程度代表收入。

18. One day, has not been able again to come.
一天過完，不會再來。

19. Even if the present, the match does not stop changes the page.                
即使現在，對手也不停地翻動書頁。

20. Has not been difficult, then does not have attains.                        
沒有艱辛，便無所獲。


參考來源：人間福報

[文章]正義，一場思辨之旅(Justice - Michael Sandel)

正義，一場思辨之旅(Justice)是哈佛教授 Michael Sandel 的一門課，是哈佛大學有史以來最受歡迎的課程之一。談論正義、平等、民主和公民權，帶您重新審視何謂道德上的正義!

哈佛現已將課程對全世界開放，Youtube影片整理如下：

Class 1 : 福祉、自由、美德 ◎ 三個出發點
Class 2 : 最多數人的最大幸福 ◎ 功利主義
Class 3 : 我身我命歸我有1 ◎ 自由至上主義
Class 4 : 我身我命歸我有2 ◎ 自由至上主義
Class 5 : 募兵制與代理孕母 ◎ 市場的角色
Class 6 : 人權是普世價值 ◎ 康德的自由主義
Class 7 : 為底層爭平等 ◎ 羅爾斯的自由主義
Class 8 : 公平的起點 ◎ 羅爾斯的自由主義
Class 9 : 適才適性適本質1 ◎ 亞里士多德
Class 10 : 適才適性適本質2 ◎ 亞里士多德
Class 11 : 有歸屬就有責任 ◎ 社群主義
Class 12 : 同性婚姻與良好生活 ◎ 公共衛生

另外，在MyOOPS開放式課程也有詳細介紹，也可以到官方網站參與討論和觀看更多影片~

[文章]開源授權規範比較(BSD,Apache,GPL,LGPL,MIT)

現今存在的開源協議很多，而經過Open Source Initiative組織通過批准的開源協議目前有58種（http://www.opensource.org/licenses/alphabetical）。我們在常見的開源協議如BSD, GPL, LGPL,MIT等都是OSI批准的協議。如果要開源自己的代碼，最好也是選擇這些被批准的開源協議。

這裡我們來看四種最常用的開源協議及它們的適用範圍，供那些準備開源或者使用開源產品的開發人員/廠家參考。

BSD開源協議（original BSD license、FreeBSD license、Original BSD license）

BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以"為所欲為",可以自由的使用，修改源代碼，也可以將修改後的代碼作為開源或者專有軟件再發佈。

但"為所欲為"的前提當你發佈使用了BSD協議的代碼，或則以BSD協議代碼為基礎做二次開發自己的產品時，需要滿足三個條件：

如果再發佈的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSD協議。
如果再發佈的只是二進制類庫/軟件，則需要在類庫/軟件的文檔和版權聲明中包含原來代碼中的BSD協議。
不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。
BSD 代碼鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發佈代碼，也允許使用或在BSD代碼上開發商業軟件發佈和銷售，因此是對 商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議，因為可以完全控制這些第三方的代碼，在必要的時候可以修改或者二次開發。

Apache Licence 2.0（Apache License, Version 2.0、Apache License, Version 1.1、Apache License, Version 1.0）

Apache Licence是著名的非盈利開源組織Apache採用的協議。該協議和BSD類似，同樣鼓勵代碼共享和尊重原作者的著作權，同樣允許代碼修改，再發佈（作為開源或商業軟件）。需要滿足的條件也和BSD類似：

需要給代碼的用戶一份Apache Licence
如果你修改了代碼，需要再被修改的文件中說明。
在延伸的代碼中（修改和有源代碼衍生的代碼中）需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明。
如果再發佈的產品中包含一個Notice文件，則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可，但不可以表現為對Apache Licence構成更改。
Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發佈/銷售。

GPL（GNU General Public License）

我們很熟悉的Linux就是採用了GPL。GPL協議和BSD, Apache Licence等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用，但不允許修改後和衍生的代 碼做為閉源的商業軟件發佈和銷售。這也就是為什麼我們能用免費的各種linux，包括商業公司的linux和linux上各種各樣的由個人，組織，以及商 業軟件公司開發的免費軟件了。

GPL協議的主要內容是只要在一個軟件中使用("使用"指類庫引用，修改後的代碼或者衍生代碼)GPL 協議的產品，則該軟件產品必須也採用GPL協議，既必須也是開源和免費。這就是所謂的"傳染性"。GPL協議的產品作為一個單獨的產品使用沒有任何問題， 還可以享受免費的優勢。

由於GPL嚴格要求使用了GPL類庫的軟件產品必須使用GPL協議，對於使用GPL協議的開源代碼，商業軟件或者對代碼有保密要求的部門就不適合集成/採用作為類庫和二次開發的基礎。

其它細節如再發佈的時候需要伴隨GPL協議等和BSD/Apache等類似。

LGPL（GNU Lesser General Public License）

LGPL是GPL的一個為主要為類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的的軟件必須採用GPL協議不同。LGPL允許商 業軟件通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟件的代碼。這使得採用LGPL協議的開源代碼可以被商業軟件作為類庫引用並發布和 銷售。

但是如果修改LGPL協議的代碼或者衍生，則所有修改的代碼，涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協議。因此LGPL協議的開源代碼很 適合作為第三方類庫被商業軟件引用，但不適合希望以LGPL協議代碼為基礎，通過修改和衍生的方式做二次開發的商業軟件採用。

GPL/LGPL都保障原作者的知識產權，避免有人利用開源代碼複製並開發類似的產品

MIT（MIT）

MIT是和BSD一樣寬範的許可協議,作者只想保留版權,而無任何其他了限制.也就是說,你必須在你的發行版裡包含原許可協議的聲明,無論你是以二進制發佈的還是以源代碼發佈的.

轉載自InspireGate派克空間

[文章]為什麼軟體工程無法估算時間？

我們都有這樣的經驗：要開發一個東西，請工程師估算時間，大概要五天。結果過了一個禮拜，東西還沒出來。一問之下，碰到了原先完全沒有預期的情況，否則就是某個套件原來不能這樣用，必須要換一個，否則就是一個莫明的錯誤，找了一個下午還是不知道為什麼。久而久之，工程師開始習慣在回報的時間裡面灌水，預留空間給這些「未知數」，而我們也常常把他們給的時間乘以二，來得到最壞情況的數字。問題是這樣的方法之下，最後整個組織開始習慣用最龜的速度前進，因為估算精準、動作快，在這中間一點好處也沒有。更壞的情況，是叫九個女人去生一個小孩，那才是災難的開始。

為什麼軟體工程無法估算時間？

要了解這件事情發生的原因，你必須要先知道為什麼軟體工程是無法估算時間的。我以前常常喜歡用「常態分布」來解釋軟體工程時間的花費 — 上述的情況，讓大家慢慢從 Average 變成 (Average + 3 STD) 估算，最後平均浪費了 3 STD 的時間 — 不過這只是統計學上的解釋，並不是真正的「原因」。直到我前幾天看到這篇文章：「Why Can’t Developers Estimate Time?」，才給了我超大的一個領悟。(文章有點難，不過英文不錯的人，我鼓勵你們去讀讀。)
作者 Ashley Moran (愛許麗‧莫倫) 說：

我們無法預測軟體開發中每一個項目的時間，是因為這些工作的本質就是「創造新知識」。開發軟體的目的是創造「自動化的流程」，一但目標達到，自動化後的流程就可以重複的被執行，在可預測的時間裡面。所以一個軟體就像是「食譜」一樣，而電腦就是「廚師」，輸入的資料是「食材」，而輸出的資料是「晚餐」。

因此，我們在做的事情是讓未來從不可預測，變得可預測，讓大哥小弟、老爸老媽、只要想煮飯的，人人都可以當食神，給他三十分鐘，都可以弄出一鍋超級無敵海景佛跳牆。所以，「開發食譜」這件事情的本身，是一個創造新知識的過程，時間上當然很難預測。

如何管理

因此，軟體工程用硬體工程的模型去管理，從出發點就是錯誤。一個建築案是先有了「藍圖」，才去估算每個細項需要的時間。當我們在做的是藍圖本身，怎麼能夠沿用他們的模型？如果是這樣，一個創業團隊該如何「管理」開發的時間？
我的答案是你沒辦法 — 你怎麼能夠控制臭蟲什麼時候要出現？但是你可以管理「生產力」，也就是確認團隊總是在高效率的情況下工作，那最後你會得到的是 Average 的工作時間，比起前述 Average + 3STD 快上了 3 STD，這前後有可能就快了 2-3 倍。
而要管理「生產力」，一個現代化的軟體開發團隊，我認為有以下的幾個好工具可以用：

• Pair Programming (兩人小組) — 一個人寫程式常常會有盲點，兩個人一起則可以看到對方遺漏的地方。更重要的是兩個人都會從對方身上學到很多知識和技巧，彼此都會成長。而當兩個人都了解一組程式碼，日後的維護也有了兩個選擇，不會因為一個人請假、離職，這些 code 就變成孤兒。記得給他們兩個鍵盤，實務上這會比鍵盤移來移去有效率。
• Daily Stand-Up Meeting (每日早會) — 每天早上固定開一個快速早會，全部人都站著，每個人依序報告昨天的進度，碰到的問題，和溝通彼此程式間該如何傳遞資料。這讓團隊明確的知道彼此的進度，也省去很多溝通不良的麻煩。
• 高效率的工作環境 — 開放、明亮、舒適的工作環境，或許讓大家換上拖鞋，確認團隊成員們可以取得他們需要的飲料、食物，但是不會吃得過飽、或是喝下過多的咖啡因。當其中一個成員困惑時，確認有人可以幫助他。
• 隨時找得到使用者 — 代表「使用者」的那個人 (通常是 PM)，最好是使用者本身，必須要隨時在現場，幫團隊解釋開發上細節不明確的地方。
• 設定上線時間 — 雖然你沒辦法知道每一個子項目會花的時間，但是你可以設定一個上線的時間，然後所有的人通力合作在那個時間之前，盡可能做出一個可以推出的版本。當然，如果第一個版本推出時你不會覺得丟臉，那就是花了太多的時間。

以上，希望可以幫助你們重新思考軟體開發該如何做，也希望對你們正在做的網站、行動應用有幫助。(當然這不是完整的列表，歡迎大家提出你們喜歡用的工具。）

來源：http://goo.gl/qSm92

[文章]轉載_軟體公司該這樣做：領導你的員工、而非管理他們

過去一段時間，iKala 收了很多履歷，面試了非常多的傑出人才，我發現到一個有趣的現象：「大部分的人都非常害怕公司會對他們不利。」怎麼說呢？許多面試者對於 iKala 的福利都覺得有點驚訝，因為他們之前待過的公司並沒有這樣子在照顧他們，福利內容甚至讓他們有點不安，覺得福利的背後一定隱藏著公司的陰謀，我覺得啼笑皆非。

從傳統電子公司出來的一些面試者，有這種反映出現的比率更高，我其實很好奇到底他們之前是被公司壓榨到什麼程度，以致於他們根本不相信公司會秉持著照顧和培育人才的理念在經營。員工對於企業缺乏信任，雖是全球普遍的現象，但是在台灣，這樣的情形似乎更為嚴重，許多離開工作的人，對於自己的前公司沒一句好話，不是工時長、就是老闆賤，長期下來造成他們心中對於工作型態的刻板印象，認為工作就是這個樣子。

「這群人真的受到很嚴重的心理創傷」我常常在心裡這樣想，這樣子的工作型態，在未來越來越靠腦力競爭的環境，豈能久乎？

軟體公司不能這樣經營
腦力密集的工作者型態，跟勞力密集工作者的型態完全不相同。勞力密集工作者的生產力，基本上是以工時在計算，工時越長，能組裝的零件越多，一翻兩瞪眼；腦力密集的工作者，卻沒有辦法用工時計算生產力。尤其是程式設計師，寫過 code 的人都知道，當你連續的工時拉得越長，你寫出來的 code 就越接近垃圾。等到你明天清醒了，你會很驚訝自己寫出的這堆垃圾，像是前一夜喝醉酒鬧事留下的爛攤子，然後你的隊友或是你自己，要花額外的時間把這些垃圾清掉或是重構 (refactor)，結果整體的生產力，還比不上你早點去睡覺，早點起床後神智清醒的那短短幾個小時。

一個腦力密集的工作者能夠集中意志、進入「flow (心流)」狀態的時間是有限的，「flow」的概念已經反覆被討論，人一旦進入這個狀態，會發現意志極度集中、全世界與你隔絕、甚至於感受不到時間的流逝，在這段時間內，生產力達到顛峰。不過一旦脫離這個狀態，會需要花額外的一些時間才能再次進入，一天之中能維持心流狀態 8 個小時的人，已經算是超人了。開發軟體最重要的是腦袋有沒有清醒，而不是工時夠不夠長。站在經營者的角度，你要確定的是你的員工知道自己在做些什麼，而不是不讓他們回家。有些工程師喜歡晚上夜深人靜的時候拼進度 (我就是其中一個)，有的人喜歡多一些面對面討論、不介意隨時被打斷。身為軟體主管，你得尊重每個人偏好的工作方式，你要做的是訂定清楚的目標和時程，然後隨時審視軟體的品質，至於工程師打算怎麼把東西生出來，是他們自己的事情。我不介意這些 code 是在上廁所的時候、還是乖乖坐在辦公桌前時寫出來的。

領導，而非管理
好的人才並不需要管理，他們需要的是領導，站在領導者的立場，最迫切的三件事情，就是給予好的人才最明確的目標、最大的彈性、和爭取最多的資源。剩下的，好的人才都會自動幫你完成。他們甚至會反過頭來告訴你，什麼是該做，什麼是不該做的。一個好的人才會幫你解決問題，一個不好的人卻會幫你製造更多的問題。如此一來一往，就決定了公司的命運，因此創業的初期，最重要的就是人，天大的 idea，如果你不能一個人完成，你需要的就是最棒的人才，組成一個真的能實現 idea 的團隊。idea 和執行力同樣重要。沒有人能保證任何 idea 一定會成功，但是如果沒把人找好，找到錯的人，失敗的機率鐵定大增。

好的人才最討厭人家管他們。他們自己有企圖心、自律、和執行力，你不用總是拉著他們的小手一同去郊遊，他們會自動把很多事情完成。

領導應該是明顯的，管理應該是隱諱的
軟體人才通常是一群很 free style 的人，但是身為領導者，應該要確實掌握住公司的方向願景，和制訂公司的發展策略，如此可以給公司員工清楚的目標，然後激勵他們，讓他們覺得自己真的是在做很棒的事情，這是領導。相較之下，軟體人才的管理應該建立在「制度」之上，而非建立在諸多「手段」之上。所以我把制度盡量簡化，並且致力於自動化重複性的管理工作，為的是盡量讓員工平常感受不到這些東西，有時間去做真正重要的事情，而非配合公司的重重規定作一些沒有生產力的事情。

「只有管不住自己的人，才需要別人管」，這也同時告訴我們，員工的自律，對於軟體公司是最重要的一個特質。

即使事實如此，很多人打從心底不相信公司可以這樣運作
Google 和許多成功的大公司，都是以這樣的一套哲學在經營公司，主管給予員工充分的自由，去完成訂定的目標。這並不代表放縱員工，而是代表員工必須有高度的「自律」，而不是「他律」去達成目標，因為公司依然存在著有效的淘汰和評量制度，能夠評判每個人的成果，目標沒有達成或是打混摸魚的人，都會攤在眾人眼前，這樣的環境，讓員工擁有高度的自由，但同樣是一個競爭激烈的環境。重要的是，這樣的環境可以讓員工充分發揮創意和獨立思考，用自己的方式去達成目標。軟體的本質本是如此，需要創意和獨立思考，才能創新和創造；也只有用這樣的方式，才能留住你的人才。

全世界都在喊著創新與創造，台灣更是不落人後，許多電子公司想要跨入軟體的領域，政府也拼命喊著文創的口號，要讓台灣成為設計島和創意國。但是這些機構和公司對於軟體公司的文化卻所知不多，也缺乏實踐，結果傳統的硬體文化和軟體文化格格不入，嚴重限制了軟體工程師能發揮的空間，造成軟體業始終沒辦法向上提升。

台灣很多公司普遍認為員工就是該被管，該被公司的重重規範用力綁住，才能為公司帶來生產力，這在軟體公司完全行不通。身為老闆，我們都有一種直覺，認為「員工工時越長，公司越划算」。但是，是時候做出違反直覺的決策了：給你的員工清楚無比的目標和設定公正有效的評量機制，剩下的，就不要管太多了吧。

本文作者為 MMDays 共同創辦人，現任 iKala 執行長，曾任 Google 軟體工程師。

文章轉載自：http://goo.gl/wgahD