專案管理入門
karl e. wiegers 著，mirnshi 譯 (非程式設計師雜誌 第3期)
當你預期的那一天，也許是害怕的那一天，終於來到了：從工程師的隊伍裡你被提拔到了軟體專案領導或者團隊領導的位置。這也許就是你選擇的職業道路，或許你不太情願，將就嘗試一下。無論在哪種情況下，你都可能缺少工程學科、人員管理以及領導能力的相關教育。
這需要更多的領導能力和管理(它們不是一回事)，而不能象dilbert（譯註：著名it漫畫主角）那樣簡單地和老闆對抗了。當你考慮新的目標時，請考慮下面的活動計畫列表。一次就抓住了每個亮點，這是不可能的。但是這份建議說明可以幫助你將注意力放在可以提高你和你的團隊績效的活動上。
建立優先順序
作為經理，首先要做的、最重要的事是你需要有意識地建立優先順序。當你仍陷於繁重的軟體開發活動中時，你需要一套新的職責。過多的經理新手不能抗拒技術的吸引而陷於此類活動，這將導致專案組的其他人員想要獲得經理的幫助時，卻得不到幫助。
有成效的領導知道他們首要的任務是為其他組員提供服務。這些服務包括訓練和指導、解決問題和衝突、提供資源、建立專案目標和優先順序、提供適當的技術指引。要使每個組員都能清楚的知道，你總是可以幫助他們。我發現將自己定位於為被我監督的人工作是非常有意義的，而不是相反的。在你所作的事情中，對於組員要求你幫助他們這件事，應該具有非遮蔽中斷的優先順序。
第二重要的，是使你的客戶滿意。作為一名經理，沒有直接的能力使客戶滿意，因為你已不再是作為個人提供產品和服務完成這點。相反，你必須建立一種環境，准許你的組員最大程度上滿足客戶的需求。經理提供了強有力的方法，有效地提高客戶的滿意度。
第三重要的，是為你的專案工作。因為也許還有其他許多技術上的專案，或者其他經理的請求幫助，諸如為指導委員會工作。當這些和二個高階別的發生衝突時，都要準備推辭掉。
很明顯，使其他經理滿意的事情是你最不重要的事情。在乙個有秩序的組織裡，如果你在三個以上的重大環節上獲得了成功，其他的經理都會很激動的。我們並不都能很幸運地工作在乙個良好的環境裡，但一定要對你任務單上排在最前面的工作任務努力盡到最大的責任。集中精力有效地、快樂地、盡可能地幫助你的組員，不要將精力放在使你上司滿意的上面。
分析你的技能差距
定義「質量」
表彰成績
對你組員成績的表彰和獎勵，是激勵他們的一種很重要的手段。除非你的小組中已經有了一種表彰程式，否則這應是你最重要的事情之一。表彰包括象徵性的東西(證書，旅遊獎勵)以及實際的東西(電影票，餐館禮品券，兌現獎)。在送贈品時要說一些親切的話語：「感謝你所給予的幫助」或者「祝賀取得了成績」。在表彰和獎勵上花費很少的心思和錢，就可以獲得很多的友好和將來的合作。包括客戶代表，以及為專案成功做出過貢獻的支援人員等等開發組外的人員也可以獲得表彰。
和你的組員討論，了解他們感興趣的表彰和獎勵的方式。使得無論大小成就的表彰活動成為小組文化的乙個標準組成部分。對每位組員對其所作的工作表現出發自內心的興趣也要給與含蓄的表揚，為消除所有影響他們戰鬥力的障礙盡你的力量。表彰是展示組員以及小組外的其他人的一種方式――你要知道並感謝他們為小組成功所作的貢獻。
學習過去
你的小組在過去承擔的一些專案有可能沒有取得完全的成功。甚至在成功的專案上，我們也能經常認為一些事情我們下次會作得更好。當你進入了新的領導角色，需要花點時間了解早期的專案為什麼失敗，並要計畫避免犯同樣的錯誤。對於軟體開發，每位經理花時間處理每種可能要發生的錯誤是非常困難的，學習過去的成功和失敗就是個成功的開始。
可以從過去你們小組承擔的乙個沒有經過檢查評估的專案著手，不要管其成功還是失敗，實施專案後的回顧(有時稱作事後調查分析)。你的目標不是判定責任，而是為了在將來專案中作得更好。藉此，可以了解什麼已經作得很好，什麼應該作得更好。在當前每個專案的主要里程碑時，通過集體討論或公平的組織者，用同樣的方式，領導小組用頭腦風暴的方式對其展開分析。
另外，要了解領悟已有的軟體工業的最佳準則。乙個好的起點是steve mcconnell的jolt award獲獎作品：快速開發(rapid development，microsoft press, 1996)的第三部分 ，敘述了27個最佳準則。也要避免mcconnell敘述的36個常見的軟體開發錯誤。你的組員也許反對新的工作方式，但是你的角色是作為一名領導，要確保團隊一致連續地使用最佳可用的方法、過程和工具。積極促進組員之間的資訊共享，這樣區域性單個最好的實踐經驗就能成為每個開發人員的工具箱的一部分。
建立改進目標
一旦你對過去的專案建立起了回顧，確立了質量對小組的意義，你就要建立短期以及長期改進的一些目標。目標要盡可能量化，所以你要劃分幾個簡單的階段，標明你是否採取了適當的過程朝著目標前進。
例如，如果你認定由於需求的不穩定導致專案經常延期，你可以建立乙個改進需求穩定的目標，在6個月內提高50%。這樣乙個目標需要你確切知道每週或每月需求的變化數，清楚他們的出處，採取行動控制那些變更。這可能要求你要改變與那些提交需求改變的人的交流方式。
你的目標和階段是軟體過程改進程式的組成部分，你要使之有序。作為缺乏創造力的官僚主義的最後避難所，輕視「過程」很流行。雖然事實上，每個小組都能找到改進其工作的方式。當然，如果你總是用已有的工作方式工作，你也就不要期望你會得到比以前更好的結果。
有兩個強烈的原因要求改進過程：校正問題，防止問題。確保你的改進努力要圍繞著已知的或可預知的可能威脅專案成功的問題。領導你的小組找出當前正在使用的方法的長處和短處，以及專案面臨的風險。
我的小組召開了一次「兩段式頭腦風暴」練習，來確定改進軟體生產力和質量過程的絆腳石。在第一次會議中，參會者在便條上寫出他們關於會議主題的想法，乙個便條乙個想法。組織者將他們寫在便條上的想法收集上來並分組。最後，我們就會得到一打主要的分類，並將其記錄到活動掛圖上。
第二次會議，相同的參會者在便箋上寫出解決這些障礙的思路，並貼在掛圖的合適位置。進一步細化，歸納出一些詳細的活動，就可以成為我們努力的一部分，清除障礙，幫助組員實現軟體的質量和生產力的目標。
建立可度量和可達到的目標，便於你集中精力實現改進。要使目標具有明顯的優先順序，並可周期性地監視過程。記住你的目的是，提高你的專案和公司完成的技術和業務上成功，不要滿足於一些過程改進書籍裡提到的期望細節。要把改進的工作視為迷你專案，具有可分發、資源、計畫和有責任的小專案。否則，過程改進活動將總處於比誘人的技術工作低的優先順序上。
緩慢的開始
這篇文章提供了許多建議，幫助你，一位軟體經理新人，帶領你的小組走向偉大的成功。在日復一日新的工作壓力面前，要努力保持你的頭腦清醒。在長時間的塑造軟體開發小組的文化和習慣上，你還是個非常重要的角色。你不必一次性都作完，可以選擇跟環境最相關的的幾個開始。
作為軟體經理，除了專案要按時按照預算完成外，你要擔負的責任還很多。你還要：
領導技術人員，將他們形成乙個具有凝聚力的團隊；
建立協同團隊工作的環境；
鼓勵和獎賞高階軟體工程師的實踐應用；
平衡來自客戶、公司，組員和你自己的需求。
這是項重大的任務，祝你好運！
專案管理入門
當你預期的那一天，也許是害怕的那一天，終於來到了 從工程師的隊伍裡你被提拔到了軟體專案領導或者團隊領導的位置。這也許就是你選擇的職業道路，或許你不太情願，將就嘗試一下。無論在哪種情況下，你都可能缺少工程學科 人員管理以及領導能力的相關教育。這需要更多的領導能力和管理 它們不是一回事 而不能象dilb...
專案管理入門
karl e.wiegers 著，mirnshi 譯 當你預期的那一天，也許是害怕的那一天，終於來到了 從工程師的隊伍裡你被提拔到了軟體專案領導或者團隊領導的位置。這也許就是你選擇的職業道路，或許你不太情願，將就嘗試一下。無論在哪種情況下，你都可能缺少工程學科 人員管理以及領導能力的相關教育。這需要...
管理 專案管理入門
karl e.wiegers 著，mirnshi 譯 非程式設計師雜誌第3期 當你預期的那一天，也許是害怕的那一天，終於來到了 從工程師的隊伍裡你被提拔到了軟體專案領導或者團隊領導的位置。這也許就是你選擇的職業道路，或許你不太情願，將就嘗試一下。無論在哪種情況下，你都可能缺少工程學科 人員管理以及領...