廣州pmp,產(chǎn)品經(jīng)理在說的項目管理到底是什么？

  01、什么是項目管理？
  了解項目管理之前，我們得先明白，每個PM天天掛口頭上的“項目”到底是什么？
  項目是為了創(chuàng)造獨特的產(chǎn)品，服務，成果而進行的臨時性。
  那么，項目管理是什么？
  百度百科的解釋是：項目管理是運用管理的知識、工具和技術(shù)于項目活動上，來達成解決項目的問題或達成項目的需求。所謂管理包含領(lǐng)導（leading）、組織（organizing）、用人（staffing）、計劃（planning）、控制（controlling）等五項主要。
  項目管理的影響因素很多，阿境總結(jié)歸納為六要素：質(zhì)量、進度、成本、范圍、組織和客戶滿意度。
  簡單的說，項目管理即一個標準化的流程，使得項目能夠按照預定的時間、計劃（包括質(zhì)量、成本等）順利地開展。
  項目管理的流程大致可以拆分為幾個步驟：項目啟動→項目計劃→項目執(zhí)行→項目監(jiān)控→項目收尾。在下文會做詳細解答。

  02、為什么要進行項目管理？
  首先我們明確一個范圍，本篇文章中提到的“項目”指的是互聯(lián)網(wǎng)產(chǎn)品項目；
  另外，對于專業(yè)的項目經(jīng)理來說，產(chǎn)品經(jīng)理在項目管理層面更注重的是服務于需求，包括需求的傳遞、評審、落地，同時，追求更高效的跨部門溝通，協(xié)作。
  2.1整合資源，集成協(xié)同并進
  一個項目是多個部門甚至是多個組織/公司進行合作開發(fā)，即集成協(xié)同并進。拿開發(fā)軟件來說，涉及產(chǎn)品、設(shè)計、前端開發(fā)、后端開發(fā)、測試、運營等多個角色，進行項目管理能夠有效的將多方面的資源融合，更有效地利用起來；
  2.2減少不確定因素，進度可控
  項目在進行的過程中會出現(xiàn)各種不確定因素（錯誤、延期、改版等），項目管理能夠更好的將不確定的因素盡量可控；
  2.3內(nèi)容文檔化，使得項目清晰化、邏輯化、一致化
  項目管理的核心是將內(nèi)容文檔化。人的記性是有限的，在項目過程中涉及的方案，人員安排，項目變動等信息量都是巨大的，且經(jīng)常會出現(xiàn)多個項目并行開發(fā)的情況，這個時候項目文檔的作用更加凸顯。
  能夠使得項目人員的思路清晰化、邏輯化、一致化，同時在項目結(jié)束之后，相關(guān)項目文檔能夠作為復盤項目的有效依據(jù)。
  總的來說，項目管理就是為了滿足項目管理人員對于項目的需求和預期，在質(zhì)量、范圍、進度、成本上進行項目的整體把控。

  03、怎樣進行項目管理？
  項目管理涉及的范圍較廣，歸納起來可總結(jié)為項目管理的道、法、術(shù)，即方法及工具。
  上文提到項目管理的流程（該流程也是PMP中涉及到的完整流程）：項目啟動→項目計劃→項目執(zhí)行→項目監(jiān)控→項目收尾。
  在這部分阿境就將這幾個流程一一拆解開進行描述，以便于大家能夠更加清晰地理解項目管理的概念及流程。
  3.1階段：項目啟動階段
  不論是什么項目，成功與否，之所以能被啟動，有它背后的原因：市場推動、資本推動、領(lǐng)導主觀、多次調(diào)研后決定......等等，本篇文章主要重點在于項目管理，這邊就不過多地做項目誕生原因分析。
  那么，在項目啟動階段，我們該如何做呢？
  利用3W1H的分析思想去思考：①為什么項目要啟動（立項）——why②項目目標是什么——what③項目參與人員——who④項目怎么啟動——how
  3.1.1項目為什么要啟動？
  項目啟動的標志為項目立項，所以該問題可以轉(zhuǎn)化為：項目為什么要立項。
  該處分為大項目和小需求，大項目主要指的是從0到1的項目完整開發(fā)，例如某電商系統(tǒng)APP，或者是某產(chǎn)品中的大型功能，例如淘寶中的會員系統(tǒng)等。小需求指的是系統(tǒng)中的部分版本迭代。
  項目立項是為了能夠更加明確項目的目的及來龍去脈。
  3.1.2項目目標是什么？
  項目的種類跟需求不同，造成了項目目標的差異。有的項目是為了應對上級需求（質(zhì)量不要求高），有的項目是為了探求市場（質(zhì)量中等，開發(fā)時間短），有的是完善產(chǎn)品各項體驗，有的是針對產(chǎn)品的促活、拉新，有的是公司的戰(zhàn)略部署等等；
  只有明確了項目目標，才能夠合理的安排項目及資源分配。
  3.1.3項目的參與人員？
  可以從兩個方面來進行思考：哪些人跟項目有直接關(guān)系？哪些人跟項目項目有間接關(guān)系。針對于互聯(lián)網(wǎng)項目，項目的提出方一般是領(lǐng)導/老板/產(chǎn)品/客戶，項目的執(zhí)行者為開發(fā)團隊：產(chǎn)品、設(shè)計、測試、開發(fā)、運營等都跟項目息息相關(guān)。
  通常在項目啟動之后，阿境會將項目的參與人員（包含需求提出方跟開發(fā)團隊）拉一個群，這樣一來，將項目大概進行介紹，如此一來，項目的參與人員能夠清楚自己是該項目的參與者，也能有個提前準備的時間。
  3.1.4項目如何立項？
  在項目啟動階段，針對于線上，則是進行拉個小群，在線下，通常有個“項目立項會”，跟項目參與人員闡述項目的來源（為什么做），誰來做（參與該項目的人員）、怎么做（采用什么框架、何種設(shè)計規(guī)范等）、項目目標（快準狠等）、項目的大概起止時間等。
  主要是跟團隊的負責人員進行灌輸項目啟動的概念。
  3.2第二階段：項目計劃階段
  在進行項目啟動之后，并不是立即的進行投入開發(fā)，產(chǎn)品同學更多的是先將項目理清需求，進行需求文檔的制作，接著進行開發(fā)資源的排期安排等，也就是項目計劃階段。
  3.2.1任務分解
  任務分解就是將任務不斷地進行去分解到不可細分，然后根據(jù)任務來估算工期及成本，同時責任到人，每個人在固定的節(jié)點給到固定的文檔及完成自身相應的任務。
  通常我們也稱之為WBS（Work Breakdown Structure），分解結(jié)構(gòu)。當任務不斷細分，則整個項目的抗風險能力也越強。
  對于任務，可以分為兩個類型的項目來看
  一個是大項目（從0到1/從1到100）
  一個是小需求（產(chǎn)品迭代）
  不論是項目的體型大或者小，都是由數(shù)量不等的需求組成的，也就是我們說的需求池。定好項目目標及功能之后，需求池也基本有了大概的框架。
  我們要做的，就是將需求池里面的需求，篩選一部分需求放到項目的1.0開發(fā)計劃中，接著將這些按照既定的順序進行排列（不可能一次性完成所有需求）。
  分解方式
  分解的方式有：按照產(chǎn)品的功能模塊分解、按照產(chǎn)品的平臺類型分解、按照實施過程來分解，將多種分解方式結(jié)合等方法。
  舉個例子，產(chǎn)品需求是做一個商城，那么可以分為APP端、小程序端、網(wǎng)頁端（如果需要做這么多平臺的話），這是按照產(chǎn)品的平臺類型來分；
  每個端的負責人員又各有異同，APP端分為Android開發(fā)，IOS開發(fā)，后端開發(fā)；小程序端分為前端開發(fā)跟后端開發(fā)；網(wǎng)頁端也分為前端開發(fā)跟后端開發(fā)。
  接著，針對于某個平臺，按照功能細化開，可以分為會員模塊，積分模塊，訂單模塊，商品模塊等等，每個模塊又可細分為更細的功能，例如會員模塊又分為會員權(quán)益，會員信息等。
  工具
  任務分解的話，可借助excel、Xmind等工具進行梳理分解，因個人喜好來選擇合適的即可。任務分解是比較重要的一步，只有分解清楚，后面的優(yōu)先級安排及任務計劃排期才能做的準確。
  3.2.2任務優(yōu)先級安排
  在前面的任務分解完成之后，接著就是將這些雜亂的進行優(yōu)先級安排。先開發(fā)哪個功能，再開發(fā)哪個功能。
  劃分優(yōu)先級的方式也有多種：按產(chǎn)品功能劃分，按緊急程度劃分等。
  按照產(chǎn)品功能劃分的前提，一般是在項目時間充裕的前提下，按照功能的優(yōu)先級進行排序。不好理解？來，阿境舉個例子，開發(fā)一個小程序商城，有商品模塊，訂單模塊，分銷模塊，退貨退款模塊等。那么順序應是將前期的基礎(chǔ)商品模塊、訂單模塊先建立起來，再來做分銷模塊跟退貨退款模塊。
  按照緊急程度來劃分的話，按照時間管理四象限法來看，依次的排序是：緊急且重要＞緊急不重要＞重要不緊急＞不重要不緊急，但前提也是功能劃分可行的前提下。例如，下個月要啟動商城分銷的功能，但商城的商品體系還沒建立起來，那么再急的話，也得將商品體系先建立起來后，再做分銷體系。
  任務優(yōu)先級的安排，更多的是將兩三種分類方式結(jié)合，才能夠?qū)⑷蝿諆?yōu)先級劃分得精確，做到開發(fā)效率化。
  3.2.3任務計劃排期
  完成了任務分解跟任務優(yōu)先級安排，接著就是任務排期（一個項目不可能無休止的進行下去），上文提到，可利用excel、project等工具進行羅列項目功能點跟優(yōu)先級，接著跟開發(fā)人員進行溝通，進行各功能點的項目排期。
  正常來說，項目都有一個整體時間，例如2020.5.1-2020.9.1，那么，要按時交付項目，項目計劃排期是十分有必要的，因為項目會出現(xiàn)大大小小的變動，排期是為了控制項目的整體進度。
  3.2.4風險控制
  在項目管理當中，要盡量將風險前置，盡量風險可控。（劃重點，這個也考）
  不管項目管理做得再好，項目風險總是存在的，有的風險可以杜絕，有的風險可以防范，阿境將項目風險劃分如下幾大類：
  需求提出方對項目過程沒有監(jiān)控
  在項目需求對接的前期，需求提出方只給了一份需求文檔，然后產(chǎn)品同學就開始進行項目的規(guī)劃，在項目規(guī)劃的階段跟設(shè)計、開發(fā)的階段，需求提出方并沒有完全參與進來（沒有一步步確認），那么就有可能造成，等項目完全做好之后，提給需求提出方之后，需求提出方指出項目并不是他想要的，需要進行重大改版，甚至是推翻重來。那么這個時候的問題就大了，不論是在成本上還是項目影響范圍上，無疑都是晴天霹靂。
  所以在項目的每個步驟（對接需求、設(shè)計稿、程序后端建表、測試等）都跟需求提出方進行溝通確認，才不會造成后期返工項目大改的情況。
  需求不明確
  明確項目需求是產(chǎn)品同學的內(nèi)容之一，深入挖需求是必要的。只有明確了全部的需求之后，設(shè)計同學跟開發(fā)同學才能夠順利地進行設(shè)計跟開發(fā)，自然對于需求文檔的改動也會比較少。需求不明確同樣會造成返工調(diào)整，雖然可能在短時間內(nèi)可以調(diào)整，但也容易降低設(shè)計跟開發(fā)同學的積極性（不斷的返工容易讓人疲倦）。
  所以產(chǎn)品同學提高自己的挖掘需求的能力也是很有必要的，有的需求提出方并不能夠完整的描述他的需求，特別是對于傳統(tǒng)行業(yè)的需求提出方，所以這個時候產(chǎn)品同學的作用就很重要了。
  任務計劃不合理
  任務計劃在上文有提到過，包括任務分解、優(yōu)先級安排、任務排期。任務計劃不合理的原因在于這三個部分其中的一個或者多個出了問題。
  舉一些計劃不合理的例子：項目預估工期為五個月，給開發(fā)同學三個月的時間，在任務時間安排上已然不合理，若此時PM不進行任務優(yōu)先級安排，或者是優(yōu)先級安排失誤，那么項目鐵定延期無疑了。
  需求提出方變更需求
  需求提出方通常有以下幾個角色：領(lǐng)導、運營、市場（用戶）、銷售、甲方、PM等。
  可能由于各種不可控的因素，導致了需求變動，也會造成開發(fā)難度的增長、工期的延長。部分需求的改動，可能是PM在最初時期沒有考慮清楚，當框架搭建好了之后，再去新增需求的話，開發(fā)人員改起來就會比較傷筋動骨。
  技術(shù)風險
  技術(shù)風險主要在于開發(fā)人員身上。在項目立項的時候，往往會進行技術(shù)評估，在立項會中，參與項目的技術(shù)人員在了解了項目情況之后，會進行技術(shù)選型，以及技術(shù)難點的探討，若涉及對接第三方接口，則會進行第三方接口文檔的查看，這個時候會綜合判斷第三方接口提供的功能是否能夠符合預期功能。
  在技術(shù)階段評定之后，在后續(xù)的開發(fā)，可能會推翻前面的技術(shù)評定，也可能由于前期的判斷失誤，在實現(xiàn)某個功能的時候遇到了瓶頸，也可能在技術(shù)層面上的拖延，導致工期的延長。
  3.3第三階段：項目執(zhí)行階段
  3.3.1各細分過程跟蹤
  在開發(fā)的過程當中，項目經(jīng)理往往要根據(jù)前期所制定的排期計劃（包括之前提過的任務計劃排期、任務分解、優(yōu)先級排期）來進行設(shè)計過程、開發(fā)過程、測試過程的跟蹤，也就是項目管控。一個項目，少則一兩個月，多則一年半載。
  同時，往往在真實的項目開發(fā)過程當中，并不是只有單一的項目在運行，可能會有多條產(chǎn)品線，多個項目并行開發(fā)的情況（也可能涉及到不同的開發(fā)人員），也就是說，一個開發(fā)/設(shè)計/測試人員，手頭可能同時負責多個項目的情況，A項目完成到15%，B項目完成到35%......所以，項目的多、亂、雜，需要科學合理的過程跟蹤。
  若沒有進行項目的過程跟蹤，可能造成未能按照預期完成項目計劃，項目延期。
  項目如期完成，質(zhì)量卻不盡人意，最終造成項目返工修改。
  產(chǎn)品、開發(fā)、設(shè)計等對于PRD的功能理解有偏差，模塊的完成與預期不符合，最終也造成返工。（此點更偏向于在開發(fā)過程當中多溝通方面）
  由此可見，項目過程跟蹤是否得當，對于最終項目產(chǎn)出的質(zhì)量也是至關(guān)重要的一點。
  3.3.2階段性產(chǎn)出文檔審核
  在整個項目的生命歷程當中：
  產(chǎn)品經(jīng)理需要輸出PRD（產(chǎn)品需求文檔），其中包括功能框架、泳道圖、業(yè)務流程圖、原型圖、其余說明等等。
  項目經(jīng)理需要輸出排期表，任務優(yōu)先級表，人物分工表等等。
  設(shè)計師需要輸出設(shè)計選型，配色方案，風格定位，設(shè)計稿等等。
  開發(fā)工程師需要輸出開發(fā)選型、數(shù)據(jù)庫結(jié)構(gòu)設(shè)計、接口文檔、開發(fā)操作文檔等等。
  測試工程師需要輸出測試用例、測試方案、測試結(jié)果報告等。
  目前太多PM會局限于各類文檔模板，追求文檔的完整度美觀度等。但在這里，阿境要說的是，文檔存在的意義，在于使得項目更加規(guī)范、有條不紊地進行下去。
  文檔在這當中只是一個傳達信息的介質(zhì)，之所以選擇文檔來代替口頭，是因為文檔能夠更好地留存及記錄。而只要能夠達到目的，明確了這點，文檔具體的展現(xiàn)形式，樣式就不那么重要了。
  最適合自身公司及業(yè)務需求的文檔，才是好文檔。
  3.4第四階段：項目監(jiān)控階段
  3.4.1例行項目會議
  提到了項目過程跟蹤的重要性，那么問題來了，如何進行項目跟蹤？一個比較重要的措施，便是例行項目會議。
  項目會議可分為每日站會跟周會。作用除了能夠管理項目，也可以管理項目當中每個角色的開發(fā)狀態(tài)。當然，這邊的管理并非指傳統(tǒng)意義上的管理者，這是由于互聯(lián)網(wǎng)行業(yè)，產(chǎn)品經(jīng)理/項目經(jīng)理可以看作是一個總的牽頭人，可謂是產(chǎn)品的靈魂。（自賣自夸一下哈哈哈）
  每日站會
  在每日站會上，不同的角色所需要關(guān)注的點也不同。
  1、產(chǎn)品經(jīng)理，可在項目看板上，整體介紹每個項目目前的進展情況，與預期的差別，著重點在于每個項目整體的進度是否符合原先的項目排期。
  2、設(shè)計師的重點，則在于目前手頭項目的頁面數(shù)量及美觀，由于設(shè)計方面包含了大量的主觀性，所以設(shè)計出來的產(chǎn)品，是否能夠滿足目標用戶（使用者/產(chǎn)品/甲方等）的要求，在目標用戶提出要求之后，加上修改的時間是否能夠如期完成等。往往會遇到一個情況，設(shè)計師用兩周的時間完成了設(shè)計稿，卻用了一周多的時間來進行設(shè)計稿的修改優(yōu)化。這個情況難免會造成項目的延期。
  3、開發(fā)人員的話，相對來說就比較復雜一些。除了關(guān)注不同項目的不同進度之外，還要著重于每個單一項目的進度。整體進度是否與項目排期表一致；功能模塊是否按照優(yōu)先級來完成；開發(fā)的時候是否遇到瓶頸；準備如何解決，若無法解決，與產(chǎn)品經(jīng)理協(xié)商下，是否有Plan B等等問題，也是開發(fā)人員需要在每日站會上來進行匯報討論的。
  4、測試人員，關(guān)注點在于項目的完成情況，是否需要進行提前的模塊化測試；若整體完成，則測試進度是否如期進行等。
  整體的每日站會時間，控制在5-15分鐘之間，快速高效是重點，不開無意義的會議。
  重要的事情說三遍：
  不開無意義的會議！
  不開無意義的會議！
  不開無意義的會議！
  同時站會通常安排在每天上班后的半小時后，原因在于：剛開始上班的前半小時，每個人可以回顧一下昨天完成的任務，同時規(guī)劃下今天的任務安排，討論下遇到的任務難題，如此也能使站會更加有意義，形式化的每日站會是不提倡的。
  每周會議
  而每周會議，與每日站會不同的是，著重點不在于關(guān)注項目本身，需盡量脫離各個項目的細節(jié)點（防止陷入細節(jié)討論，耽誤時間），以宏觀的角度來考慮整體的項目進度及情況。
  回顧本周的進度成果，與本周的任務計劃是否有偏差。若未按期完成，分析一下原因（包括個人原因、溝通原因、技術(shù)原因）等，以便于提高個人效率。
  計劃下周完成任務，具體每個任務的大致模塊及完成的整體進度。
  項目經(jīng)理/產(chǎn)品經(jīng)理需要大致總結(jié)下項目情況，將項目具體的進度如何如實地給到項目成員，做到一個人人都心中有數(shù)的地步，因為大家是一個團隊，缺少了任何一個環(huán)節(jié)，項目都進行不下去。
  緩和氣氛，結(jié)束過去的一周，周末充分休息，迎接新的一周（團隊和諧的氛圍對于項目的配合也有舉足輕重的作用）
  3.4.2項目周期中的日報與周報
  上文提到，有每日站會，每周周會，那么同樣的，也相應會有日報跟周報，如何寫好日報跟周報是個老生常談的話題，也有許多大佬有他們的分享，這邊就不提了。
  對于每個崗位，日報跟周報都是及其重要的，但是對于不同的崗位，寫日報跟寫周報的方式也全然不同。日報跟周報在一定程度上，是寫給自己看的（但其實往往都被要求發(fā)送上級領(lǐng)導審核），一旦成為了任務，那么，便可能產(chǎn)生應付的情況，那么意義也不大了。
  3.5第五階段：項目收尾階段
  3.5.1工程師自測
  當開發(fā)小哥完成代碼之后，需要進行冒煙測試后，再給到專業(yè)的測試人員。
  程序員進行自測是對自己所寫模塊的進一步檢查，這樣可以使對該模塊的邏輯更加明確，同時加深對于該模塊的記憶，并且可以程度確保每個模塊程序書寫的正確性。
  3.5.2設(shè)計師自測
  UI驗證是由UI設(shè)計師來驗證當前的系統(tǒng)UI是否能夠達到預期的效果。
  UI驗證是當前頁面UI還原度的一個重要證據(jù)。UI驗證是檢測當前頁面能否做到UI圖級別的視覺效果，以及開發(fā)人員是否按照UI設(shè)計師的界面需求進行實現(xiàn)的一個重要準則。
  3.5.3產(chǎn)品經(jīng)理自測
  產(chǎn)品驗收是產(chǎn)品經(jīng)理在項目交付前進行最后需求與程序開發(fā)是否統(tǒng)一的過程。
  產(chǎn)品經(jīng)理進行驗收是對整體系統(tǒng)流程的一個把關(guān)，也是對當前系統(tǒng)一次總的檢查，在驗收過程中需要綜合UI驗證以及測試時的一個結(jié)果來確認在產(chǎn)品經(jīng)理在驗收后是否可以交付該系統(tǒng)。
  3.5.4、測試工程師測試
  測試工程師需要進行功能測試、性能測試、兼容性測試、壓力測試、回歸測試，這邊隸屬測試工程師的范疇，這邊不再過多贅述。
  3.5.5項目收尾文件
  在一個項目結(jié)束之后，必然要進行項目文件的留檔記錄、包括但不限于項目需求文檔（PRD）、驗收文檔、測試報告、數(shù)據(jù)庫設(shè)計文檔、項目實施總結(jié)報告、產(chǎn)品使用說明手冊等文檔。
  原則上，文檔涉及到項目生命周期當中的所有文件，PM在項目過程當中需要合理地進行分類及保管，以便后續(xù)項目迭代、復盤使用。
  具體需要到什么程度的文檔，各公司要求各異，作為產(chǎn)品，尋求一個平衡點即可。
  3.5.6項目復盤
  項目復盤是每個項目的極其重要，卻又容易被忽略的步驟。
  在經(jīng)歷了每個項目節(jié)點的開發(fā)推進，往往在團隊當中會暴露出部分問題，那么，不斷地復盤可以總結(jié)經(jīng)驗，并且在下一次產(chǎn)品迭代當中，減少錯誤的發(fā)生。
  同時也有成功的經(jīng)歷，那么復盤總結(jié)可以將將成功的經(jīng)驗變成規(guī)律，再次遇到的情況可增加整體項目效率，從另外一方面來看也是為公司減少成本。
  最后，在團隊當中，幾個項目下來，團隊人員的心情、狀態(tài)都在不斷改變，復盤總結(jié)的同時，也能夠及時關(guān)注，及時處理及溝通。
  項目復盤的四大步驟：收集問題、分析問題、討論問題、解決問題。
  這邊不過多贅述，感興趣的可關(guān)注阿境（公眾號：夢想家阿境），同阿境一起聊聊。

  04、項目管理中的幾個注意點
  4.1項目成員的把控
  項目管理由人來管理，那么，“人”在項目這個過程當中，尤為重要。
  “水能載舟，亦能覆舟?！表椖勘茸鞔?，那么人便是水。人促使了項目的推進，但在某些情況下，也能夠?qū)е马椖康氖　?br />   作為項目管理者，不僅僅是要關(guān)注項目本身狀態(tài)進程，同時也要關(guān)注團隊成員當中，每個人的狀態(tài)，包括效率、情緒等方面。
  對于這點來說，較難細化，也沒有具體的方法論，需要朋友們切身去體會下。（有興趣的可同阿境來討論交流）
  4.2項目管理工具、方法論的合理使用
  項目管理工具市面上包含了TAPD、jira、禪道等等，項目因其體量不同，公司因其流程不同，人員因其性格不同，都造成了項目管理的差異。
  明確項目管理的目的才是項目管理者要關(guān)注的點：在規(guī)定的時間內(nèi)保質(zhì)保量的完成項目目標。那么，在這個結(jié)果之前，使用什么方法論，使用什么工具，就都較為次要了。
  切勿過于迷信工具以及方法論，他們存在的意義，是為了更好地幫助項目管理者完成項目，提高項目管理的效率。
  4.3做好項目延期后的準備
  作為項目管理者，當然是希望項目能夠如期、保質(zhì)保量地完成。
  但往往因為各類原因，沒辦法如愿，那么在一開始的時候，就需要做好項目延期的準備，出現(xiàn)風險之后的預案，避免驚慌失措的情況。
  因為人員效率、外界原因?qū)е碌捻椖垦悠?，那么可以適當調(diào)整需求，將較難的需求，換個方式實現(xiàn)。舉個例子：開發(fā)某平臺，來不及做客服功能，可考慮對接第三方客服，若還是來不及，彈出客服的聯(lián)系方式暫時應急下。一個功能按照復雜程序來做可做數(shù)個月，按照簡單程序來做可能幾個小時就能完成。
  那么，項目的時間也因需求復雜程度而定，把控好這個平衡點，是產(chǎn)品經(jīng)理需要做的。