項目經理的掙扎:“垂死項目”復活記(2)

　　王峰默默地打著腹稿做記錄，最觸動他的是，團隊中居然有近80%的員工50%的時間處于等待狀態，但自己每次看到大家都在忙碌啊，假象嗎?同時，沒有幾個團隊成員真正了解每次發布的產品要實現的全部功能，有的甚至只知道20%，實在令人驚詫。

　　“好的好的，李成打斷大伙的發言，大家辛苦。我們再聊聊過去半年中大家沖突和討論最多的一件事吧!”

　　“當然是棺材板元寶啦!”一位員工搶答道。

　　王峰知道他說的是“X城市”游戲中，玩家完成任務后，點擊房子就會嘩啦啦地掉金幣。后來有成員提出金幣不好看，就改成元寶，有人又說元寶像棺材不吉利，就改成了不同顏色的元寶，后來干脆改成金磚，改成寶石，甚至一度改成阿爾卑斯牛奶糖……而這些改變對于用戶數據的改觀沒有起到任何效果。

　　團隊在這些低優先級的活動中耗費了大量精力，整個過程全憑團隊成員拍腦袋。而開發低優先級功能時，將大大增加代碼的復雜程度和缺陷數量。同時，很多文檔尤其是策劃設計小組的功能需求文檔不規范，缺乏必要的信息和路徑，導致大量返工，開發團隊非常不滿。

　　王峰沒想到，自己的團隊信息如此不透明，角色和職責如此不清晰，策劃人員、開發人員和測試人員都沒有很好地承擔職責，對自己高度依賴，都等著他去分配任務。想想吧，自己每天來得最早走得最晚，既負責技術又負責產品，而他們卻不得不郁悶的等待。

　　會議臨近結束，一個團隊成員說：“從來沒有這么痛快地將自己的真實想法說出來!以前都是通過郵件、電話、QQ和文檔聯系，確實沒感覺。”王峰望了望李成，豎起了大拇指。

　　再戰江湖

　　當晚，王峰叫上核心團隊，當然少不了李成，一起到附近一家茶館喝茶，順帶進行頭腦風暴，聊聊“X城市”下一步的發展策略。近半年的投入讓大多數成員對這款游戲有了很深的感情，但也少不了有一些核心成員認為早放棄早超生。

　　“李成，你的看法?”王峰問。

　　“我們是否要放棄由V—City決定，而不是我們自己。對同一類型的社交游戲產品，玩家只會選一個，如果國內玩家確實喜歡V—City，那我們就別做了。”

　　“V—City的完成度和實力確實比我們強很多，但相關的玩家數據我們還沒有拿到。”

　　“你們不斷提到‘完成度’，但它不是社交游戲的核心，核心應該是‘社交’!”李成說。王峰看出李成今晚是有備而來的，也很期待他能給大家帶來新的思路。 “我認真研究過V—City，它的核心玩法是一個‘幫’字，利己不損人，這符合西方人的社交觀。但國內之前最火爆的社交游戲卻是開心農場的偷菜!占小便宜、不勞而獲、損人利己，這是國內大多數玩家在社交游戲中認可的趣味點。同時，V—City僅僅是漢化了，它的建筑仍然是歐美風格，對西方玩家代入感極強，但對國內玩家則極差。”

　　“對!社交游戲要基于社交觀來做，中西社交觀完全不同!代入感的問題非常關鍵，這是我們的機會!”王峰搶過話頭，其他團隊成員也頻頻點頭。又陸陸續續聊了一些細節問題后，最后大家終于統一目標，一致認為要再搏一把，定一個清晰的產品方向，快速增加新功能并且優化現有功能，通過迭代式開發改進產品。機會是看到了，但團隊問題怎么解決?在大家陸續散去后，王峰叫上李成到附近的酒店開了間房，兩人暢談了一個通宵，而他們的“基情”故事也由此在團隊中流傳開來。

　　天下武功，唯快不破

　　問題1：大家都覺得自己很努力，但為何團隊就是快不起來?

　　原因：由于團隊信息不透明導致團隊成員能力調度與時間調配混亂，項目進展的瓶頸始終潛伏在大家的視野之外。

　　方案：建立故事墻，推行站立式會議。

　　(圖1 “X城市”游戲項目早期故事墻)

　　如圖1所示，故事墻分“Ready(計劃)—Play(開發)—Test(測試)—Done(完成)”四欄，不同的紙片代表不同的任務種類，黃色代表功能需求，藍色代表的是技術任務，紅色代表的是Bug，紙片內容含任務、執行人、工作量和計劃完成時間等信息，任務的優先級程度根據紙片自上而下的位置而定，在上的為高優先級。通過引入故事墻，將項目信息完全透明和可視化，團隊成員每天經過故事墻就可以很清楚地看到整個項目的進度，每個任務要實現的功能，以及項目的瓶頸和問題。

　　圖1是最初的一個故事墻，從中不難發現，很多任務已經在Play欄里了，但Ready欄內容嚴重不足，尤其竟然沒有一張是代表功能需求的黃色紙片，這說明開發人員做得足夠快，但策劃設計人員沒能提供足夠的玩家需求，項目瓶頸一目了然?？吹竭@樣的場景，策劃設計人員就不得不在沒有任何人敦促的情況下，抓緊去做需求研究，被故事墻趕著走。產品策劃設計部門在自我剖析后發現，由于很多需求是由前后臺技術共同完成，而很多需求的后臺技術已經完成但前臺卻沒有實現。后來得知，原來是前臺員工嚴重不足所致!于是王峰迅速從公司其他部門借調相關人員加入團隊。到周五時，有成員發現有些功能還沒進入測試狀態，大家站在故事墻前分析，原來是開發人員太慢了，開發人員就自動自發地快馬加鞭趕工。就這樣，通過團隊自發地不斷找到項目瓶頸，并自動消除瓶頸，項目過程不斷優化，故事墻僅僅上墻4個星期，團隊效率就提升2-3倍，團隊的滿意度也隨之上升。

　　(圖2 “X城市”游戲項目改革兩周后的故事墻)

　　在故事墻的基礎上，王峰與李成又將團隊開會方式改為站立式，每天早晨大家圍著故事墻討論項目進展，溝通相互之間的信息和困惑，會議長度控制在5分鐘左右。一個員工告訴李成：“自從有了故事墻和站立式會議，如果墻上沒有自己的任務，或自己的任務優先級不夠，壓力就巨大，而且很丟人，不得不努力加班加點。”通過管理方式的改變，王峰不用再分配任務了，團隊成員根據自己的任務情況去Ready欄領取任務，任務完成后將紙片挪到別的欄即可(認領—完成—確認)。從圖2可以看出，在兩周后的故事墻上，待完成的任物紙片越來越多，且功能需求(黃色紙片)越來越多，說明團隊對用戶的研究越來越深入，從事的改善工作越來越多，同時Bug(紅色紙片)消失了，說明隨著信息的暢通高效，返工任務越來越少，團隊實現了高速有效運轉。

原文轉自：http://www.anti-gravitydesign.com