當上專案經理後，技術人員往往對自己的定位失去了感覺。其中最令人困惑的就是自身原有的技術標籤，撕了也不是，因為技術還不能丟，貼著也不是，因為個人的成敗往往決定於自己對團隊的管理，而不再是自己的技術。
想要從這種困惑中擺脫出來，首先就要搞清楚下面幾個問題：
question 1——專案經理職位對技術到底有什麼要求？
answer：
想把專案管理工作做到點子上，兩個觀點要明確：
①技術不是必須項。專案經理個人技術很重要，但這不屬於必須項，屬於有了更好的東西，當然越高越好。因此，在工作中，固然出任專案經理職位的以技術高手居多，可設計人員、文件人員、測試人員等出身的專案經理也不少見。
②對技術要了解。作為底層管理者，專案經理是脫不開技術的，那麼你必須要對技術有所了解。那麼，專案經理對技術要了解到什麼程度呢？作為一名合格的專案經理，在技術上必須掌握兩方面內容：一是業務的技術方向，你如果技術深度上不如手下，那麼你要在廣度上、高度上找到發言權；二是團隊的技術現狀（技術方向、技術能力、個人水平等等），不管你自己技術如何，你都要知道自己團隊強在**、團隊裡技術上誰強誰弱、以及與業界平均水平相比自己強弱幾何。
question 2——做專案管理，是不是一定要懂技術？
answer：
不一定。專案規模越小、時間越短、人員越少，專案經理是否懂技術所起到的作用越大。專案越大、時間越長、人員越多，專案經理是否懂管理所起到的作用越大。是否一定要懂技術要根據實際情況。因為有些情況下，專案所需技術誰都不會，都要從頭學；或者有技術主管存在，專案經理不懂也沒有關係。
question 3——做專案經理後，還要繼續學習技術知識嗎？
answer：
很多技術者在當上專案經理後，學習補充管理方面知識之餘，對繼續關注技術與否搖擺不定——不學吧害怕技術落伍，學吧專案緊張抽不出時間，怎麼辦？
如果你想走技術道路，那就不要放棄對自己所關心技術領域的鑽研。如果你決定走管理道路，那麼我的建議是——學習，請僅限於跟蹤調研公司相關技術領域。管理是乙個長期性的工作，最忌頭腦一熱等臨時性決定。這使得管理者對技術的看法不是越新越好、越高越好。管理屬意於謀定而後動，當技術發展方向已經確立，效果已經被公認後，管理才會進入實質性階段。我的經驗是：對技術細節的精力投入，會讓你得到技術知識的同時，失去對管理問題的敏感。
question 4——做專案經理，要如何把握技術發展方向？
answer：
當上了專案經理，技術也還是要關注的。但是和之前相比要有所不同：①要觀其大概，而不要處處留情；②要學會借他人智慧型，不要乙個人獨自鑽研。
作為基層管理職位，技術還是不能丟。但是，這時候的技術學習需要借力，借助團隊的力量，不要乙個人在陋室裡苦學。而且要學其中關鍵部分，要學會提綱挈領，不要試圖面面俱到。不如此的話，你就沒有時間來學習管理。因為技術思維和管理思維是有衝突的，如果你腦筋總是處在技術思維狀態，那麼你學管理學到的也只是知識性的、機械性的東西，即便是學了也用不好。
下面專門來談談——專案經理學習技術如何借用他人智慧型。
我在日本工作期間，有個叫古橋的日本同事。此人原來是做平面設計的，技術基本上是外行，後來轉型專案經理卻做的很成功。後來我總結了一下古橋的成功秘訣：
①不懂就問。
這一點做到的人並不多，古橋在這方面不但做到了，還更進一步，他會要求手下寫出來「怎麼辦」和「為什麼」，然後自己去檢驗，確實沒有問題他會認真存檔。
艾偉也談專案管理，如何管理「人」
我們常說工作中應該 對事不對人 但事都是人做的，不同的人做相同的事效果可能相去甚遠，再好的業務如果用錯了人也會全盤皆輸。正所謂 事在人為 嘛，識人 用人 聚人是乙個團隊管理者獲得成功的基礎。先說怎麼認識人 人格矩陣法。即所謂的topk技術，topk就是由 tiger owl peacock 與 ko...
艾偉也談專案管理，架構組織管理
架構組織管理的五大原則 構想 節奏 預見 協作和簡化 架構組織的三在概念 準則 模式和反模式 準則 為了把原則運用到實踐中，需要實施細節。準則把廣泛的原則翻譯成是否和如何執行原則的細節。模式 描述了開發或者使用軟體架構時可能遇到的常見問題的解決方案。反模式 反模式描述了組織在實踐中可能遇到的陷阱，描...
艾偉也談專案管理，微型專案實踐感悟
微型專案是指絕大部分工作由乙個人員負責的專案，這個核心成員負責專案的系統分析 構架 及絕大部分的編碼工作。專案的持續時間一般不會超過乙個月。專案的參與人員除了核心的程式設計師外還可能一部分輔助人員，包括第二程式設計師 負責一部分編碼工作 美工 負責介面設計 等。微型專案的規模一般很小，業務邏輯也比較...