摘要今年整體帶了幾個項目。我本人不是專業的PMP培訓出身，落文的目的主要是爲了把所積累的一點點經驗分享給大家，所以項目管理的術語和措辭上的不專業，希望大家諒解。 其中一個項目落地非常快，質量和效果產生也非常快的一個項目，落地到產生效果就一個月，所有項目成員都不是全職做這個項目，受到研究...
今年整體帶了幾個項目。我本人不是專業的PMP培訓出身，落文的目的主要是爲了把所積累的一點點經驗分享給大家，所以項目管理的術語和措辭上的不專業，希望大家諒解。
其中一個項目落地非常快，質量和效果產生也非常快的一個項目，落地到產生效果就一個月，所有項目成員都不是全職做這個項目，受到研究員高度認可並取得對應成果的項目。
另一個項目歷經小半年，橫跨多個部門，最終取得了所有主鏈路全部達到秒開的水平，並被開發部申請了技術部牛氣沖天獎的項目。
第三個是無線測試發聲最多，體現最專業的一個項目，在項目的整體流程推進上，風險把控上，需求控制上，測試方都付出了不少的努力，運營和PD方紛紛回覆郵件給測試團隊點贊。
下面我就從自身的角度來講講我帶項目考慮的幾個方面：
一、整體規劃
1.1需求管理
整體規劃裏，我比較關注的是需求列表和時間節點2個部分，首先將需求分類，大致分爲強風險性需求、強需求性需求、普通需求、可刪減性需求幾個部分，如果非要劃一個優先級，按照我的理念我會關注強需求性需求>強風險性需求>普通需求>可刪減性需求。強需求性需求這種需求可能是導致本次版本更新的核心訴求，這種需求資源優先保證，所有風險性問題優先考慮，保證強需求性需求能夠上線，這裏不考慮強需求性需求不滿足時間排期的情況。然後是強風險性需求，這種需求需要提前去溝通了解風險點，並且提前準備好備案，強風險性需求面臨着可能多部門合作，進度問題，或者技術難點問題，時間問題等，分析出強風險性需求的瓶頸點，線下單獨溝通，並準備好預案，如果該類需求在最後的節點仍然不能夠達到我所期望的目標，那麼因爲我已及時溝通到各合作方，各合作方也有心裏的預期和準備就更好容易處理一些，可刪減性需求，這類需求可以按照當前的計劃，時間，資源等條件因素選擇性的提取，如果資源等情況充沛和全部接過來，否則最好在立項階段就要對需求進行合理刪減，不要出現當初承諾完成需求，在項目快結束時才周知相關利益人此需求無法完成的情況，這點對於其他人來講是相當的討厭的。
1.2時間節點
關注時間節點的原因是，當前阿里的大部分項目都是倒推的，每一個部分在什麼時間完成都是有時間標準並且是可衡量的，例如需求溝通，PRD產出，視覺&交互的產出，開發開始時間與結束時間，項目提測時間，項目測試完成時間，項目灰度時間，項目小渠道發佈時間，項目全渠道發佈時間，在一個項目裏，大部分的時間節點，在項目開始計劃的時候就已經產出了，作爲PM需要管理時間節點的風險，要經常和主要的責任人溝通相關項目的進度，不緊張的時候各合作方發週報通報內容，緊張的時候各合作方發日報通報內容，甚至當前溝通，建立項目的多種溝通方式，例如項目1推進每週一次的碰頭會議，郵件組，旺旺羣，釘釘，週報，日報等。PM不能想着到時間節點就要東西就好了，這不是一個好的PM，一個合格的PM應該時刻的關注每個節點的進度，質量，風險等情況，尤其是快到接近每個節點產出的時候，如果時間上發現已經delay，那麼應該和相關的業務方溝通提高進度產出，加班等手段，把節點的產出和敏捷項目的管理相配合，這樣就可以儘量保證每個時間節點都達到項目計劃的規劃目標。
二、溝通
2.1 人與人的溝通
人與人的溝通就是P2P，單點對單點，這種溝通的內容一定是該內容僅涉獵你們2個人的，例如某一個問題一直掛在某一個人上長期沒有解決掉，作爲PM要了解情況進行溝通，溝通的時候多從對方角度考慮問題，多從共贏的角度上考慮問題，不能說你作爲PM你有這個權利怎麼怎麼樣，這種溝通一般都對在對方心裏產生抵制的效果，瞭解到可能是因爲該責任人被安排了其他任務，還是說這個問題有難度不好解決，還是說人家準備要離職了，把影響項目進度的節點問題解決掉，溝通時可以先採取先郵件溝通，再旺旺溝通，最後當面溝通的方式，一般的阿里人到達第二步旺旺溝通的層次基本都會有響應了，如果旺旺都不行，那你一定要當面去溝通，不要怕，有的PM就不知道如何當面進行溝通，當面溝通預約好時間，不要先入爲主，先把問題提出來，看看對方怎麼說，然後你根據瞭解的情況再去有策略性的推進這個事情，前幾步也都沒有，直接當面質問，這個問題怎麼還不解決，這個時候我都想罵他，我手裏有更重要的事情好不好，你過來嘚瑟個屁來着。當然如果這個事情非常非常緊急，P1故障，那直接去找好了，這種問題沒什麼顧忌其他人感受的了，影響到我們的線上用戶那是一等一的大事，還要什麼面子。
2.2 合作方的溝通
與合作方的溝通，一定要讓對方的leader知道並瞭解支持此事，這一點尤爲重要，即使對方leader沒有時間，那麼也需要在旺旺或者郵件內抄送一下，避免最後因爲各種理由，這個項目支持到中間半途而廢了，再臨時叫老大的老大的老大從上到下來壓這件事情，按照我的話來說，就是這事辦的不夠漂亮了。對方老大知曉同意這件事，那麼需要擬定合作方需要溝通的接口人，對方的團隊畢竟是對方更熟悉，也更能說的上話，你在人家團隊裏，碧池碧池的說100句，可能不如人家在內部團隊裏嘻嘻哈哈的一句話，項目合作推進的事情一定要交付給接口人做，你作爲PM不能把合作方團隊也一併管理了，再說，真正項目做起來後，你也沒有那份時間和精力的，定好接口人，這個接口人一定能把有效的信息傳達到團隊內，並落地執行，這樣的接口人才是有效的，不要隨便指定一個，哦，張三，你是接口人，結果張三自己在團隊裏什麼都落實不掉，最後你說是張三的責任，還是你的責任，你倆都有責任，但最主要的可能還是你的責任，知人善任，作爲PM，運營團隊、PD團隊、開發團隊、測試團隊，哪個團隊都有哪些人非常適合做PM接口人，或者自己團隊的PM，你至少平時工作中要多和合作團隊瞭解，即使你不瞭解的團隊，也最好側面打聽打聽，要人的時候直接要指定的負責人，那辦事效率槓槓的，溝通起來相當的絲滑，再提醒一點，與合作方的溝通一定要有禮有理有句有據，意思是一定要有禮貌要尊敬人家尊重人家的意見，你說的話一定要有道理，有理由能站得註腳，能經得起推敲，有句你說的話一定要清晰易懂有邏輯有重點，有據你說話一定要有根據，有事實，有數據，讓合作方得知道你這個人要辦的事情靠譜，人家纔會非常願意和你合作幹項目，要不然背後說不定指着你脊樑骨罵，靠，什麼鳥人，這個項目一點前景都看不到。
2.3 自己團隊的溝通
自己的團隊就是親人，是最親最親的人，能自己上的，都不會讓自己團隊的人頂，所以項目的任何風險或者進度情況等對自己的團隊就是實話實說，提前幫自己的團隊多考慮一些事情，善意的提醒他們一些注意的事情，關鍵的節點等等，今天可能你是PM，明天可能就是別人就是PM，能把自己的經驗傳遞給大家的就share給大家，多從團隊方面考慮問題，也需要幫助其他人從團隊的角度考慮所有事情，而不是個人角度，因爲不管是項目，還是任務，沒有任何一件事是屬於指定的某個人的，你可以任何時候離職撂挑子不管，所以不管是自己團隊還是別人團隊，大家一起能參與這件事，一起做這個項目，你心裏就要報有感激的心態，多去讚美別人，即使別人做錯了，做的不好，也要懂得如何婉轉的提醒給他，讓他有面子的同時達到項目的目的，也許就是我的做人之道吧。每個人管理項目的手段都是不同的，人的不同就會導致風格的不同。
三、專業
什麼是專業，就是把自己份內的事情做到極致，我認爲這就是專業，一個PD需求寫不好，一個運營頁面都不會搭建，一個測試連Bug都不會跟蹤不會提，這可能都是不專業的體現。在項目中，你是PM，或者你是其他角色都必須要做到夠專業，測試的PM就要整體把控測試的進度，提測時間點，業務的風險點，測試完成時間，業務上線時間，把該暴漏的問題要儘早的暴露出來，很多測試PM總是怕得罪人，問題暴露出來了，這個問題是某某個團隊的，某某個人的，人家會不會覺得我事多，記恨我，以後是不是合作上就有問題了，其實我覺得如果這個問題藏着掖着上線了，最後被爆出個P1\P2故障出來，我想人家更會記恨你，提前發的預警信息，風險郵件，加班郵件如果能把問題暴露出來，大家都應該感謝你的，測試PM都是從整個項目的質量上來考慮整個項目的，大家應該都能理解，你是測試PM，你要對這些事情負責，項目的週報定時的發送，讓整個大促合作方都知曉測試的進度，項目時間緊時，要把風險性的問題及時發送郵件或者旺旺消息，讓大促的總PM知曉，不暴露出來解決掉問題，就意味着時間不夠用，要帶bug上線，這種事情是必須全部周知纔可以，否則憑什麼你讓業務帶問題上線，是我，我這東北人的性情我就不爽。
專業的人做專業的事情，PM同學管理好項目的人與人的關係，業務的進度，風險，時間點等等，消息傳達和溝通要儘量協調好，做一件事情要多考慮一分鐘，想想是不是遺漏了什麼，讓大家都覺得很順，很爽，下次做項目還願意跟着你幹，這不僅僅是項目的成功，也是你的成功，每個人身上都被其他人貼上了不同的標籤，而你自己就是你的品牌。
四、回饋
什麼是回饋，按照我的想法，就是付出就必然有回報，雖然大家做項目不是給你做的，說白了你也是給公司做的，那麼作爲PM這件事情的帶頭人，你有理由，有責任給與參與項目的人給予感謝，請大家喫個飯，來個下午茶，爲大家申請加班倒休，爲大家申請酒店住宿等加班條件，這都是PM需要考慮的事情，我又想抱怨一下，看過很多項目，做完了就做完了，作爲PM連封感謝的郵件都沒有，心裏真是不爽啊，中國這個社會還是一個人際關係的社會，認識你喜歡你的，你沒說話，事就給你辦了，不認識你的不鳥的你，你天天求着人家，人家都不願意給你辦事，這事情就是這麼個事情，我覺得非常簡單，但是還是發現有很多人不是很明白這個道理，一定要多讚美人家，不要害臊，當面讚美，例如：這個模塊，做的很牛，Bug非常少。給與開發同學實力上的肯定。這個需求寫的非常清晰，我一看就懂了，多謝多謝，給與PD讚美，人家從內心上肯定你，後面還會堅持這麼做，否則，今天我寫的很好你不吱聲，明天我寫的不好你也不吱聲，好，那下次我不寫了，省事誰不會呢？
這個回饋方式有很多種，有大有小，你要變通着來，這樣大家才原因跟着你幹這個項目吧，否則要是我，我都覺得這個PM腦子是木頭的....
總結：最後我想說，其實我嘚吧嘚吧這麼多，也沒有把自己所有的體驗全嘚吧出來，也沒有把項目的整體流程啊，目標啊什麼的給大家說一遍，那是因爲我覺得處在什麼環境下，哪個所謂的流程啊，目標啊，標準啊什麼的，都不是一成不變的，作爲PM要考慮當前的環境，以前項目的方式等等因素和大家好好配合，有句話怎麼說來着，樹是死的人是活的，我覺得作爲PM能夠變通着做事情，讓各位儘可能的滿意，對項目滿意，對你滿意，對結果滿意，又達到了項目的目標就“齊活”了。