前言：這一篇文章對於軟體專案控制方面的內容可能比較趨近於專業範疇，不一定可以為不相關的讀者所理解，各位讀者可以適時跳過一些片斷內容，甚至是大部分片段，直接跳到最後兩段。
談到領導藝術，就要考量到一個十分重要的因素─動力，若是沒有動力便不會有適當的領導契機，底下的人不自動自發也不願意完全聽從領導者的指令便是領導工程的最大失敗。
學生時代當過系學會會長，整個過程中發現自己很難將底下幹部的動力提升起來，主要的原因在於這些幹部本身是無給職的，很多人只是願意幫忙，但很少會將大部分心力放在對於自己沒有絕對助益的系方工作上，也因為如此，到了學期即將結束時，熱情早就被課業壓力給壓住了，而在這項工作上的感受是，只有給予相當的動力才能讓整體工作完美地運作，然而大學是個自由世界，連系費都有人不想交了，還有什麼辦法去推動工作，其實大學生的想法千千萬萬，大多會有自己的一套思維模式，已經不太能像國中、高中一般地願意聽從一些假象的利益，例如名義上的獎勵(記功、嘉獎)或者實際上的獲益(例如給你一點微薄的薪水)，但這些都不如一個十分現實的一項推力，就是有許多人擔任幹部是為了有機會與異性接觸，至少這個動力能夠一直維持著，當然幹部甚至會長都有其服務大眾的心，所以很多活動都還是會自動自發地合作，但從頭到尾都很用心的還是不多，不過，這種情況在實際的工作環境中就比較沒有，畢竟工作所獲得的是一種實際的溫飽，甚至是一家大小的溫飽，不再如同學生時代般那樣能有自己的許多想法。
金錢並非萬能，但沒錢卻萬萬不能，這是十分市儈卻又真實的現實，沒有利益驅使就找不到願意真正付出一己的人力，所以在利益的觀點上，金錢成了驅從動力的一項重要要素，然而雖然金錢重要，若是讓金錢成為一種功德圓滿的錯覺會對整體效能與結果產生十分不良的影響，尤其是在軟體專案研發方面。
一般的老闆對於軟體部門的看待大多是確定可以一本萬利但卻又經常無法收得預期的效果，在我的觀點下，比較好的看待方法是將權利與權力充分下放到相關主管，因為軟體業的成效不是一、兩年可以看到的，而是要有相當的一段時間才能讓成效立見，而軟體研發過程之中不可因為要趕出某項結果而放棄該有的品質問題，這會讓整個軟體研發程序產生不可挽回的下場。
一般軟體發展部門都是由一位經理職來負責所有下屬工程師的管理工作，這種做法實際上是事倍功半，主要事倍功半的原因是主管未能有時間做到他該做的工作而將某些工作承接給下屬，而一些無意義的繁瑣工作也讓經理職等人員無法充分利用時間來用心於專案研發計畫過程，在大概參考過幾本微軟所出版的書籍以及自己反覆反省後的結論中可以歸納出一個比較好的架構可以讓主管的工作能不那麼嚴重地被壓縮殆盡，這種架構就是要確認一個可以讓主管人員充分將工作下放的組織方式，而這種管理方式讓微軟在近幾年的軟體研發地位漸為人所肯定。
首先，經理職不應該只有一個職缺，應該有數個職缺架構出整個軟體研發部門，首先當然是要一個到數個專案經理來負責各個不同計畫的時程與人力管理，而技術方面的問題則是需要設置一個技術經理，這個職位在微軟中大多是由某個最熟悉計畫的工程師兼任，他可以對於自己熟悉的特定專案進行程式工作以及技術文件整理等工作，另外需要有個程式經理來當作產品的主要窗口，讓他來推廣產品的各種要素，而不是由任何一個對於產品不很熟悉的人來主導推廣工作，並要讓其他相關部門的業務人員能夠以這個窗口來了解產品的真正功能與特性，並由這個窗口確認後才能決定是否產品符合某個特殊案例的要求。而最重要的專案經理必須設有專案副理之職缺以為傳承工作的需求所在，這才不會讓所有工作在靈魂人物離開或暫時離開時完全停頓。
除了這些特定的經理人員外，最好能有一位技術長來負責對於工程師進行基礎知識的訓練，讓瞬息萬變的資訊知識能適時地更新以提高日後的研發成效；另外，最好能有一個部門負責研發所謂的函式庫，將不斷重複的工作函式庫化，並要能規劃出一個理想的回報系統以供基礎工程師使用，這個系統一般可以用網頁介面達成，主要功能可能有新技術討論、程式錯誤紀錄、測試報告紀錄、文件管理紀錄等元素都可以讓專案管理的工作更加輕鬆；而測試工作最好是由一組專門人員來測試，才能跳脫出工程師的侷限想法，讓系統更加接近商品化；最後還有一個重要的工作就是市場分析人員，從有工程以及資訊背景的人中選擇一位專門人員對於市場新技術以及市場動向進行分析，定時將結果報知決策高層以及專案經理以決定軟體的真正研發方向來為軟體開發過程奠基。
當然，以上提到的架構只是理想，能做到的公司並不多，大多數的公司決策主管並應不見得都有資訊背景，他們會覺得軟體研發部門只需要一個很簡單的架構，就經理一名加上工程師數名即可，這種做法普遍存在於資訊業界，這樣的做法讓專案經理一人身兼數職，他要做的工作除了專案管理之外，還要擔任技術經理、程式經理、技術長、函式開發主管、市場分析師等全部工作，而工程師在這樣不良的管理方式下，經常會無所適從，而主管也很難抽出時間來指導許多關鍵技術，其中還隱含著一個十分嚴重的問題，就是加班問題，經過統計，加班越久的人的生產效能大多是最差的，因為他必須把平常下班後才做的雜務設法移到工作時間中完成，也因為這種干擾讓工程師無法全心地利用無止盡的加班時間做完一天八個小時應該做完的工作，甚至做不完四個小時的工作，所以加班對於軟體工程師而言並沒有任何好處。
此外，在統計之下，一個良好的工程師工作環境是要能讓他儘量減少中斷干擾，包括電話的干擾、噪音的干擾，甚至是其他討論聲音對於自己的干擾，所以一個理想的工程師工作環境是能夠擁有一個安靜部受干擾的自我空間，並避免讓工程師自身處理電話這一類的干擾，這時，電子郵件便發揮了很大的功效，可以讓工程師與其他工程師或主管之間以這種安靜的方式溝通，所以那些禁止下屬在上班時間看電子郵件的主管人員可能就因為其他考量而無法充分利用這一項好處，而改以聲音表達的方式來傳遞資訊，事實上對於工程師本身並不好。
而一個專案經理身兼數職的結果就是專案經理將許多工作轉嫁給下屬，例如程式方針的確認、程式實作的方法、進度報告的文件化以至於無以計數的會議召開都會將工程師的心力轉移到其他方面，然而，工程師該做的只是將經理的想法實作出來，不太需要對於一些需要經驗的關鍵技術做研究動作，當然，對於關鍵技術的研究也是對於工程師十分好的一項工作，也因此，我會贊成由專案經理或技術經理確認需要的技術方面工作，然後明白地告知工程師要如何去做這麼一個案子，而另外也要讓工程師花一些時間來了解一些新技術，透過報告的方式來與同事交流知識，至於一些繁瑣的進度報告以及文件整理應該是由專案經理來處理的工作，不太適合讓下屬為了決策高層需要的一些形式化工作佔用時間，並要減少開會時間，增加一些技術交流的機會，與其將時間花費在整理詳盡的進度報告，還不如花時間來整理一些有助於實作的技術文件。
這邊強調一下，以上的想法並不是一朝一夕可以達成目標，而是要有計畫地執行本身架構的改造才能見其成效，並不是三、兩個月可以達成的目標，當然這一切也要決策高層能夠體會這些觀念才能促使高層同意進行改造。
最後還要強調的是適合於許多行業的觀念，同時也是是最重要的一件事，就是有錢能使鬼推磨，曾有一些文章點出一個觀念，就是要將百分之七十的薪資支出給有能力也有心要為公司奉獻的成員，然後將百分之三十的薪資放在那些可有可無的成員身上，所以一個高於市場平均的合理薪資是留住下屬的主要關鍵，而人須盡其才，物必盡其用，一個人才除了要以合理的薪資來留住之外，也要能有識人之明來將人才安放到合適的地方，有些人天生是個好工程師，卻不是個好主管，反之亦然，若是由一個不適合當主管的人來擔任經理，可能會造成某些資源無意義地浪費，而一個適合管理眾人的人才要是一輩子放在工程師之列，也會是資源的一種無視。我一向認為年資的重要性遠不及能力的重要性，一個有能力之人的充分利用必須在呆版的升遷制度中破格擢昇，若是一個工程師一定要工作超過五年才能升上經理，那這種制度明顯地在扼殺一個優秀的主管人物在這前五年原本可以改善的許多成果。
除了以上特質外，一個優秀的領導人還需要具備某種令人信服的能力，他必須能夠了解從底到上的許多流程，如此才能正確地做出適當決策，然而決策必須由開明的更高層決策主管支持才能順利執行。總之，即使自己是個伯樂，也要有一個能接受伯樂推薦千里馬的決策高層以及要能接受千里馬超越自己的醒悟，如此千里馬才終有飛騰雲間的一天。
