項目經理需要管控項目的所有細節嗎？

01-05

背景類似於給電信運營商做外包的項目，管理經驗太淺，這個問題嘗試了很多辦法，一直得不到很好的解決，希望大家能不靈賜教。
1. 管控所有的細節。
因為項目的特殊性，客戶這一環節無比重要。因此能及時的解決問題和反饋客戶的問題顯得很重要。因此如果管控所有的項目實現細節，就能很好的溝通交流。由於團隊成員技術、業務已經責任心等參差不齊，如果不加以管控，很可能做出來的功能就不符合要求。管控起來，能及時回復成員的疑問就能更好的指導大家做功能實現；
但現實是精力和能力有限，並不能每一方面都能很好的了解以至於掌控；
2. 不掌控所有細節，粗放的只盯大的功能實現和進度等；

粗放的盯進度實現，這就對團隊成員提出了更高的要求。團隊成員需要不斷站在用戶的角度思考問題，例如用戶體驗等，需要站在項目的角度思考功能，比如這個功能是否是客戶真實想要的，是否可以有更簡單的實現來代替，從而節省人月等；
但是讓成員做決策又基本不可能，畢竟不在其位不謀其政，工程師的思維也不是那麼好拗過來的；責任心不強的工程師，做出來的東西簡直是要罵街的。
以上兩點算我目前的背景詳情。
另外我知道可能中庸的做法是取平衡，但平衡之術難比移山。
希望能得到實際可行的思想指導和實踐方法，謝謝大家。

對於一個項目經理來說，唯一的目標就是實現項目的目標，能夠給客戶交付一個滿意的結果，所有的工作，行動和管理圍繞該目標進行。

那麼從你自己列出的兩種場景可以看到，如果不管理細節那麼一定是無法很好達到項目目標的，則結論就是需要管控細節。但是你描述裡面首先由給自己下一個台階，即自己精力和能力有限，我管控不好所有細節是理所應當的事情，如果是這個思維的話這個問題沒有解。

回到問題本身，一開始一定是要管控所有細節，後續管理和努力的方向是如果逐步減少對細節的管理，如何讓團隊裡面的人自己能夠管理好細節。那麼團隊人員本身你已經分析到了只有兩個方面的影響，一個是本身技能問題，一個是責任心和態度問題。而這兩點的改進在剛開始時候往往並不需要過於複雜的方法論。

責任心問題：剛罰就罰吧，再人性化的管理該處罰的時候還得處罰，只有涉及到個人經濟利益時候個人才會真正的重視，不是每個人都能夠積極主動的。

技能問題：這個相當重要，即通過前期迭代的項目執行能夠發現項目團隊技能和知識上的缺陷，能夠發現哪些細節內容本身就沒有事先做好約定形成團隊通用辭彙表，哪些應該加強評審和檢查。所有這些目的都是逐步形成團隊的技術辭彙表。有了這個即逐步有了大家對細節的共同認識，細節很多時候不是簡單的態度問題，更多是技術歸約不清的問題。

對於做不好的地方，不斷強調並加強獎懲力度，逐步潛移默化為習慣。對於開始做的好的地方後續即可以逐步進行粗粒度和抽查式的管理了。對於細節把握相當好的團隊成員，逐步提升為你的輔助管理者，分擔管理和檢查職能。

最後，再給你提一點，不要讓團隊裡面的人認為你是一個單純的管理者，只知道管理和安排跟催任務，而是要體現自己的技術角色，能夠幫助團隊一起分析和解決技術難題。技術類項目管理一個重點就是讓下麵糰隊成員從內心裡認同你。

直接上方法，請依次進行：

1.人員列表。

做一個人員列表，標示出團隊每個人的管理能力、需求分析能力、程序設計能力、編碼能力、測試能力。根據能力制定不同的層級角色，比如具體需求分析能力的人跟你一起做需求分析,具有管理能力和程序設計能力的人做開發組長...;再把當前的工作列表分配到每個人。

2.溝通。

團隊中每個人單獨溝通，了解他們對工作的期望，提升的慾望，激勵他們在項目中發揮積極作用，如果這一句話做不到就直接跳過。告訴他們你的安排，要求每人每天下班前必須向你彙報。不會做的，做不好的沒關係，每天向你彙報的時候你給他們解決方案。

3.短期培訓，樓主當前的境況聊長期培訓貌似不現實。看起來樓主急需一個業務需求溝通負責人和一個開發組長。前面已經找出了人選（不一定這個人已經具備當前的能力，只要他們有潛力有意願就ok），接下來是重點培訓這兩個人，短時間內讓業務需求溝通負責人和開發組長上位。

4.監控

通過每天的彙報和開發成果測試監控所有成員的進度和問題，同時也通過此步驟了解每個人的額能力。

5.優化

認定開發組長或者某個成員的工作之後，逐漸放寬對此人的監控細度。對於出現問題的人或者任務分析原因，調整方案，調整人員。開發組長時機成熟可以替你管理一兩個人的開發。然後再培養其他開發組長... （通過樓主的表述貌似開發人員中暫時沒有頂得住的人，因此出此策，如果已有人選做開發組長這一步會容易得多）

業務需求溝通負責人逐漸做一些與客戶的溝通工作，直到他完全替代你與客戶溝通業務需求。

﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣

其實很多回答說得都對，只是貌似樓主急需一個方案解燃眉之急，因此直接給出了5個步驟。沒有人一開始就是一個遊刃有餘的項目經理，慢慢來慢慢學。

1. 管控所有的細節。
因為項目的特殊性，客戶這一環節無比重要。因此能及時的解決問題和反饋客戶的問題顯得很重要。因此如果管控所有的項目實現細節，就能很好的溝通交流。由於團隊成員技術、業務已經責任心等參差不齊，如果不加以管控，很可能做出來的功能就不符合要求。管控起來，能及時回復成員的疑問就能更好的指導大家做功能實現；但現實是精力和能力有限，並不能每一方面都能很好的了解以至於掌控；

作為項目經理一個人，企圖管控所有的項目實現細節，事無巨細事必躬親，眉毛鬍子一把抓，這在實踐中往往既做不到，也是錯誤的。因為並非所有的項目細節都重要，值得一個團隊領導親自抓，而決定項目成敗的往往只是少數關鍵細節。

要管控項目開發的所有細節，不是依靠 PM 一個人之力，而是應該依靠團隊的整體力量，尤其應該為項目團隊建立起一套完整的質量管控體系與成熟的軟體開發流程。二十年來國際上可參考的標準模型和最佳實踐已經很多，如 ISO 9001、CMMI、UP、Agile、PMBOK 等等。團隊有了成熟的管理流程和方法論，把項目風險、責權利等等分解到每個人而不是 PM 和少數個人英雄身上，才能實現有效率、高品質的項目管理、服務管理，做到萬無一失。

題主未提及團隊規模，以上分析主要針對大中型團隊。對於小微團隊（如 &<10 人）PM 掌控所有細節是有可能的，因為這些項目本身細節不多，也不是很複雜。這在 2000 年以前國內軟體工程的蠻荒時代比較流行，當時的 PM 與架構師常常是一個人，既抓管理也抓技術，還要搞好客戶關係，而很多需求文檔、架構文檔也是 PM 寫的。不像現在角色分得細，除了 PM，還有產品經理、業務分析師、需求分析師、系統架構師、軟體架構師等等。

2. 不掌控所有細節，粗放的只盯大的功能實現和進度等；

這句話只說對了一半。

PM 的正確做法是抓大放小，風險驅動，客戶價值優先，利用有效的時間和精力只抓住關鍵細節，而不是所有細節。抓這個關鍵細節的管理不是粗放的，而是精細、精準的。

例如，你們有 100 個需求，PM 要抓住所有這 100 個需求的細節？不可能吧。通常的做法是，PM 只抓住這其中 10-20 個對客戶最重要、最有價值或者實現起來難度最大、風險最大的需求，重點了解它們的需求定義是否符合客戶需要，實現難點和技術障礙，如何克服困難、消除瓶頸等等細節。

其他的 80 個需求怎麼辦？細節 PM 只能大致了解，它們的實現和進度管控應交給你的助手，團隊里的其他管理與技術骨幹（如 TL、架構師），以及項目的整個質保體系、開發流程管理來負責或保障。

粗放的盯進度實現，這就對團隊成員提出了更高的要求。團隊成員需要不斷站在用戶的角度思考問題，例如用戶體驗等，需要站在項目的角度思考功能，比如這個功能是否是客戶真實想要的，是否可以有更簡單的實現來代替，從而節省人月等；

做到以上這些並不難，現代軟體工程方法里有許多成熟的需求管理、需求分析實踐，關鍵在於你們團隊里是否有足夠成熟、掌握這些技能的需求分析師、需求工程師、產品經理等。如果沒有，每個需求都要 PM 自己來盯，那會把 PM 累成狗。

但是讓成員做決策又基本不可能，畢竟不在其位不謀其政，工程師的思維也不是那麼好拗過來的；責任心不強的工程師，做出來的東西簡直是要罵街的。

軟體開發中的決策多種多樣，有大有小，有主有次。如果所有決策都讓 PM 來做，PM 也要累成狗。PM 一般只負責管理決策，讓架構師負責主要的技術決策。每個工程師如何實現自己負責的需求，他有這個決策權。涉及到架構的技術決策，通常需要集體討論，架構師有最終決策權。

如何保證工程師做出東西的質量？主要靠成熟的質量保證流程，在需求、設計、測試等等許多環節都可以設置評審、抽查、運行、演示等等檢驗和反饋步驟，而不能單純靠工程師的責任心。

背景類似於給電信運營商做外包的項目，管理經驗太淺，這個問題嘗試了很多辦法，一直得不到很好的解決，希望大家能不靈賜教。
...
以上兩點算我目前的背景詳情。另外我知道可能中庸的做法是取平衡，但平衡之術難比移山。

平衡的思路很對！二十年來世界上主流的的項目管理、軟體工程管理方法論都是講究平衡的，在中國管理 IT 項目尤其應該如此。

PM 不應該抓所有的細節，而應該只抓關鍵的細節。這 20%（或更高的比例）關鍵的細節隨著項目的進展，是動態變化的。

你們目前的一個主要問題就是還沒有找到一套適合自己的管理方法論和體系，所以思路有點亂。事實上世界領先的軟體工程與項目管理已經很成熟了，成熟的方法論與知識體系就擺在那裡，只是需要大家去學習。建議趕緊找點資料、參考書研究下。

除了確立團隊開發的管理方法、流程之外，還需要把管理的人才梯隊建起來，讓管理和技術骨幹們掌握必要的技能，而不是把所有細節、壓力都壓到 PM 一個人身上。只有這三個方面結合起來，才能實現高效、成熟的項目管理。

建議了解下scrum + xp。雖然敏捷開發國內有各種觀點，但敏捷開發有很多很好的實踐來應對你所說的這些問題。

比如管控所有的細節，這種想法是比較典型的瀑布式的做法。瀑布式能成功嗎？當然可以成功，但前提是有一個強悍的項目經理。:) 從需求分析，到設計，編碼，測試等等每個環節都要力求正確。

敏捷開發提倡團隊協作，團隊共進退。傳統項目經理可以把很多決策的權利交給團隊，以期實現團隊的自我管理。當然達到這一點還是非常困難的。但不是說不可以達到。我們團隊本身做項目管理軟體的開發，我們自己的過程也是按照scrum的框架來走，同時輔助於適合我們自己的開發實踐。這五年多下來，效果還是很不錯的。

門後的秘密 (豆瓣) 推薦這本書，裡面的很多經驗對你會有幫助

細節的基本設定當然要去了解，後期也得讓反饋來看看效率；
主要看戰略目標是啥。

結論開頭：沒有必要掌控所有細節。

項目經理有兩點關鍵任務，兩者做好了，才能算是一個成功的項目經理，做好第一點，只能算是合格：

一、對外，順利交付項目，保證項目質量，超出客戶預期，達成占坑目的，即客戶認可我方結果，希望與我方再度合作。

二、對內，讓兄弟們成長，獲得物質和精神上的雙重獎勵，製造項目歸屬感，為我方下一個階段的拓展奠定厚實的人員基礎。

而項目經理的本質是什麼？

是項目經理通過績效管理手段，通過和項目組同事反覆溝通，明確思路，確認結果的一個過程，而在這個過程中，所謂的掌握所有細節，僅僅只能是一種手段，而不能作為一種固定流程。我們可以在一個階段掌握所有細節，來保證新來同事的成長和對我們要求的明確，而一個項目正式上了軌道以後，項目經理絕對不可以掌握所有細節，否則則肯定會發現無法掌控項目。

項目經理應該掌握什麼樣的細節？

1、項目經理首先應該把注意力放在項目範圍和職責上，該處的細節必須項目經理完全掌握，才能保證項目最後的成功交付；

2、其次是對於新的項目成員的思路和結果進行反覆CHECK，保證項目成員雙方都能對於結果認知相同；

3、第三是所有的交付物，在安排檢查人員的同時，應該儘可能對於最後的結果進行某一個層面上進行詳盡的把關，作好最好一道交付；

4、剩下的也就是把注意力放在項目難點以及項目成員的心態上，保證難點的攻克，以及項目本身有一個很好的歸屬感；難點決定進度，項目歸屬感決定未來；

項目經理不應該掌握什麼樣的細節？

1、所有時候的進度情況，項目經理應該關注的是項目關鍵節點，以及難點問題的解決情況，剩下的問題關注多了，反而失去項目的歸屬感；

2、應該給熟悉的弟兄們過程上的自由，結果上的check；一定要讓大家認可，我們對於大家的期望；

最後，借用《人人都是產品經理》裡頭的一句話，短視的人把方法當作目標，遠見的人把目標當作方法，所謂的掌握細節只是方法中的一種。

1.你可以不知道所有細節，但當你需要知道時你要知道這些細節在哪裡。

2.不需要你驅動團隊，因為你不是買單的那個人。你存在的價值，是讓團隊始終代表客戶的價值並以此為努力的方向。

答案很抽象，可是我覺得無數項目管理的工具、方法都是以此為目標的。

［行業乾貨］

Jason最近在讀Jack R.Meredith的《項目管理Project Management》很受啟發，在回想之前半路出家從攻城獅被提到項目經理崗位帶隊完成大小項目的經歷，雖然最終呈現的結果是被客戶認可和肯定的，但是一路磕磕碰碰走了不少的彎路，心情也經歷著像過山車般的跌宕起伏。在此書中找到了不少共鳴和感悟，所以打算寫出來，一是和大家分享、學習；二是自己對之前項目的再次梳理，提醒自己不要再犯類似的錯誤。這個系列打算用一月的時間陸陸續續的寫吧，以Jack的著作為主，輔以自己的觀點。

還是那句話，本人能力有限，水平一般，還請大家多賜教。

在旅行之前，先了解一下將要經過的路線是非常有用的－－寫給之前自己對書本派的不客觀認識。

項目管理是一項獨特的挑戰，它需要有自己的戰略和方法，可能更為重要的是，它需要人們主動行使領導人的職能。項目經理必須為整個過程制定適當的計劃，而且要為自己的團隊完成目標提供方法、支持和信息。通常有能力的項目經理常常不以發號施令者或者獨裁者的身份出現，而是以推動者、團隊成員和拉拉隊長的身份發揮作用。

項目經理常常在公司位置非常特殊，往往也很不穩定，就像大家所說，項目經理要發揮王者作用，但是卻不沒有王者的權利，又或者權力往往得不到明確的界定。所以項目經理的管理風格必須側重於說服和影響，而不是強制和命令，特別是當你的項目複雜度高，所需協同的技能組合度高時。

成功的項目管理是同時迎接人員和技術的雙重挑戰。它要求領導人員具有長遠的戰略眼光，並能夠靈活地解決每天都會產生的各種衝突和問題。要想獲得成功，就必須學會洞察並應對項目團隊所面臨的各種約束條件和團隊散漫行為，同時要對最終目標保持清醒的認識。

項目經理需要謹記的12條規則

一、了解項目管理的背景情況

項目管理不是單純地對項目進行管理，而是一種對項目經理的獨特挑戰，其特殊環境構成一種額外的困難。項目遊離於組織原油的等級結構之外，這種環境與其說是對項目工作的一種支持，不如說是一種威脅，因為它們總是不斷的發生各種變化。對於項目經理來說，在慷慨就職的同時，還需要睜大眼睛，密切關注自己將要面對的任務所具有的獨特性質。

二、將項目團隊的衝突看做項目進程中的必然現象。

項目經理對項目成功有害的時間（比如團隊衝突）都會引起他們的嚴重焦慮。然而，現實中，這些人際關係的緊張是將不同背景的人員組合起來協調行動的必然結果。衝突作為團隊發展的各個階段的必然現象，通常是團隊逐漸成熟的標誌。

在發生衝突時，項目經理可能犯一個重大的錯誤就是不對其本質進行分析，就立即將其壓制下來。儘管很多人際關係上的衝突起因是因為個人，但是也有一些源自於工作性質的不同，需正面對待，不然重複爆發是必然發生的，而且會帶來更嚴重的後果。

一旦對團隊成員之間所發生的衝突性質進行了分析，就可以正確應用多種多樣的衝突解決方法，比如迴避、引爆或者解決問題等。

三、了解利益相關者的情況及其需求。

項目管理是一種平衡活動，項目經理要在眾多實力強勁的利益相關者所提出的種類繁多而又相互衝突的要求之間周旋。最佳方法之一：在項目的早期就進行現實的評估，並且明確各個主要利益相關者的情況和需求。當一方的去權益得到滿足往往會以另一方的利益損失為代價，所有滿足所有利益相關者的需求是不可能的，需要找到平衡點。

四、接受並運用組織的政治性本質

有人的地方就有江湖，就有政治，接受並運用它。可通過與其他利益相關部門的成員結成同盟、構建關係網路、相互之間童工談判為那些表面看起來無法解決的問題尋找雙方都可接受的解決方案，學會討價還價。

五、身先士卒，勇往直前

項目經理需要如實地評價自己的優缺點。任何人都不可能掌握所有需要的知識和信息，也不可能精通所有的項目工作。承認自己的局限性，充分發揮下屬的長處，作為項目的推動者。而且還需要具備的能力有：到哪裡去尋求合適的幫助，以及如何提出正確的問題。

提出問題不是簡單的問話，好的問題是對下屬的一種挑戰，這類問題都需要做出明確的回答，而不是似是而非。項目經理的工作就是提出問題，要求下屬從各個角度和各種可能去考慮問題，並協助他們做出合理的決策。

六、理解成功的含義。

項目的成功不但受預算、進度和績效影響，還有第四維度－－客戶使用效果和滿意度。所有工作都必須保證符合客戶的需求為己任，項目經理必須聽取客戶的意見和建議，並作出相應改善。項目的未來使用者才是項目成功與否的決定因素！

七、建立並維繫團結緊密的團隊。

團隊氛圍越健康，項目成功可能性就越大。極盡所能建立並維繫這種團隊。

八、熱情和絕望都具有很強的感染力。

對項目的信心，團隊整體都會從項目經理所表露的態度和情緒獲得暗示。當團隊成員提出建議或者了解到最新進展情況時，項目經理必須以誠相待，態度誠懇永遠比敷衍了事更能贏得團隊成員的感激。

九、向前看遠勝於向後看。

用不停歇的提出「如果...那麼..."的問題。「如果...那麼..."的問題實際上表明，我們永遠也不應該滿足於項目工作的現狀。導致項目失敗的首要因素就是缺乏解決問題的機制。所有保持長遠眼光可能對某些經理人員來講非常擾頭，但是這做法有非常重要的意義。我們無法控制未來，但是我們能夠積極地對其做出回應。

十、時刻牢記自己真正的使命。

不要失去對項目自身目標的認識，不要被瑣碎的小事所困住。項目經理無論是使用何種技術手段，都必須讓所有團隊成員保持對整體目標的清醒認識。成員是否領會？可通過「間斷地考察他們對目前狀況的認識。他們應該了解自己對於項目整體計劃做出了怎樣的貢獻。他們能否清楚地認識團隊其他成員的具體貢獻？如果不了解，則需要更多的精力去建立他們對目標共同的認識。

十一、謹記利用時間。

＊進行現實的時間預測，不要給自己留過多的餘地。

＊確切了解上級或客戶的具體需求

＊準備應急計劃（進度順延，團隊關鍵成員的流失）

＊在需要時隨時修正最初對時間的預計，並提供一系列變通選擇。

＊確保各項因素的落實（具體內容、資源情況等）

＊學會說」是的，並且....「，而不是」不，但是。。。「談判時解決問題的關鍵。

十二、最重要的是計劃，計劃，計劃

儘可能在第一時間就對各類事項做出正確處理，包括但不局限進度安排、構建團隊、明確項目具體內容和制定預算。但過分精細或複雜的計劃可能對項目也會有不利影響。所以項目經理必須進行計劃，但是還必須保持足夠的清醒，以便隨時發現錯誤並相應修正自己的戰略計劃。俗話說「計劃沒有變化快」。

答案一定是「否」，當然項目人數在七人以下的可以例外，畢竟可能技術總負責也是你兼任的。

之前有個回答可參考：http://www.zhihu.com/question/19677325/answer/85506527

我也是做運營商行業的項目經理，向來把人放在第一位，準備進項目組的人要打聽能力和工作態度，口碑不好的找個借口換掉。面試優先順序最高，超過一般的會議。

另外以前我也是個喜歡做監控的人，整天盯著進度和承諾，近來逐漸有些改變，一直在給項目組灌輸：交給你的事就應該做好，如果做不好提前叫，提前求助。不會再耗費自己的精力盯著別人幹活，隊伍反而成長的很快。

當然，我會有一個合格的技術負責人，如果沒有現成的，那就培養一個。

PMBOK.

推薦這本書，項目管理是很複雜的一個系統工程，需要系統的知識來運作，我覺需要結合PMBOK這種系統的知識體系和方法論並結合具體實踐，不能簡單地靠幾個地方的優化就達成理想狀態；

抱歉，看你的問題就想先武斷地猜測一下你的能力，感覺做項目管理，你缺少兩個最核心的知識和技能，既不懂項目管理該做什麼，也不具備技術能力。好在從你寫的東西來說，溝通能力還行，就有可做，否則會直接建議你別做項目管理了。

前面朋友在教你的怎麼做項目管理，抓大放小，管好節點和介面，說得真心好，我就不重複說了。我覺得有個根上問題咱得先想清楚，什麼叫細節什麼叫大局？不是所有團隊或者參與人做的事情都是細節。項目經理的核心是成功交付，關鍵的、影響交付的東西都叫大局，都得了解、理解還得有能力控制好，比如你說的客戶需求，那個要叫細節，項目中沒大局要項目經理管了啊。大路線要抓住，簡單說客戶需求是什麼，哪個主哪個次，排序，各個需求可實現程度、方法，內部外部資源需求和缺口情況，技術和管理的難度點，這些在項目里都是大局，要在項目經理視野思考中都隨時有數的。至於團隊做事具體的方法，每個具體操作文件的完成，他們間建立上下游的配合就好，可以當細節放權給大家，並且確定好界限，什麼情況視為大問題了會影響大局，要通知你。從你大小分不清來說，你不具備項目管理技能，也就更沒做到正確授權和建立團隊合作了。

說你技術能力也不夠用，來源於你的抱怨。你和客戶交流需求感覺很辛苦，團隊成員做的事情沒法快速了解質量並判斷與解決問題來講，你對應用技術掌握一般或者說有點差，做不到深入淺出，沒有什麼自信。

寫這個給你，不能單純打擊你，逞毒舌，那忒不厚道了。給你個建議吧，從溝通能力看你還是項目管理的可塑其才。先去學習一下項目管理，找找書看看，了解一下基本流程，關鍵要素吧。參加個Pmp學習和認證應該對你有幫助。學了這個，分得出大小，練習一下授權，技術上的缺陷用建好團隊正確授權來解決吧，發現技術人才充分合作，用好他們。