領導者不需要是技術最強的那一位

無論你是一名技術能力卓越的領導者，或者對軟體技術不甚熟悉，想要讓你的角色扮演得更為輕鬆，建立你在團隊成員心中的信任感，絕對是十分關鍵的一環。

技術能力強大的人，可以力服人，因為你更高竿，所以你說的話值得聽。技客們有崇拜高手的傳統及文化，對程式人來說，聽從高手的指示，不僅僅只是服從，而且還可以從中學習。

但技術能力不夠強大、甚至能力遜於自己所帶領的程式人，這類的領導者，同樣有機會能贏得團隊的信任。

程式人不想當乖乖牌，你最好有中心思想
程式人喜歡做有意義的事，通常他們不會想當個乖乖牌，照著主管的意思做事，做一個只要能領到錢就好的員工。

很多程式人希望自己做的事能真的產生效益，有實際的作用。當你在思考工作的進行方式以及任務的指派時，必須讓他們明白這方式，以及任務的意義何在。

很常見的，失敗的領導者在交付一件工作後，會讓程式人覺得這工作根本一點意義都沒有。失敗的領導者會讓程式人覺得照你的方式做事，不過只是浪費時間而已。

當這樣子的事重複發生時，很難建立起整個團隊對你的信任感。

好的軟體團隊的領導者應該是一名傳教士，你對於自己的行事方式要有一個中心思想，你自己明白、也信仰這麼做是會有好處的。例如，你相信輕量級的開發方法像是XP（eXtreme Programming），對團隊會帶來好處，但這個相信是有你的依據的，不單只是一個盲目的信仰。

當你告訴團隊成員，你打算採用XP來做為開發流程的基礎，你或許會遭遇到團隊成員的抗拒，例如他們不願意徹底地執行單元測試，因為這種方式不符合一些程式人的習慣和觀念。你當然可以用「上司」的身分來強力推動，但這可能無助於你和他們之間的關係，當然，這也不會讓他們更信任你。

如果你有一個中心思想存在，你會真的有一套想法，是你自己也很真誠地相信這麼做是對的。那麼做為傳教士的角色，你可以很明白地，在清楚的脈絡下，告訴你的開發團隊，為什麼你認為這麼做可以帶來更好的結果。

程式人喜歡有邏輯的論述，討厭無法自圓其說的說法。如果你能妥善地解釋，進一步再加以說服，那麼不僅能更順暢地推動你希望工作進行的方式，同時還能夠增進在程式人心目中的地位。

怕得是連你自己都沒有固定的中心思想，你的想法、還有原則也是飄來變去的，對程式人而言，今天看到和明天聽到的不一致，這就很難讓他們對你產生信賴的感覺了。

若能燃起程式人的熱血，他們甘願沒日沒夜地工作
除了金錢的回報之外，程式人也都會希望自己所做的軟體是有意義的。

好的領導者會讓他的開發團隊明白，整個團隊所努力開發的軟體，究竟能夠為客戶，或者為使用這軟體的使用者帶來什麼幫助。

據說，蘋果電腦的Steve Jobs在以前帶領一票程式人開發軟體時，總是能夠讓這些程式人沒日沒夜地工作，但仍舊心甘情願。因為Steve Jobs能夠讓這些人相信，自己所辛勤工作的成果，具有足以改變世界的力量。

我們可以說，他擁有燃起程式人熱情的魔力。

我想講的便是類似這樣的情境。雖然我們可能都不具備像Steve Jobs那種天生的領導者魅力，但是，讓程式人能夠對自己所開發的專案或產品產生認同時，絕對有利於開發的進行。

在現實生活中所看到的許多例子，恰好都是這種情況的反例。程式人好像和自己所開發的東西完全疏離，工作只是領到薪水的途徑，而產品的完成，只是為了要能夠交差。

要讓程式人更為投入在自己工作，有一個好方法，便是讓他們對自己所開發出來的東西產生認同。這個認同很有可能像是「自己也覺得很好用」、「這產品讓自己以身為產品開發者為榮」、或是像「這東西肯定能改變很多事情」之類的情感。身為一個軟體團隊的領導者，可以透過像傳遞產品開發願景之類的方式，加深程式人對產品本身的認同感，驅動程式人努力開發的力量。

領導者的責任，是帶領整個部隊有效率地往前邁進
此外，很多人都期待軟體團隊的領導者，是特定領域技術最強的那一位。但事實上，這樣的觀點忽略了一件事：軟體團隊領導者的主要工作，並不是解決特定的技術問題，而是建立起一個讓每個團隊成員都能流暢工作的環境。

軟體團隊領導者的重要工作之一，便是讓每個人都知道自己的分工、應該扮演的角色，及他應該跟其他人如何合作，讓工作完成。所以說，建立一套常規，及為每個人安排工作流程，相形之下是更為重要。

這些常規，小至命名慣例、版本控制系統的簽入／簽出原則、系統測試及部署的原則，大到系統分析、系統設計的方法及開發的流程等。軟體團隊的領導者應該是規則的建立者及設計者，他應該是站在制高點上的那個人。

許多軟體團隊的領導者參與太多實際的開發活動，最常見的就是自己本身負責撰寫程式碼，而且還是最關鍵的那一塊程式碼！

這種情況，很容易讓自己陷入當局者迷的情境，因為你顧著解決自己的問題都來不及了，那裡會有餘暇關心其他人的情況呢？軟體團隊的領導者應該關心整個團隊的全貌，或是整個專案的全貌，領導者的責任，是帶領整個部隊有效率地往前邁進，而不單只是自己一個人拼命地往前衝。所以，他應該要把工作的重心，放在怎麼讓所有人的開發能夠更流暢。

領導者工作的重心根本不在技術，而是整體的進展
軟體開發團隊的領導者在專案開發的過程中，有時候看起來好像無所事事，因為他並沒有實際地參與實際的程式碼撰寫工作。但事實上，他工作的焦點放在觀察專案進行的狀態，及專案進行的模式。

觀察專案進行的模式，有助於觀察團隊運作的方式是否順暢，是否存在結構性的問題必須解決。例如，你觀察到某一類型的工作，總是集中在某一個特定的成員身上，這是因為這位成員具備某些其他成員無法取代的技能，進一步造成這位成員成為開發時程上的瓶頸，甚至時常出現在專案開發時的關鍵路徑之上。

那麼，在觀察出這樣子的問題後，便可以試著透過教育訓練或技能移轉的方式，讓其他成員也能逐步地具備相同的技能。漸漸的，團隊成員中的瓶頸便能夠消除，在工作指派上就會更有彈性，也會更有效率。

從這個例子中可以看得出來，軟體開發團隊的領導者看的是整體，而不是局部。

他更需要關心的是規則、流程，而不是單一的技術問題或程式碼開發。從這邊來看，便能夠明白，軟體開發團隊的領導者即使不是團隊中特定技術最強的那一位，仍然無礙於工作的進行，因為他工作的重心根本不在技術。