愛辦公是企業資訊化統一融合平臺，是一整套完善的企業移動雲辦公系統，功能涵蓋雲OA、雲通訊、雲郵局、雲CRM、人力資源管理、企業雲盤等，能夠一站式服務企業辦公所有流程，實現辦公協同化、辦公移動化，是公司提升辦公效率，實現資訊化管理不錯的選擇。

　　愛辦公依託強大的全雲能力，不僅將企業常用的辦公應用整合到統一平臺，並且在雲端實現了靈活的擴充套件，打通了資料層的共享，實現管理和應用分離。響應現代企業資訊化構建的趨勢：去中心化構建，降低運營壓力和成本，實現靈活擴充套件；打通資料層，實現企業大資料分析。

　　統一平臺的優勢：

　　統一平臺的部署成本，遠遠低於一個個業務模組單獨部署的成本；

　　統一平臺帶來相同的操作體驗，各業務模組間的互通性更好，大大節約培訓和使用成本；

　　統一平臺的各模組資料互通，大大降低了企業資訊化成本和資料維護；

　　融合平臺的優勢：

　　企業之前部署的業務平臺可以快速被融入，不需要推到重來，歷史投入不浪費；

　　企業之前的資料不會丟失，可以遷移到融合平臺，歷史積累不浪費；

　　融合平臺擴充套件性更強，可以根據業務發展需求，靈活加入新應用；

我們團隊現在使用的是億圖專案管理軟體，透過日曆標記工作時間和計劃時間，首先用工作分解結構圖對專案進行分解，分工；然後用關係矩陣圖理清所有專案的承接，提高效率；使用質量功能部署來提升專案質量，時間線貫穿整個專案的管理。

今日完成事項：從一個工作者的一天來說，今日完成事項，應該是前一天、或者這一天的早上就已經合理規劃完畢，經過一天的工作，你只需要把完成的打鉤，然後整理到狀態表上即可。

今日計劃完成但是未完成事項，要詳細寫上，然後分析原因，並且通知可能涉及的其他同事，以免造成不便。

遇到問題就勢必會有解決方法，主動工作是提升自身能力的最好工作方法。講你所嘗試的方法反饋給管理者，一方面能得到有用的指點，避免走彎路；另一方面也會給人留下積極工作的印象。

明日的計劃：透過今日的記錄、整理、反思，結合整個專案的進度安排，按照要事為先的原則合理安排第二天的程序。

這樣的記錄既能充分體現每個人的工作狀態，又能層次分明地向傳遞工作困難和工作能力。億圖管理軟體讓團隊工作視覺化，讓每個人的日程和團隊的工作安排打通，實時跟進。很多專案管理人問地址，地址：http://www.edrawsoft.cn/download-edrawmax.php。

專案進度管理，不是日曆管理，也不是任務鏈管理，而是關鍵路徑管理和需求表更管理。這是一個系統工程學科，不是一兩個視覺化工具就能替代的。

專案進度控制管理，是指採用科學的方法確定進度目標，編制進度計劃與資源供應計劃，進行進度控制，在與質量、費用、安全目標協調的基礎上，實現專案目標。在專案過程中，必須不斷掌握計劃的實施狀況，並將實際情況與計劃進行對比分析，必要時採取有效措施，使專案進度按預定的目標進行，確保目標的實現。

專案進度控制是專案經理的一項重要職責。俗語說的“時間就是金錢”在這裡體現得再明顯不過了。專案管理和自駕車回老家過年是相同的，實際上按照專案的定義，“自駕車回老家過年”也是一個不折不扣的專案，只是它更貼合大家的生活，更容易引起共鳴，我們就拿它來做例子說明。

　 從乘客的角度，如果坐車很久，但是沒有達到預期的目的地的時候，就會產生疑問，一般都會去詢問司機“到哪裡了”，如果司機的回答沒有那麼令人滿意，這個疑問就會積累。積累到一定程度，就會開始懷疑是否迷路，如果這個疑問一直無解，最終就會要求停車問路。如果坐的是計程車，就會導致乘客下車，換車繼續前進。

　　專案進行過程中同樣如此，因為軟體專案的“不可見”特性，客戶心理更脆弱和不穩定。如果每次專案經理給出的進度都是無法驗證的，客戶的疑問就會積累，最終到無法忍受而爆發。

　　人對一個事物的完成都會有自己的“心理預期值”，這 個值會隨著人對該事物的瞭解的加深而進行調整，並變得越來越準確。乘客坐車到目的地，如果他對路線熟悉的話，一般都會跟蹤一些關鍵的地標和時間的對應關係。比如從南山科技園到深圳火車站，一般用時不會超過1小時，開車走深南的話，肯定會經過世界之窗、市民中心、帝王大廈，最後到火車站。如果在晚上8點出發，過了半小時都沒看到世界之窗，乘客會怎麼想?

　　專案也是如此，客戶的心理預期就是專案“里程碑事件”的到達時間。專案經理制定專案的里程碑，目的之一就是去影響客戶的心理預期。但是這種行為是一把雙刃劍，會影響客戶的心理，同時也會對專案構成約束。

　　實際上，專案進度表現在兩個程度，一個是微觀的層 面，這個層面上，所有的事情都是一個一個的task，一個專案下來，有成百上千個task要去完成，這個層面是專案經理和專案組員關注的，是最準確的進度 描述;另一個是宏觀的層面，這個層面是客戶以及專案外部的干係人所關注的，每一個進度都是一個“里程碑事件”，這種層面的進度描述並不是十分準確。

　　依然從心理角度去分析，專案經理給出的進度有誤差是肯定的，關鍵是和現實的落差是否在範圍之內。如果客戶持續覺得專案的進度描述是準確的，那麼對專案也就越有信心，對專案的支援也就越好，對失誤的寬容度也越高。反之，如果對專案進度沒有信心，那麼就會對專案施壓，對失誤的處置也會越嚴厲。

　 如何把握進度和進度的報告，常用的方法有“堵”和“疏”。所謂的“堵”就是隱瞞，專案經理可以進度造假造得很漂亮，但是到最後交付不了，就會被修理得很慘;而”疏“則是如實彙報，讓專案干係人透明地掌握專案的主要細節。實踐中，很多專案經理採用了折中的方法，有些如實彙報，另外一些則隱瞞起來，避免不必要的麻煩。但是實際上，專案經理“說真話”是要有一定能力的。

　　首先是專案組實際的完成能力，通俗點就是每天、每週最多能完成多少任務，如果專案經理和客戶都知道這個速度，客戶就不會提出過分的進度要求，專案經理也可以拒絕所有超出能力的進度要求。這個“能力”其實就是專案經理“Say No”的底氣來源。現實中很多專案經理因為不知道團隊真實的能力，胡亂應承，結果害了自己，也坑了團隊。

　　其次是“專案進度的預測能力”，如果專案經理給出的完成時間每次都能做到，他以後的專案工作就會越來越順暢。許多專案組和客戶的衝突，起因大都是因為進度預測不準，甚至無法預測進度導致的，進度再一再三地突破客戶的心理預期，想不讓人發飆都不行了。

　　在專案實戰中，專案進度的評估和預測非常不容易，但是並不是完全做不到的。我們可以反過來看，從專案結項的那一刻開始。在結項時刻(算上變更之後的)，專案的進度毫無疑問是100%，往前推一週，我想進度是可以預測的，但是往前推一個月就會模糊一點了，越往前越模糊。換言之，專案的進度預測是隨著專案的進展而越來越清晰的。

對於這個問題，齒輪君認為，萬事皆有因，從因出發，能更好的導向“果”。我們得先給專案管理程序排雷，讓路好走一點。本回答思路適合極大部分的專案經理，不同行業、產品請結合實際進行操作。

專案策劃時，準確評估專案開發週期

首先，我們要確認這個問題的目的，也就是剛才我提到的“是什麼”！正確評估時間是為了讓我們預估風險，已保證按時高質量的上線。所以在回答之前我們需要先明白，都是哪些因素影響了開發開發的週期：

專案成員對需求的理解不一致（50%）：產品／專案經理要實現的功能是否很完整的展示給其他成員，互動也有體現到位還是僅僅是口頭描述，PRD中是否有清楚描述邏輯和規則？異常經常和邊界條件未考慮充分（20%），是不是隻考慮主流程或者只考慮本功能流程，其他關聯功能要不要同步處理？資料統計需求有沒有考慮進去？新功能線上後原來的資料要不要清理和同步？表單的邊界條件、報錯、為空等邏輯呢？開發成本太高（20%），產品這些要求是否真的合理？有必要做到這個地步嗎？是否可以請自己的leader或技術leader一起討論評估成本呢？對風險的預期管理是否到位（10%）：需求變更和臨時需求（後面會具體談到）、人力變更（請假、節假日和人員流失），這些都需要靈活應對。

對於專案策劃這一部分，總覽全域性，預先控制風險變數，才能更好保障專案進行。

高效專案進度管理方法評估、選取，請看齒輪君以往的回答，在此不再贅述。

專案進行中，在排除技術因素後，如何調節不可控的團隊溝通風險？

協調團隊內不同角色的意見，尤其是領導的想法

首先，齒輪君認為產品／專案經理有一項非常重要的能力，那就是換位思考：做產品的時候要站在使用者角度考慮他的需求場景，對吧！同樣的，與人溝通也需要換位思考，對方為什麼有這樣的意見，他要表達的真實意圖是什麼？大家是不是隻是說法不一樣，但要的目的是一樣呢？

那為什麼大家會有不同的意見，那是因為：

每個人無時無刻都在用產品，所以對於功能和產品就會有自己的使用體驗和理解，換個角度就是“人人都是產品經理”不同人的背景、使用習慣和場景造成對功能的理解、優先順序的認定和需求滿足度不一致，所以判斷標準也就不一樣在人性中，人天生是以自我為中心的，潛意識認為自己理解的便是全部事實

當不同的人有了意見之後我們需要考慮：

想清楚對方的意見背後動機，也就是他要的是什麼根據對方的目的判斷這個意見的優先順序：是純個人看法還是好的功能建議？是純粹為了表現自我獲得認同感還是故意挑刺？是比自己想的周全還是在瞎扯?好的建議和想法就採納，純粹想個人表現那就適當奉承，對功能的理解不一樣那就回到大家的目的和場景去推導，這樣大部分情況就都可以處理掉了。實在沒法平衡，那就請求各自的上級一起加到討論，或用事實和資料做驗證，有條件的大家可以做A/B test。

這些方法同樣適用於領導或老闆，也就是想清楚他要的是什麼。如果你始終覺得這個老闆有點二，那就換一家吧。時間寶貴，不要在無謂的溝通上浪費時間。

產品／專案經理如何在專案中有效管理進度，避免專案推遲上線

管理好風險，如需求變更和人力資源的變動。

站在全域性考慮問題，必要時可以先縮減需求以保證上線，因為後續會持續迭代。

使用適合自己的公司的敏捷的專案管理方法。

專案管理中有兩大比較突出的模型，一個是瀑布式，另一個就是我們常說的敏捷式。

瀑布的主要是特點是根據專案的工作內容進行了階段切分，如需求分析、概要設計、詳細設計、程式碼內部開發、功能測試、釋出上線等。各個階段之間是線性推進的，即只有上一個階段基本完成後才推進到下一階段。這裡的專案週期就是所有階段的週期之和。

另一個模型是敏捷，也就是我們常說的快速迭代，小步快跑。敏捷的關鍵點是迭代和並行，在敏捷中，將產品功能拆成足夠小的單元同時推進，這樣可以大大降低時間週期風險。因為哪怕某個單元出現延遲，其他單元也可以先上線（當然這些單元是可以獨立拆分上線的，如果邏輯緊密那就要小心了），這樣也就實現了快速迭代，從另個角度解決了推遲上線的問題。

最後各位專案經理和產品經理還要注意一個很常見的現象：版本開發中出現頻繁的需求變更時要謹慎處理。具體處理方式可看齒輪君其它的相關回答，在此不再贅述。