如何做到事半功倍？淺談專案管理中的閉環思維

“騰訊遊戲學院”授權釋出

導語：談到閉環，想必大家都不陌生。本文將結合專案管理中一些實際的場景和模型，談談專案管理中的閉環思維。作者徐州系騰訊互動娛樂光子工作室群高階專案經理。

我所理解的閉環

我們先看看關於閉環的一個定義：閉環（閉環結構）也叫反饋控制系統，是將系統輸出量的測量值與所期望的給定值相比較，由此產生一個偏差訊號，利用此偏差訊號進行調節控制，使輸出值儘量接近於期望值。這裡有一個筆者認為特別重要的詞——反饋。回到我們實際的工作場景中來看，我們主動push的一件事，或者一個詢問，是不是都希望能夠得到對方的反饋？這就是最簡單的閉環。


前段時間在某微信公眾號上面看到這樣一篇文章——《一個人靠不靠譜，就看這三件小事》，文章認為，一個人靠不靠譜，其實就看這三點：“凡事有交代，件件有著落，事事有迴音。”而這正是筆者想引申和借鑑的閉環思維，如果別人發起了一件事，你不管做得如何，都要最後閉環到這個發起者。這是文章中所提到的觀點，也是筆者非常認同的觀點。

專案管理中的閉環

不知道大家是否有這樣的感覺，在做專案的過程中，或者是在平時的工作中，很多資訊的獲取，或者資訊的同步，都會相對被動。以下這些場景，大家是否有熟悉的畫面？


01、場景原型

場景1：開發側的前後臺聯調，大家一開始各自做自己的事情，到聯調的時候，總希望別人來主動發起，或者自己的部分寫完了，就去繼續做其他事情了；

場景2：PM安排好了一個需求評審會，需求評審完了，對應需求或者模組人員也落實了，卻總是要一而再再而三的催促之後，才會給出WBS分解和工作量評估；

場景3：提交了一個美術需求，安排了具體的負責人，也明確了設計時間，但到時間節點的時候，還是需要去問APM或者當事人，是不是已經完成了；

場景4：需求實現過程中，好像還挺順利的，但一到驗收環境，就各種問題頻出；

場景5：版本開始測試了，卻不知道測試的具體進度，以及是否有什麼問題；

場景6：老闆交代了一件事情，比如寫總結報告或者分析報告，自己寫完之後，郵件發給了老闆，但老闆可能過了好些天才想起來，還是會問，你報告或者PPT輸出了沒；

場景7：一件老闆比較關心的事情，安排自己去處理，比較複雜或者比較費時，短時間內給不了結論或者反饋，老闆因為關心，又來催問，想了解事情的進展。

諸如此類的場景，大家是否都曾經歷過？而這些場景，在專案管理過程中，時常會出現或者遇到，概括起來說，這些場景，都可以歸類為，沒有形成比較好的閉環，沒有形成比較好的反饋。

那麼問題來了，我們在輔助、引導和管理一個專案時，哪些是可以形成閉環的呢？這裡不去說專案的五大過程管理組，也不去講PDCA閉環管理，因為這些本身就是很好的閉環。


02、閉環模型

這裡要談的更多是聚焦具體團隊可以形成的閉環模型：

產品/策劃側：一個需求的提出，不管是美術落實還是開發落實，這個閉環就是PM有沒有落實下去，落實的是誰在做，什麼時候做，什麼時候做完，什麼時候可以驗收，驗收完，轉給測試驗證，這個需求最終實現。這就是一個完整的閉環。裡面其實是有一個大閉環和一個小閉環，小閉環：你提的需求，PM是否有落實下去，你確認了，這就是小閉環了；大閉環：什麼時候做，什麼時候做完，什麼時候驗收，然後到驗收完，就是大閉環。模型中標註顏色的部分，是在負責具體需求時，比較容易忽略的。專案過程中，有多少策劃同學是在提了需求之後，就基本上啥也不管的，也不專注去驗收需求的，可以自省。


開發側：接到一個需求任務，從需求的評審開始，到方案設計、編碼、聯調、自測、轉驗收、bug解決、需求完善、周知美術或者策劃驗收，才算一個完整的閉環。同樣，有不少同學可能只專注於自己的編碼和自測，但並沒有去同步或者沒有及時同步到相關人驗收。


美術側：美術方面的需求，設計的同學接到需求，製作完成，周知到下一個環節的負責人，然後在版本里面驗收完效果，才算一個完整的閉環。這點在以往的一些專案中，是很弱的一個環節，經常會在驗收版本的時候才發現，版本里面的美術效果和設計的效果差別很大，這裡很明顯的一點，就是驗收的環境，沒有把美術納入到驗收的閉環裡面來。


測試側：從需求評審開始，到用例設計、版本的測試、bug的迴歸、版本質量風險的評估和總結、專案報告的反饋，形成完整的閉環。而實際測試的過程中，因為週期往往比較長，或多或少會缺少中間測試環節或測試進度的反饋，也缺少版本質量風險的評估。


綜合以上閉環模型來看，每個團隊或多或少都會出現某個環節的遺漏，或者反饋不到位的地方，而這些情況累計起來，對專案的推進，會有很大的影響。作為PM，不僅僅要在專案的啟動、規劃階段做好，還應該將更多的精力放在執行和監控階段。

我們每天可能有75%的時間都在溝通，專案中的很多事情，我們是堅持“相信團隊，但必須核實”的原則。小團隊可能還好，專案事情的check、晨會等方式就能溝通清楚了，但在團隊規模比較大，專案團隊成員很多的情況下，什麼事情都要一一去check的話，會耗費非常多時間，而且一天下來，基本上沒有什麼收穫。如果check的時間耗掉太多，基本上也就沒有什麼時間去思考和解決專案中可能存在的問題，也沒有時間去彙總、整合專案的有效資訊同步給主要干係人，這樣勢必會導致一個惡性迴圈。

所以，筆者更加的認為，作為PM，應該要讓以上各閉環模型形成真正的閉環，形成良性的閉環，這樣不僅可以釋放大量的精力，也會事半功倍。

03、構建閉環

那麼在專案管理的過程中，如何更好的讓各個環節都形成有效的閉環呢？

3.1 規範流程

流程是為了效率服務的，通過規範專案開發流程，把大大小小的閉環串聯起來，形成專案的大閉環，這樣可以讓團隊成員清楚的知道，每個團隊在某個階段需要做什麼事情。下圖是我們在專案過程中總結提煉的一個雙閉環的驗收流程，在多個專案和實際反饋來看，是形成了比較好的效果，每個需求完成後，開發在自測期間，涉及到美術資源的驗收，就及時的周知美術負責人一起驗收，這樣可以很好的避免需求轉到策劃驗收時出現大量的美術效果方面的問題。


3.2 建立規則

光有流程還不夠的，因為流程並不具備很好的約束力。因此建立規則的目的很簡單，就是希望在有限的時間內，獲得有效的反饋，讓團隊互相形成一種約束力。比如，流程走到需求評審完，該輸出WBS任務分解和具體的工作量時，提醒過一次沒有按時輸出，可以豁免，後面還沒有按約定時間輸出時，那就有相應的懲罰措施了；同樣，比如美術設計完成時的確定，以及完成時及時周知到下個環節的負責人，提醒過一次兩次之後，還是沒有按時，那同樣也有相應的懲罰措施；策劃沒有按時體驗和驗收需求或版本的，也同樣有懲罰措施。建立基本的有效反饋機制，更深層次的目的是釋放PM，不用事無鉅細地去問，以此形成積極主動的、有效的反饋機制。但有一個前提，PM在定這些規則的時候，一定是要和團隊達成共識，切忌單方面的去制定某種規則，否則很容易適得其反。


3.3 用好工具

工具可以幫助我們在管理的過程中，儘可能的自動化。PM要儘可能的讓能夠自動化的都自動化，讓各個環節的閉環在工具中生根發芽，潛移默化，形成有效的自運轉，這樣才可以進一步的釋放自己的精力。


3.4 積極主動

流程、規則、工具，如果說是客觀上的可以形成有效的閉環和反饋，那麼積極主動，就是主觀上，是形成閉環的催化劑。我們很多時候都是多執行緒的工作狀態，可能會同時處理很多工，這也涉及到多工的管理。因此在很多時候，需要更積極，更主動的反饋，讓下個環節的負責人清楚的知道當前的情況，以便提前做好預判。此外，積極主動，還可以確保很多有必要的反饋，尤其是向上管理，比如領導交辦可能是一個需要很長時間週期完成的工作，那麼中間過程或者中間結論，及時的進行反饋，佔據主動權，避免領導來問。所以，無論是作為PM ，還是專案成員，都應該要要積極主動去同步或者獲取資訊。請主動出擊！


結語

前面提到筆者理解下各個團隊的閉環模型，細細分析和挖掘會發現，在跟進、落實每項工作時，我們彼此都不僅僅是完成事情的本身，更需要心裡裝著與此相關的同事、團隊或整個專案的目標；在跟進、落實每項工作時，我們彼此不僅僅是做事情時積極主動，更需要養成凡事有交代，件件有著落，事事有迴音的習慣。因此，閉環思維強調的不僅僅是責任心，進取心，更強調的是團隊間的合作，配合的成熟度還有團隊間的信任，同時，還體現出彼此間的契約精神。