⑴ 從程序員到項目經理（12）：如何管理自己的時間（上）
項目經理必須要主動的管理自己的時間，合理安排自己的工作，才能真正「翻身」做自己時間主人。1.誰動了我的時間時間對於每個人而言，都是最稀缺的資源，對於一個管理者更是如此，時間不夠用成為幾乎所有管理者共同的問題。如果要對項目經理常說的話做一個調查的話，想信「我很忙」一定可以名列前茅。以我的經驗，當要求項目經理按時提交項目材料，或者臨時支援某件緊急事務的時候，經常會聽到同樣的回答：「我很忙」。多年以前，我就從經理那裡聽說，厲害的管理者都是很輕松的，因為他的工作全部交出去了，根本不用自己操心，所以他們出去度假十天半個月，一切工作都會如常進行。從那時起，我就充滿了對管理的神往，可是後來我才發現原來這只是個傳說，現實中忙忙碌碌的經理比比皆是，而輕松自如的管理者則是眾里難尋。為什麼管理者都這么忙呢？是誰動了他們的時間？實際上，這是一個綜合性的問題，既有內部原因，也有外部原因，既有主觀原因，也有客觀原因。總的來說，讓經理們不堪重負的因素有三：(1)工作對於一個程序員來說，他的工作是比較單純的，基本上是單線程運作，只需要項目經理交待開發任務即可，可是當上了項目經理就不一樣了。以前好比在游泳池中游泳，現在是在大海里沖浪，各種事情如潮水一般向你涌來，讓你顧此失彼，手足無措。(2)下屬下屬也是一種資源，即人力資源，這種資源與時間一樣，同樣具有稀缺性。其實我們可以設想一下極端情況，如果你的下屬人數足夠，能力也很強的話，你完全可以像我的經理說的一樣，把你的全部工作授權給你的下屬，你自己也就不用整天焦頭爛額了。因為你的下屬不給力，所以你總是要自己來制定計劃、自己來做系統架構、自己來監控進度、自己來檢查質量、自己來寫文檔、自己來匯報工作、自己來解決重要問題、甚至自己來編寫代碼，你整天忙忙碌碌，就是在忙這樣的事情。然而，千萬不要怪你的下屬，因為他們不給力正是老闆僱傭你的原因，況且資源的稀缺性是永遠存在的——從原始社會到將來的共產主義社會。要知道，老闆做項目為了賺錢，而不是讓管理者更輕松，如果每個項目都是精兵強將，你只要一聲令下工作就會自動完成，你倒是輕鬆了，但老闆還要你來做什麼？(3)自己既然資源受限是一定的，項目經理還是應該反求諸己，從自己身上找到解決之道。這就好比天下雨了，你怪老天是沒有用的，只能怪你自己沒有帶雨傘。經常問一問自己，我對工作安排合理嗎？我抓住了主要問題嗎？我在旁枝末節的事情上浪費時間了嗎？我有充分發揮下屬的能力嗎？我自己工作拖拖拉拉嗎？…通過不斷的自省，改善自己的管理方法和行為習慣，我們對時間利用也必然會變得越來越高效。 2.時間管理的本質是對工作的梳理要破解忙的難題，必須要有意識的對時間進行管理。其實時間本身是沒法管理的，因為無論你怎樣管理，時間既不會變多，也不會變少，既不會變快，也不會變慢。所謂的時間管理，其實就是如何更有效的利用時間的問題，更加直白地說，其本質就是工作管理，即通過對工作的梳理，讓我們在有限的時間內，使得工作更有條理、更有成效。必須要主動、有目標地對工作進行梳理，這是對一個管理者的基本要求。工作梳理就好比整理房間，你不去整理它，雜物就會堆積得越來越多，你房子最終會變得不適合人類居住。一個好的家庭主婦，必定善於將各位物品分門別類，並且適時扔掉一些用處不大的物品。一個好的項目經理也一樣，同樣需要對工作進行分類，對不同類型工作採用不同的策略，有些工作要現在就做，有些可以晚點做，或者不做；有些工作一定要自己做，有些工作則可以請其他人來完成。通常對工作梳理，可以採用5W1H法，即： Why——為什麼干這件事？（目的）； What——什麼事情？（對象）； Where——在什麼地方執行？（地點）； When——什麼時間執行？什麼時間完成？（時間）； Who——由誰執行？（人員）； How——怎樣執行？採取哪些有效措施？（方法）。在一般的項目中，Why和where往往不是什麼問題，或者說對項目經理的時間管理影響較小，因此我們不妨將其簡化為3W1H，也就是確定要做什麼，不做什麼；先做什麼，後做什麼；誰來做；怎樣做才更有效。基於此，項目經理可以按以下三個步驟來梳理工作：（1）分析要做什麼、不做什麼，以及先做什麼、後做什麼解決What和When的問題。事有輕重緩急，事情的重要程度和緊急程序直接決定其處理的優先順序。雖然很多事情來勢洶洶，但並不表示一定要當即處理，有些事情只是靜靜的躺在那兒，也並不意味著要「等有了時間再做」。（2）分析由誰來做解決Who的問題。雖然我們提倡項目經理要以身作則、親力親為，但並不是說每件事項目經理要親自去做。對於下屬可以勝任的事情，就把它分配出去。如果出現項目經理很忙、下屬很閑的情況，那就說明項目經理你做得太多了，不要和你的下屬搶事情做。（3） 如何讓工作更有成效做不做、什麼時候做以及誰來做的問題都解決了，剩下就要解決怎麼做才能讓工作更有成效的問題了。在這里我們不是要討論編碼或寫文檔的技巧，而是個人的習慣和認識，這對工作成效的影響更是本質上的。 3.做事要分輕重緩急老外就是善於總結，中國有詞語叫「輕重緩急」，可是到了國外搖身一變，變成了「時間管理四象限法」——自從美國總統艾森豪威爾提出以來，人人將其奉為圭臬，成為時間管理領域最重要的方法論。所謂的「四象限法」，就是將工作按照重要程度和緊急程度兩個維度進行分類。我們找一張白紙，以緊急程度為縱軸，以重要程序為橫軸，在紙上劃上一個十字，將紙面分為四個象限，然後將當前所有要做的工作放到這個四個象限中。一個典型的項目經理四象限圖如下所示： （1） 第一象限：重要緊急這一類往往是火燒眉毛的事情，需要馬上去處理，否則項目會受到重大影響，比如客戶伺服器崩潰。（2） 第二象限：重要不緊急這類事情一般是預防型的工作，例如制定項目計劃、團隊建設等，它們不需要你停下手上的工作馬上去做，但如果沒做好的話，可能就會導致產生項目危機。許多第一象限工作產生的原因，正是因為第二象限的工作沒有去做。（3）第三象限：不緊急也不重要這類事情看上去最不需要做了，例如上網偷菜、看新聞、寫博客等，但如果你在辦公室走上一圈，就會發現很多人正在干著這些不需要乾的事情。 （4） 第四象限：緊急不重要這類事情雖然不重要，卻需要馬上去處理。一個典型的例子就是桌上的電話響了，你接還是不接？當然要接，因為你不知道是誰。接通後，發現是推銷保險的，你又不好意思立即掛掉，只好被對方折磨一番了。 我們到底該怎樣安排四個象限的工作呢？對於一個普通的管理者，其工作的優先順序一般是這樣的：第一象限>第四象限>第二角限>第三象限。可是，等做完了第一、四象限的工作，根本就沒有時間來人做第二象限的工作，於是項目到了後期項目經理只好四處救火。管理大師彼德.德魯克十分推崇「時間管理四象限法」，並將其總結為「要事第一」的原則。根據這個原則，每個象限的工作處理策略是不一樣的。（1）重要緊急優先順序最高，需要盡快處理。很多人都玩過《植物大戰僵屍》的游戲吧，那你一定知道「一大波僵屍正在逼近」的感覺，是的，你必須要馬上打死它們，不然它們就會沖進你的房子，吃掉你的大腦！（2）重要不緊急這類事情看上去可以暫緩，但考慮到其重要性，應當與第一象限的工作並行去做。如果不及時去做，它們就會轉移到讓你頭疼的第一象限中去，或者在第一象限產生更多新的「僵屍」。所以，要在僵屍還沒有逼近的時候，就好防禦工事，並盡快打死它們，如果等到它們沖了過來，你還能不能保住大腦，就要看你的運氣了。（3）緊急不重要它們就像是在你耳邊「嗡嗡嗡」地叫著的蒼蠅，你必須要花時間去趕走它們。這多少讓人有些無奈，但這些事情確實層出不窮。有些公司在實施緊急項目時，經常採用封閉式開發，這樣做的一個重要原因就是要迴避那些緊急不重要的事情。很多管理專家建議我們在必要的時候勇敢說「不」，其實就是針對這類事情。如果實在無法說不，建議安排或委託其他人來做。（4）不緊急也不重要如果不是時間充裕的話，建議不要去做。如果礙於人情的話，建議安排或委託其他人來做。它們就像一群在幾百米遠處飛的蒼蠅而已，你完全不必要放下手中的飯碗，舉起蒼蠅拍跑過去和它們決斗。因此，對於一個卓有成效的管理者，其優先順序應該是這樣的：第一象限=第二象限>>第四角限。第三象限就像數學中的無窮小一樣，被舍棄了。寫到這里，我想起了前不久一位項目經理的故事：項目定於當天上線，項目組決定搬到客戶現場辦公，以應付可能出現在的突發事件。項目成員電腦已經全部打包好，都圍在項目經理周圍等待。原來項目經理正在理一大堆發票准備報銷，於是發生了這下面這樣的對話：我：「大家都在等你，怎麼還在填報銷單呢？」項目經理：「今天是公司的報銷日，不填好單子，又得推後很久。」我：「你的電腦打包了沒有？」項目經理：「沒有」我：「放行條開了沒有？」項目經理：「沒有」我：「申請用車了沒有？」項目經理：「沒有」我不知道說什麼好了。要知道公司的報銷單粘貼和填寫非常嚴格，經常被打回重新弄，那一堆發票，顯然不是十幾分鍾可以搞定的事情。還有公司的用車也比較緊張，不趕緊申請，說不定就沒有了，到時就只能租車或打的，這無疑又會耽誤更多的時間。更何況六七個同事都在等項目經理一個人，耽誤的時間還得要乘以他們的人數。萬一系統上線，狀況頻出，客戶火燒眉毛，項目組卻仍然在路上，這樣的後果是很嚴重的。貼報銷單看上去一件重要緊急的事情，實際上它既不重要也不緊急，因為今天不報銷，以後還是可以報銷，可是因此耽誤的寶貴時間，卻無法再要回來。
⑵ 當程序員變成軟體項目經理怎麼辦
當你預期的那一天，也許是害怕的那一天，終於來到了：從工程師的隊伍里你被提拔到了軟體項目領導或者團隊領導的位置。這也許就是你選擇的職業道路，或許你不太情願，將就嘗試一下。無論在哪種情況下，你都可能缺少工程學科、人員管理以及領導能力的相關教育。 這需要更多的領導能力和管理（它們不是一回事），而不能象Dilbert（譯註：著名IT漫畫主角）那樣簡單地和老闆對抗了。當你考慮新的目標時，請考慮下面的活動計劃列表。一次就抓住了每個亮點，這是不可能的。但是這份建議說明可以幫助你將注意力放在可以提高你和你的團隊績效的活動上。 建立優先順序 作為經理，首先要做的、最重要的事是你需要有意識地建立優先順序。當你仍陷於繁重的軟體開發活動中時，你需要一套新的職責。過多的經理新手不能抗拒技術的吸引而陷於此類活動，這將導致項目組的其他人員想要獲得經理的幫助時，卻得不到幫助。 有成效的領導知道他們首要的任務是為其他組員提供服務。這些服務包括訓練和指導、解決問題和沖突、提供資源、建立項目目標和優先順序、提供適當的技術指引。要使每個組員都能清楚的知道，你總是可以幫助他們。我發現將自己定位於為被我監督的人工作是非常有意義的，而不是相反的。在你所作的事情中，對於組員要求你幫助他們這件事，應該具有非屏蔽中斷的優先順序。 第二重要的，是使你的客戶滿意。作為一名經理，沒有直接的能力使客戶滿意，因為你已不再是作為個人提供產品和服務完成這點。相反，你必須建立一種環境，准許你的組員最大程度上滿足客戶的需求。經理提供了強有力的方法，有效地提高客戶的滿意度。 第三重要的，是為你的項目工作。因為也許還有其他許多技術上的項目，或者其他經理的請求幫助，諸如為指導委員會工作。當這些和二個高級別的發生沖突時，都要准備推辭掉。 很明顯，使其他經理滿意的事情是你最不重要的事情。在一個有秩序的組織里，如果你在三個以上的重大環節上獲得了成功，其他的經理都會很激動的。我們並不都能很幸運地工作在一個良好的環境里，但一定要對你任務單上排在最前面的工作任務努力盡到最大的責任。集中精力有效地、快樂地、盡可能地幫助你的組員，不要將精力放在使你上司滿意的上面。 分析你的技能差距 除非你已經為新位置做好了准備，否則相對於你當前的領導能力和管理技能，你會感到一些差距。出色的技術背景或許是你被選為領導角色的一個因素，但是你要想幹得出色，你需要更多的技能。針對別人的評論和項目，真實地列出你的長處和短處，然後減少差距。 軟體人員並不以令人滿意的人際關系技能出名。你會希望增強處理人際關系的經驗：解決沖突、說服以及灌輸想法。你也不得不處理包括招聘、解僱、商談計劃表，以及在你的辦公室里評論某人業績使其傷心落淚等一些事務。 我發現從一堂傾聽技能課開始我的管理職業是非常好的。當作為個體提議人，積極地將我們自己的技術議程提交小組時，我們經常對此感到非常愜意。有效的管理要求更多的合作和善於接受的人際關系方式。要花點時間學習如何（何時）巧妙地引導自己的自然判斷。傾聽技能課提供了一種交流機制，我已經發現在許多場合下都很有用。 接著，到講台的另一側，提高你的演講能力。如果你真的不適應公開場合的講話，學習戴爾．卡內基的課會有幫助的。你會發覺，通過這樣的培訓獲得的經驗，以及獲得提高的交流能力，都可以幫助你更好地適應將來的工作。 作為項目領導，為了計劃和跟蹤項目，以及當需要項目回退而採取修正措施時，你有責任調整其他人的工作。參加項目管理的培訓課，閱讀一些有關項目和風險管理的書籍和文章。參加項目管理學會，閱讀其月刊--PMNetwork。SEI的軟體能力成熟度模型對於軟體項目計劃和項目跟蹤提供了很多有用的建議。建立優先順序的能力、控制有效果的會議、清晰的交流，對於你，作為一名經理的績效將會有實質上的影響。 定義「質量」 幾乎每個人都會認真地對待質量問題而且都希望生產出高質量的產品。然而，對於軟體的質量含義，沒有一個統一的定義。傳統上的軟體質量觀點和「足夠好」的軟體觀點有著激烈的爭論。為了幫助小組走向成功，需要花一些時間和你的組員、客戶共同探討質量的含義。 這兩種陣營在思想上經常不會有相同的定義，可以很容易的就不同目的開展工作。關注交付計劃的經理對於想正常地檢查每行代碼的工程師會不耐煩的；認為可靠性非常重要的客戶對一個帶有很少使用但帶有很多bugs的特性的產品是不會滿意的；一個很好的GUI也許會讓用戶厭煩，因為用戶已經熟記了如何有效地使用前一個版本的產品。 為了更好的理解客戶對軟體質量的看法，在Kodak，我的小組曾經邀請了我們的客戶和他們的經理就這個議題在一個開放的論壇展開討論。這個論壇是很有意義的，那些使用我們產品的人有著自己的理解，通過討論，我們可以知道我們制定質量的思路有哪些和他們是不相符的。明白了不同，就可以使你集中精力，照顧客戶的最大利益，而不是使開發人員獲得最大滿意。 軟體質量的傳統描述包括要與說明書一致，滿足客戶的需求，代碼和文檔沒有缺陷。「六個∑質量」（six-sigmaquality）這個流行詞，建立了一個非常高的尺度，用於監測失敗的頻率和密度。但它不適用於如快速產品交付，可用性，充足的特性集，已支付價錢的交付意義這樣的質量尺度，。對於我們生產和購買的產品，我們總是熱衷於盡可能涵蓋所有的這些質量特性，然而，妥協總是必須的。 在一個項目的需求階段，我們制定了包括十項質量屬性的一個列表，如效率，協同性，正確性以及宜於學習，我們認為這對於用戶來說是最重要的。我們請客戶關鍵人物代表小組以1到5的尺度評估每項屬性。一旦我們決定了哪些屬性是最重要的，我們就可以設計並實現這些目標。如果你在了解了對於客戶的質量含義並在設計實現質量屬性的過程中沒有麻煩的話，而且客戶對質量屬性表示滿意，那你是很幸運的。 在眾多關注的質量說明中，我曾聽到過一個：「客戶回來了，但產品沒有」。和你的客戶、開發人員一起對每一個產品都確定適當的質量目標。一旦決定了，就給出達到質量目標的明確的最高優先順序。以身作則，按很高的質量標准要求你自己的工作。採用這個座右銘：「力求盡善盡美，滿足於優秀。」 表彰成績 對你組員成績的表彰和獎勵，是激勵他們的一種很重要的手段。除非你的小組中已經有了一種表彰程序，否則這應是你最重要的事情之一。表彰包括象徵性的東西（證書，旅遊獎勵）以及實際的東西（電影票，餐館禮品券，兌現獎）。在送贈品時要說一些親切的話語：「感謝你所給予的幫助」或者「祝賀取得了成績」。在表彰和獎勵上花費很少的心思和錢，就可以獲得很多的友好和將來的合作。包括客戶代表，以及為項目成功做出過貢獻的支持人員等等開發組外的人員也可以獲得表彰。 和你的組員討論，了解他們感興趣的表彰和獎勵的方式。使得無論大小成就的表彰活動成為小組文化的一個標准組成部分。對每位組員對其所作的工作表現出發自內心的興趣也要給與含蓄的表揚，為消除所有影響他們戰鬥力的障礙盡你的力量。表彰是展示組員以及小組外的其他人的一種方式――你要知道並感謝他們為小組成功所作的貢獻。 學習過去 你的小組在過去承擔的一些項目有可能沒有取得完全的成功。甚至在成功的項目上，我們也能經常認為一些事情我們下次會作得更好。當你進入了新的領導角色，需要花點時間了解早期的項目為什麼失敗，並要計劃避免犯同樣的錯誤。對於軟體開發，每位經理花時間處理每種可能要發生的錯誤是非常困難的，學習過去的成功和失敗就是個成功的開始。 可以從過去你們小組承擔的一個沒有經過檢查評估的項目著手，不要管其成功還是失敗，實施項目後的回顧（有時稱作事後調查分析）。你的目標不是判定責任，而是為了在將來項目中作得更好。藉此，可以了解什麼已經作得很好，什麼應該作得更好。在當前每個項目的主要里程碑時，通過集體討論或公平的組織者，用同樣的方式，領導小組用頭腦風暴的方式對其展開分析。 另外，要了解領悟已有的軟體工業的最佳准則。一個好的起點是SteveMcConnell的JoltAward獲獎作品：快速開發（RapidDevelopment，MicrosoftPress，1996）的第三部分，敘述了27個最佳准則。也要避免McConnell敘述的36個常見的軟體開發錯誤。你的組員也許反對新的工作方式，但是你的角色是作為一名領導，要確保團隊一致連續地使用最佳可用的方法、過程和工具。積極促進組員之間的信息共享，這樣局部單個最好的實踐經驗就能成為每個開發人員的工具箱的一部分。 建立改進目標 一旦你對過去的項目建立起了回顧，確立了質量對小組的意義，你就要建立短期以及長期改進的一些目標。目標要盡可能量化，所以你要劃分幾個簡單的階段，標明你是否採取了適當的過程朝著目標前進。 例如，如果你認定由於需求的不穩定導致項目經常延期，你可以建立一個改進需求穩定的目標，在6個月內提高50%。這樣一個目標需要你確切知道每周或每月需求的變化數，清楚他們的出處，採取行動控制那些變更。這可能要求你要改變與那些提交需求改變的人的交流方式。 你的目標和階段是軟體過程改進程序的組成部分，你要使之有序。作為缺乏創造力的官僚主義的最後避難所，輕視「過程」很流行。雖然事實上，每個小組都能找到改進其工作的方式。當然，如果你總是用已有的工作方式工作，你也就不要期望你會得到比以前更好的結果。 有兩個強烈的原因要求改進過程：校正問題，防止問題。確保你的改進努力要圍繞著已知的或可預知的可能威脅項目成功的問題。領導你的小組找出當前正在使用的方法的長處和短處，以及項目面臨的風險。 我的小組召開了一次「兩段式頭腦風暴」練習，來確定改進軟體生產力和質量過程的絆腳石。在第一次會議中，參會者在便條上寫出他們關於會議主題的想法，一個便條一個想法。組織者將他們寫在便條上的想法收集上來並分組。最後，我們就會得到一打主要的分類，並將其記錄到活動掛圖上。 第二次會議，相同的參會者在便箋上寫出解決這些障礙的思路，並貼在掛圖的合適位置。進一步細化，歸納出一些詳細的活動，就可以成為我們努力的一部分，清除障礙，幫助組員實現軟體的質量和生產力的目標。 建立可度量和可達到的目標，便於你集中精力實現改進。要使目標具有明顯的優先順序，並可周期性地監視過程。記住你的目的是，提高你的項目和公司完成的技術和業務上成功，不要滿足於一些過程改進書籍里提到的期望細節。要把改進的工作視為迷你項目，具有可分發、資源、計劃和有責任的小項目。否則，過程改進活動將總處於比誘人的技術工作低的優先順序上。 緩慢的開始 這篇文章提供了許多建議，幫助你，一位軟體經理新人，帶領你的小組走向偉大的成功。在日復一日新的工作壓力面前，要努力保持你的頭腦清醒。在長時間的塑造軟體開發小組的文化和習慣上，你還是個非常重要的角色。你不必一次性都作完，可以選擇跟環境最相關的的幾個開始。 作為軟體經理，除了項目要按時按照預算完成外，你要擔負的責任還很多。你還要：領導技術人員，將他們形成一個具有凝聚力的團隊；建立協同團隊工作的環境；鼓勵和獎賞高級軟體工程師的實踐應用；平衡來自客戶、公司，組員和你自己的需求。 這是項重大的任務，祝你好運。
⑶ 程序員怎樣培養自己成為項目開發經理
項目開發經理?老古怪的頭銜。我知到有開發組經理。項目經理。項目開發經理是不是只是負責某個項目的開發負責人?
程序員和開發經理的區別是，一個是控制項目質量，進度，分配工作的。一個是埋頭苦寫的。兩個側重點不一樣。背負的責任也不一樣。不要以為套上個經理頭銜就是成功了。
我覺得在你為成為開發經理目標努力的過程中，你先要弄清楚，自己公司里各個部門的分工，包括你所說的項目開發經理有怎麼樣的工作智能。再看看自己缺什麼技能。你就知道自己怎麼努力了。
一般來說，開發經理需要嚴密的思維，和較強的協調能力。
⑷ 如何從程序員做到項目經理
經驗決定一切。。有任務能合理安排，對整個項目流程熟悉，有技術問題能解決，這一切的一切都需要經驗積累。。這些經驗書上是沒有的，樓主做程序做到一定年齡，就行了
⑸ 程序員轉項目經理
能不能，是能力的問題。這是不關鍵，因為只要有意願，能力是可以培養的。程序員連復雜得讓人琢磨不透的軟體都能搞定，還有什麼搞不定的？
因此最後落實在需不需要這個問題上。這個問題很棘手，需要從程序員自身以及外部環境等方面進行分析。要討論這個問題，就要弄清楚它和想不想的關系。想和需要是緊密相關的，但並不是一回事。想不想，主是感情的因素，而需不需要則要進行理智的分析的了。理智與感情，並不總是一致的。有些東西，是你需要的，但你未必想要。比如，被困沙漠的時候，有時被逼喝自己的尿液，這是理智戰勝了感情。電影《色戒》中的湯唯，則是感情戰勝了理智，愛上了敵人，最後造成了悲劇的結局。因此，我們還是少說氣話了，不要沖動，冷靜的分析自己的處境吧。
⑹ 如何從程序員轉行成一個成功的項目經理
你的為人處事，你的關系，這是一個復雜的問題，但首要的是你的技術能技壓群芳嗎？
⑺ 從程序員到項目經理要學習哪些東西
吃苦
能抗
技術
交際
機遇
賞識
時間
⑻ 從程序員到項目經理（13）：如何管理自己的時間（下）麻煩告訴我
項目經理必須要主動的管理自己的時間，合理安排自己的工作，才能真正「翻身」做自己時間主人。4.管理者無需事必躬親有一種類型的管理者，他們不論什麼事一定要親自去做，至少也是親自過問。人們習慣用一個成語來贊美他們，叫「事必躬親」，彷彿諸葛亮再世一般。凡事親自去做未必真的可取，為什麼諸葛亮只活了53歲，恐怕跟他這種事必躬親的精神也有莫大的關系吧——他是把自己累死的。（1）不要和下屬搶事做管理者相對於操作層員工，多了一項法寶，就是授權。理論上，只要員工可以勝任，所有的工作都可以授權。事實上，總經理為什麼能對全公司發號施令、對工作進行變革，那是因為董事會授予了這個許可權。連這么高層的工作都可以授權，一個項目裡面的工作還有什麼不可以授權的呢？因此，當你疲憊不堪的時候，就應該問問自己，我是不是管得太多了？如果一件事情下屬能做，就應該讓下屬去做，不然等於是你搶了下屬的工作。項目經理最可悲的事情就是，自己累得半死，項目組成員卻閑得發慌。管理者必須學會授權。授權不只是為項目經理分擔工作，也是項目培養下屬成長的必要方法。如果項目經理總覺得下屬能力行，不給他分配具的挑戰性的工作，這顯然不利於下屬的能力成長，從長遠看，對項目、對公司也是有百害而無一利。（2）授權絕不是簡單的把工作交出去授權兩個字說起來簡單，但做起來效果卻會因為而異。有效的授權必須把握以下幾個要點：l 目標明確：要做什麼內容、達到什麼質量要求、什麼時候完成等等，必須要清晰具體。管理學家們認為目標必須要SMART（S=Specific、M=Measurable、A=Attainable、R=Realistic、T=Time-based），這是很有道理的。l 跟蹤反饋：項目經理應當經常性對任務完成情況進行檢查，這是很多項目經理非常欠缺的一個重要環節。只授權不檢查，最後的情況可能就是進度大大延遲，或者與你想要的東西大相徑庭，下屬進行種種解釋，但為時已晚。l 能力輔導：項目經理要對下屬的能力有比較准確的把握，安排工作也應該在其力所能及的范圍。如果跳一跳能夠得著，就比較理想，但項目經理仍然需要主動輔導，加強監控，當發現偏差時，應及時採取應對措施。如果工作大大超出其能力范圍，再怎麼跳也夠不著，項目經理就要另想高招了。（3）不做甩手掌櫃是不是任何事情都可以授權呢？理論上是可以，但由於資源的稀缺性，這種條件往往並不具備。至於什麼可以授權，什麼不可以，這要因項目而異，根據項目工作與資源的實際情況，兩廂權衡之後才能決定。不管怎麼說，授權不可過度，否則項目經理就成了甩手掌櫃，實際也等於放棄對項目的控制權。項目經理應該做的工作：l 系統性工作由項目經理做，比如制定計劃、安排任務、鼓舞士氣、項目檢查等，具體事務由下屬去做。l 重要的事情項目經理來做，緊急的事情讓下屬去做。l 決策由項目經理來做，執行由下屬去做。l 下屬能做的事由下屬去做，否則由項目經理自己做或帶著做。 5.好習慣讓工作更有成效高爾基曾這樣來描述時間：「世界上最快而又最慢，最長而又最短，最平凡而又最珍貴，最易被忽視而又最令人後悔的就是時間。」的確，時間是快還是慢，是長還是短，不在於鍾表是的指針轉了多少圈，而是在於在我們如何使用時間。一個人的習慣，對如何利用時間具有至關重要的作用。（1）盡力避免返工項目中最浪費時間的事情是什麼？是返工！一旦發生返工，不但所耗時間將會成倍增加，而且會大大降低員工的成就感，打擊員工士氣，降低員工作效率，使得項目時間進一步滯後。我見過一個城市三維模型製作的項目，經過一年多的辛苦工作，終於提交成果了，但是由於客戶認為模型不夠漂亮，最後幾十平方公里的模型全部重做！項目組員工身心俱疲，公司遭受嚴重損失，客戶也非常不滿，一個三輸的結局。返工並不總是這樣嚴重，其實在一般的軟體項目中，返工現象也是大量存在的，只不過我們借著迭代的名義將其掩蓋了。例如軟體試運行後，客戶要求將某項業務流程中的兩個環節進行整合，或者將某個環節中的輸入信息，轉移下一個環節中。單個修改的工作量也許並不算大，但累積起來就相當可觀了。很多項目在試運行後要修改幾個月，甚至半年以上，這就是返工的代價。迭代設計還是返工之間，並沒有明確的界限。要區分二者，有兩條標准：一是迭代是計劃之中的完善，而返工則是計劃之外、迫不得已而為之的事情；二是在工作量的層面，如果拋棄或被重做的功能工作量很大，那隻能認為是返工，如果你非要認為這是設計就是要這樣乾的，那我只好給它取個新名字：「返工式迭代」。這也這給我們一個啟發，做系統原型的時候，千萬不要寫大量的代碼，否則的話，迭代最後會變成返工。（2）打破帕金森定律的魔咒英國學者帕金森通過多年的調查研究，發現一個規律：「工作會自動地膨脹占滿所有可用的時間。」一個人可以在十分鍾內看完一份報紙，也可以看半天；一個程序員開發一個功能，可以兩小時完成，也可能花上一周的時間；項目經理制定計劃，可以半天完成，也可能一個月還不見影子......總之，只要還有時間，工作就會不停的擴展。帕金森定律就像一個魔咒一個樣，困擾著很多人。它之所以起作用，表面上原因在於時間充裕，外部壓力太小。因賴床而上班遲到的人常有，但因賴床而誤飛機的則很少，因為誤機的後果很嚴重。因此，有必要對每件工作確定一個時間期限——dead line，一過這條線dead！給下屬安排工作時，這的確是一個好辦法，但對於管理者而言，約束別人容易，約束自己則很困難。即使工作到期，還可以告訴自己，再推遲幾天也沒關系，這件事情還可以讓某某來完成，即使到了dead line還可以說這件事其實不重要，少做一點沒關系。圖帕金森定律的魔咒歸根到底，還是在於我們的內心力量不夠強大，面對一點點的外部阻力，就變得消極懶散，不能自我驅動。截止日期是靠不住的，要靠只能靠自己，養成良好的習慣，主動給自己壓力和動力，戰勝心中的「懶惰小人」，才能真正解除這個「帕金森魔咒」。（3）合理利用時間每個人都希望工作不被打擾，但作為一個管理者，你的時間不是自己的，你的上級和你的下屬都有權來隨時打擾你。你坐在那裡，就會有人過來找你簽字，找你談工資，找你討論技術問題，找你支援其他工作……每天的時間就這樣被打成了無數的碎片，所以經理們常不由自主的感慨：「白天真的做不了事，只能晚上和周末才能工作」——加班才能做事，你說經理能不累嗎？的確，項目經理很多工作都需要大塊時間，比如制定計劃、編寫文檔、分析風險、關鍵技術實現等，都需要較長時間的思考。一個人要讓心靜下來，進入工作狀態是時間的，一旦被打斷，再次進入這種狀態會花很多時間。這就好比炒菜，把鍋燒熱是需要時間的，你剛放下油，來了電話，等你接完電話，鍋又冷了。時間碎片的問題對管理者而言是不可避免的，但可以採取方法更加合理的利用時間，將其影響降到最低。l 制定規則例如約定在指定的時間簽單、討論技術問題、反饋進展等，而不是隨時進行。l 瑣碎事情一起做對於工作中的瑣碎問題，不用急著處理，可以啟動「碎片整理程序」，將其記錄下來，在你不需要「炒菜」的時候一起處理。l 利用碎片時間碎片時間並非不可利用，而是要安排合理的工作。幾塊大石頭中間的縫隙，肯定塞不下另一塊大石頭，但放一些小石子或沙子還是沒問題。
⑼ 程序員如何成為一名合格的項目經理
千萬不要在進行需求分析階段就先進行編碼工作，也許你覺得這些模塊和具體的業務功能無關，可以直接進入編碼階段，但是你要知道，在這個階段進行編碼工作會使你忽視了對需求的理解和分析，而且並不見得你現在完成的代碼模塊百分之百適合未來的業務系統，萬一有偏差，那就是得不償失了，在需求分析和系統設計上多花一點時間，會為以後的工作減少很多麻煩。所以在項目管理過程中，我認為最為保險的辦法就是嚴格按照軟體開發流程規范來開展工作，雖然這樣會相對比較繁瑣，但是在很大程度上保證了我們項目的成功率。
有經驗的項目經理都說自己是打雜的，所以，你要明白你不再是一個coder，項目組中大大小小的事情都要你去處理，你需要學會主動和小組成員加強溝通，從工作和生活等各個方面加以關心和幫助，這樣會使團隊氣氛更加融洽，提升團隊成員對你的信任度，在很大程度上能緩解大家的工作壓力，我們倡導的是快樂工作，而不只是為了工作而在一起工作。不要認為自己和團隊的成員只是工作關系，同時，他們也是你的朋友。如果你是一位性格內向的項目經理，那麼，你應該讓自己開朗點，不要因為自己的性格而讓整個團隊變得很沉悶，那樣大家工作起來會感覺非常痛苦。
作為項目的管理者，你不僅僅是被人領導，而是還有一個團隊需要你去帶領，當他們請教你的時候，你有責任和義務去幫助他們解決，或者給他們指定找誰解決，而不應該因為自己不會而一走了之。同時要學會培養團隊中的成員，放開手，大膽的讓他們去做，不要認為教他們完成任務還不如自己親自動來得快，那樣你只能做一名程序員，而且越做越累，要知道，還有更多更重要的事情等著你去做。
我建議每一兩天應該組織項目組成員開一次討論會，否則，項目組成員之間誰也不知道誰在做寫什麼功能。和大家談談項目的進展，了解下大家目前遇到的困難和工作進展，適當調整項目組成員之間的工作分配。而不是在項目前期安排了任務後，後期的工作任務不根據項目的實際情況進行調整，等到項目後期時，大家同時拋出很多問題，這樣會讓你束手無策，一片混亂。所以要及時舉行項目討論會，學會靈活得安排工作任務，沒有誰規定一個項目的所有工作任務只能安排一次。
其實作為基層的管理者，要管理好團隊相對還是比較簡單的，我認為只要和同事之間的關系處理得足夠融洽，就意味著你的管理已經成功了一大半了，都說做人比做事重要，相信這一點沒錯的，但是管理走向更高的層次，就需要你學習一些比較專業的管理學方面的知識了，這段時間在看《從技術能手到管理高手》這本書，我覺得非常適合從程序員逐步轉向管理的朋友閱讀，但不能照搬書上的條例，要結合自己的實際工作環境，消化吸收之後，再用於實踐才是最好的。前段時間CSDN上一位牛人阿朱出了一本書叫做《走出軟體作坊》，我只是看了書中的目錄和部分內容，從同行的評價來看，我想這本書應該是值得一讀的，哈哈。
⑽ 做開發做了2年多 如何成為項目經理呢
呵呵，從我的經歷來給你一點啟發吧，不敢說一定奏效，但是希望能有所幫助：
1、單純做開發時只要做好本職工作就OK了，不需要考慮團隊裡面各個人員的契合；成為項目經理後，這些事情是在開發之前就已經定好了的，項目的進度時間表，責任分配表，資料庫設計表，詳細設計文檔，風險評估等等，這些都是需要項目經理妥善安排的；
2、做項目經理需要深刻一點理解老闆心中的產品是什麼樣子的，這就比單純做程序員跟老闆的交流多一些，期間有很多要注意的地方，必經是跟老闆在交流，這種事情沒什麼可說的，平時多留意總結經驗即可；
3、做了項目經理了，當然要多多關心一下「兄弟們」了，一句話，除了常規工作外，你還需要調節你的上下級之間的關系，呵呵，這種事情比較麻煩，當然，這種事情比較稀少，一般不會遇到！
4、再有就是往大了說了，培養團隊意識，作交流時要起到引導作用，目的是讓大家增加默契，有利於協作。
就說這些吧，希望能給你幫助哦！