1. 程式人生 > >項目計劃定制:項目計劃劃分與產品項目推進的有機結合

項目計劃定制:項目計劃劃分與產品項目推進的有機結合

描述 text 指數 級別 標記 周期 自己 方向 思考

目錄:

  • 第一章:導語
  • 第二章:需求采集部分的一些要點
  • 第三章:項目中一些需要明確的內容
  • 第四章:關於成本管理部分

第一章:導語

那麽什麽叫項目,項目計劃和項目管理?

項目管理簡稱為PM,是project management的縮寫,直譯就是項目 管理方法。其國際標準化驗證為PMP。其中考核內容以時間管理,資料管理,進度管理等管理學科為主,產品及需求了解為輔助進行。

整體上根據生存周期的階段共分“需求”“可行性”“規劃”“設計”“建造”“測試”“移交”七個部分,交互進行;但從項目管理角度我們簡單分割為“關鍵概念確認”“啟動項目準備”“規劃”“執行”“監督”“結束項目”六個大範圍進行管理。當然這其中也包含一定的細節,這裏我們會慢慢的在今後的培訓中和大家交流整理

技術分享圖片

技術分享圖片

那麽回到正題,我們今天主要說的是項目計劃的制作方法,其最主要的方式方法事實上並不是從我們制定項目計劃開始的,而在這之前我們就必須進行多方面的準備,可以說追溯起來,一切的起源在產品的需求采集階段就已經開始了

項目計劃主要包含如下一些信息:

  • 約定並通過雙方同意的內容
  • 信息源的粗細度劃分
  • 明確的內容分割
  • 驗收標準的明確性

    約定並通過雙方同意的內容

項目中“約定並通過雙方同意的內容”主要包括在《項目規章》或《項目章程》中進行界定或明確。例如是否符合國家法律,是否涉及國外行業等都是用以劃分內容,和內容邊界具體說明,這裏便不做重點描述

信息源的粗細度劃分

信息源的出席度劃分事實上就屬於比較重要的範疇,因為這裏的產出會直接關系到整個項目的走向,計劃的制定,重點部分的明確甚至是測試及驗收階段都有著至關重要的作用。

今天,我分享的內容也主要是針對這以一個方面

第二章:需求采集部分的一些要點

一、需要先明確我們要做的是什麽?

當產品經理采集完成用戶的需求之後,我們並不是就可以認為已經完成了,然後按照這個進行原型圖的設計了。事實上在這裏我們缺失了最重要的一個環節,而缺失的原因實際上很簡單,這部分工作對產品來說並沒有任何的意義,反而會增加工作,而對於之後的項目工作來說卻至關重要,這就是——需求粗細度劃分確認。

技術分享圖片

二、如何管理需求粗細度劃分—-產品經理的工作要素

簡單來說,對收集上來的需求,按照權利(需求方要求),價值(技術側重)的評估級別進行對應的分割和明確,一般我們利用二線四項圖來進行明確的區分和判斷。

舉個例子方便大家思考:

我們需要做一個PIAZZ,那麽我們需要如下材料:

餐桌,蘇打水,煤氣/電爐子,烤箱,火,披薩面團,番茄醬,配菜,奶酪

然後我們的需求方進行排序:

  1. 披薩面團
  2. 奶酪
  3. 配菜
  4. 烤箱
  5. 番茄醬
  6. 其他(利益引導)

我方“廚子”要求:

  1. 披薩面團
  2. 奶酪
  3. 烤箱
  4. 煤氣/電爐
  5. 番茄醬
  6. 其他(開發需求引導或可行性引導)

那麽我們可以得到如下圖形

技術分享圖片我們不難看出,雙方都關註的部分是披薩面團,奶酪,然後還有各自重視的部分,因此區分完成後,我們可以根據對應的需求方面擬定此方向的運作及具體內容的安排

那麽一定有人要問,為什麽我們需要這部分的資料呢,因為這有了這部分資料之後我們才能夠明確我們的項目到底是個什麽類型的產品,按照各自不同來說在行業裏面我們一般將其分為ON-PREMISES,IAAS,PAAS和SAAS以及整合型IPAAS類型產品

好吧我們依舊用上面的例子告訴大家具體的區別,使用不同的類型,會有不一樣的思路和解決方法。

技術分享圖片

技術分享圖片

技術分享圖片

技術分享圖片

IaaS: Infrastructure-as-a-Service(基礎設施即服務)

有了IaaS,你可以將硬件外包到別的地方去。IaaS公司會提供場外服務器,存儲和網絡硬件,你可以租用。節省了維護成本和辦公場地,公司可以在任何時候利用這些硬件來運行其應用。

一些大的IaaS公司包括Amazon, Microsoft, VMWare, Rackspace和Red Hat.不過這些公司又都有自己的專長,比如Amazon和微軟給你提供的不只是IaaS,他們還會將其計算能力出租給你來host你的網站。

PaaS: Platform-as-a-Service(平臺即服務)

第二層就是所謂的PaaS,某些時候也叫做中間件。你公司所有的開發都可以在這一層進行,節省了時間和資源。

PaaS公司在網上提供各種開發和分發應用的解決方案,比如虛擬服務器和操作系統。這節省了你在硬件上的費用,也讓分散的工作室之間的合作變得更加容易。網頁應用管理,應用設計,應用虛擬主機,存儲,安全以及應用開發協作工具等。

一些大的PaaS提供者有Google App Engine,Microsoft Azure,Force.com,Heroku,Engine Yard。最近興起的公司有AppFog,Mendix和Standing Cloud.

SaaS: Software-as-a-Service(軟件即服務)

第三層也就是所謂SaaS。這一層是和你的生活每天接觸的一層,大多是通過網頁瀏覽器來接入。任何一個遠程服務器上的應用都可以通過網絡來運行,就是SaaS了。

你消費的服務完全是從網頁如Netflix,MOG,Google Apps,Box.net,Dropbox或者蘋果的iCloud那裏進入這些分類。盡管這些網頁服務是用作商務和娛樂或者兩者都有,但這也算是雲技術的一部分。

一些用作商務的SaaS應用包括Citrix的Go To Meeting,Cisco的WebEx,Salesforce的CRM,ADP,Workday和SuccessFactors。

也就是說,不同的產品的類型會直接影響我們在產品設計及項目裁剪的明確方向和界限,因此,在項目計劃中起到了至關重要的作用。

人話就是:你要去旅遊,你坐車去旅遊,你和你的小夥伴坐車去旅遊,在這3句話裏面,你去旅遊才是核心的部分。那麽就要優先完成核心部分,項目計劃粗細度,還有側重的確認方法。

第三章:項目中一些需要明確的內容

如何規劃進度,如何使用以上信息進行操作,這裏將進行詳細描述

步驟1.區分需求嚴重性

我們一般通過使用二縱四項圖標對需求及內容的優先級及投入重點,具體樣式及使用方法如下:

通過合理的拆分和裁剪,可以更好的優化項目優先順序,更好的提供界定參考,規劃方案。

用人話來說,就是需求分主次還有ROI,而這個雙方的立場不一致,需要溝通確認,而核心需求和功能基本上是大家認可的,在項目預備中,確認了核心需求和功能,是可以先做一些框架性的部署。

技術分享圖片

步驟2.通過評估標準進行輸出界定裏程碑,活動及活動關系

進度管理計劃是項目管理計劃的重要組成部分。它描述了管理進度的過程的流程,包括如下指標:

  1. 將用於制定進度模型的進度方法和工具
  2. 準確度(這將包括項目進展)
  3. 計量單位(小時、天、周)
  4. 控制臨界值,例如當機遇浮動或者緩沖而采取的預防措施或糾正措施預案及可行性
  5. 度量方法。例如進度偏差(SV)界限或進度績效指數(SPI)
  6. 制定網絡圖的指南
  7. 資源的可用性和持續時間估算的估算方法
  8. 進度狀態報告的頻率和格式

通過以上指標進行界定,可以進行工作分解結構(Work Breakdown Structure,即WBS)

利用分解或滾動式規劃進行分解,最終可以產出如下資料:

  • 活動清單(任務列表)
  • 活動屬性(任務完成要求)
  • 裏程碑清單(界定小實現周期)

活動清單包括:範圍基準

範圍基準包含:

  • 項目範圍說明書(項目章程內已經制定)
  • WBS包
  • WBS詞典

活動屬性包括明確的WBS屬性及額外信息

活動屬性包括:

  • 活動標識符或編碼(WBS編碼)
  • 活動名稱(WBS任務名)
  • 活動描述(WBS任務描述,及完成條件描述)
  • 緊前或緊後活動(前置WBS任務,引發WBS任務關聯)
  • 邏輯關系(WBS隸屬關系)
  • 提前量或滯後量(WBS評估完成進度)
  • 強制日期(WBS強制完成日期)
  • 制約因素
  • 假設條件(觸發條件)
  • 所需要的資源和技術水平
  • 履行地理位置(履行人或組織)
  • 投入類型(投入資源模式或力度)

裏程碑清單:作為每一個生存周期階段的開始和結束、關鍵可囧付成果的完成、通過某個標桿對照或測試,或者獲得正式簽字同意驗收。

每一次裏程碑的界定,都要再次界定當前階段活動的需求、風險、成本和其它項目管理計劃中需要更新的部分,具體參考《活動屬性》表

活動屬性表如下:

技術分享圖片

步驟3.利用以上信息,明確項目內裏程之間的關聯關系

一般通過網絡圖進行調整:

技術分享圖片

網絡圖內的區域概念:

區域描述

  • 綠色區域:當前模塊內任務執行的順序(A~G)
  • 藍色區域:某些任務需要的附加條件或緊前活動(F)
  • 紅色區域:緊後任務配合產出

整個流程完成了當前裏程碑的研發進度計劃及發展方向

技術分享圖片

關於其中的一些字符的介紹

  • FS-2d:在活動A完成和活動C的開始之間有2天的提前量
  • +2d:在活動的完成和活動D的開始之間有2天的滯後
  • SS:E和F之間有開始——開始(SS,即同步開始)關系
  • FF:G和H之間有完成——完成(FF,即同步完成)關系

其它沒有標註的關系都是完成——開始(FS)關系

步驟4.項目活動周期時間估算

大多數發起人和客戶傾向於激進的估算,它們希望項目更快更好的完成。但是如果你的估算古語激進,你將在開始的時候就落後於計劃,並很難趕上。更激進的估算,在整個項目進度運轉的過程中都有很高的風險,因此預算也會無法衡量,造成整個項目的不可控和不可評估狀態的出現

那麽我們應該如何評估項目的活動周期時間甚至是成本,這就成了每個項目管理這必須要掌握的部分

一般來說一個準確的活動周期估算,是需要有穩定的核心團隊作為基礎,配合相關數據形成可行性預估,其他相關數據材料包括:

  • 季度管理計劃
  • 活動清單
  • 活動屬性
  • 活動資源需求
  • 資源日歷
  • 項目範圍說明書
  • 風險登記冊
  • 資源分解結構
  • 事業環境因素
  • 組織過程資產

而後通過專家判斷,同類對比估算,參數估算,三點估算,群體決策技術,儲蓄分析能力進行等方法進行分解後得到我們所需要的數據

這裏將著重介紹其中的一種方法:

類比估算法(RERT估算)

類比估算法采用標準化計算方式,簡略估算“行業價值”及“期望持續”等標準化基數

公式如下:(最樂觀+最可能*4+最悲觀)/6

舉例:你需要出差去上海,機票是596一張,然後你查詢特價時票價為300,緊俏時期價格達到過700,那麽可以期待的票價應該介於396~596之間。這裏請註意你期待的價值並非最終的實際價值,但是可以依據此類進行倒推甲方的期待價值及項目各個階段可以接收的時間周期範疇

同樣的,在計算項目周期時我們也可以如此計算

例如:一個功能,如果1個人實現,那麽需要7天(每天8工時)。如果2個人,需要3天(每天8工時)做完,如果3個人2天可以做完(8工時)

那麽計算工時可以使用此為標尺進行計算:

(8*7+8*2*3+8*3*2*4)/6=(56+48+192)/6=49.34工時

可以確定最好的配置時間方案為2人3天完成

步驟5.制定進度計劃

依據以上的信息進行規則處理後,我們可以得到如下具體的一些信息:整個項目需要執行的過程和單個節點所需要的時間及周期,於是在這裏我們可以初步的制定相關的進度計劃,這裏我們將繼續使用到網絡圖概念完成

技術分享圖片

首先我先需要制定任務卡片,卡片樣式如下:

其中ES=最早開始日期,EF為最早完成日期;LS為最晚開始日期,LF為最晚結束日期

任務編號與WBS包中的任務編號保持一致,預計時間為之前評估完成時間(具體參照步驟4)

然後我們需要對整個項目網絡圖(參照步驟3)進行“最早”(期望)條件預估,變形為:

技術分享圖片

之後我們進行進一步的完善進行“最晚”(底線)條件預估,變形為:

技術分享圖片

最終產出樣式為下圖(差異點在於自由浮動,以及總浮動的標記說明)

技術分享圖片

其中一些名詞解釋:

  • 浮動:最早(開始-結束)和最晚(開始-結束)之間的數據差異叫做浮動
  • 總浮動:在不延誤項目完成日期或違反進度制約因素的前提下,進度活動可以從其最早的開始日期到當前任務狀態下可以延誤,推遲的底線時間量
  • 自由浮動:在不延誤任務今後活動最早開市日期或違反進度制約因素的前提下,某進度活動可以推遲的底線時間量
  • 最早開始日期(ES):在關鍵路徑中,基於進度網絡邏輯、數據日期和進度制約因素,某進度活動未完成部分可能開始的最早時點
  • 最早完成日期(EF):在關鍵路徑中,基於進度網絡邏輯、數據日期和進度制約因素,某進度活動未完成部分可能完成的最早時點
  • 最晚開始日期(LS):在關鍵路徑中,基於進度網絡邏輯、數據日期和進度制約因素,某進度活動未完成部分可能開始的最晚時點
  • 最晚完成日期(LF):在關鍵路徑中,基於進度網絡邏輯、數據日期和進度制約因素,某進度活動未完成部分可能完成的最晚時點

當然在一些必要的條件下,可能需要緊急或者優先保證一部分功能的優先實現,我們一般稱這種狀態為關鍵路徑狀態,通過關鍵路徑發進行表述

技術分享圖片

即無論發生任何工時或活動變化,必須優先保證當前流程中相關內容的實施和完成

依據以上內容,我們可以完整的對項目的具體內容和時間進行劃分,完成劃分後借助

Microsoft Project完成項目計劃的描述制定,並配套跟進燃盡情況,及下發對應WBS任務包。整體進度依據產出結果對比差值為基準,完成項目進度及成本管理

第四章:關於成本管理部分

事實上之上已經完成了對於項目管理中比較重要的項目計劃內容的方法進行了講解,但是如果在實際的設計過程中我們必然會發現一個比較尷尬的問題,為什麽周期只有這麽就,而我們的如何可以有效的有依據的方案給我們的領導層或者業務方,讓其明確周期的必要性和健全性,這裏就必須包含成本管理部分的內容,以此明確人員及項目周期定義的原因

這裏面我們需要提到《項目章程》中定義的幾個必要的元素,它們分別是:投資回報(ROI),回收期,凈掙值(NPV),未來值(FV),內部回報率(IRR)

簡單來說,ROI即投資方需要的回報標準,一般我們依舊利用RERT估算,通過對於產品行業價值進行RERT估算,大致確定其軟件開發成本及配套價值一般來說

  • ROI=評估成本*未來值
  • 未來值=1+投資預期紅利
  • 投資預期紅利=凈掙值/產品投入價值
  • 凈掙值=產品回收期價值-產品投入價值
  • 內部回報率=(ROI-評估陳本)/成本

這裏說的有點多,只是告訴大家對於以上這些內容就是用來轉化產品價值變成周期的具體方法,通過這些轉化,我們可以明確給予我方單位時間價值

然後我們依據自身團隊的價值進行評估,在此周期內,是否可以滿足對應的成本要求,因此進行對應的人員調配

舉例說明:一個披薩的成本是100塊,一個人力得成本是1分鐘5塊。1個需要10分鐘做完;如果2個人得話需要3分鐘完成

那麽計算如下

第一種1個人10分鐘完成

凈掙值=100-(1*5*10)=50

那麽第二種2人3分鐘完成

凈掙值=100-(2*5*3)=70

那麽第二種方法就是更加高效得。

經過以上得計算和整理,我們可以直接將成本管理明確得提上管理得直觀層面,更加好的保護自己得利益,當出現需求變更及大改時,我們能夠在通過評估周期後給予對方成本或者周期得投入選擇,進而讓業務方更加明白我方得價值。同樣通過對於成本得把控,更加優化團隊,提升效率起到一定得幫助。

項目計劃定制:項目計劃劃分與產品項目推進的有機結合