文/浦薇娜
每個專案經理都希望能有效地控制專案進度。但這件看似簡單的事情，實際操作起來卻常常不盡如人意。即使在成熟的大公司裡，有著完善的專案管理流程，配備著一流的團隊，專案延期事件還是頻頻發生。這裡分析主要的三個原因。
常見的原因之計畫不清
很多專案經理，計畫做得很漂亮，卻總是計畫趕不上變化。原因 在於，有些時候，按工作量預估的發布日期卻得不到領導的同意，領導有時會說我們現在就是和時間賽跑，這個專案必須在某某時間發布。這將致使計畫推倒重來，一切都要趕進度。而對於其他團隊成員來說，這份計畫沒有同他們商量，無異於強壓任務。專案還沒開始，抱怨聲就不絕於耳。因此，專案工具選得好、任務劃分細 致清楚只是做好計畫的基礎，更重要的是專案計畫要得領導和團隊成員的認同，並願意為之全力以赴。
總之，想做好專案計畫，要做好以下三點。
常見的原因之需求問題
需求中的功能點要在prd（產品需求文件）中羅列清楚，業務流程要寫得完整清晰，互動細節要體現在視覺稿中。要組織專案組所有成員參加prd評審，評審時要 針對具體的問題，給出明確的處理意見。暫時不能確認的問題，問題跟進人要在限定時間內給出反饋，專案經理可以制定問題跟進**。
專案進行中 的需求變更，盡量在前期提出。在專案管理的過程中，當前期的需求和計畫都確定後，專案經理不能只顧著跟進開發和測試的進度，也要階段性地和需求方多溝通， 讓他們及時反饋意見。不要等到臨發布時，產品經理跑過來說「我要的不是這樣的，這裡要改一下」。永遠不要把問題留到最後一分鐘，要超前一步，留有餘地。下 面是乙個真實的案例。
案例情景：該項目的整個週期為2個月，有3**能測試。當第3**能測試結束時，也就是即將進入預發布階段時，產品經理才給出使用者反饋並要求按使用者的反饋修改。改動的地方涉及到頁面的樣式、文案、sql語句和校驗邏輯等，總共可能有20多個檔案要被改動。
專案經理建議只改頁面的樣式和文案，其他部分先不要改，等下次公升級維護時再改，否則可能會影響發布。而在多次交涉無果的情況下，開發人員只能硬著頭皮修改，測試人員只能再重新測一輪。雖然大家努力地按需求方的要求做了，但專案延期已不可避免了。
常見的原因之溝通不暢
為某專案臨時組建的團隊往往來自不同部門，團隊成員之間不熟悉，此時，要為團隊建立乙個溝通通道，確保溝通順暢。常用方式為：
作者浦薇娜，天貓（****）核心系統負責人
文/白天
軟體開發的專案週期大體分為3個階段：獲取需求和定義產品、開發和測試、部署和運維。
在獲取需求和定義產品階段，需要防止 的不是進度太慢而是過快、過草率。特別是對於創業公司的產品經理來說，很可能因為看到開發人員無事可做而感到壓力，所以盡快完成產品定義，而沒有充分了解 市場和競爭對手資訊，沒有與合作夥伴充分溝通，沒有做深入的思考。
這些因倉促而隱藏的問題，發現得早則導致開發階段大量返工，發現得晚則導致產品上線後不 受歡迎。常聽一些人說現在網際網路開發，講究快速迭代和敏捷，邊做邊想，返工也正常。這是乙個誤解。快速迭代指的是將不同版本之間的週期縮短，小步快跑，而 不是在乙個版本的週期內來回折騰。
在開發和測試階段，專案管理重在跟蹤進度和保持溝通—用整合和演示跟蹤進度，基於bug溝通問題。
要做到各個模組外部介面相對清晰穩定，並盡早完成各個模組間的整合，最晚不超過開發周期的1/4時間。第一次整合之後，就應該開始每日整合和每週演示。每日 整合使得測試團隊每天能同步測試最新的**，幫助開發團隊盡早發現問題並及時了解技術細節上的進度；每週演示使產品經理、專案經理和管理層能從使用者的角度 感受產品，使他們對產品有信心。整合和演示是專案管理的心跳，合理利用它們，有助於及時把握專案的健康程度。
無論開發流程多敏捷，工程師能 力多強，記錄和跟蹤bug都是必不可少的。開發團隊和測試團隊的溝通都應該基於bug，才能言之有物。開發工程師每次提交**都應該記錄是針對哪個bug 的，每日工作演示文稿都應該寫今天關/開了哪些bug。要在每日晨會（站著開，一般15分鐘內）時說好，今天打算解決哪些bug，其中有哪些點不清楚，需要和 誰溝通。
在後期部署和維護階段，要快速響應。考驗的是團隊成員的責任心和抗壓能力。系統運維工程師要深夜工作，因為部署可能要在流量低的時 候進行；專案經理要保持能隨時溝通，做出快速而準確的決定，鼓勵團隊並做出表率；一旦出現高危害bug，開發團隊要在24小時內準備好補丁。amazon 的做法比較有趣：在產品剛上線一段時間內，開發工程師要保持24小時開機。如果自己負責的模組中出現高危害bug，那麼很可能會在深夜被系統運維工程師叫醒。這樣不僅能保證快速響應，還能讓工程師意識到：前期**不好好寫，後期就別指望能好好睡覺了。
作者白天，北京合輝資訊科技****ceo
文/李晨旭
專案管理的目的是能夠按照預定的成本、進度和質量要求順利地對人員、產品、過程和專案進行分析和管理。在專案管理中，有些細節需要引起專案經理的重視。
根據經驗規劃
即先做少量的規劃，再根據實踐過程中得到的資訊來做進一步的規劃，這樣可提高專案的可行性。試圖**未來的規劃很難奏效，除非你是個預言家，否則應該盡量在專案中根據經驗做規劃和日程安排。
安排專案日程
首先，要按可交付物安排日程，而不是按功能；其次，要以迭代的方式安排日程；再次，要使用難度較低的工具安排專案日程。過度追求完美的專案時間表可能意味著在實際專案中浪費更多的時間。
足夠的時間規劃
日程安排是由整個專案團隊共同制定的，因此，每個人都要對日程有信心。不過，天有不測風雲，總會發生點兒意外，所以我們要做足夠的時間規劃，而且要使用波浪式規劃，這樣才可以隨著環境的變化靈活地更新日程安排。
管理會議
在組織專案時，專案經理要盡量避免浪費時間的會議。要讓團隊將注意力集中在專案上，這是最簡單、最有效的方式。在幫助團隊朝著合理的交付截止日期前進時，要 保證團隊不受外界干擾和影響。如果會議對於任何人都毫無價值，那就取消掉；同時准許團隊成員不參與無法貢獻和收穫價值的會議。也許有些團隊成員會不高興， 認為你覺得他們不夠重要從而不能參加會議。要跟他們解釋清楚，你不讓他們參會是因為他們太重要了。
速度圖
如果只能繪製乙個圖表，那就選擇速度圖。速度圖集三種度量方式為一身：需求、已完成工作和時間。雖然無法從中看到自己希望了解的缺陷率或成本，卻能從該圖中 對專案的整體進度有所掌握。使用速度圖可以使你在一張圖中同時度量多個趨勢：整體需求數量和已完成工作，其中包括所有的測試、文件以及專案需要等其他內 容。這是最有用的圖表，是專案經理的好朋友。但要注意，速度圖只是獲取資料的工具，不是目的。
測試
從專案開始就要堅持「減少技術債務」的原則，讓測試與開發同步進行。測試會將專案的風險展現在眾人面前，大家越早看到這些風險越好。在採納順序式生命週期的 專案中，要讓測試人員參與到需求分析階段，詢問他們關於產品需求的反饋；在採用迭代式生命週期的專案中，要請測試人員幫助評估原型；使用增量式生命週期的 專案，只要有可供測試的部分，就可以讓測試人員盡早開始測試功能；在實施敏捷的專案中，要確保測試人員與開發人員一起工作，以開展技術層面的測試。同時， 還要讓測試人員與產品負責人一起，編寫面向客戶層面的測試。
作者李晨旭，方順攀藤（北京）網路科技****研發中心經理
專案延期原因及應對之道
每個專案經理都希望能有效地控制專案進度。但這件看似簡單的事情，實際操作起來卻常常不盡如人意。即使在成熟的大公司裡，有著完善的專案管理流程，配備著一流的團隊，專案延期事件還是頻頻發生。這裡分析主要的三個原因。常見的原因之計畫不清 很多專案經理，計畫做得很漂亮，卻總是計畫趕不上變化。原因 在於，有些時候...
專案延期的4大原因及解決方案！
專案從啟動到收尾涉及到的工作非常多，在過程中的某一處因為某個原因可能便會導致專案延期 一 前期評估偏差 評估偏差，由於專案成員經驗不足或者粗心大意沒有詳細了解專案內容，乙個月的工作量可能評估了20天，那麼專案延期是必然的。在專案成員經驗足或者不足的情況下，都需要去詳細的過一遍專案內容，沒注意到的乙個...
專案進度延期的關鍵因素和應對措施
任何乙個專案或多或少都會遇到某些環節的進度被延遲的情況，所以如何確保專案按計畫計畫進行，成為了專案過程中的乙個重點。當專案進度延期我們要搞清楚專案是因為什麼原因延期的，一般專案延期主要是因為專案進度本身制定不合理，另一方面是來自於專案團隊人員方面的，對於進度延遲時候應該首先分析專案進度計畫安排本身是...