當程式設計師變成軟體專案經理
專案經理
程式設計師角色
當你預期的那一天，也許是害怕的那一天，終於來到了：從工程師的隊伍裡你被提拔到了
軟體專案領導或者團隊領導的位置。這也許就是你選擇的職業道路，或許你不太情願，將就嘗試一下。無論在哪種情況下，你都可能缺少工程學科、人員管理以及領導能力的相關教育。 這需要更多的領導能力和管理(它們不是一回事)，而不能象dilbert(譯註：著名it漫畫主角)那樣簡單地和老闆對抗了。當你考慮新的目標時，請考慮下面的活動計畫列表。一次就抓住了每個亮點，這是不可能的。但是這份建議說明可以幫助你將注意力放在可以提高你和你的團隊績效的活動上。
建立優先順序
作為經理，首先要做的、最重要的事是你需要有意識地建立優先順序。當你仍陷於繁重的軟體開發活動中時，你需要一套新的職責。過多的經理新手不能抗拒技術的吸引而陷於此類活動，這將導致專案組的其他人員想要獲得經理的幫助時，卻得不到幫助。
有成效的領導知道他們首要的任務是為其他組員提供服務。這些服務包括訓練和指導、解決問題和衝突、提供資源、建立專案目標和優先順序、提供適當的技術指引。要使每個組員都能清楚的知道，你總是可以幫助他們。我發現將自己定位於為被我監督的人工作是非常有意義的，而不是相反的。在你所作的事情中，對於組員要求你幫助他們這件事，應該具有非遮蔽中斷的優先順序。
第二重要的，是使你的客戶滿意。作為一名經理，沒有直接的能力使客戶滿意，因為你已不再是作為個人提供產品和服務完成這點。相反，你必須建立一種環境，准許你的組員最大程度上滿足客戶的需求。經理提供了強有力的方法，有效地提高客戶的滿意度。
第三重要的，是為你的專案工作。因為也許還有其他許多技術上的專案，或者其他經理的請求幫助，諸如為指導委員會工作。當這些和二個高階別的發生衝突時，都要準備推辭掉。
很明顯，使其他經理滿意的事情是你最不重要的事情。在乙個有秩序的組織裡，如果你在三個以上的重大環節上獲得了成功，其他的經理都會很激動的。我們並不都能很幸運地工作在乙個良好的環境裡，但一定要對你任務單上排在最前面的工作任務努力盡到最大的責任。集中精力有效地、快樂地、盡可能地幫助你的組員，不要將精力放在使你上司滿意的上面。
分析你的技能差距
我發現從一堂傾聽技能課開始我的管理職業是非常好的。當作為個體提議人，積極地將我們自己的技術議程提交小組時，我們經常對此感到非常愜意。有效的管理要求更多的合作和善於接受的人際關係方式。要花點時間學習如何(何時)巧妙地引導自己的自然判斷。傾聽技能課提供了一種交流機制，我已經發現在許多場合下都很有用。
接著，到講台的另一側，提高你的演講能力。如果你真的不適應公開場合的講話，學習戴爾.卡內基的課會有幫助的。你會發覺，通過這樣的培訓獲得的經驗，以及獲得提高的交流能力，都可以幫助你更好地適應將來的工作。
作為專案領導，為了計畫和跟蹤專案，以及當需要專案回退而採取修正措施時，你有責任調整其他人的工作。參加專案管理的培訓課，閱讀一些有關專案和風險管理的書籍和文章。參加專案管理學會，閱讀其月刊--pm network。sei的軟體能力成熟度模型對於軟體專案計畫和專案跟蹤提供了很多有用的建議。建立優先順序的能力、控制有效果的會議、清晰的交流，對於你，作為一名經理的績效將會有實質上的影響。
定義「質量」
幾乎每個人都會認真地對待質量問題而且都希望生產出高質量的產品。然而，對於軟體的質量含義，沒有乙個統一的定義。傳統上的軟體質量觀點和「足夠好」的軟體觀點有著激烈的爭論。為了幫助小組走向成功，需要花一些時間和你的組員、客戶共同**質量的含義。
這兩種陣營在思想上經常不會有相同的定義，可以很容易的就不同目的開展工作。關注交付計畫的經理對於想正常地檢查每行**的工程師會不耐煩的;認為可靠性非常重要的客戶對乙個帶有很少使用但帶有很多bugs的特性的產品是不會滿意的;乙個很好的gui也許會讓使用者厭煩，因為使用者已經熟記了如何有效地使用前乙個版本的產品。
為了更好的理解客戶對軟體質量的看法，在kodak，我的小組曾經邀請了我們的客戶和他們的經理就這個議題在乙個開放的論壇展開討論。這個論壇是很有意義的，那些使用我們產品的人有著自己的理解，通過討論，我們可以知道我們制定質量的思路有哪些和他們是不相符的。明白了不同，就可以使你集中精力，照顧客戶的最大利益，而不是使開發人員獲得最大滿意。
軟體質量的傳統描述包括要與說明書一致，滿足客戶的需求，**和文件沒有缺陷。「六個∑質量」 (six-sigma quality)這個流行詞， 建立了乙個非常高的尺度，用於監測失敗的頻率和密度。但它不適用於如快速產品交付，可用性，充足的特性集，已支付價錢的交付意義這樣的質量尺度，。對於我們生產和購買的產品，我們總是熱衷於盡可能涵蓋所有的這些質量特性，然而，妥協總是必須的。
在乙個專案的需求階段，我們制定了包括十項質量屬性的乙個列表，如效率，協同性，正確性以及宜於學習，我們認為這對於使用者來說是最重要的。我們請客戶關鍵人物代表小組以1到5的尺度評估每項屬性。一旦我們決定了哪些屬性是最重要的，我們就可以設計並實現這些目標。如果你在了解了對於客戶的質量含義並在設計實現質量屬性的過程中沒有麻煩的話，而且客戶對質量屬性表示滿意，那你是很幸運的。
在眾多關注的質量說明中，我曾聽到過乙個：「客戶回來了，但產品沒有」 。和你的客戶、開發人員一起對每乙個產品都確定適當的質量目標。一旦決定了，就給出達到質量目標的明確的最高優先順序。以身作則，按很高的質量標準要求你自己的工作。採用這個座右銘：「力求盡善盡美，滿足於優秀。」
表彰成績
對你組員成績的表彰和獎勵，是激勵他們的一種很重要的手段。除非你的小組中已經有了一種表彰程式，否則這應是你最重要的事情之一。表彰包括象徵性的東西(證書，旅遊獎勵)以及實際的東西(電影票，餐館禮品券，兌現獎)。在送贈品時要說一些親切的話語：「感謝你所給予的幫助」或者「祝賀取得了成績」。在表彰和獎勵上花費很少的心思和錢，就可以獲得很多的友好和將來的合作。包括客戶代表，以及為專案成功做出過貢獻的支援人員等等開發組外的人員也可以獲得表彰。
和你的組員討論，了解他們感興趣的表彰和獎勵的方式。使得無論大小成就的表彰活動成為小組文化的乙個標準組成部分。對每位組員對其所作的工作表現出發自內心的興趣也要給與含蓄的表揚，為消除所有影響他們戰鬥力的障礙盡你的力量。表彰是展示組員以及小組外的其他人的一種方式?d?d你要知道並感謝他們為小組成功所作的貢獻。
學習過去
你的小組在過去承擔的一些專案有可能沒有取得完全的成功。甚至在成功的專案上，我們也能經常認為一些事情我們下次會作得更好。當你進入了新的領導角色，需要花點時間了解早期的專案為什麼失敗，並要計畫避免犯同樣的錯誤。對於軟體開發，每位經理花時間處理每種可能要發生的錯誤是非常困難的，學習過去的成功和失敗就是個成功的開始。
可以從過去你們小組承擔的乙個沒有經過檢查評估的專案著手，不要管其成功還是失敗，實施專案後的回顧(有時稱作事後調查分析)。你的目標不是判定責任，而是為了在將來專案中作得更好。藉此，可以了解什麼已經作得很好，什麼應該作得更好。在當前每個專案的主要里程碑時，通過集體討論或公平的組織者，用同樣的方式，領導小組用頭腦風暴的方式對其展開分析。
另外，要了解領悟已有的軟體工業的最佳準則。乙個好的起點是steve mcconnell的jolt award獲獎作品：快速開發(rapid development，microsoft press, 1996)的第三部分 ，敘述了27個最佳準則。也要避免mcconnell敘述的36個常見的軟體開發錯誤。你的組員也許反對新的工作方式，但是你的角色是作為一名領導，要確保團隊一致連續地使用最佳可用的方法、過程和工具。積極促進組員之間的資訊共享，這樣區域性單個最好的實踐經驗就能成為每個開發人員的工具箱的一部分。
建立改進目標
一旦你對過去的專案建立起了回顧，確立了質量對小組的意義，你就要建立短期以及長期改進的一些目標。目標要盡可能量化，所以你要劃分幾個簡單的階段，標明你是否採取了適當的過程朝著目標前進。
例如，如果你認定由於需求的不穩定導致專案經常延期，你可以建立乙個改進需求穩定的目標，在6個月內提高50%。這樣乙個目標需要你確切知道每週或每月需求的變化數，清楚他們的出處，採取行動控制那些變更。這可能要求你要改變與那些提交需求改變的人的交流方式。
你的目標和階段是軟體過程改進程式的組成部分，你要使之有序。作為缺乏創造力的官僚主義的最後避難所，輕視「過程」很流行。雖然事實上，每個小組都能找到改進其工作的方式。當然，如果你總是用已有的工作方式工作，你也就不要期望你會得到比以前更好的結果。
有兩個強烈的原因要求改進過程：校正問題，防止問題。確保你的改進努力要圍繞著已知的或可預知的可能威脅專案成功的問題。領導你的小組找出當前正在使用的方法的長處和短處，以及專案面臨的風險。
我的小組召開了一次「兩段式頭腦風暴」練習，來確定改進軟體生產力和質量過程的絆腳石。在第一次會議中，參會者在便條上寫出他們關於會議主題的想法，乙個便條乙個想法。組織者將他們寫在便條上的想法收集上來並分組。最後，我們就會得到一打主要的分類，並將其記錄到活動掛圖上。
第二次會議，相同的參會者在便箋上寫出解決這些障礙的思路，並貼在掛圖的合適位置。進一步細化，歸納出一些詳細的活動，就可以成為我們努力的一部分，清除障礙，幫助組員實現軟體的質量和生產力的目標。
建立可度量和可達到的目標，便於你集中精力實現改進。要使目標具有明顯的優先順序，並可周期性地監視過程。記住你的目的是，提高你的專案和公司完成的技術和業務上成功，不要滿足於一些過程改進書籍裡提到的期望細節。要把改進的工作視為迷你專案，具有可分發、資源、計畫和有責任的小專案。否則，過程改進活動將總處於比誘人的技術工作低的優先順序上。
緩慢的開始
這篇文章提供了許多建議，幫助你，一位軟體經理新人，帶領你的小組走向偉大的成功。在日復一日新的工作壓力面前，要努力保持你的頭腦清醒。在長時間的塑造軟體開發小組的文化和習慣上，你還是個非常重要的角色。你不必一次性都作完，可以選擇跟環境最相關的的幾個開始。
作為軟體經理，除了專案要按時按照預算完成外，你要擔負的責任還很多。你還要：領導技術人員，將他們形成乙個具有凝聚力的團隊;建立協同團隊工作的環境;鼓勵和獎賞高階軟體工程師的實踐應用;平衡來自客戶、公司，組員和你自己的需求。
程式設計師必讀
大資料之路 雙管齊下 maxcompute資料上雲與生態 阿里雲機器學習平台程式設計模型演進之路 熱門技術探索 深度學習vs機器學習vs模式識別 血淚史 七種it失誤讓你直接走人 乙個合格的程式設計師應該讀過哪些書 程式設計師在囧途 垃圾創業團隊 程式設計師到高階程式設計師 只需要10個步驟！1 c...
程式設計師從業必讀
程式設計師從業必讀 如何定義一本書是不是好書？我的原則是，這本書是否對自己有益。leo的 程式設計師羊皮卷 的讀者定位主要有2大人群，1是計算機或相關專業的在校大學生 2是it從業人員，正面臨求職困境或工作瓶頸的 大體可以歸結為還沒有當上專案經理或部門主管的it從業人員 針對這兩大類讀者，我相信，這...
程式設計師必讀之作 重構
十月一之後安排了我去培訓 設計模式 由於聽眾多為c與c 的新手，我想先從重構開始講起，循序漸進，於是我決定仔細閱讀 重構 這本書。這本書我很久之前買的，當時大概讀了讀，感覺不錯，就拿給了我表弟去讀，他是程式新手。這次是系統地讀。有個朋友曾經跟我說過，這本書不錯，只是有點羅嗦，他是十多年經驗的老程式設...