項目管理從零開始

項目管理從零開始項目管理從零開始項目管理從零開始xxx公司項目管理從零開始文件編號：文件日期：修訂次數(shù)：第1.0次更改批準審核制定方案設(shè)計，管理制度項目管理從零開始文/陳海春項目管理簡單嗎非常簡單！因為只要你掌握了基本的思路和方法，就能一通百通，達到“一切皆項目”的境界。那么項目管理復雜嗎當然復雜！因為項目管理不僅僅是根據(jù)相應的方法論依葫蘆畫瓢，更重要和更具有挑戰(zhàn)性的工作是在項目執(zhí)行過程中的人員間的協(xié)調(diào)、溝通、沖突處理、團隊的凝聚力等與人密切相關(guān)的部分，只有相互信任的團隊才能到達項目順利交付的彼岸。本文記錄了筆者近三年的時間里在四個不同業(yè)務部門從事項目經(jīng)理工作的主要過程，如何將縱橫交織、盤根錯雜的業(yè)務部門各項目梳理到基本的井然有序交付，提煉出一些在弱矩陣環(huán)境下項目管理基本思路，供各位參考。一、通過訪談了解問題項目經(jīng)理要做好隨時被空降到不同部門、不同項目的準備，項目經(jīng)理往往是業(yè)務部門領(lǐng)導心目中的那個可以信賴的人：組織者、協(xié)調(diào)者、促進者。也許是老板們一個緊急的合作項目希望項目經(jīng)理管起來、也許是一個遲遲看到不到進展的項目需要項目經(jīng)理去撥亂扶正按期交付、也許是一個迫在眉睫的有及具挑戰(zhàn)性的deadline項目需要項目經(jīng)理去按時上線。項目經(jīng)理被寄予厚望，信心飽滿的走馬上任，那么如何開始呢不論一個項目經(jīng)理擁有多么理論的知識豐富、多么牛逼的實戰(zhàn)經(jīng)驗，如果對項目背景、團隊成員不了解的話，也是寸步難行、舉步維艱的，更別說按時交付項目了。所以不論你接手的項目時間是多么的緊急，多么的負責，作為項目經(jīng)理的你需要開展一些一對一的或者一對多的訪談。帶著同理心去聆聽大家的反饋，并適時的引導到家朝正確的方向前進。如何了解和知道當前業(yè)務部門對項目管理的期望呢如何了解項目的當前狀態(tài)呢只有知己知彼方能百戰(zhàn)不殆，雖然業(yè)界有很多方法來達到這個目的（如問卷調(diào)查、面談、焦點小組、匿名反饋等），但都比不上1對1、面對面的訪談來了解情況直接和真實。面談的問題列表主要包含以下內(nèi)容：部門的愿景是什么（或者項目的目標是是什么）目前項目或部門中的主要風險/問題有哪些目前的工作方式/流程是怎么樣的團隊成員的分工是怎么樣的目前質(zhì)量衡量指標有哪些影響項目成功的關(guān)鍵因素是什么如何界定項目的成功對項目管理的期望是什么筆者在初入一個業(yè)務部門時通過所有團隊主管（8名）和部分同事（6名）進行1-1訪談后，得到的主要反饋有：項目立項較隨意比較缺少市場調(diào)研分析，對該項目/功能所帶來的改變/收益沒有詳細的研究；無法說服相關(guān)參與者真正的參與到項目當中，下游開發(fā)測試團隊感覺都是為上游的網(wǎng)站策劃團隊打工；需求變更頻繁，需求變更無流程，變更原因不清，變更后通知不及時需求討論和分解不充分，測試和客服團隊經(jīng)常包含進來；沒有召集所有可能影響到得團隊成員參與討論（如經(jīng)常忘記加測試、客服人員參加）、或者需求討論只在會議上進行，沒有預留時間讓大家提前了解需求；需求文檔和相關(guān)的交互、視覺文檔沒有基線化，大部分的需求變更都是通過在文檔系統(tǒng)上追加備注進行更新的，而下載的文檔內(nèi)容并不是最新的內(nèi)容；需求變更經(jīng)常發(fā)生在IM通訊群里進行討論，而需求文檔經(jīng)常沒有及時同步更新，并且有些相關(guān)人員沒有及時通知（如測試人員）無變更管理流程（什么樣的需求變更需要誰在什么時候做決定）各項目的計劃不清楚、項目狀態(tài)不透明無項目交付節(jié)點、或者對milestone的交付物定義不清楚相關(guān)項目參與人員很少有定期的面對面會議進行狀態(tài)同步，大多數(shù)溝通時通過IM工具來完成的產(chǎn)品策劃人員沒有得到充分授權(quán)進行項目的執(zhí)行，或不知道如何進行進度監(jiān)控和風險規(guī)避，部分策劃人員沒有動力去進行項目的計劃、跟蹤、交付過程，認為策劃出的功能后續(xù)團隊就能自動化的交付；相互推諉比較多，對于延遲的項目/任務，基本上都認為問題出在其他團隊身上（如技術(shù)認為UED是瓶頸，UED認為策劃是瓶頸等）會議效率較低:沒有留出時間讓會議參與人員進行準備很少有會后跟蹤措施，沒有做到問題的閉環(huán)跟蹤很少有人在乎計劃的交付日期:產(chǎn)品部門無中、長期的計劃，以及如何達成這些目標計劃不可視，希望能夠有季度部門會議從業(yè)務優(yōu)先級上使大家達成一致無部門管理團隊定期的面對面的周會，周報大多流于形式，各組間的依賴、風險、問題沒有進一步的跟蹤和解決措施臨時性任務多、經(jīng)常打斷正在做的項目/任務，每個小組都認為問題出在其他相關(guān)小組上，不認為是由于本小組導致項目/任務延遲，無相關(guān)歷史數(shù)據(jù)供參考；總體來說，大家對項目管理的期望是：項目計劃清楚、可視、可控整理一個項目啟動評審的決策流程，能夠幫助大家識別項目的價值和優(yōu)先級加強各部門在項目中的合作，使相互的協(xié)作更加流暢項目需求更加清楚合理，考慮更全面需求變更有據(jù)可依，有據(jù)可查提高項目參與人員的主人翁意識和責任感盡快做1~2個標桿性的項目，通過此項目向其他同事傳播專業(yè)的項目管理方式在得出基本的問題列表以及結(jié)合大家對項目管理的期望，和業(yè)務部門主管一同討論后水到渠成的得出了項目管理工作的基本思路，不積跬步無以至千里，改變和提升先從試點項目開始。二、改變從試點項目開始試點項目的選取首先試點項目要具有典型性和代表性：其中包括項目規(guī)模、人員構(gòu)成、時間長度、結(jié)果跟蹤。項目規(guī)模最好是平均規(guī)模的項目，不可太大或者為了制造出一個試點項目而圈定2-3人參加的小項目。人員構(gòu)成應該是保持全部流程參與方的團隊，例如一個典型的互聯(lián)網(wǎng)項目需要有產(chǎn)品經(jīng)理、交互視覺設(shè)計師、開發(fā)工程師、測試工程師、運維人員、運營推廣員主要角色，在試點項目中最好能夠包含這些全流程的角色。在互聯(lián)網(wǎng)領(lǐng)域通常的項目交付時間長度應該是1~2個月，不可選時間太短（1~2周）或太長（＞3個月）的項目，時間太短可能一些項目活動都被剪裁了，時間太長則試點輸出的結(jié)果需要很久才能得到推廣。試點項目的結(jié)果跟蹤指的是被選定的項目需要在項目開始的時候定義清楚如何衡量這個項目的成功與否（項目管理鐵三角、線上數(shù)據(jù)表現(xiàn)、團隊成員反饋、用戶研究訪談等指標）其次試點項目要得到業(yè)務部門領(lǐng)導的支持和授權(quán)，明確的讓領(lǐng)導們知道這是試點，在試點過程中可能由于新引入的一些方法、流程不一定適合團隊，而且可能會導致團隊的效率下降。需要對試點項目希望達成的結(jié)果有統(tǒng)一認識，如通過試點項目找到比較適合目前團隊的流程方法、度量指標，還是提高項目及時交付率，抑或是通過項目交付打造優(yōu)秀團隊文化和自組織團隊。最后試點項目團隊成員需要知道自己身處‘試點’之中，猶如在撥打自助電話客服時被提示‘您的通話將會被錄音’一樣，使每個人有心理預期和準備，更能積極有效的加入到試點中來。試點項目的執(zhí)行、數(shù)據(jù)收集&分析 試點項目的目的要明確，需要針對性的收集數(shù)據(jù)，數(shù)據(jù)是為下一步?jīng)Q策改進提高基礎(chǔ)，沒有數(shù)據(jù)提供支持的決策基本上都是憑感覺和拍腦袋，正所謂‘無量化，不管理’。針對前面訪談所暴露出的主要問題，在試點項目中重點收集的數(shù)據(jù)有：項目人力支出、項目規(guī)模變化、線上bug數(shù)量、及時交付率。項目人力支出 網(wǎng)易可以說是一個不差錢的互聯(lián)網(wǎng)公司，很多產(chǎn)品/項目不需要進行相關(guān)的預算審核和營收考核的，大家可以在一種寬松的環(huán)境下發(fā)揮創(chuàng)造力，自由的打磨產(chǎn)品。但同時也帶來一個問題，有些產(chǎn)品投入了上百人月但是用戶規(guī)模、營收很不理想，就是導致團隊成員懷疑其產(chǎn)品定位和質(zhì)疑我們的價值、我們的ROI在哪兒。統(tǒng)計項目人力支出并不是想通過投入的人力來判斷一個產(chǎn)品/項目的好壞，而是希望通過統(tǒng)計實際支出人力讓部門總監(jiān)知道在不同項目的人力投入，以及項目所帶來的收益是否值得，后續(xù)如果有類似的項目是否還會投入這么人力、抑或是減少/加大人力投入，甚至需要考慮類似的項目是否可以直接從市場采購。 下圖是一個對外合作項目的投入人力情況，數(shù)據(jù)來源是每周項目周會上每人記錄在過前一周投入到這個項目的時間百分比，歷時4個來月，總共投入了24人月。項目上線后的第一個月帶來的銷售額是2w多元，新用戶數(shù)也區(qū)區(qū)可數(shù)不足千人。 在項目回顧會議上大家都認為這個項目的ROI很低，需要在項目啟動時慎重評估，項目發(fā)起方商務團隊需要對接項目的結(jié)果進行預估和上線后有相應的衡量考核體系。項目規(guī)模變化 在不同部門的初期訪談過程中，研發(fā)團隊反復提到的一個希望是能夠控制需求變更，減少變更。為了能夠衡量項目開發(fā)過程中的需求變化情況，在試點項目中從項目規(guī)模維度進行了量化和記錄。由于大家以前都沒有接觸過敏捷中的故事點估算方法，在大家對敏捷還沒有什么概念的時候如果推行故事點估算的話將會遇到很多困難（故事點和人天間的換算、模塊負責人估算的權(quán)威性等）。這里使用大家最容易理解的人天來進行估算，下圖的項目在初始階段時規(guī)模是人天，中途增加了需求導致規(guī)模上升到人天，同時實際花費的人力也是人天，最后得出規(guī)模變化率為29%，其計算公式是：（實際花費人天-項目初始估算人天）/項目初始估算人天。 得出項目規(guī)模變化率的目的并不是想達到控制需求變化、減少需求變化，而是通過三個試點項目的統(tǒng)計數(shù)據(jù)發(fā)現(xiàn)在A部門中的項目規(guī)模變化率中位值是25%，通過回顧分析發(fā)現(xiàn)這些變化的需求大部分來源于兩個方面：一是由于產(chǎn)品策劃考慮不充分，例如一些異常情況的處理；二是技術(shù)實現(xiàn)上的難度比估算時更大。因此在A部門的后續(xù)其他項目中基本上預留額外的20%項目規(guī)模作為緩沖時間。線上bug在加入K部門后要求QA部門對線上bug進行了統(tǒng)計分析，并發(fā)出月度線上bug總結(jié)郵件，P0級線上bug是指已影響到用戶使用的情況，不論影響了多少用戶（如支付環(huán)節(jié)中支付不成功問題）。P1級線上bug指的是不影響用戶使用的功能（例如內(nèi)部系統(tǒng)問題，活動頁面圖片/鏈接配置錯誤問題）。統(tǒng)計時間區(qū)間P0bug數(shù)P1bug數(shù)線上bug總數(shù) 深入分析這些數(shù)據(jù)后還發(fā)現(xiàn)一個有趣的現(xiàn)象是約有1/3左右的線上bug是由于修改前一個線上bug導致的，或者是由于測試場景不充分倉促上線導致的?；旧厦刻於荚谏暇€（當然如果CI做的好的團隊、自動化測試足夠的團隊每天上線也許沒有什么問題），合代碼并進行手動回歸測試基本上只有1天的時間。為了減少線上bug的發(fā)生和做到有計劃、有節(jié)奏的上線，因此制定了固定上線節(jié)奏（在K部門是每周二、周五兩次）。及時交付率 通過對部門中3個月里面交付的所有項目完成時間和計劃完成時間的比較得出項目及時交付率，從日到日在部門中共上線了16個項目，平均項目時長天（日歷日），其中三個試點項目由本人作為項目經(jīng)理，其他13個項目由開發(fā)負責人或者產(chǎn)品經(jīng)理兼任項目經(jīng)理。 16個項目中按計劃日期上線的有8個（部門中的項目及時交付率為50%），這和訪談中大家談到的項目延遲嚴重比較吻合。8個延遲項目中，延遲率從2%到60%不等，詳情如下圖所示：（由于涉及到公司具體的項目和人員在下圖中的項目名稱已做模糊化處理，項目經(jīng)理一列中具體的人名已移除） 通過上圖的數(shù)據(jù)可以看出超出一個月的項目延遲風險比一個月內(nèi)的項目延遲風險要大得多，其中延遲57%、60%的兩個項目主要原因是中途方案調(diào)整較大。三、建立基本的項目管理流程和度量體系項目集Roadmap機制 公司的運營、部門的運作猶如行使中的高鐵列車，一旦啟動就很難停下來，部門中每位同事每天都很忙，最近兩年互聯(lián)網(wǎng)公司流行一個術(shù)語叫996（指工作時間從早上9:00到晚上9:00，每周6天），但是經(jīng)過半年左右的996后，團隊就會頻繁的質(zhì)問我們真的需要996嗎為什么每天都在救火每個事情是真正值得做的事情嗎 由于業(yè)務部門的業(yè)務不斷發(fā)展壯大，業(yè)務啟動時的單一倉庫無法滿足要求了，需要將貨物挪倉，有時同一貨物需要在不同倉庫中發(fā)貨，而開始的系統(tǒng)是針對單一倉庫設(shè)計的，有些功能無法實現(xiàn)。例如某天的主管站會上一運營同事提出希望在不同的倉庫間售賣同一商品時能夠做到用戶看到頁面一個，并且評論共享。產(chǎn)品經(jīng)理答應會后給出解決方案來幫助運營同事減少評論復制、頁面復制的人肉工作量。但是，詳細分析和了解目前系統(tǒng)架構(gòu)和數(shù)據(jù)結(jié)構(gòu)后發(fā)現(xiàn)底層商品邏輯不支持，需要對相關(guān)系統(tǒng)進行重構(gòu)，也無法承諾具體什么時候能夠重構(gòu)完成。而倉庫間貨物轉(zhuǎn)移早在2個月前就已經(jīng)開始了，那是什么導致了如此重要的功能一直沒有被提上產(chǎn)品開發(fā)日程呢第二天項目經(jīng)理和業(yè)務部門CTO就此事進行了討論，得到的結(jié)論是平時大家都忙于應付緊急的事情，而這些重要的事情往往就被一而再、再而三的delay了。 這類情況在其他部門也經(jīng)常見到，因此對應的解決一個方法是設(shè)立部門重點項目集管理，通過每兩周一次的產(chǎn)品roadmap會議來對項目集中的每個項目狀態(tài)在核心主管團隊中review，以評估當前的重點項目是否有風險/問題、以及是否有新的項目需要納入重點項目集中。 下圖是在K部門所使用的項目集列表，其中1~6個淺綠色背景的項目為部門重點項目。 為了保障重點項目能夠有足夠的人力投入，和CTO及各位主管達成的協(xié)定是：一旦重點項目立項，那么需要保障人力來交付項目，如果其他項目或事情需要擠占重點項目的人力并且影響到重點項目交付的話，需要部門CTO批準。三步評審法 在完成了三個試點項目后，擺在項目管理工作面前的問題是：如何找到適合于業(yè)務部門的項目管理基本方法和流程誠然，原封不動的應用Scrum流程時機未到，并且阻力較大（涉及到組織結(jié)構(gòu)的調(diào)整、新的角色職責、考評方式的改變），也無法照搬CMMI/IPD等繁重的流程體系。在和業(yè)務部門領(lǐng)導、及團隊主管同事討論后提煉出里程碑規(guī)劃+迭代的項目管理基本思路，從項目啟動到項目上線期間輔以3次主要的評審活動，取名為‘三步評審法’，這些評審活動的目的是使項目團隊在‘做正確的事’方面更有保障。 通過對業(yè)務部門的項目交付流程的整理，梳理出如下圖所示的基本過程，其中產(chǎn)品idea討論階段、和項目需求確認階段是市場/需求小組和部門主管間的一些討論，主要集中在市場前景分析、ROI預估等方面，不需要包含大部分項目組成員，因此這兩個步驟沒有納入項目評審會議中。而最后面的項目總結(jié)階段目前僅僅針對于有營收指標的一些項目進行分析，并沒有覆蓋到所有的項目中，所有項目的評審會議中也沒有包含這一步驟。因此，‘三步評審法’包含的內(nèi)容是下圖中紅色框內(nèi)的內(nèi)容：策劃需求評審、交互/視覺評審、上線評審。 三次評審會議內(nèi)容結(jié)構(gòu)是：會議時長會議目的說明InputOutputOwnerApprover參與者策劃評審會<=1h用戶場景描述；

技術(shù)可行性；

項目的期望交付計劃；項目背景簡介

網(wǎng)站邏輯上如何被用戶使用

功能列表交互計劃

項目整體大致計劃

確定項目組成員項目經(jīng)理所涉及部門的leader們共同決策項目組同事、所涉及部門的leader交互/視覺評審會<=1h闡述用戶的交互體驗是怎么樣的交互稿/視覺稿視覺計劃

開發(fā)計劃

項目計劃更新項目經(jīng)理所涉及部門的leader們共同決策項目組同事、

所涉及部門的leader上線評審會<=1h各方判斷是否可以上線

準備啟動上線后相關(guān)活動上線評審PPT

可演示的軟件是否同意上線項目經(jīng)理部門總監(jiān)產(chǎn)品總監(jiān)、

項目組同事、

所涉及部門的leader 上述三個評審會時長限制在1個小時是希望會議組織者、參與者能夠在會議前準備好，在會議上重點討論有分歧的問題，避免冗長而低效的會議。 形成每周固定上線節(jié)奏 結(jié)合前述訪談的反饋和試點項目的反饋，在業(yè)務部門中建議實施了每周二、周五兩次固定上線節(jié)奏，上線窗口之外的上線均需要部門CTO批準，項目計劃時將上線時間匹配入對應的上線時間窗口。這樣的安排所帶來的最直接的一個好處是使研發(fā)部門（開發(fā)、測試團隊）的計劃性更強了，工作也更從容了。 通過兩個月的觀察和數(shù)據(jù)統(tǒng)計發(fā)現(xiàn)緊急上線頻率下降的有限，實行固定節(jié)奏上線的機制后的第一個月緊急上線了20次（22個工作日）、第二個月緊急上線了18次（21個工作日），這其中主要原因是電商活動相關(guān)的一些修改和上線。通過和研發(fā)同事對這些數(shù)據(jù)進行分析，發(fā)現(xiàn)每次緊急上線的內(nèi)容變少了，沒有了以前那種搭便車的情況了，因而研發(fā)的壓力并不是很大。 要做的業(yè)務人員眼中的‘想發(fā)就發(fā)’的境界，下一步需要建立其比較完善的CI系統(tǒng)，其中最重要的是完善相關(guān)的自動化測試腳本，能夠做到回歸測試交由機器來完成，而測試人員聚焦在新功能的完備性測試和相關(guān)的探索性測試上。最小度量數(shù)據(jù)集+閉環(huán)跟蹤指標 通過在試點項目中形成的數(shù)據(jù)統(tǒng)計，和業(yè)務部門領(lǐng)導達成了項目的最小度量數(shù)據(jù)集、以及閉環(huán)跟蹤指標，其中最小度量數(shù)據(jù)集主要包含內(nèi)容是：人力支出、及時交付率、規(guī)模變化率、線上bug。 =1\*GB3①人力支出：在每次項目站會上收集項目成員投入到本項目的人力占比，單位為人天，用于衡量項目的基本人力投入。由于計算機服務器資源在互聯(lián)網(wǎng)公司一般都是在云端了，所以這一塊的成本基本不用在項目中進行記錄和衡量了。 =2\*GB3②及時交付率：用于項目延遲/及時交付情況，計算公式是：（項目實際上線日期-項目計劃上線日期）/項目計劃時長，日期對應的單位為工作日。 =3\*GB3③項目規(guī)模變化率：可以使用人天或者故事點來衡量項目規(guī)模，規(guī)模變化率是指實際項目所花費的人天或故事點除以計劃的人天或故事點，用于衡量產(chǎn)品方案的完備程度。獲得較多數(shù)據(jù)后將可以用于項目緩沖時間的基準。 =4\*GB3④線上bug：用來衡量項目質(zhì)量的一個主要指標，記錄線上bug數(shù)量和嚴重程度。線上bug嚴重級別根據(jù)不同的業(yè)務可以進行劃分，例如下面P0-P2級別劃分是某部門的定義：故障等級P0：重要性高的服務功能不可用或功能異常，且大面積影響到用戶使用。故障等級P1：重要性高的服務功能不可用或功能異常，但影響的用戶有限；或者是，重要性中等的服務功能不可用或功能異常，且持續(xù)故障大面積影響用戶體驗。故障等級P2：重要性中等的服務功能不可用或功能異常，輕微影響用戶體驗。 其中閉環(huán)跟蹤指標主要是在上線的1~3個月內(nèi)對線上表現(xiàn)情況進行跟蹤分析，記錄的數(shù)據(jù)主要是營收和新用戶數(shù)兩大類指標，PV,UV以及復購率作為輔助指標。全員培訓一個流程的確定和實施需要廣而告之，讓部門所有同事知其然、知其所以然，需要講解為什么選取這樣的流程、記錄這些數(shù)據(jù)等內(nèi)容，對部門全體同事進行培訓，是開展后續(xù)全面項目管理必不可少的一個環(huán)節(jié)。全員培訓的內(nèi)容主要放在如下四個方面=1\*GB3①流程和項目最小數(shù)據(jù)集：三步評審法的內(nèi)容、輸入、輸出以及需要參與的人員介紹。解釋為什么要進行項目的最小數(shù)據(jù)集度量，每個歷史數(shù)據(jù)將如何使用（這些基本的數(shù)據(jù)不能用以團隊成員的季度考評，主要用來衡量一個部門的整體的項目健康度情況）。=2\*GB3②成員職責說明：除了團隊成員的各自角色介紹外，其中項目經(jīng)理和產(chǎn)品經(jīng)理的職責需要重點介紹，這是一般人比較容易混繞兩個角色。項目經(jīng)理主要工作職責是組織和協(xié)調(diào)項目中各項活動，提高團隊效率；項目計劃跟蹤執(zhí)行，識別風險和解決團所遇到的問題；服務于產(chǎn)品，使項目順利交付。產(chǎn)品經(jīng)理主要工作職責是理解用戶需求、定義產(chǎn)品形態(tài)、形成需求列表和決定功能優(yōu)先級。=3\*GB3③不同項目類型的定義：為了簡單起見將項目分為重點項目、非重點項目兩大類別。特別需要對重點項目的評選機制、變更流程要重點說明，并且讓大家清楚的知道當前有哪些項目是重點項目。四、對項目管理的反饋每個人都希望自己的工作能夠得到他人的承認，作為項目經(jīng)理也不例外。為了能夠知道過去一段時間在業(yè)務部門的貢獻和價值況，基本上每半年會對業(yè)務部門全員進行匿名反饋，以下是其中一個部門在項目經(jīng)理介入6個月后的一些團隊反饋，其主要結(jié)果如下：100%受訪者認為項目管理介入后項目管理及時交付有了提升；（數(shù)據(jù)顯示在項目經(jīng)理介入的半年中項目及時交付率從20%上升至68%）78%受訪者對項目管理工作是滿意或者非常滿意的；75%受訪者認為項目管理介入后對項目的透明性、質(zhì)量方面有提升；50%受訪者認為三步評審法適合于目前業(yè)務部門的現(xiàn)狀，38%受訪者認為比較占時間或沒什么感覺,12%受訪者認為沒有必要；雖然基本的項目管理流程三步評審法接受程度不是太高，但使項目經(jīng)理深刻的認識到一個流程是需要不斷優(yōu)化和演進的，沒有一個可以解決所有問題的‘萬能藥’式的流程能夠解決目前業(yè)務部門所有的問題。知道問題所在才是更進一步的工作的動力之所在。除了上述量化的反饋外，在工作中的項目管理對項目風險的管理、減少外界對團隊的干擾、為項目保駕護航等方面帶來的好處而贏得團隊成員的稱贊是無法用量化數(shù)字能體現(xiàn)的。五、項目管理的下一步項目管理在一個部門中得到初步的認可了，基本的項目管理流程也已建立，及時交付率得到了一定的提升，后續(xù)項目管理在業(yè)務部門該如何發(fā)展呢及時交付項目是我們項目管理的基本要求、持續(xù)優(yōu)化項目管理相關(guān)流程是我們項目管理的本職工作。三步評審法只是一個起點，計劃后續(xù)結(jié)合項目的實際情況使這些評審更好的落實，并且在效果和會議時間上取得更合理的折中；項目中‘硬性’的東西（例如流程規(guī)范、度量指標、工具使用等）是相對而言比較容易建立的，而團隊中‘軟性’的東西（團隊文化、激情和士氣、認同感等）是需要長時間的引入改變的。后續(xù)在保持和維護基本的硬性要求外將在這些偏軟性方面發(fā)揮更多的項目管理增值服務，例如打造相互信任的自組織文化、減少浪費、閉環(huán)反饋、教練機制。打造信任的自組織文化，團隊是否認同所設(shè)定的基本項目管理流程團隊是否還為產(chǎn)品的未來心存夢想團隊是否還在為達成項目目標而自愿奉獻這些更深層次的問題需要的不僅僅是項目管理的流程方法去解決了，需要更深入業(yè)務部門和團隊中去，希望通過聆聽大家的心聲，施加相關(guān)的正能量影響之。要想在上下級中獲得信任，一個前提條件是團隊的產(chǎn)出能夠是一個完整的交付物，而敏捷圈的特性團隊（featureteam）能夠從基礎(chǔ)上提供一個良好的組織架構(gòu)。特性團隊（featureteam）是指承擔端到端交付任務、長期的、跨職能成員合作的一種團隊形式，例如一個典型互聯(lián)網(wǎng)項目的特性團隊包括策劃、交互視覺、開發(fā)、測試、運營成員。相對目前大多數(shù)組織所采用的功能團隊(functionteam)而言它的好處是一個特性團隊可以承擔完整的、端到端交付、能為結(jié)果負責，而不是眾多環(huán)節(jié)中的一個螺絲釘，無需在功能團隊間進行任務傳遞，整個特性團隊對項目的成敗負責。在項目集管理方式中各項目團隊成員在一個一個項目完成后就解散了，針對這種項目成員不固定、項目周期比較短的項目性質(zhì)是否可以采用固定的特性團隊方式來提高團隊合作效率呢在參加的CSM（CertifiedScrumMaster）培訓中和今年上海的ScrumGathering上和業(yè)界同行聊起這個話題時，幾乎大家建議都是把業(yè)務部門目前的功能團隊組織架構(gòu)改成類似下圖中的特性團隊：雖然特性團隊的好處是可以將團隊固定下來，不同的項目可以由任意一個功能團隊完整的交付，每個團隊對從頭至尾的項目定義、開發(fā)、測試、上線、運營負責。但另外一方面在應用特性團隊之前需要和相關(guān)團隊、上司達成一致：這些以前每個團隊的負責人角色如何定義每個同事的領(lǐng)域能力如何能夠