2.1

專案管理-套路

把複雜的問題簡單化-任務分解

把簡單的問題數量化-明確目標

把量化的問題專業化-技術方案

把專業的問題標準化-建立模板

專案管理四個部分-源自專案的四個生命週期

啟動專案

計劃專案

實施、跟蹤和控制專案

收尾專案

2.2

啟動專案

需要明確的：

專案需求（範圍、做且僅做）、專案目標（為什麼做）、專案價值（做了有什麼好處）、專案干係人（誰說了算）、專案環境因素（其他一切）

專案案例1：

某資訊化平臺建設專案處於專案初期立項階段，作為專案經理的你，協同產品經理和客戶進行了多次的需求討論會議，

客戶並不是實際平臺的管理者和操作者，導致需求收集會議每次都成為方案的彙報會，每次客戶並不給出同意或是不同意的結論性意見，只是一味在專案設計細節上進行討論，作為該專案的專案經理你應該怎麼辦？

專案經理：

進行專案的干係人分析

與專案的客戶進行溝通，明確客戶的職責和定位，爭取到客戶的支援

通過客戶的協助，接觸到最終平臺使用使用者和管理使用者，以及充分聽取客戶的管理需求，從而完成需求的收集

專案案例2：

某APP專案處於專案實施階段，由於前期未做相應的業務設計評審，就按照業務部門老大的想法進行了專案實施，在專案的後期實施過程中，業務部門的實際介面人發現按照業務部門老大的想法，在業務流程中有很大的漏洞，隨即提出推翻現有的業務設計，進行延期上線處理。而運營的老大，出於運營活動的需要，不能在業務修改後再進行上線，要求你必須就這個版本進行快速處理，儘快上線，作為該專案的專案經理你應該怎麼辦？

專案經理：

首先針對業務和運營的新功能上線矛盾點，儘快召集相關方進行一次會議，主旨在於達成解決問題的共識（很可能雙方進行PK）

對於前期業務沒有評審的漏洞，儘快梳理業務的新的需求，在結合產品經理進行了充分的論證前提下，儘快推動進行相關方參與的業務方案評審

與運營老大進行協調，可採用減少需求來確保上線功能的方式進行

專案案例3：

某論文專案處於新功能的開發階段時，前期產品經理離職，並且在離職時與新的產品經理進做了口頭上的快速交接。在新功能進行驗收的過程中，專案經理和新的產品經理髮現，現有版本的需求和團隊開發出的功能存在極大的差異，而且，現有的專案需求也不完整，很多業務功能都沒有包含到版本中。作為該專案的專案經理你應該怎麼辦？

專案經理：

首先停止現有版本的發版，團隊和產品經理進行梳理，現有版本和需求的差異範圍

儘快協調產品經理進行需求的確認，確保客戶需求點沒有缺失

協同產品經理儘快進行產品原型的補充，確保本次上線的版本需求一致性

專案需求：（區別於產品經理的關注點）

客戶的真正需求（可量化的點、質量、效能、指標、價格、範圍等等）

我方能做什麼（能力，上限，達不到的）

專案有價值麼（是否符合公司（組織）的戰略意圖）

專案需求一般體現在功能和技術兩個層面

需求完成的條件是：

對需求進行記錄和相應的詳細描述

獲得終端使用者的確認，且由驗收人進行確認

在專案的利益相關人員之間達成共識