[讀書筆記] Peopleware - 第三部 適任的人

由誰來做總比如何去做的影響還要大

管理科學比較關切的是，如何讓老闆扮演好工作中策略家與戰術家的角色，玩這種遊戲不需要考慮人的個性或才華，成功或失敗是取決於在何時、何地部署那些沒有靈魂的人力資源

找到適任的人、讓他們快樂到不想走、放手讓他們發撥

14. 霍布洛爾因素

• 管理一艘橫帆戰艦或船隻，與管理某個公司部門或專案並沒有太大的差異：人員招募、訓練、工作分派、時程規畫，以及戰術支援
• 良才出於天生，而非後天的培養
• 能迅速估量下屬的實力，並明白何時能仰賴這些人，便是霍布洛爾最偉大的才能
• 人通常都不會在一個地方待太久，管理者也缺乏足夠的影響力來改變部屬的天性，假如一開始就不適任，那他將來也不會適任
• 整齊劃一的需要，假然是管理階層缺乏安全感的徵兆
• 熵就是均勻度或相似度，熵值越高，激發能量或執行工作的潛能就越少。就像熱力學所講的，宇宙裡的熵一直持續在增加，而企業的熵也是
• 管理的熱力學第二定律：組織裡的熵一直持續在增加

15. 雇用雜耍小丑

• 面試時，有什麼比要求每個求職者自備一些作品更合理的呢？
• 性向測驗可以量測出不適合之處
• 在健全的組織裡，讓員工經常做些有趣的自我評量是必要的
• 聘雇程序至少應著重某些社會性和人際溝通的特性
• 試鏡
• 你有責任捕捉從主講人眼神裡所散發出來的迷人熱情，那種在你工作中睽違已久的熱情

16. 很高興能待在這裡

• 聘雇一位新人的成本相當於一個半月至兩個月的薪水
• 倘若員工只會待一或兩年，留住優秀人才的唯一辦法就是加速升遷
• 離職率會刺激離職率
• 最優秀的公司本能地會去努力使自己變成最優秀的
• 低流動率公司還有另一項共同特徵，就是廣泛的再訓練

17. 自我修復的系統

• 摒棄雜亂無章又無法控制的自我修復能力，乃是自動化頗為正面的好處
• 假如新系統的運作要視情況應變的成分居多，那麼自動化便是一個錯誤
• 假如高層所給的方向對他們來說沒有意義，那就一點意義也沒有
• 方法論造成文書工作的泛濫，方法的不足，責任感的缺乏，以及士氣全面低落
• 大量的文件只會製造問題，而非解決問題
• 假如按方法論做下去，出了錯，就是方法論的錯，不是人的錯
• 人都希望承擔責任，但必須在多少能掌握自身成功的情況下，他們才願意
• 方法論 - 管理階層認為員工無能，打擊士氣莫過於此
• 惡意的盲從 - 就算明知結果是浪費時間、沒用的產品、無意義的文件，也照做不誤
• 標準 - 經過驗證(內路獲得普遍且成功的證實)，用於執行一項重複性工作的方法
• 統一方法是很好，但不一定要透過方法論來辦到這一點：訓練、工具、同儕審查
• 人們對差異會感到著迷，喜歡專注，對新奇的事物很感興趣，這就叫做霍桑效應 (Hawthorne Effect)

[讀書筆記] Peopleware - 第二部 辦公室環境

為了協助員工投入工作，你必須努力對付有可能阻撓工作的因素

浪費一個工作天的辦法有千萬種，卻沒有任何一個辦法可以重拾一個工作天

7. 傢俱糾察隊

• 改善工作場所是最有助於提升生產力的手段，只要員工被擠在吵雜、無趣、經常被干擾的環境裡，最值得改善的就是工作場所

8.「從早上九點到下午五點根本做不了任何事」

• 所有產業的開發人員普遍存在一項認知，就是「加班是生活的常態」
• 待晚一點、提早上班或在家安靜工作，無一不是對辦公環境的嚴厲控訴
• 具有十年經驗的人，其表現並未優於只有兩年經驗的人。參賽者對自身所使用的語言，若經驗不足六個月，則表現將不如其他人，除此之外，經驗與表現之間沒有任何關聯
• 我們找到對良好績效具正面影響的因素中，有一項是始料未及的：跟你配對的夥伴有很大的關係
• 程式設計師之間存在這種「10比1」生產力差異是可以理解的，同樣，軟體公司也存在著10比1的生產力差異
• 表現較好的人傾向於待在提供了較佳工作場所的公司
• 環境因素：1.你的工作空間有多大？2.夠安靜嗎？3.夠隱密嗎？4.你的電話可以調整為靜音嗎？5.你的電話可以轉由他人接聽嗎？6.同事是否經常非必要地打擾你？

9. 在空間上省錢

• 節省開支 v.s 喪失工作效率的風險

插曲

• 硬科學講求客觀，有非常嚴謹的推理論證，如：物理、化學
• 軟科學比較主觀，解釋彈性很大，如：哲學、社會學
• 任何你需要量化的東西，都能以某種方式進行評量，而且比完全不去評量要強
• 一家無法對自己程式設計生產力進行評量的公司，只是沒有用心去努力嘗試罷了
• 你無法承擔一無所知的後果
• 評量時請閉上眼睛 - 工作評量在改善工作方法、激勵，以及增進工作滿意度上是很有用的工具，不過，一般幾乎都不是為了這些目的，評量機制反倒變得既駭人又沉重

10. 腦力時間與身體時間

• 員工一天之中有30%的時間對噪意很敏感，其餘時間則是噪意的製造者
• 假如他們一週內只有一、兩個小時不受干擾，這並不是他們的錯，而是公司的錯
• 讓你的員工把焦點放在神馳時間的重要性
• E因子 = 不受干擾的時間 / 置身工作環境的時間
• 單一組織的因子數值會隨不同辦公地點而不同

11. 電話

• 頭號問題人物卻往往是管理者 - 「我老闆一外出，就把他的電話轉到我這裡」
• 負責做好工作的人必須享有某種程度的和諧與寧靜，這意味工作時段不宜受到任何干擾
• 為了換取若干不受干擾的腦力時間，大家必須接受每天都有部分時間可被干擾，並同意以合理頻率查看電子郵件 --如，一天三次。

12. 把門找回來

• 面對員工對噪音的不滿，你能做的不是治標，就是治本。 治本 - 牆與門
• 負責數學演算與邏輯的那半邊腦並不會受到音樂的影響 - 負責聽音樂的是另半邊腦
• 但是創音靈感來自於右腦，但假如此時右腦正忙著聽1001首管絃樂，就不會有這種創意靈感了
• 封閉式辦公室不見得就是一人辦公室
• 最佳的管理，應該要確保員工擁有足夠的空間、足夠的安靜、足夠的隱私，以使他們能夠創造出屬於自己的合理工作場所
• 裝設背景音樂或其他形式的粉紅噪音或戴上耳機聽錄音帶，預料都會在員工的工作表現上付出無形的代價：他們將缺乏創意

13. 雨傘步 (辦公空間的永恒之道)

• 若工作場所過於封閉或者暴露，其中的人就無法有效率地工作，好的工作場所應力求平衡，身後有牆的工作場所會讓你感到較為自在，在你前方八呎以內，不該是一道沒有門窗的牆
• 當今的模組化隔板是妥協下的代表作：給你是沒有任何意義的隱私，卻又讓你有被孤立的感覺
• 任何人類團隊要是缺少共同進食的活動，都無法長久共事
• 這些模式既不否認個人的特質，也不否認他希望與其他夥伴有所連繫的傾向，這些模式讓人能夠做他自己
• 根據非複製公式，沒有哪兩個人的工作空間一模一樣，沒有哪兩個咖啡區一模一樣，任何圖書室或休息區也都是如何
• 先判別哪些專案最重要，然後讓這些關鍵專案出走。在企業總部以外進行重要工作通常會有更佳的表現
• 只要你的小組生產力較高，離職率較低，就登明你是一個更優秀的經理人

[讀書筆記] Peopleware - 第一部 管理人力資源

[讀書筆記] Peopleware - 第一部 管理人力資源

只有當你完成一件事之後，才真正知道該如何完成

這些習性非常普遍，而且講得理直氣壯，卻往往是錯誤的

我們大多數人都很容易犯一種特別的毛病：傾向於把人當成零件來管理

1. 當下，有個專案即將失敗

• 倘若你認定某個問題本質上就是政治問題，自然就會對該問題抱持宿命的觀點
• 我們在工作中所面臨的，在本質上，主要都是社會性的問題，而非技術性的問題
• 他們對人的憂慮遠多於對技術的憂慮，但在管理時卻又是另一回事，他們主要關切的還是技術
• 他們永遠在追尋可望讓工作自動化的技術絕招，對於職務中越是以人為主的層面，卻越不關心，這種現象有部分肇因於管理者的養成方式，他們所受的訓練是如何做好工作，而非如何管理工作
• 我們身處的應該是人際溝通產業，工作的成功來自於所有團隊成員的良好人際互動，失敗則肇因於不良的人際互動
• 人際互動很複雜，效果也非三言兩語所能道盡，然而其重要性往往凌駕於其他工作層面

2. 做起司漢堡，賣起司漢堡

• 開發工作在本質上就跟產品製造不同，但從事開發工作的經理人，其思維還是常常承襲了製造業的管理哲學
• 允許犯錯 - 你為禁止犯錯所採取的措施，或許能提升一點點技術水平，但團隊社會學將深受其害
• 管理：膚淺的定義 - 管理就是踢屁股
• 你很少需要採取嚴厲手段才能讓部屬工作下去，因為大部分的人都熱愛他們的工作，甚至你有時還得想辦法讓他們少做一些，以便完成更多有意義的事
• 人力商店 - 因為擔心某位關鍵人物會離開，便強迫自己相信根本沒有關鍵人物這回事
• 對盲目採行製造業管理風格的經理人來說，員工的獨特性一直是很討人厭的事，相反地，真正會用人的經理人則了解，獨特性會讓專案起更活潑而有效的化學作用，是需要培養的東西。
• 處於穩定狀態的專案就是死專案
• 應該把整個專案管理的焦點放在開發工作的動力(dynamics)
• 當我們在評估人對於新專案有多少價值的時候，通常根據的是人的穩定狀態特質：能寫出多少程式，或能產出多少文件。我們鮮少關心每一個個體在融入整個開發工作時，能有多契合
• 當風險升高時，多思考的重要性就大幅增加
• 遇到真正困難的工作，就必須學習以更少時間做事，而以更多時間思考工作本身

3. 維也約等著你

• 當人們在大談特談「聰明工作」的話題時，普遍都認為真實世界的管理就是如何讓人工作得更久，更賣力，並以大量犧牲員工的個人生活做為代價。
• 無論你有多企盼他們在工作時全力付出，也不能以犧牲其個人生活做為代價
• 每加一小時的班，就約莫換來打一小時的混，這種交換在短期內或許能得到好處，但長期而言就很不划現
• 處於時間壓力下的人不會把工作做得更好，只會做得比較快

4. 品質 --- 倘若時間允許

• 人的個性乃是由少數基本本能所主宰：求生、自尊、繁衍、地域等等
• 挑動情緒最主要的因素，就是自尊受到威脅
• 你所採取任何可能危及產品品質的行動，都將引爆部屬對你的負面情緒
• 在槍桿之下，反而過度限制他們所能做的努力，為求準時完工，將喪失在各項資源之間做取捨的自由，也不可能增加人手或減少功能，唯一能動手腳的，只剩下品質。
• 強迫部屬交出一個品質達不到他自認為合格的產品，幾乎可說是一項錯誤的決定
• 創作者對品質的看法卻完全不同，由於他們的自尊與產品品質緊緊相繫，所以通常會用自己的品質標準加諸於產品之上。
• 品質能夠超過最終使用者所需要的標準，乃是通往更高生產力的途徑
• 價格與品質的妥協不存在於日本，甚至，高品質可帶來成本降低的觀念非常普遍
• 讓創作者訂自定自認為滿意的品質標準後，所提高的生產力將足以彌補為改進品質所付出的代價
• 「品質---倘若時間允許的話」的政策將保證產品沒有任何品質

5. 重審帕金森定律

• 帕金森定律 - 無論配置多少工作時間，該工作都會把配置的時間耗光
• 帕金森定律幾乎肯定不適用於你的部屬，只要不在他們自訂的品質標準上打折扣，他們會跟你一樣渴望完成工作
• 把你的部屬當成帕金森式的員工一定沒效，此舉只會打擊他們的自尊與工作衝勁
• 當專案的時程既不合理又不切實際，無論加多少班也完成不了時，專案團隊就會既憤怒又沮喪……而且士氣將跌到谷底
• 研究指出，老闆不給時程壓力的專案竟然締造了最高的生產力，這並不能證明帕金森定律不適用於從事開發的工作者，但這難道不令你驚奇嗎？

6. 苦杏仁素

• 許多經理人因為絕望，所以輕信可以改善生產力的說辭，淪為技術上的苦杏仁素受害者
• 我們確信，這些做得比較好的組織並沒有使用任何特別先進的技術，他們之所以有更好的表現，完全是因為更有效率地處理人事、改進工作場所和企業文化
• 簡單卻解決不了問題的辦法，往往比困難的辦法更誘人
• 軟體產業的生產力年成長率為三到五個百分點，僅略勝於鋼鐵或汽車產業
• 程式語言很重要，因為它會影響你對問題的思考方式，但話說回來，所影響的也僅限於專案的實作部分 (頂多只有5%的效益)
• 你要是對部屬施加大量壓大，他們就會有更好工作表現？ 不 --- 這只會減少他們的工作樂趣
• 管理者的工作並不是叫人去工作，而是去創造讓人想去工作的情境

好一陣沒寫Blog..

翻了一下之前的文章發現有幾篇去年的草稿都只寫一半就停了，數一數大概有十來篇... XDD

今年因為公司的2個資深軟體工師離職了，所以最近都忙著找新人、面試新人、帶新人、準備教育訓練，但我該寫的程式還是一個都沒少，時間不夠用就是看技術資料的時間也相對變少了，rss常常累積了半個月的文章沒看，以前總是可以照著自己的步調寫程式，一天內總是有幾個小時可以看一下新技術學東西，現在連可以安靜寫寫程式的時間也很難，常常就是開會、無意義的出差、當保姆，想想可以專心著寫程式真是幸福的一件事。 :)

忙到很時間寫blog是個藉口，懶及文筆不好才是沒持續寫的原因，之所以幾年前開blog就是想練習一下自己的表達能力及分享一下自己的程式心得，為了這兩個目標我還是改掉懶這個壞習慣吧。 囧

-------

時間過很快，在embedded system領域不知不覺就過了七年了，想說最近幫blog灌一下水寫寫這幾年來的工作心得吧。 :)

從Visual Studio 2008升級到2010的記錄 (2)

因為前陣子公司電腦跑VS2010實在是太慢了，就把VS2008專案升級的計畫延後，也剛好我老闆願意升級我們的研發機器 (淚)，換了i7-2600 + 8G RAM跑VS2010終於順多了，前幾天找時間升級了一下專案，結果又出現了一些相容性的問題。 囧

------------------------------

錯誤訊息:

1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\stdint.h(72): warning C4005: 'INT8_MIN' : macro redefinition

原因: Including stdint after intsafe generates warnings

這個問題我原本以為是boost的關係，也找到boost相關的ticket有說明這個問題，後來查得更仔細才發現是Visual Studio 2010和Windows SDK 7.0的定義衝突問題

解法:

參照這篇MSDN說明，這個問題要等到下次主要版本更新才會修正了，也許是VS2010或是SDK 7.1? 目前的解法就只能忽略這個warning...

#ifdef _MSC_VER
#pragma warning (push)
#pragma warning (disable : 4005)
#include <intsafe.h>
#include <stdint.h>
#pragma warning (pop)
#endif

2011-06 妖怪村+內湖國小

Flickr 上的相片集 2011-06 妖怪村+內湖國小。