【it168 專稿】
因為我在參與的軟體專案開發表現出色，公司在新乙個軟體開發專案上委派我做專案經理，全權負責專案各種事務的管理。繁忙的事務處理使我體力透支, 有一種脫了一層皮的感覺，但最使我心力交瘁的是從軟體程式設計師到專案經理的一種思維方式和觀念的痛苦轉變。
在軟體越來越複雜，需求多變的情況下，程式設計師式的個人英雄主義已經行不通了，從程式設計師到專案經理需要主動轉變思維方式，否則將陷入心靈和精神的痛苦折磨。在我負責專案管理時，痛苦的經歷使我深深明白到轉變思維方式和觀念對於乙個專案的成敗是至關重要。
痛苦轉變之一：跳脫典型的程式設計師思維
我在剛負責專案的時候認為保持團隊高效的工作，和讓專案成員有成就感當然重要，但如果連**工作都完不成的話，就不能談什麼高效工作了。因此，在我接管專案團隊的時候，我認為從某種程度上講專案經理最重要而且唯一的目標就是控制**編寫進度，團隊所有工作的成果就是要提交乙份高效的**。所以，成員**的質量以及對**的控制，是專案經理管理的主要任務。例如軟體程式主要由**組成，編碼階段就是整個軟體專案的最重要的階段，應該給與大量的時間，並且集中主要的資源。
**就是一切的程式設計師式經驗讓我嘗到了做專案經理的第乙個苦果。實際上，與以前相比，由於軟體的規模和複雜度的增加，以及半自動化軟體**開發平台的出現，軟體專案管理的中心發生了轉移——不再著重編碼階段，而是著重系統總體/詳細設計階段。一般說來，軟體專案管理中各種資源的合理分配比例是：專案論證、風險評估階段10% ，專案需求分析階段10%，系統總體/詳細設計階段40%，編碼階段10%，系統測試階段30%。
在我過往編寫**的程式設計師經驗中，優秀的程式設計師與平庸的程式設計師效率差5－10倍。因此，我在專案啟動的第一要務就是選擇最優秀的程式設計師，並時時關注這些優秀程式設計師的進度表和滿足他們的需求。我認為，用乙個優秀程式設計師要比用2個或3個平庸的程式設計師來的划算。
在多次痛苦經歷後，我終於明白到專案管理第一要務應該是：控制專案範圍，控制專案進度和合理分配各種資源。完成客戶需求和公司任務應該要讓每個成員都發揮作用，和都覺得有成就感，這樣的專案經理才能算是比較合格的專案經理，而不僅僅只是關注最優秀的程式設計師。這個苦果讓我明白到，即使是有優秀的程式設計師，如果缺乏專案控制和協調，要完成客戶需求和公司任務往往也會是天方夜譚的事情。
只有專注於程式設計，才能成為一名優秀的程式設計師，這是程式設計師的座右銘。然而這種專注所付的代價是忽視了團隊合作，過於以自我為中心。有調查結果顯示，許多程式設計師只侷限於在某一小範圍內結交知心朋友，**技術。但也正因如此，當程式設計師轉變為專案經理時，就會發現處理專案各種紛繁複雜的事情時能力衰退，缺乏通達權宜，靈活反應的能力，這無疑不利於程式設計師綜合素質的提高。
因此，在程式設計師轉變為專案經理，從從事「技術」到「管理」這一跨行上，必須轉變思維方式和觀念。專案管理是一種典型的系統管理，也是一種典型的管「人」的管理。在乙個軟體專案中，有成百上千的相互關聯的活動，例如各種人際關係，資源和突發性事情。哪一種活動都可能會在工期、資源和預算等方面發生變化而對整個專案開發過程產生連鎖反應。例如專案組成員存在不同的分工，他們各自的工作對專案目標都會產生不同的作用和影響，不能僅靠鼓勵他們提高對專案的自發性的責任感，也不能僅靠評價機制來驅動他們共同承擔專案的責任。
專案管理的定律之一是「魔鬼藏在細節中」，專案經理必須在對專案各種活動變動全面了解的基礎上，才能確定工作的焦點。因此，在程式設計師轉變為專案經理最容易犯的就是「一葉障目，不見泰山」的錯誤，這個時候需要跳離大俠式的個人主義思考方式，建立系統化管理的思維方式，這是我從程式設計師轉變過程中得到的乙個重要教訓。
痛苦轉變之二：痴迷於技術，忘記管理控制
專案管理的三要素:進度、質量、成本，哪個都不能少。專案管理要處理的事情非常多，需要排程非常有限的資源去完成一大堆的工作。資源包括:人力，時間，金錢。這三種資源往往只是剛剛夠，或者還缺少很多，這個才是考驗專案經理的地方。
但在我剛剛開始做專案經理時沒有轉變觀念,一味地按程式設計師的思維方式去追求完美,痴迷於技術,而忘記及時交付,這也是軟體開發人員的通病。
軟體專案的複雜決定了需要協作，也決定了協作時溝通與交流的複雜。乙個專案想要做到管理有條不紊，就要有管理層次，這是我在四處碰壁，燋頭爛額後得到的經驗。軟體開發專案中各層次，各成員都分有與之相對應的職責和權利，例如專案主管負責計畫管理和組織開發，程式設計師負責具體的**編寫操作。
作為專案經理，如果管理過細往往會打破正常的管理秩序，使管理處於紊亂狀態，影響專案進度。因此，專案管理應具有層次，而從程式設計師出身的專案經理應該特別注意，避免「越俎代庖」的現象發生，不要一看到下屬程式設計師做事效率低，就自己下場親自操刀編寫**，事事都包攬不是乙個好的專案經理。因為這樣的管理是有問題的，會滋養了成員的惰性，造成了事無大小全憑指揮的缺乏思考和創造性的局面，以至於離開了專案經理，專案便無法正常運轉。
就管理成效而言，這是一種十分糟糕的情況。包辦一切的另外乙個害處，是不利於調動成員的積極性與創造性，不能盡人才之用。對於那些有才華，有能力的成員，他們在工作中處處都得不到體現，在這種情況下，難免會有一種壓抑感，時間長了，要麼就在此磨洋工，要麼有些能耐的就乾脆辭職走人。
因此，在專案管理中，專案經理可以和成員打成一片，但在涉及到具體的權利和職責，或處理專案內部中的種種問題時，就必須注意管理的層次，切忌越俎代庖和越權指揮。這也是程式設計師轉變專案經理的乙個大考驗。
我們的專案面臨著多變的環境，各種突發事件層出不窮，特別是專案經理工作負荷大，頻於應付。出於程式設計師需要先把自己需要做的工作做好的習慣，我把大部份時間花在了個人績效的工作上。但在進度總結會議上，我遭遇到最難堪的事情，就是我個人的績效不錯，但團隊的績效是一塌胡塗。後來我明白到專案經理要做正確的事，而不僅僅正確的做事。就是要分清工作的主次—哪些工作應該由專案經理來做，哪些工作可以交給其他人員來做，哪些工作需要資深人員來完成，哪些工作由一般人員做就行。
專案管理強調的是團隊行為，而不是個人行為。面對乙個複雜而多變的軟體開發專案，只有專案經理乙個人是無法解決這些問題的。因此，專案經理需要關注每個人的進度和績效，重點是技術經理和資深人員。而且，專案經理僅管好自己的時間還不行，還要掌握授權的技巧。應當明白管理是通過別人的手達到專案目標，通過計畫、組織、協調、控制和兄弟專案組和業主等有關人員來實現這個目的。所以，專案經理是乙個過程轉化者，他要把目標轉化為結果，把資源轉化為成果。
因此，專案經理應當花費相當的時間在對專案組人員的管理上，花費時間在對下屬指導、激勵、團隊建設、專案協調和控制上。強化專案成員以專案為榮，以專案為目標，提高團隊的士氣，目前這也是程式設計師轉變為專案經理的最大薄弱環節。
在軟體專案管理中成本管理一直是乙個很讓專案經理心傷的事情，我們也經常聽到許多專案成本超支，預算失控的訊息。軟體專案管理成本的控制實在很難，主要原因有：需求不確定，專案工期不確定，費用無法控制等。
效能和成本永遠是一對矛盾，程式設計師出身的專案經理常常為此陷入兩難的境地，這種狀況下常常考驗著專案經理對質量、成本、輕重、緩急判斷的均衡感。因此，專案成本估算和控制是程式設計師轉變為專案經理所遭遇到的最大困擾，這也常常構成了程式設計師向管理方向發展的恐慌。
痛苦轉變之三：到底是專案經理還是技術經理？
在我剛剛負責專案的時候，由於各種原因導致乙個人身兼多職。正常來說，專案經理的關注點應是專案的進度把控，協調各方資源使專案能夠如期完成，但結果是我這個專案經理經常這也做那也做，有時還要管理編寫和測試**。這樣的後果是一方面把人搞的很累，另一方面也是乙個很大的風險。
後來，經過挫折和打擊後，我明白到理想的專案經理無需參與具體設計，他們只需要運用獨特的管理能力去協調各種流程、專案、預算和團隊成員，優秀的專案經理需要做乙個領導者，象汽車司機一樣操作汽車。而理想的技術經理，是乙個有著技術天賦的人員，是其他技術人員眼中的技術領導者，他們是技術導航員並能夠解決問題，就像乙個汽車發動機一樣。專案經理是對專案整體負責，技術經理是對專案的技術負責，專案經理主要負責成本和範圍，技術經理則負責技術實現和質量。專案經理監控技術經理的質量工作，技術經理從技術角度協助專案經理的成本、範圍工作。
後來經過多次的混亂後，我們決定把專案經理和技術經理分開。這個事情也讓我深深明白到，專案經理不應該把應是技術經理做的事情也做，必須轉變思維方式，立足於管理才是正道，這也是我從程式設計師到專案經理轉變的最寶貴經驗。
程式設計師從技術開發到專案管理PM 思維轉變
對以往所做專案的經驗做下總結，作為專案經理首先要對專案負責，思維要做下轉變，要從專案全域性角度考慮問題 從個人成就到團隊成就。無論是做管理還是做技術，成就導向意識是優秀員工的基本素質。只有具備很強的成就導向意識，才能把事情做得超預期，才能追求卓越。剛剛上任的管理人員的思維方式往往還處於個人成就導向階...
程式設計師從技術開發到專案管理PM 思維轉變
對以往所做專案的經驗做下總結，作為專案經理首先要對專案負責，思維要做下轉變，要從專案全域性角度考慮問題 從個人成就到團隊成就。無論是做管理還是做技術，成就導向意識是優秀員工的基本素質。只有具備很強的成就導向意識，才能把事情做得超預期，才能追求卓越。剛剛上任的管理人員的思維方式往往還處於個人成就導向階...
程式設計師如何修煉管理思維
程式設計師如何修煉管理思維 1 從個人到團隊轉變，包容同事，出問題不是指責而是引導 培養人，給每個同事鍛鍊的機會。以人為中心而不是機器。2 從專心做好一件事到同時處理多個任務轉變，擁抱混亂但不要陷入其中，做好個人的時間管理，把雜亂的任務理清楚才是進步。3 從關注點到關注面轉變，先設計再開發。4 從說...