老K淺談項目管理

「目標清，範圍明，時間成本動平衡，用戶滿意是根本，團隊向心信息靈。趨利避害勤變更，取長補短定合同 」，短短的一句順口溜就涵蓋了項目管理的九大知識領域，今天老K只能淺談一下項目管理，講的淺還請一笑而過。

一、項目管理概述

談起項目，首先要提到它的一個關鍵特點：獨特性。何為獨特呢，獨特就是每個項目都是獨一無二的，比如項目目標？ 實現功能？時間長短？內外部環境？資源？約束？那麼多要素，所以沒有完全一模一樣的項目，那每個項目的管理辦法也就不是一模一樣的，故，項目不是一些模板式的流程、也不是書本上的各種技巧？他需要我們在每個項目中審時度勢，通過各種線索尋求信息、識別風險，針對性的採取措施，促使項目成功上線。

項目成功。那成功的標準又是什麼呢？按時上線？所謂的零缺陷？成本最低？高層十分滿意？對於不同的干係人，可能滿足某一條標準，項目對他而言就算成功了，但是對於項目經理而言呢，項目經理的成功，是在各類項目干係人中，尋求最佳的平衡，滿足了目標，滿足了鐵三角，避免了那些令人討厭的缺陷，迎合了市場等等。當然，每個項目都有關鍵性因素，但關鍵性因素的滿足，往往也是一種平衡。

平衡。在實際工作中的項目中，項目經理最常遇到的便是項目的工期被壓縮，被嚴重的壓縮，而且是再三協調又無法改變的壓縮，那我們需要如何去做呢？除了」向關鍵路徑要時間，向非關鍵路徑要資源「之外，還可以進行需求壓縮（時間和範圍的平衡），開發和測試的進度壓縮（時間和質量的平衡）；一個好的研發團隊，時間在非常緊急的情況下，往往也會通過縮減範圍（非需求）的方式首先滿足高優先順序、重要性的功能。總之，不要認為得到了時間，也會得到其他，這其實都是平衡的取捨。最後，想說的一點是，很多大企業盤根複雜，所以，項目往往會採取一些極致的手段（流程規範等），確保一些關鍵因素的成功。

說起範圍，便想到了項目中的信息獲取，項目從開始到結束，其實全部都是信息獲取的過程，初期獲取客戶和需求的信息，以及後續獲取項目的進程、開發和測試的信息、缺陷的信息等等；項目的管理更是如此，也是一直獲取信息的過程，好的項目經理，要不過各種不同的方式去獲取信息，分析信息，發現風險，提出方案，解決風險。

風險。風險其實就是阻撓項目成功的各種絆腳石，那如何想要項目成功呢，那就是幹掉絆腳石，所以說，項目成功的目標就是發現風險、發現風險、發現風險！

綜上，項目管理是非常注重實效的，它需要我們實戰、實戰、實戰！正如張無忌學太極劍一樣，先記後忘，最終達到伺機而動，見招拆招的境界！

說了一些整體性的，後面再簡單說說項目的啟動、排期和項目的掌控。

二、啟動項目

項目開始後，首先我們要確保項目的儘快開始。這裡面有需求的平衡，有計劃的平衡，對於「度 」的掌握，只能根據團隊的不同特點來定。如果每次需求不完善，導致研發團隊對需求的理解、評估產生了極大的影響（風險很大，必須先解決），那需求就不能從簡，即使在敏捷模式下，需求的質量如果引起了很嚴重的後果，那就必須採取措施，採取瀑布流的一些做法也是可行的。如果需求在分層、在需求框架等方面都做的非常好，和團隊一起達到一種循序漸進的開發，那需求就沒必要那麼繁瑣，儘快的啟動就可以讓更多的風險暴露在我們面前。

項目初期，很多人喜歡制定非常複雜的計劃，把項目後續的每一項事情都考慮了進來。其實，這是一種不妥的做法，因為項目的風險是隨時產生的，為了解決風險我們會採取各種解決方案，甚至會對我們的計劃產生極大的影響。所以，我們需要波浪式的計劃，因為他會隨時在變，另外，計劃制定時，我們要重前期，輕後期，並在項目的不斷進行中，逐步豐滿。

項目啟動時，我們需要確定里程碑節點，這會對研發的一些關鍵活動進行指引和限制。

最後，如果項目感覺沒有頭緒時咋辦呢，我們可以採用試點的方式，也就是我們常說的哈德遜灣式啟動。儘快的迭代，儘快的開始，才會有更多的思路和方法。

三、項目排期

需求評審後，我們要進行研發的排期，這裡牽扯需求的拆分、任務的分解、介面的識別，工期的評估、人員的分配。

首先，研發會按需求的優先順序進行選擇，先實現優先順序等級高的功能。最後實現優先順序最低的需求（在風險大時可放棄），這便是我們常說的，永遠在做最重要的事情。

識別優先順序後，便進行需求的拆分，需求的拆分，其實是對需求深刻理解的過程，團隊人員一起針對需求提出討論，這其實便是提前規避了需求理解不充分的風險，在拆分的過程中，我們還能識別介面，及早與介面方對接。

在工期評估時，我們常採用卡牌出牌的形式評估，這有利於團隊熟悉需求、確定研發方案和工期的相對準確性，另外，這是團隊自己主動給出的時間，執行起來的偏差會很低。

之後我們根據優先順序和工期，再確定對應的開發人員、測試人員等。這樣，一個簡單的、團隊內部認可的工期便可以引導大家絕大部分的工作。

最後，在項目排期時，有的團隊喜歡按小時計算工期，有的團隊喜歡按天計算，這其實要依據項目、團隊來定的，我們最主要的是保證他的相對準確性，而不是他的衡量標準，過渡關注「小石子」的顆粒度，會慢慢陷入日程安排遊戲，在後期的工作中不厭其煩。

四、掌控項目

如何掌控項目，我先從6個方面進行闡述：

1、業務理解：無論是需求、UI、開發還是測試，對業務、規則的理解程度直接決定項目的質量，我們通過各種方式（需求拆分、規格文檔、需求反講、團隊任務拆解等），目的就是為了加深大家對業務的理解，提前規避需求不明確、需求理解偏差、傳遞偏差的風險。

2、里程碑交付物：項目進行中，我們需重視里程碑，更需要重視里程碑的交付物，它可以是代碼、可以是文檔，可以是一次代碼review，更甚至是一次培訓或者一次面對面的交流，我們要監督每次交付物的質量，規避風險。另外，比較重要的一點便是按功能交付，增量式的交付，這樣不但能提高產品的質量，更極大的提高了機動性。

3、晨會&看板：晨會是非常重要的一個環節，他能促進研發的進度，促進產品研發和測試的溝通，識別風險，當然，晨會絕對不是解決問題的戰場。

4、進度監控，信息獲取：我們通過項目報告，項目儀錶盤等來監控項目的進度，收集信息，發現風險。這裡更重要的是信息獲取，通過各種方式來獲取信息（溝通很重要），發現偏差後及時糾正，關鍵時刻也可通過日計劃進行推進。

5、人員狀態：一個團隊的狀態很重要，如果發現一些令團隊或者個體不愉快的事情，這其實也是一種風險。

6、拒絕打擾：「流」是研發人員的一種狀態，當研發進入「流」之後，效率會極大提升，當研發人員沒有入「流 」時，效率會大大折扣。所以，我們要儘可能少的打攪研發人員（包含測試人員），以免在任務切換和入「流 」中浪費大量時間。當然，在同一段時間，研發全身心僅處理一件事情，效率也是極高的。除了人員打擾，項目不被打擾也是極好的。

今天，就簡單和大家分享這些，後期再和大家逐步分享，這些只是項目的冰山一角。比如為什麼不倡導過渡設計？項目為什麼在很好的勢頭下突然結束？項目經理為什麼期待需求變更？怎麼保證項目的高質量？如何培養團隊的全局性？為什麼要敏捷？為什麼要持續集成？等等，更多精彩，請持續關注「巧吧軟體測試」公眾號，二維碼如下：

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！