Team剛剛完成了一個敏捷專案，做一下專案總結，以備以後借鑑和提高。

需求 - 溝通 – 人 - 過程 - 工具

專案要成功的最關鍵因素是什麼？軟體要快速高效又高質量的提交靠的是什麼？有人說最關鍵是專案經理，關鍵是溝通，有人說是技術設計，有人說是對需求的把握… … 從我看來，都是盲人摸象，專案要成功，軟體要快速高效又高質量的提交，靠的是多重因素的整合和平衡；首先要對需求的準確理解和把握，貫穿全流程的溝通，做專案靠人，對人/士兵的管理（物質、心理），適合組織的先進的過程（開發，測試，評審，組織，考核），還有工具的運用和整合大大提升組織效率，缺少那一樣都是不行的。成功的模式只有一個，而失敗卻有各式各樣，就是這個道理。

溝通，隨時隨地，全方位立體的，有效的，及時的溝通

溝通，溝通，隨時隨地，全方位立體的溝通。面對面、站立會議、咖啡間、IM、Email、文件、電話。上下級、跨部門、客戶，溝通，直到雙方的理解沒有Gap（鴻溝），沒有Misunderstanding（誤解）。主動溝通，有問題隨時反饋。對被動的同事，主動問他。注意溝通的效率和時間表，不要一個會議開兩個小時。如果有必要，儘量讓少的人蔘與，除非是kick-off會議。此外，溝通會影響時間表，比如你有個問題要問某人，而這個人下週開始休假了，要早做預防。否則，吃虧的是自己。

白板，任務板，Sketch，Prototype

Team位置必須坐在一起，最好是圓圈式的座位，旁邊有玻璃白板，上面畫好下一個里程碑和Release的Roadmap，玻璃白板便於馬上溝通。任務板便於大家清楚當前致力的目標和Release。對於Sketch要用好，在產品或者功能還沒有做出來以前，先把Sketch或者Prototype發給客戶看一下是否認可，獲得用好Remarks，然後再開始動手；畢竟動手了再修改代價就更大了。所以一定要用好Sketch草圖。

Stand up meeting要不要

很多人說到Scrum就要每日晨會Stand Up Meeting，但我們Team的實踐來看，並不是必須的，其實敏捷也是根據組織和專案實際情況因人而異的（有人說敏捷對結對開發人員的能力要求很高，我覺得敏捷是一種境界，良好的架構，程式碼規範，成員間非常好的默契，才能敏捷的起來）。不能拘泥於形式主義，我主張實用主義。現在不是有反敏捷、有瀑布敏捷（Water-Scrum-Fall）、實用敏捷嗎？關鍵是我們還沒有領會敏捷的深刻內涵和思想體系，不會用敏捷的思想和思維方式高屋建瓴的思考我們的開發流程，而只是依葫蘆畫瓢學個一招半式，那就真的不是敏捷了。我聽到有人說，敏捷只適用於產品型公司和小型專案，還有人說敏捷只適合於需求不穩定的專案，還有人說敏捷了就等於速度快，就等於客戶報價可以低一些，還有人說敏捷說的什麼迭代持續整合和重構都是理論，沒有考慮到實際執行起來的風險……都沒有錯，關鍵是我們還沒有領會敏捷的深刻內涵和思想體系，不會用敏捷的思想和思維方式高屋建瓴的思考我們的開發流程，而只是依葫蘆畫瓢學個一招半式，在這兒討論，說白了還是理論，坐而論道不如起而行

保證程式碼質量

如何獲得高程式碼質量？打個比方，現在要打仗了，如何打個漂亮的勝仗。我想你肯定知道答案了。那就是你的隊伍必須各個是精兵，能力強，平時訓練有素，而且還有實戰經驗，這樣的一個兵強馬壯的精兵隊伍你拉出去，只要指揮好，士氣高，就能打漂亮的勝仗。OK，現在你明白了，軟體開發何不如此？你手下的程式設計師是不是技術能力很強，是不是平時就對技術研究很深，對某科技術有很深的理解，還有很多專案經驗，是不是幹勁十足，是不是對他們做了培訓，是不是做了程式設計規範的要求，都明白了命名規範、異常處理、日誌處理、安全性、使用者許可權、配置檔案、設計模式、執行緒安全、單元測試、除錯技巧、條件編譯等專案標準處理；如果還沒有這些標準的貫徹，那你的士兵還需要培訓（訓練），這樣子上戰場會很危險。當然，有個變通辦法，讓資深程式設計師帶小弟，小弟在一邊看著，下個專案備用。當然。除了培訓以外，分享、知識庫都是團隊很重要的機制。

基礎不紮實的程式設計師程式碼質量不會高起來，比如有的C#程式設計師根本理解Task.Factory.StartNew這句話是非同步執行的執行緒池起執行緒，就把它放到同步的迴圈裡面，導致問題。再比如，有的程式設計師用匿名函式，不懂閉包，導致放在迴圈裡面每次取到的都是最後一個值。再比如有的程式設計師不深刻理解Session，就認為瀏覽器關了Session就沒有了。再比如有的C#程式設計師不理解GC以為一個類只要實現了IDisposable介面就一定會記憶體釋放……舉不勝舉，都是專案中遇到過的（注：對基礎不紮實的程式設計師進行程式碼Review管用嗎？我們專案實踐來看不管用，因為資深程式設計師很忙，不可能一行一行去看去除錯。）……所以，優秀的程式設計師都是建立在對該技術的深入理解的基礎上的。優秀的成熟的程式設計師員工都有專業化（技術方面）、職業化（服務意識、協作能力、解決問題的能力和態度）和商業化（替客戶思考和解決問題）多方面的優秀特質，才能真正的為業務創造價值。

保證程式碼質量的另外一個非常重要的方面就是測試，一定要寫單元測試，使用Moq做單元測試。這可以培養程式設計師面向介面的思維方式，如果程式碼不能做單元測試往往是耦合度很高的程式碼，所以單元測試能發現程式碼質量的問題。此外，測試組的工作要及早介入，對業務的深刻理解，重複利用bug管理工具，敏捷測試。

為需求變化和維護早作準備

在系統設計的時候，要考慮到未來可能的需求變化，做好面向變化的架構設計。但不要過度設計。（這需要深入理解商業需求）

為維護早作準備，意思是說，在編碼階段，就要考慮到系統的可維護性，設想你自己就是將來維護這個系統和這段程式碼的人，這種意識很重要。有的程式設計師以為系統提交了上線了就沒他的事情了，結果到頭來上線了出現問題，系統又沒有很好的log和trace，導致問題極難線上除錯，而線下又不能模擬真實的環境，這種情況下必須為維護而設計，提升系統的可維護性、可追溯性、可管理性。

不要過度設計和過早優化

過度設計是敏捷開發應該避免的，很多工程師都有過度設計的衝動。例如，在一個web系統還沒有看到被大規模使用的曙光以前，就設計了系統規模化，什麼叢集、負載均衡、讀寫分離、分散式快取系統……說真的，這些東西確實是好東西，但也很貴。在系統還沒有被大規模的使用者接受和喜愛之前，這樣做是否會抵消了我們把專注點放在核心功能和簡練和簡單的努力呢？時間是有限的，投資也是有限的。我們必須把有限的時間和有限的金錢用在當前最核心的功能和體驗上。有時候系統初期，可能一兩臺伺服器就足夠了。只有在看到產品有被大規模使用和使用者喜愛的曙光之後，才來增加功能和規模量。當然，你的網站功能，在你只有 10 萬用戶的時候，可能和你有 1 億使用者的時候會很不一樣。所有太多太早太頻繁的架構上的大動作可能會適得其反。這一點上，你要小心判斷。系統架構需要及早規劃，但不要提前實施和過早優化。

關注非功能性需求

也許大多數客戶和諮詢師也會聽說過神馬TDD、迭代、原型、持續整合和持續部署、Agile等時髦的詞語，這些也讓管理者很興奮，以為軟體產品是可以在很短的時間內高質量的完成的，即使完不成也可以在後面用TDD，快速迭代，不斷重構，持續整合直至持續部署的方法在進行軟體開發。這聽起來好像很美好。但其中有個很大的陷阱，那就是客戶和諮詢師，還有原型、TDD大都只關注功能性需求，而忽略了非功能性需求，比如效能問題，高可用性問題，系統維護問題（模組的耦合問題），等等。客戶和諮詢師在專案前期閉口不提這些或很少提及，但一旦功能性需求都做完了他們就會抱怨這些隱藏的非功能性需求。而像效能問題，高可用性問題，系統維護問題（模組的耦合問題）等並不是很容易重構，往往涉及到Re-design, re-architect；因此這些問題往往都在後期會成為重構噩夢，甚至可以讓你的軟體設計重新來過！更加糟糕的是，大多數客戶不願意為這些隱藏的功能重構而付錢。筆者曾經遇到過前期只注重功能性需求而後期發現效能不好而進行re-design, re-architect，這對專案管理來說有很大的挑戰，因為不單單是程式和架構重構的困難，還要面對時間和人力成本的增加，最難的是你還要面對的是團隊士氣因為不斷的rework而逐漸低落併產生厭倦和懈怠情緒。這是一個很大的陷阱。

所以，前期就要關注非功能性需求，不要急於動手，如果你能有多一些時間去和客戶討論一下需求和未來可能的變化，去調查一下實現的技術難點和細節，去和其他有經驗的人討論並推敲一下架構和設計，去思考設計上的缺陷，那麼，你的coding會變得非常地直，直到你一眼就看到盡頭，你的測試案例也會寫得非常地好，你會幾乎不需要重構，於是，你會在未來少寫很多程式碼，從而你的軟體開發會越來越輕鬆，直到技術開始換代。這就好像我們修路造橋一樣，我們需要花大量的時間勘測地形地質，分析資料，思考可能出現的各種問題（各種自然災害），評估不同的設計方案，而不是先儘快建好再說。(：磨刀不誤砍柴工) 說到這裡，有些反敏捷（反Scrum），沒錯，好的程式設計師要會做權衡/平衡，好的架構師要會做平衡，好的專案經理也要會做平衡，這非常重要。

再補充一點，有資深經驗的工程師/架構師對非功能性需求的設計和平衡很有經驗，這些經驗對系統設計和專案成功至關重要。如果你很不幸，手頭沒有這些有經驗有價值的人，而只有一堆碼農，那麼恭喜你，你可以在一張白紙上畫畫了。就開發他們的潛力吧，做好這個專案給他們積累經驗的心理準備吧，量力而行吧，小馬過河吧……實在不行你就自己上吧，畢竟公司要求用最少的錢在最短的時間內出來最優秀的東西；如果你有話語權，那就把你的困難及早讓上層知曉。

嚴格控制需求和範圍，和進度權衡，不出現資源空閒

領導一般會給專案經理壓力，要求在什麼時間提交一個版本趕進度等，這時候專案經理要麼能調整一些需求和範圍（Scope），要麼就把可能出現的問題進行報憂，因為現在如果不這樣做，你就等著現在報喜，後期報憂吧。所以專案經理一定要嚴格控制需求和範圍（scope），和進度，和質量權衡。同時要合理調配資源，不要出現專案進行中資源空閒的情況（這個在Project工具中可以看出）。

專案風險管控

專案經理要有專案風險管控能力，及時在專案進行的各個階段進行風險的預識別和管理。專案一般是前期工期鬆，風險低；而後期工期緊，風險高。所以專案經理要儘可能在專案早期能列出大部分的風險，這樣在專案的風險應該是倒三角形狀的，就是前期風險多，後期風險少。要預先把下階段可能的風險明確告訴客戶，讓客戶提供幫助來控制風險的發生，同時迫使客戶加強風險意識，不讓需求任意擴散和蔓延。在各個階段都要有雙方風險認知的會議紀要記錄。一般情況下，專案的外部依賴條件是最不可管控的風險（比如要和第三方聯調，要第三方提供API等）。其次是需求的不明確和需求蔓延的風險（需求問題佔專案成功的40%因素以上，你能控制需求，你就成功60%了）。然後還有資源的可用性（如：專案進行中核心人員流失，要知道專案進行中間換人和加人都很是問題）。

資源提供者和問題解決者

大家都知道，打仗的時候什麼最重要？對了，補給（後勤保障）。士兵上戰場了，誰做後勤？專案經理。每天都要問大家，你下一步需要什麼，你還缺什麼輸入？你有什麼問題需要我這邊配合的？程式設計師旁邊有垃圾了，專案經理去掃一下地，這就是後勤補給。所以管理者首先要理順管理者和人的關係，調整好服務的意識，做好資源源源不斷的提供、幫助大家解決問題，系統就有了潤滑劑，有了源源不斷的輸入，就能順暢的開展。否則，千里馬到你手裡也跑不快的。

管理使用者期望

對每一個Sprint提交，謹慎選擇功能集合，多和客戶溝通，管理好使用者期望，他下一階段希望有什麼功能，這些功能的優先順序如何，實現難度如何，及早告訴他下一個版本會友什麼，不會有什麼。

增加團隊成員之間的親密感

有時候如果一個團隊成員裡面有多個牛人，大家都是很有主見的人，就很容易在一些問題上爭執，甚至產生內部競爭。兩個聰明人意見採取誰的呢？緊張關係在所難免。這種糾結的合作和競爭關係是同事關係的主線。但要保持合作為重點。所以，要把這樣的狀況保持在一個健康的狀態，需要加深團隊成員的親密感。具體來說，坐在一起聊天、吃午餐、喝咖啡、散步、打球、打牌，都是增加親密感的方法，這樣拉近人與人的距離，就不會覺得有什麼競爭的緊張感了。

管理團隊目標和情緒

Scrum有一個優點就是短週期快速迭代，每週大家都有明確的目標，因為Release週期很短，大家Vision很明確，所以為什麼Sprint就是衝刺的意思。管理好團隊的目標、Vision，有明確的目標，有衝刺的幹勁。及時發現團隊的情緒波動，採取應對措施（休整，腐敗，激勵）。

保持耐心，不斷調整

技術上要重構，架構改進和提煉等。信任程式設計師，給他們時間來重構，來調整和優化架構等。管理上要重構，程式碼促進委員會，評審組等等。改進適合組織規模和業務發展的流程，目標是獲得持續、快速、更好質量的交付產品和更好的客戶滿意度、更低的成本和更高的效率。總之，要不斷努力，不斷調整，不斷嘗試新的方法，做的越來越好。要保持耐心，給員工/系統的成長/成熟一點信任和時間。

專案經理的人格魅力和以德服人

作為專案經理您必須與同事以團隊合作方式才能保證專案的順利完成，如何鼓舞團隊成員的士氣？讓大家心甘情願的與你朝著共同的目標努力。要做到這一點，人格魅力非常重要。但要讓大家真正服你，真正的服是以德服人。比如，你要求所有的手下都主動配合你的工作，但是你自己如果沒有首先要求自己主動配合大家，你就不會贏得大家的尊重。這只是一個例子而已，很多點滴細微之處會讓大家感覺到你的人格魅力，究竟是一個值得尊敬的人，還是一個不值得尊敬的、自我的、高高在上的釋出命令者。總之，做人是最要緊的，做人沒做好，做事肯定做不好了，專案多半要搞砸。

但就專案經理的專案管理能力來說，也關係到專案的成敗，比如能否引導客戶需求、對問題的透徹理解、對複雜的任務緊密跟蹤並設定輕重緩急、利用各種渠道和方法來溝通解決問題、有能力做出適當的取捨、說服客戶或領導的能力、推銷自己解決方案的能力、突破性格制約的溝通技巧、面向全域性思考的思維方式、如何合理動態分配大家的工作項使不被Block住……

總結

先寫這麼多吧，想到了再補充。

Update：現實專案管理中的一些實際矛盾

4. 專案經理兼任Team Leader的矛盾

專案經理和Team leader這兩個職位貌似是一樣的，其實不一樣。專案經理的職責包括：專案進度控制，成本控制，需求控制，風險管理，配置管理、任務分配以及與客戶相關的溝通和交流等。而Team leader的主要職責包括技術方案確認，開發計劃制定和跟蹤，技術架構設計，重要技術問題攻關，核心程式碼編寫和技術指導以及開發團隊管理。對於小公司來說，為了節約成本很可能把兩個角色讓一個人來承擔，這樣的混合角色對個人能力要求非常高，需要兩方面的專業知識，兩方面都得一手把握，壓力很大。現在很多大公司基本都將這兩個角色分拆了，專案經理就是管進度，做協調，Team Leader就負責開發相關事宜，另外還有一個角色，叫Product Manager，這個角色主要是市場和開發之前做協調了。按照我的理解，專案經理需要對專案功能和需求（產品）有非常深入的瞭解，對軟體開發過程相當有經驗，同時具有很強的溝通能力，因為客戶都是牛的一塌糊塗，你要引導客戶的需求，那是溝通功夫了得。另外，專案經理是專案總負責人，對領導對跨專案和部門也需要及時的溝通協調以獲得最佳的資源，以解決過程中的問題。而Team leader需要控制開發過程中的系統性風險，總體架構把我和關鍵核心部分開發。軟體開發過程有很多的環節，任何一個環節出現大的差錯都會導致焦頭爛額並最終專案失敗。但是在大多數公司，我們都不會稱其為失敗，一般會說：專案延期，好的延期半年，差的甚至有的延期1年！核心競爭力：開發管理＋過硬的技術能力。

5. 有限的資源和時間與按時上線的矛盾

分配任務的核心原則，就是先分清輕重緩急，作為管理者，一定要將它養成習慣。  

Update：優秀專案經理必備素質

專案經理是專案的負責人，不管發生了什麼，都能按時交付，優秀專案經理要具備這個素質。充分理解需求和範圍，充分和客戶明確詳細需求和期望，充分考慮自身團隊的技術能力、專案依賴、隊員排期衝突、負面情緒、技術方案風險、未預知的技術障礙、需求變化等。具備為功能的設計做取捨的能力，但功能取捨並不以犧牲產品的核心願景為前提。具有極強的交付能力的前提是具有極強的責任心。有了責任心，你會把專案當成自己的孩子，傾注你的全部心血，即使出現極端困難的局面也會死扛。責任，會驅使你關注專案的進度，千方百計去尋找各種資源，推著專案往前走。甚至吃飯、睡覺，走路、坐車，都想著整個專案團隊，想著他們還在加班加點，你可能很自然地給他們帶點夜宵、衝杯咖啡，犒勞員工。有了你這樣的專案經理做表率，整個團隊會鼎力支援工作，士氣非常高，技術問題也迎刃而解，得到領導稱讚和客戶肯定，專案將朝著預想的方向發展。許多開發人員抱怨專案經理一天沒幹多少事情，而工資還挺高。其實，專案經理一刻都沒閒著，他總在想著怎樣更好的執行專案計劃，調整專案進度等，腦子一直在不停地運轉，所以說專案經理是真累。

Update：Scrum Checklist中文版下載

Update：敏捷專案中的風險管理

How does Agile address these particular five areas of risk?  Let’s discuss...

1. Mitigating schedule flaw is the biggest risk out of the five risks in terms of its planned versus actual performance. Estimating is a guess, a forecast. It is not an exact science. Scrum provides feedback loops to mitigate invalid guesses. Teams update the release plan at the end of every sprint with the emerging information gained from their last sprint timebox. Traditional projects take an estimate early in the project and don’t look back as they trot to the finish line - even when the guess (estimate) is discovered to be wrong. Agile gives you the feedback loops to refine the plan as the project moves along through prioritizing the product backlog to deliver value sooner (based on value, not time) by looking for early release opportunities (combining value with time).
   
   
2. Mitigating Specification Breakdown is resolved in agile by having a product owner to communicate the customer needs and decisions about what the product should do. Stakeholder expectations can be overwhelming for delivery teams if they don’t have a dedicated product owner to help point them toward what the customer needs. A scrum delivery team will work collaboratively with the product owner to ensure alignment between what is requested and how it can be delivered.
   
   
3. Mitigating Scope Creep is part of every scrum ceremony. The product owner, and other stakeholders, will discover new things to include in the product as they see progress from the delivery team throughout the sprint. During the demo at the end of the sprint, feedback from attendees will generate new backlog items. The product owner will evaluate the new product backlog items and decide what action to take:  add, delete, trade-out in priority with other product backlog items.
   
   
4. Mitigating Personnel Loss on agile projects involves having self-organizing teams involved in focusing on work and problems to solve, thus resulting in higher morale. Traditional projects that focus on “death marches” to deliver the work experience with low morale and a higher risk for turnover. Working in persistent teams does not mean that you are signing a contract for life to never leave the team. There will be turnover in any team. I am saying the turnover will not be based on traditional project “death march” criteria - low morale.
   
   
5. Mitigating Productivity Variation is the difference between the assumed and actual performance of the team.  In agile projects, we extend this variation to include the performance of the product. Scrum delivery teams address the performance of the team at the end of every sprint as part of the sprint review. Mitigating or correcting the difference variation happens in the next sprint. If a team is failing to meet its commitment, they will look to commit to less work on the next iteration. If the product is failing to meet the customer’s needs, those issues will be corrected through the product owner’s managing of the product backlog. Teams guess on how much work they can do in their first iteration. After three or four iterations, teams establish a low confidence, medium confidence, and higher confidence velocity.  Velocity - the amount of work done - for an agile team acts as an indicator that teams can use to forecast work past a single iteration and can be used to help mitigate productivity variation.

1. Integration Management
2. Scope Management
3. Time Management
4. Cost Management
5. Quality Management
6. Human Resource Management
7. Communications Management
8. Risk Management
9. Procurement Management

Update：專案管理簡圖

Update: 海爾集團的PDCA管理法

• 在計劃階段，要通過市場調查、使用者訪問等，摸清使用者對產品質量的要求，確定質量政策、質量目標和質量計劃等。它包括現狀調查、原因分析、確定要因和制定計劃四個步驟。
• 在執行階段，要實施上一階段所規定的內容，如根據質量標準進行產品設計、試製、試驗，其中包括計劃執行前的人員培訓。它只有一個步驟：執行計劃。
• 在檢查階段，主要是在計劃執行過程之中或執行之後，檢查執行情況，看是否符合計劃的預期結果。該階段也只有一個步驟：效果檢查。
• 在處理階段，主要是根據檢查結果，採取相應的措施。鞏固成績，把成功的經驗儘可能納入標準，進行標準化，遺留問題則轉入下一個PDCA迴圈去解決。它包括兩個步驟：鞏固措施和下一步的打算。

上海通用汽車公司成功地把此方法應用於自己的經銷體系中，極大地改善了經銷商的服務。在其近100家經銷商中，上海通用奉行的政策是，對一些業務表現不好、不能完成上海通用的要求、不能在市場上進行有效的開拓，或者在售後服務方面不能夠完全按照上海通用的理念和規範去操作的經銷商，會先給他們做一個PDCA改進計劃。完成了這個計劃性的四部曲後，經銷商的整個市場營銷的管理工作應該會隨之步入一個良性迴圈的軌道。如果還是不行，經銷商就會被淘汰掉。
由上可知，PDCA管理法的核心在於通過持續不斷的改進，使企業的各項事務在有效控制的狀態下向預定目標發展。

Update: 幾大令人頭痛的管理難題

1. 如何激勵團隊？

金錢並不是所有的因素，如何給團隊注入正能量，給予下屬充分的肯定，甚至是冒險的空間。這是個問題。而如何持續給團隊注入正能量的活力則是一大挑戰。

2. 如何解決團隊合作問題？

你把整個團隊看成一條船，制定一個明確的航行目標，明確規則和職責。要知道，職責不明往往帶來各種扯皮。而且，不同部門的不同人都有各自的利益，要事先未這類衝突想一些解決方案。

3. 如何管理更有經驗的人？

讓更有經驗的人來挑重擔往往能降低風險，謙虛些沒什麼錯，不妨多聽聽他們的意見，但也要自信別怯場，相信自己肯定有過人之處，你必須不斷學習新知識，但也要想辦法多發揮有經驗人士的才幹。

4. 如何在團隊中建立信任？

一個不公平的領導是不值得跟隨的。關鍵是要保持客觀、中立、判斷力，不要輕易判斷是非。也不必刻意掩飾失誤。讓你的同事相信你在努力，你是客觀公平的，並且有解決問題的能力。

5. 如何和其它部門協作？

部門協作往往是完成公司更高層次的任務，每次多做點功課，知道每個部門的長處和特點，尊重各自的主管，明確自己在大任務裡面的職責和責任物件，遇到矛盾先冷靜。

6. 如何處理團隊動盪？

你可能面臨流動性的挑戰，因為一個組織裡總有經驗比你豐富的人，或價值觀與你不同的人，不過這對你是個好機會，你可以重建符合你價值觀的人員體系，組織也更加穩定。不過，要做好核心人員流失的預案和多米諾效應，這就是平時的功底了。 

做好PM的幾個關鍵點（轉）

在專案過程中，通過觀察，感覺做好PM這個角色需要做好以下幾點：

• 對專案關鍵點的細節要足夠了解 
  雖然PM可以不參與具體的編碼工作，但並不等於不需要了解具體的實現細節，特別是一些影響專案成敗的關鍵點。有些PM離技術越來越遠，遠到一些功能是怎麼實現的、用的是什麼技術、有哪些地方需要特別注意都不清楚，這會非常影響他的決策力和判斷力，特別是在處理突發事件時會手足無措。在現階段，特別是專案規模不大的情況下，感覺PM兼任架構師比較好。
• 對專案各個階段的時間點要足夠清晰 
  PM頭腦得時刻有一個清晰的專案roadmap，並對每個時間點做好準備，比如在專案立項前，預估好工作量和資源分配，與其他團隊協調好時間點和容錯方案；在需求評審前得組織專案骨幹瞭解需求並做好架構設計，與PD深入探討，避免業務上走不通；在設計評審前，得評估出所有風險點和合作方，並完成設計文件，與合作方充分探討合作細節，並達成一致；在提交測試前，關注各個任務的進度，特別是有風險的，併為測試準備好環境；在開發聯調前，與各個參與方的介面人聯絡好，並準備好環境；在釋出前，做好釋出計劃，預估出發布風險點。總之，需要對各個關鍵時間點有清晰的認識，提前做好準備，控制好風險。
• 處理好與其他團隊的關係 
  一個專案的成功不是隻靠自己這個團隊就能做到的，需要所有團隊的通力合作，因此，非常有必要學會與其他團隊處理好關係，而與其他團隊溝通的介面人主要就是PM，PM對於團隊之間的合作是否順暢起著決定性的作用。首先需要弄清楚什麼是原則性問題，什麼是可以退讓的，在有分歧的時候，要立即判斷出是否可以出做讓步。再則，一定得把問題想在前面，提前溝通，只要大家都是為了把專案做好，並在出現分歧前，就把這些可能的分歧點討論清楚了，就沒什麼很難處理的關係。最後，學會與任何型別的人打交道，林子大了什麼鳥都有，溝通不是為了爭個輸贏，而是達成一致，這方面的技巧就多了，需要學習和積累。
• 調動組員的積極性，儘量把事情讓他人去做好 
  在以前待過的一個專案裡，PM非常敬業，很多事情都是自己去做，結果出現一個很不好的現象，每天晚上，他的專案成員都走光了的時候，就留下他一個孤獨的身影，奮力拼搏，結果每次釋出的時候問題多多，驚險不斷。這說明一個問題，你不是一個人在戰隊，並且你不應該衝在第一線，PM的成就感不應該是你自己把事情給搞定了，而是在你的策動下，你的組員把事情搞定了，只有這樣專案團隊才有戰鬥力，並且其他成員都希望在專案過程中體現價值，你需要學會鍛鍊和培養其他組員，發揮他們的最大潛力，這也是為什麼在發揮同樣出色的情況下，納什比科比更容易獲得MVP的原因了。
• 處理好風險點
  PM可以把不影響專案成敗的點扔給你信任的人，但對於那些會導致失敗的風險點必須給予足夠的重視。我以前帶過一個小專案，其他什麼都完成很好，事情做得很漂亮，bug也沒測出幾個，但沒有review其中幾個比較容易出錯的SQL，但QA告訴我沒bug的時候我也沒去多看兩眼，結果它隱含了一個比較深層次的bug，在線上暴露了出來，造成了不小的損失和不良影響。其實，後來總結的時候，發現這個SQL存在明顯的疏漏，如果當時認真地review，並審視測試case，是應該能發現問題的。PM必須對各個風險點心裡有本帳，專案可以做得不漂亮，但如果在風險點上有任何疏忽，那就是失敗。
• 安排好任務，並清晰瞭解任務的進度 
  PM需要對自己團隊的組員深入的瞭解，瞭解他們的能力和興趣點，把任務交給最合適的人，並保持與他們的深入溝通，瞭解他們面臨的困難，你雖不是直接去完成任務的人，但一定是幫助別人完成任務的人。任務牆是個不錯的方式，能讓自己和他人清晰看到各個任務的完成情況，便與跟進
• 保持清晰的思路，儲備應對各種突發事件的措施 
  專案裡最需要保持思路清晰的人是PM，別人可以亂，但PM一定不能亂，特別是在有突發事情發生時。因此，PM有必要有意識地鍛鍊自己抗壓能力，比如多做專案釋出、設計評審和資料訂正的工作，並且要有意識地儲備一些應急方案，比如程式碼回滾，緊急釋出等等。另外，要清晰地弄清楚團隊之間和系統之間的依賴關係，往往這種依賴性是引發事件的根源。
• 保持平和的心態，多站在他人立場考慮問題 
  專案會進行地風風火火，專案成員之間也會爭論得很激烈，往往這種時候，保持一個平和的心態很重要。不平和的心態往往會導致不平和情緒，不平和的情緒就會導致更加混亂的局面。保持平和心態的辦法很多，很重要的一條是多站在他人立場考慮問題，一旦為他人體諒後，激烈的情緒會消退不少，並且在這種溝通態度的促發下，分歧方也會不由自主地為你考慮，非常有利於解決問題，達成一致。
• 加強專案自動化方面的能力 
  專案各個細節如果全都靠人肉去完成，會極大增加控制風險，而減少風險的最大利器就是用成熟的自動化方案去完成一些工作，特別是專案構建、持續整合和釋出等工作。PM應該在怎樣讓日常工作流程化和工具化方面多動一點腦筋，而這方面敏捷開發提供很多很好的思路和方案。
• 共識和決議要通過郵件發給相關人 
  在專案過程中會產生很多變故，需求和設計文件裡定義不了所以問題，為解決變故而形成的臨時決議一定要通過郵件發給相關人，不光是知會，更重要的是為決議提供證據，這些臨時的決議往往會引發問題，當問題產生追溯責任時需要用到這些證據
• 注意傾聽組員的意見，給他們留出足夠的發揮空間 
  特別是在大公司帶專案，組員都算是開發的精英，都不是甘於做個機械的coder，因此學會傾聽他們的想法，深入瞭解他們想得到的，儘量滿足他們成長需求，就算是由於專案客觀原因，沒法採納他們的建議，也得和他們把道理說清楚，不合適用強勢方式來決斷，畢竟技術人員的需求和管理不同一般
• 不以個人意願為基準，凡是以大局為重 
  PM也是人，在平時工作過程中，難免會帶有個人情緒，但PM應該清醒地認識到自己身後還有一個團隊，大家的情緒和狀態與自己息息相關，所以說話做事一定要三思而行，考慮清楚對別人的影響，切勿亂放炮，失去同仁的信任